我無法找到足夠的信息來決定使用哪個編譯器來編譯我的項目。在不同的計算機上有幾個程序模擬一個過程。在Linux上，我使用GCC。一切都很好。我可以優化代碼，它可以快速編譯並使用不太多的內存。sjlj vs dwarf vs seh有什麼區別？
我做我自己的基準與MSVC和GCC編譯器。稍後會產生稍微更快的二進制文件（對於每個子體系結構）。雖然編譯時間比MSVC多得多。
所以我決定用MinGW的。但是在MinGW中找不到有關異常處理方法及其實現的任何解釋。我可以針對不同的操作系統和體系結構使用不同的發行版。
注意事項：
有在MinGW-w64 Wiki一個簡短的概述：
爲什麼不MinGW的-W64 GCC支持矮2異常處理？
用於Windows的矮2 EH實現並不在64位Windows應用程序在所有旨在 工作。在win32模式下，異常 展開處理程序無法通過非dw2知道代碼傳播，這意味着 任何異常會通過任何非dw2知道的「外部框架」 代碼將會失敗，包括Windows系統DLL和使用 構建的DLL工作室。在GCC矮2退繞代碼檢查在x86 退繞組件，並且不能沒有其他矮化-2 展開信息進行。
SetJump LongJump異常處理方法適用於除win32和win64以外的大多數 情況（一般保護錯誤除外）。 gcc的結構化異常處理支持正在開發到 ，克服了dw2和sjlj的弱點。 Win64上，所述 展開信息被放置在XDATA截面並且在.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）自己的異常處理機制。 [...] 不幸的是，GCC還不支持SEH。 [...]
參見：
感謝您的鏈接。我將使用32位的DW2和64位的SEH。SEH在mingwbuild（4.8）中可用。我應該等待4.8的穩定版本還是沒問題？它在這裏編譯。我目前正在使用SEH對4.8的項目進行依賴項。沒問題... – 2013-03-28 16:00:53
我猜你已經可以使用4.8了。 – ollo 2013-03-28 18:48:34
所有相關性（包括Boost庫，OpenSSL的，ICU，freeGLUT）編譯但Qt的結束，有很多內部編譯器錯誤。我想我會等待4.8 – 2013-03-28 21:35:51
SJLJ（的setjmp/longjmp的） ： - 對於32位和64位 - 不爲「零成本」：即使不引發異常，但這樣會導致較小的 性能損失（〜異常代碼重15％） - 允許例外 通過例如遍歷窗口回調
DWARF（DW2，矮-2） - 僅可用於32位 - 沒有永久運行時開銷 - 需要整個調用棧是啓用矮，這意味着 異常不能扔過例如Windows系統DLL。
SEH（零開銷例外） - 將可用於64位GCC 4.8。
對不起，源鏈接添加 – 2013-03-27 22:02:58
謝謝爲您的答案;） – 2013-03-27 22:03:32
因此，現在在2016年，我們可以把這個問題休息，只是總是使用SEH。 – rustyx 2016-05-13 19:55:23
我很驚訝，GCC可產生更快的代碼比MSVC;在過去的幾年裏，事情一定會改變...... – trojanfoe 2013-03-27 21:52:56
@trojanfoe我曾多次被告知使用MSVC而不是MinGW。大家都認爲msvc更快！我用一個簡單的cpu-burst程序測試了MinGW 7.2和MSVC 2010.與corei7'-O3 -mtune = corei7' GCC比MSVC – 2013-03-27 21:57:27
快45％，在我自己的經驗，有一步棋發生器（其中使用位棋盤），都MSVC和英特爾C++比GCC快10％，但這是2年前... – trojanfoe 2013-03-27 22:04:38