Последствия использования структурированной обработки исключений (SEH)?

Question

Я вижу, что Даг Харрисон сделал хорошее заявление о том, что "не так" с использованием (то есть перехватом) структурированных исключений (см. Вопрос № 3). Но какие еще последствия есть? Например, что произойдет, если у меня есть несколько проектов, скомпилированных с /eha, смешанных с другими проектами, скомпилированными с /ehs? Существуют ли проблемы, когда библиотеки связаны (время компиляции или выполнения) друг с другом?

Но это только один пример. Какие еще проблемы могут быть?

Answer 1

/EHa отключает оптимизацию. С действующими / EH, компилятор может пропустить фильтры исключений, если он может быть уверен, что исключение C++ никогда не генерируется кодом, заключенным в try {}. Это небольшая оптимизация пространства на x86 и x64, очень небольшая оптимизация времени на x86. Проблема в том, что эти фильтры необходимы, если вы перехватываете не-C++ исключения. Следствием этого является то, что стек разматывается, когда такое исключение перехватывается без вызова деструктора объекта C++. Не хорошо, /EHa избегает этого.

Микширование не вызывает проблем с компоновщиком. Это вызывает вышеуказанную проблему.

Да, /EHa также заставляет catch(...) делать очень глупые вещи, они действительно ловят все. Этот корабль потерпел крушение некоторое время назад, хотя обработка исключений в Pokemon C++ тоже плохая идея.