我找不到足够的信息来决定应该使用哪个编译器来编译我的项目。在不同的计算机上有几个程序模拟一个过程。在 Linux 上,我使用的是 GCC。一切都很好。我可以优化代码,编译速度很快,而且不需要太多内存。
我用 MSVC 和 GCC 编译器做了自己的基准测试。稍后,生成速度稍快的二进制文件(对于每个子体系结构)。虽然编译时间远远超过 MSVC。
所以我决定用 MinGW。但是在 MinGW 中找不到任何关于异常处理方法及其实现的解释。我可以为不同的操作系统和架构使用不同的发行版。
考虑因素:
SJLJ (setjmp/longjmp) :-可用于32位和64位-而不是“零成本”: 即使没有抛出异常,也会引发次要异常 性能损失(异常大的代码约为15%)-允许异常 遍历例如 windows 回调 DWARF (DW2,侏儒-2)-仅适用于32位-没有永久的运行时开销-需要整个调用堆栈支持侏儒 意味着不能抛出异常,例如 Windows 系统 DLL。 SEH (零开销异常)-将可用于64位 GCC 4.8。
SJLJ (setjmp/longjmp) :-可用于32位和64位-而不是“零成本”: 即使没有抛出异常,也会引发次要异常 性能损失(异常大的代码约为15%)-允许异常 遍历例如 windows 回调
DWARF (DW2,侏儒-2)-仅适用于32位-没有永久的运行时开销-需要整个调用堆栈支持侏儒 意味着不能抛出异常,例如 Windows 系统 DLL。
SEH (零开销异常)-将可用于64位 GCC 4.8。
来源: https://wiki.qt.io/MinGW-64-bit
在 MinGW-w64 Wiki有一个简短的概述:
为什么 mingw-w64 gcc 不支持 Dwarf-2异常处理? Windows 的 矮人 -2 EH实现的设计目的根本不是为了 在64位 Windows 应用程序下工作。在 win32模式下,异常 Unwind 处理程序不能通过非 dw2感知代码进行传播,这意味着 任何异常通过任何非 dw2感知的“外部帧” 代码将失败,包括 Windows 系统 DLL 和使用 VisualStudio.Dwarf-2在 gcc 中展开代码检查 x86 不能在没有其他矮星 -2的情况下继续进行 放松信息。 异常处理的 跳远方法适用于大多数情况 除了一般的保护故障外,win32和 win64都有。 正在开发 gcc 中的结构化异常处理支持 克服 dw2和 sjlj 的弱点 Unwind-information 放在 xdata-section 中,其中有. pdata (函数描述符表)代替堆栈 的处理程序在堆栈上,需要由 real 保存/恢复 执行代码。
为什么 mingw-w64 gcc 不支持 Dwarf-2异常处理?
Windows 的 矮人 -2 EH实现的设计目的根本不是为了 在64位 Windows 应用程序下工作。在 win32模式下,异常 Unwind 处理程序不能通过非 dw2感知代码进行传播,这意味着 任何异常通过任何非 dw2感知的“外部帧” 代码将失败,包括 Windows 系统 DLL 和使用 VisualStudio.Dwarf-2在 gcc 中展开代码检查 x86 不能在没有其他矮星 -2的情况下继续进行 放松信息。
异常处理的 跳远方法适用于大多数情况 除了一般的保护故障外,win32和 win64都有。 正在开发 gcc 中的结构化异常处理支持 克服 dw2和 sjlj 的弱点 Unwind-information 放在 xdata-section 中,其中有. pdata (函数描述符表)代替堆栈 的处理程序在堆栈上,需要由 real 保存/恢复 执行代码。
GCC GNU 关于 异常处理:
GCC 支持两种异常处理(EH)方法: DWARF-2(DW2) EH ,这需要使用 DWARF-2(或 DWARF-3)调试信息 稍微膨胀,因为大的调用堆栈退出表必须 包含在可执行文件中。 一种基于 Setjmp/longjmp (SJLJ).SJLJ 的 EH 方法比 DW2EH 慢得多(即使是正常执行时,如果没有 异常) ,但可以跨尚未引发异常的代码工作 使用 GCC 编译或者没有调用堆栈展开的 资料。 [ ... ] 结构化异常处理(SEH) Windows 使用自己的异常处理机制,称为结构化异常处理(SEH)。 < em > [ ... ] 不幸的是,GCC 还不支持 SEH
GCC 支持两种异常处理(EH)方法:
[ ... ]
结构化异常处理(SEH)
Windows 使用自己的异常处理机制,称为结构化异常处理(SEH)。 < em > [ ... ] 不幸的是,GCC 还不支持 SEH
参见: