Visual Studio 2003編譯器行為

Question

我最近接手了一個用C和C ++編寫的項目，該項目將使用MS Visual Studio 2003編譯器進行編譯。 由於我對編譯器設置和編譯器輸出缺乏經驗，因此我想知道給定的設置是否確實有所作為（根據編譯輸出或性能）。

該項目混合使用C和C ++。 主要部分是用C編寫的，但使用了一些用C ++編寫的類。 所以問題的第一部分是：（MS VS 2003）編譯器是否對每個文件有所不同（僅使用c功能為.​​cpp文件編譯純c並使用類為文件編譯c ++樣式）？ 可能有使用它的理由（提高性能，向后兼容）嗎？

該項目也不使用try-catch塊（因為它不是純C語言）。 但是不會禁用編譯器設置中的異常處理選項。 所以問題的第二部分：不使用try-catch但不在編譯器中禁用它，是否還會有性能提升（或任何其他邏輯原因）？

是的，我對這種設置和嘗試理解感到困惑。

Answer 1

很難解碼，我會試一試。 默認行為是在源代碼文件擴展名以.c結尾時獲取C編譯器，而在以.cpp結尾的C ++編譯器中獲取C編譯器。 這背后沒有更大的方案，或者與向后兼容性或性能改進無關，僅.cpp文件可以包含C ++代碼。 兩種編譯器都使用相同的后端（代碼生成器和優化器），因此如果您使用C ++編譯器編譯C代碼，則不會有太大區別。

/ EH編譯選項僅在您在代碼中創建C ++對象並且編譯器可以告訴您可能拋出異常時才起作用。 如果代碼庫主要基於C，則不會有任何區別。 / EH的實際成本非常低，只需幾個cpu周期即可注冊異常過濾器。 當異常處理使用函數表時沒有任何花費，但是您的表肯定已經太老了，無法支持它（/ SAFESEH或x64代碼）。

如果您只是接手了一個大型項目，那么修改編譯器設置應該是一個低優先級。 在開始更改可能會破壞代碼的選項並讓您很難調試問題之前，請先了解代碼庫。 或者換一種說法，避免尋找Deus Ex Machina，它將使您看起來在很短的時間內就取得了巨大的成就。 使用探查器可以使您獲得更多的收獲，並獲得更深入的了解。