我正在处理遗留代码。
要修复一些错误，我必须给一些文件提供 EHa。我测试了在构建时为整个项目同时提供 EHsc 和 EHa。这解决了我的问题，但警告说编译器正在用 EHa 覆盖 EH。 （选项顺序为：/EHsc /EHa） 只有在构建需要 EHa 的文件时才会出现此警告。它不会出现在只需要 EH 的源文件中。
<name of the file that needs EHa>\cl : warning D9025 : overriding '/EHs' with '/EHa'
我的问题是，这个警告是否说明了实际发生的情况？ EHa 是否仅应用于实际需要 EHa 的源文件？ （其他不需要EHa的文件是用EHsc构建的吗？）
谢谢。
【问题讨论】：
标签： c++ visual-c++ compiler-warnings compiler-options
/EHa 是“更强”的设置。它暗示 /EHsc 但确保即使在抛出和捕获非 C++ 异常时也会调用 C++ 析构函数。 Windows 中的 SEH 异常。简单的 /EHsc 允许代码生成器优化代码并在它看不到括号中的代码抛出 C++ 异常的方法时省略异常过滤器。这种优化不适用于 SEH 异常，例如任何语句都可能引发 AccessViolation。
只有在程序中使用非标准的 __try 和 __except 关键字来捕获 SEH 异常时，才需要 /EHa。 AccessViolation、DivisionByZero、浮点异常、与使用 SEH 处理自己的异常的语言运行时互操作，等等。如果您使用它们，那么您必须确保 all 您的代码是使用 /EHa 编译的。当捕获到 SEH 异常时，错误可能会导致内存泄漏。
【讨论】：
set_se_translator()。并且此功能仅用于少数文件。我想用 EHa 编译使用该功能的文件，并以性能更友好的 EHsc 休息。目前的方法可以做到这一点吗？谢谢
You must use /EHa when using _set_se_translator。几个文件不算。异常过滤器开销在 32 位代码中非常小，在 64 位代码中没有。您是在进行微观优化还是实际测量？
catch(...) 的 SEH 异常——__except itself 根本不应该受到它的影响。当然，在 SEH 的情况下不会运行潜在的 d'tors，但仍应调用 __except 过滤器。
是的，警告会告诉您会发生什么，因为发生的事情可能不是您想要的。这就是编译器警告背后的全部想法。
编译器不知道也不关心哪些文件“实际上需要 EHa”（在文件被编译之前，编译器无法告诉任何关于该文件的信息）。它应用您告诉它应用的选项。您告诉它同时应用这两者，它会告诉您它将此解释为您希望应用 EHA。
在调用编译器时指定每个矛盾的标志不意味着“尝试所有可能的编译器选项组合，直到找到一个可行的组合”。
【讨论】：