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

Question

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

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

Answer 1

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

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

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