Исключения в C++, нужна аппаратная поддержка? (thow, catch, C++, процессор)

[serzh-z]

Тут услышал утверждение, что при использование встроенного механизма исключений в C++ (throw/catch) нужна поддержка со стороны процессора (а также и ОС)...

Учитывая, что это "авторитетное" утверждение (первое, про процессор - второе, про ОС, уже было добавлено адептами ) исходило от человека, который не в первый раз с умным видом пускает окружающим пыль в глаза говоря всякие несуразности о вещах о которых не имеет представления, дико засомневался в верности сего. Как мне припоминается, из соответствующих книг, - механизм исключений в стандарте C++ (я не имею в виду всякие расширения C/C++ от мелкософта для его компиляторов, которые завязаны на API) переносимы и никоим образом не опираются на поддержку процессора и, тем более, API ОС.

Может ли кто-то опровергнуть или подтвердить сей факт?

[Ballantre]

По-моему, это - полный бред. Даже в асме, где все завязано на архитектуре, большинство задач решается на 386 и выше. Действительно пыль в глаза. Может и возможности STL также связаны с архитектурой???
А лучше всего, чтобы развеять сомнения, взять авторитетную книгу, проверенную опытом многих людей, открыть соответствующую главу и попробовать примеры из нее в разных ОС.

[agbr]

Ну да, конечно нужен специальный прецессор, беги скорее в магаз, спроси "микрасофт пеньтивум кори два дува 64бит виста с паддержкой c++"

[serzh-z]

Ну да, конечно нужен специальный прецессор, беги скорее в магаз, спроси "микрасофт пеньтивум кори два дува 64бит виста с паддержкой c++"

М-да, твой ответ определенно не несет никакой информационной нагрузки и не является результатом знания деталей реализации механизма исключений.

[v04bvs]

Поддержка стандартного механизма исключений в С++ не нуждается ни в чём ни со стороны ОС, ни со стороны процессора.

Возможно он имел ввиду микрософтовское расширение С++ - когда например при *((char*)0) = 0; программа не падает в segmentation fault, а порождается С++-ное исключение (если интересно, ключевое слово SEH). Но это абсолютно нестандартный механизм. Для его работы действительно необходима поддержка ОС. Но на всякий случай повторюсь, это не C++, это Microsoft С++.

Любое исключение С++ порождается соответствующим throw , из ниоткуда оно прилететь не может.

[Bruce]

вообще - да - бред

[BlackStar]

Не знаю как реализовано в с++, но в контексте Linux ядра exception - программное прерывание переключающее процесс в режим ядра для выполнения обработчика исключительной ситуации. Примером может служить обработка системных вызов, которая реализуется через exception. Для х86 архитектуры это прерывание определено как машинная инструкция int 0х80. В отличии от аппаратных прерываний, исключительные ситуации возникают синхронно с тактовым генератором процессора.

[e-yes]

Hint.
http://www.google.com/search?hl=ru&cli...1%D0%BA&lr=

Для х86 архитектуры это прерывание определено как машинная инструкция int 0х80

↑

Это вообще для системных вызовов используется, AFAIK.

В отличии от аппаратных прерываний, исключительные ситуации возникают синхронно с тактовым генератором процессора.

↑

Первый раз слышу, чтобы какие-либо прерывания выполнялись не синхронно с тактовой частотой. Видимо, техника шагнула далеко вперед

[BlackStar]

Это вообще для системных вызовов используется, AFAIK.

Совершенно верно. Я привел это как пример (поправил).

Первый раз слышу, чтобы какие-либо прерывания выполнялись не синхронно с тактовой частотой. Видимо, техника шагнула далеко вперед

Что значит прерывание выполняется?

Я говорил о том , что аппаратные прерывания возникают в неопределенный момент времени, например в тот момент когда процессор выполняет комманду.

[serzh-z]

Не знаю как реализовано в с++, но в контексте Linux ядра exception - программное прерывание переключающее процесс в режим ядра для выполнения обработчика исключительной ситуации.

Имелись в виду исключения C++ для информирования вызывающего кода об ошибке (в противовес кодам возврата), а не то которое заставит процессор переключиться на выполнение кода ядра, подкачку отсутствующей страницы и т.д.

[Ballantre]

В С++ есть стандартная библиотека, отвечающая за обработку исключительных ситуаций ( например, неуспешное выполнение оператора new ). Но, насколько я знаю, стандарт С++ не зависит от ОС. Хотя, конечно, мелкософт не рекомендует пользоваться стандартами.

[aLexx programmer]

Хотя, конечно, мелкософт не рекомендует пользоваться стандартами.

↑

Рекомендует, но только своими.

[Ballantre]

Я именно это и имел в виду.

[e-yes]

Я говорил о том , что аппаратные прерывания возникают в неопределенный момент времени, например в тот момент когда процессор выполняет комманду.

↑

Да, но обрабатываются после того, как команда выполнена, т.к команда, вроде как, сама по себе атомарная (с точки зрения процессора) операция.
Впрочем, к теме C++ exceptions handling это всё равно не относится.

...MS + еще много букв...

Microsoftoвское SEH (structured exception handling) к С++ exceptions тоже отношение не имеет. За исключением того, что нельзя их смешивать в определенной области видимости (вроде как у них один и тот же стек для unwinding). SEH - это аналог обработчика сигнала SIGSEGV (и подобных), но, как и большинство костыльных решений от MS, потребовавшее внесений изменений в компилятор.

За исключением того, что нельзя их смешивать в определенной области видимости (вроде как у них один и тот же стек для unwinding).

↑

Вобщем-то догадка подтвердилась,
The C++ standard, like any other feature in C++, doesn't say anything about how exception handling should be implemented. This means that every vendor is free to use any implementation as he sees fit. I will describe how VC++ implements this feature, but it should be a good study material for those as well who use other compilers or Operating Systems [1]. VC++ builds its exception handling support on top of structured exception handling (SEH) provided by Windows operating system [2].

http://www.codeproject.com/cpp/exceptionhandler.asp

Осталось посмотреть gcc для *nix-платформ и выяснить как дела обстоят там