使用VC ++編譯SQLite時如何解決警告？

Question

每當我使用Visual C ++ 9編譯SQLite時 ，都會收到數百條警告，例如

• 潛在的未初始化變量
• 從較寬的整數類型到較窄的整數類型的轉換
• 有符號/無符號整數不匹配。

我並不孤單-有一個專門針對此的SQLite FAQ問題 。 這個問題的答案說

• 這些警告不會出現在SQLite開發人員使用的GCC中
• 警告不是問題，因為團隊徹底地測試了代碼

我當然不能反對這些觀點，但是...

• 我不使用GCC-我使用VC ++，並且VC ++確實顯示警告
• 他們測試了使用GCC編譯的代碼，而我不使用GCC，因此GCC和VC ++之間可能存在一些實現定義的差異或不同級別的C標准合規性，這些都會巧妙地破壞代碼，並帶來嚴重的后果。

這就是為什么我不喜歡簡單地忽略所有警告的想法的原因。

那么在編譯SQLite時如何處理VC ++顯示的警告？

Answer 1

如果實際上沒有造成任何危害，為什么不使用#pragmas禁用這些警告？ 還是切換到較低的警告級別（假設您擁有SQLite源作為單獨的VC lib項目？）

Answer 2

任何使用C ++的開發人員如何處理警告？ 研究收到警告的代碼，確定警告是否告訴您需要了解的信息，然后根據需要更改代碼。 我不確定我是否真的理解您的問題。

也許，如果您發布了特定的警告（帶有代碼），我們可能會為您提供有關該警告的建議。

Answer 3

我要說的是，使用開發人員自己從未使用過的編譯器和庫來編譯像SQLite這樣復雜的東西，注定會失敗，或者至少會非常非常痛苦。 GCC在Windows上易於安裝和使用（可從http://tdragon.net/recentgcc獲得），那么為什么不使用它呢？

Answer 4

首先，請記住警告不是錯誤指示符。 他們在那里是為了吸引開發人員注意那些可能指示錯誤的內容，而沒有別的。

如果該代碼有效，則發出的警告數量幾乎無關緊要。

如果您想放心，請查看以下警告：它們是否與VS和GCC處理不同的實現定義的行為有關？ 如果是這樣，您可能有問題。 但是，只要警告是關於兩個編譯器都相同地處理的事情（例如整數/雙精度轉換），就可以將其忽略。

我記得（一段時間以來，我在VS上編譯SQLite時沒有沉默警告），實際上所有警告都是關於內置類型之間的隱式轉換的，只要開發人員知道它們正在使用，所有這些都是絕對安全的地點。

SQLite在VS上工作得很好。 該庫被許多大型項目廣泛使用。 經過相當廣泛的測試。

Answer 5

在VC9解決方案資源管理器中選擇文件，右鍵單擊，選擇“屬性”。 然后轉到C++ -> General選項卡，並將Warning level設置為Off 。 這將僅關閉那些文件的所有警告。

我使用的大多數外部lib文件都是這樣做的：沒有“修復”那些文件的好處（如果它們不是真正的bug），並且關閉警告有助於保持構建輸出窗口的清潔，因此我不會錯過我自己的代碼中的警告。

Answer 6

這些警告的基本含義是：

1. 如果將代碼移植到所有基本類型（char，short，int，long，long long）的大小與原始開發人員使用和測試過的大小完全相同的環境，則該代碼可能會在測試后正常工作（盡管請注意排除那些可能未初始化的變量），但是

2. 如果您曾經將代碼移植到某些基本類型與原始開發人員使用的大小不同的環境中，那么您很有可能在您所處的某些地方以神秘和違反直覺的方式破壞代碼得到這些警告。 即使您在兩種環境中都使用GCC，也是如此。 有關可能發生的行為的一些示例，請參見C FAQ 3.19 （請記住，C和C ++標准現在都規定了“保值”規則）。

這是草率編碼的標志。 他們確實應該解決導致這些警告的大多數問題（通常，在二進制運算符之間混合有符號和無符號類型是有風險的，我敢打賭他們在這里經常這樣做）。 我已經修復了過去導致此類警告的其他人的代碼，使其更強大地移植到將來的環境中。 但這就是說，如果它們使用與您將使用的相同的基本類型大小進行編譯和測試（如果可以鏈接到兼容的C語言接口，則幾乎可以肯定它們的大小），那么您可能無需解決許多這些問題。