구조적 예외 처리 (SEH)를 사용하는 결과?

Question

Doug Harrison은 구조화 된 예외를 사용하는 (즉, 질문 # 3 ).그러나 다른 결과는 무엇입니까?예를 들어 / eha로 컴파일 된 다른 프로젝트와 함께 / ehs와 함께 컴파일 된 여러 프로젝트가있는 경우 어떻게됩니까?라이브러리가 링크 된 (시간 또는 런타임에 컴파일) 할 때 문제가 있습니까?

그러나 그것은 단지 하나의 예입니다.다른 문제는 무엇이있을 수 있습니까?

Answer 1

/EHa disables an optimization. With /EHs in effect, the compiler can omit exception filters if it can be sure that no C++ exception is ever thrown by the code wrapped in a try {}. That's a small space optimization on x86 and x64, very small time optimization on x86. Problem is, those filters are needed if you catch non-C++ exceptions. The consequence is that the stack gets unwound when such an exception is caught without the destructor of a C++ object getting called. Not good, /EHa avoids it.

Mixing doesn't cause linker problems. It causes the above problem.

Yes, /EHa also makes catch(...) do a very stupid thing, it really catches everything. That ship wreck sailed a while ago though, Pokemon C++ exception handling is a bad idea too.