Здравствуйте, _NN_, Вы писали:

_NN>Здравствуйте, lpd, Вы писали:

lpd>>Пример абсолютно бессмысленный т.к. count всегда >0.
_NN>Как раз это и смысл исключения, защититься от случайной ошибки.
_NN>Без него придется писать:

_NN>...
Я вовсе не против C++, кроме последних стандартов.

_NN>Проблемы с C++ там не от использования исключений, а например, от того, что таблица виртуальных функций может быть выгружена из памяти в неподходящий момент.
Вообщем-то элементы ООП в ядре Linux присутствуют — аналог this для структур. Но проблем несколько. Прежде всего процессор для кода ОС является не абстракцией, а всплывают низкоуровневые моменты вроде той же памяти, переключения контекста и прерываний. Посмотрю, как будешь кидать exception из прерывания и кто его будет обрабатывать. Получится, что для существенной части кода будет запрет на исключения, либо смесь чистого C и C++ с переходниками. Все это многоплатформенно. И стоит ли игра свеч? Особенно если учесть, что stl полностью с std::thread не будет.

Здравствуйте, _NN_, Вы писали:

_NN>Здравствуйте, lpd, Вы писали:

lpd>>Пример абсолютно бессмысленный т.к. count всегда >0.
_NN>Как раз это и смысл исключения, защититься от случайной ошибки.
_NN>Без него придется писать:

_NN>...
Я вовсе не против C++, кроме последних стандартов.

_NN>Проблемы с C++ там не от использования исключений, а например, от того, что таблица виртуальных функций может быть выгружена из памяти в неподходящий момент.
Вообщем-то элементы ООП в ядре Linux присутствуют — аналог this для структур, реализованного макросом. Но проблем несколько. Прежде всего процессор для кода ОС является не абстракцией, а всплывают низкоуровневые моменты вроде той же памяти, переключения контекста и прерываний. Посмотрю, как будешь кидать exception из прерывания и кто его будет обрабатывать. Получится, что для существенной части кода будет запрет на исключения, либо смесь чистого C и C++ с переходниками. Все это многоплатформенно. И стоит ли игра свеч? Особенно если учесть, что stl полностью с std::thread не будет.