我找不到足够的信息来决定我应该使用哪个编译器来编译我的项目。模拟一个过程的不同计算机上有几个程序。在Linux上，我正在使用GCC。一切都很棒。我可以优化代码，它可以快速编译并使用不那么多的内存。
我使用MSVC和GCC编译器做自己的基准测试。后来一个产生稍快的二进制文件（对于每个子体系结构）。虽然编译时间远远超过MSVC。
所以我决定使用MinGW。但是在MinGW中找不到有关异常处理方法及其实现的任何解释。我可以为不同的操作系统和体系结构使用不同的发行版。
注意事项：
答案 0 :(得分：94)
在MinGW-w64 Wiki处有一个简短的概述：
为什么mingw-w64 gcc不支持Dwarf-2异常处理？
Windows的 Dwarf-2 EH 实现根本不是设计的 在64位Windows应用程序下工作。在win32模式下，异常 unwind处理程序无法通过非dw2识别代码传播，这意味着 通过任何非dw2识别的“外国帧”的任何异常 代码将失败，包括Windows系统DLL和使用它构建的DLL 视觉工作室。 gcc中的Dwarf-2展开代码检查x86 展开组件，没有其他矮人2就无法继续 展开信息。
异常处理的 SetJump LongJump 方法适用于大多数人 除了一般保护错误之外，win32和win64都有案例。 正在开发gcc中的结构化异常处理支持 克服了dw2和sjlj的弱点。在win64上， 展开信息放在xdata-section中，并且有.pdata （函数描述符表）而不是堆栈。对于win32，链 处理程序处于堆栈状态，需要通过实际保存/恢复 执行代码。
GCC GNU关于异常处理：
GCC支持两种异常处理方法（EH）：
- DWARF-2（DW2）EH ，需要使用DWARF-2（或DWARF-3）调试信息。 DW-2 EH可以导致可执行文件 稍微膨胀，因为必须有大的调用堆栈展开表 包含在可执行文件中。
- 基于 setjmp / longjmp（SJLJ）的方法。基于SJLJ的EH比DW2 EH慢得多（当没有时，惩罚甚至正常执行） 抛出异常），但可以跨越尚未执行的代码 使用GCC编译或没有调用堆栈展开 信息。
[...]
结构化异常处理（SEH）
Windows使用自己的异常处理机制，称为结构化异常处理（SEH）。 [...] 不幸的是，海湾合作委员会尚未支持SEH。 [...]
另见：
答案 1 :(得分：71)
SJLJ （setjmp / longjmp）： - 可用于32位和64位 - 不是“零成本”：即使没有抛出异常，也会导致未成年人 性能损失（异常重码中约15％） - 允许例外 遍历例如Windows回调
DWARF （DW2，dwarf-2） - 仅适用于32位 - 无永久运行时开销 - 需要整个调用堆栈启用为dwarf， 意味着不能抛弃异常，例如Windows系统DLL。
SEH （零开销异常） - 可用于64位GCC 4.8。