許多人認為，如果源代碼編譯干凈，激活所有警告，那么它就可以進入驗證階段，例如測試或代碼審查。但是，假設如果代碼已干凈地編譯，那么存在的任何錯誤一定是由對需求的解釋而不是它們的實現引起的，這是危險的。Wojciech對這一假設進行了實證評估，并證明與專用靜態分析和編碼標準執行（CSE）工具生成的警告范圍相比，任何編譯器提供的警告范圍都非常有限。

一種普遍的觀點是，如果源代碼編譯干凈，所有警告都打開，那么它就可以進行驗證，例如測試或代碼審查。這種假設的危險在于，如果代碼已經編譯干凈，那么存在的任何錯誤都必須在需求的解釋中，而不是在它們的實現中。然而，對這一假設的實證評估最終表明，與專用靜態分析和編碼標準執行（CSE）工具生成的警告范圍相比，任何編譯器提供的警告范圍都受到嚴重限制。

本文的比較使用了GNU Common C++“2”版本1.6.3，這是一個大約42，000行代碼的真實代碼庫。由于這是一個跨平臺庫，因此它不支持任何特定的編譯器，并且可以用作任何編譯器可能期望處理的代表性示例。其適中的大小允許手動檢查所有編譯器警告的準確性，同時確保其多樣性和數量不平凡。

檢查的四個編譯器是GCC，Visual C++，C++Builder和Intel C++ Compiler，以及靜態分析和CSE工具，表明如果開發人員過于依賴編譯器來識別編碼缺陷，他們可能會發現他們的代碼不可維護，可重用或可移植。此外，Visual C++“團隊版”使用“代碼分析”功能補充其標準編譯器警告，其輸出包含在這些結果中。

生成警告輸出

在實踐中，這四個編譯器中有一個遺漏的每一個缺陷都會對代碼庫的質量產生影響，無論是可維護性、可移植性還是可重用性。這在部署代碼時是一個重大威脅，盡管大多數示例源代碼都通過了編譯器的架構檢查參數。

由于這些編譯器基于不同的前端，因此每個編譯器可能會發出不同的警告。表 1 并排比較了每個編譯器和靜態分析工具生成的不同警告，用于我們比較中使用的代碼庫：GNU Common C++ “2”。使用編譯結果時可用的每個編譯器的最新版本，并啟用最大警告級別。（表 1 的標題行指示使用的確切編譯器版本和選項。不是相對于這些編譯器進行基準測試，而是將它們的警告輸出與靜態分析器進行比較以進行C++。

表 1：默認檢測比較 – 比較的基礎和每個百分比數字是編譯器和給定類別中的靜態分析工具報告的不同警告之間的比率。標題行詳細說明了用于啟用最大警告級別的確切編譯器版本和選項。

如表中最后一行所示，CSE 工具生成了超過 400 個警告，而測試的編譯器甚至沒有一個設法返回 20 個警告。事實上，根據經驗，靜態分析識別的警告是所有四個編譯器中最好的 25 倍 - 啟用了代碼分析的可視化C++（/analyze 選項）。值得注意的是，如果未啟用此功能，Visual C++ 在所有測試的編譯器中生成的警告最少。

表 1 中的第一列數據顯示了靜態分析工具也檢測到的每個編譯器生成的警告的百分比。請注意，重疊程度很高，平均 84% 的編譯器警告由 CSE 工具復制。比較的這一面只是為了完整性，因為無論是否執行靜態分析，開發人員都需要啟用編譯器警告。

表 1 的其余行顯示了比較的另一面：編譯器標記了多少靜態可檢測的內容？很明顯，編譯器警告避開了“C++的效率和使用”類別。這是意料之中的，因為編譯器優化是在后端執行的，通常是靜默的。但是，值得注意的是，專用的 CSE 工具在此類別中有一系列檢查，專注于低效設計，與低級編譯器優化不同，這些檢查無法自動糾正。

錯過的常見警告

可移植性是編譯器庫中缺少的常見警告類別。只有 C++Builder 生成了一個可歸類為可移植性問題的警告，而靜態分析工具標記了 17 個警告。這些表示符合 ISO C++ 語言定義的構造，但可能會導致不同的編譯器實現出現問題。編譯器供應商通過提供 ISO C++ 的擴展來鎖定開發人員的情況并不少見，可移植性在他們的議程上并不重要也就不足為奇了。這代表了可移植性問題的另一個方面，即符合 ISO C++，這可以通過靜態分析工具中的單獨警告類別來解決。

對于大多數編譯器供應商來說，ISO C++合規性歸結為接受盡可能多的有效C++代碼，同時回避檢測不一致代碼的問題 - 通常是他們自己的語言擴展。檢測 ISO C++不合格是 CSE 工具的優勢之一，這在表 1 中很明顯。很明顯，大多數編譯器警告可以歸類為（代碼）“設計問題”和“可維護性”，其中一些警告非常小，值得將它們降級為樣式問題。然而，即使對于這些重點領域，與靜態分析工具相比，其覆蓋率也遠非全面，對于最佳競爭者 - 具有代碼分析功能的可視化C++，覆蓋率為7%。

編譯器傳統上避免的其他警告類別包括：命名約定、代碼布局、復雜性指標閾值以及禁止某些關鍵字（例如 throw）和函數（例如 malloc），但 Visual C++ 代碼分析功能有一個明顯的例外，該功能具有硬連線警告，用于使用 _alloca、_snprintf 和 TerminateThread 函數。由于這不如靜態分析工具的可配置檢查（允許指定任何函數）全面，因此獲得了半分，使該編譯器在本地（公司特定）標準執行方面得分為 10%。實施上述區域的主要好處是增強了代碼的可重用性，從表 1 中可以明顯看出，編譯器實際上尚未利用這一點。

在比較每個工具生成的實際警告實例時，將原始警告計數制成表格并不是特別有啟發性，因此常見的C++編碼標準將作為比較的客觀基礎。從表 2 可以看出，與 CSE 工具記錄的違規行為相比，沒有一個編譯器提供任何明顯的高完整性C++、JSF++ 或 MISRA C++ 強制實施。

表 2：編碼標準執行 （CSE） 比較

全面性教育工具：最全面/可轉移的路線

一個常見的誤解是，編譯器警告是靜態分析源代碼的充分方法。與專用的靜態分析和 CSE 工具（如 PRQA 的 QA?C++）相比，市場領先的編譯器提供的警告范圍有限。此外，可用的少數檢查往往集中在代碼錯誤行為和可維護性問題上，而可重用性和可移植性問題完全被忽視。專用的 CSE 工具提供了所有這些領域的全面實施，同時保持編譯器不可知性，因此代碼庫和開發環境不必局限于特定的編譯器和平臺。

審核編輯：郭婷