我最近接管了使用MS Visual Studio 2003編譯器編譯的用C和C++編寫的項目。由於我在編譯器設置和編譯器輸出方面的經驗有點欠缺，我想知道給定的設置是否真的有所作爲（根據編譯輸出或性能）。Visual Studio 2003編譯器行爲
該項目使用C和C++的混合。主要部分用C語言編寫，但使用了一些用C++編寫的類。 所以問題的第一部分是：MS（MS VS 2003）編譯器是否對每個文件產生影響（僅使用c功能爲cpp文件編譯純c，並使用類爲文件編譯C++樣式）？ 有沒有理由使用（性能提升，向後兼容性）？
該項目也不使用try-catch塊（因爲它不是純C）。但編譯器設置中的異常處理選項未禁用。 因此，問題的第二部分：如果不使用try-catch，而不是在編譯器中禁用它，是否還會有性能提升（或任何其他邏輯原因）？
是的，我很困惑這個設置和試圖理解。
相當難解碼，我會給它一個鏡頭。默認行爲是當源代碼文件擴展名以.c結尾並且C++編譯器以.cpp結尾時獲取C編譯器。這背後沒有更大的計劃，或任何與向後兼容性或性能改進有關的任何事情，一個.cpp文件只需包含C++代碼。這兩種編譯器都使用相同的後端（代碼生成器和優化器），因此如果您使用C++編譯器編譯C代碼，則不會有太大的區別。
/EH編譯選項只會在代碼中創建C++對象並且編譯器可以指出可能引發異常時執行某些操作。如果代碼庫基本上是基於C的，那麼它就不會有任何區別。/EH的實際成本非常低，幾個cpu週期來註冊一個異常過濾器。當異常處理使用函數表時，沒有任何代價，但是你的函數幾乎肯定太老以至於無法支持（/ SAFESEH或x64代碼）。
如果你剛接手一個大型項目，那麼修改編譯器設置應該是一個低優先級。在開始更改可能會破壞代碼的選項之前，先了解代碼庫，並且會讓您很難調試問題。換句話說，避免尋找Deus Ex Machina，這會讓你看起來像是在很短的時間內取得了偉大的成就。使用分析器可以讓您獲得更多的樂趣和更好的洞察力。