一般編譯器錯誤 c 的好習慣開啟編譯器警告

我在半年之前開始用c++來做一些演算法開發並且部署到專案中，因為寫的演算法會被頻繁呼叫，所以需要保證用c++寫出正確，簡潔，高效的演算法**，我知道現在的演算法工程師大多都是從python入門的，對c++並不是特別熟悉，甚至有許多跟我一樣，從別的專業轉行的演算法。但是無論如何，演算法工程師首先是個工程師，必須嚴格為自己的**負責，遵守**規範，培養良好的開發習慣。

if( flag = true)

那麼這個錯誤如果你不開啟warning的話，編譯器是不會發現的，事實上許多有經驗的c++程式設計師也會不小心寫出這樣的**，這種錯誤需要你有一雙放大鏡一般的眼睛逐行掃瞄，可能要花費大量的時間才能發現。而如果開啟了warning的話，編譯器會馬上告訴你

warning: suggest parentheses around assignment used as truth value [-wparentheses]
if(flag = true)

將你從人肉debug的深淵中拯救出來，不僅這樣，warning還會告訴你更多的資訊，比如未使用的變數，不正確的縮排，將不同型別的變數進行對比等等。修復這些警告不僅可以提高你程式的檔案程度，同時顯得更加乾淨和簡潔。在effective c++(如果你覺得你入門了c++,我推薦你馬上看這本書)的條款53也強調了不要忽略編譯器警告.

如果你是乙個會使用gcc來編譯c++程式的人，請忽略這節……

我想絕大多數人都會用類似於cmake這樣的工具來保護自己的頭髮，對於單個可執行程式

if ( cmake_compiler_is_gnucc )
target_compile_options(main private "-wall -wextra")
endif()
if ( msvc )
target_compile_options(main private "/w4")
endif()

就可以為那個程式開啟編譯器警告，如果希望為專案中的所有**都開啟編譯器警告

if ( cmake_compiler_is_gnucc )
set(cmake_cxx_flags "$ -wall -wextra")
endif()
if ( msvc )
set(cmake_cxx_flags "$ /w4")
endif()

當然我也推薦在-wextra後面新增-werror或者在/w4後面新增/wx來將warning視為error直接中斷編譯，嚴於律己是乙個好習慣。這裡在補充一下-wall和-wextra的小差別，-wall並不是指「all warning"而是指"all errors that everybody could agree on"，-wextra則指那些"somebody agree on"的warning.

你可能會發現許多專案都有warning,不管是國內的還是國外的，事實上對待warning更是乙個態度問題。我也知道所有公司幾乎都不會把處理warning計入kpi,事實上幾乎所有的專案都是緊急的，很難遇到乙個不浮躁的團隊，不浮躁的管理。等你真正將所有的warning解決，客戶可能已經端著大菠蘿衝上來了。但是我還是認為作為乙個開發者，寫出好的**不是對公司的態度，而是對自己的態度，只有這樣子去要求自己，才能真正提高自己的技術水平。

一般編譯器錯誤 c 的好習慣開啟編譯器警告

編譯器在處理const變數跟一般變數時的區別

編譯器在處理const變數跟一般變數時的區別

C 編譯器錯誤資訊的Trick

一般編譯器錯誤 c 的好習慣 開啟編譯器警告

編譯器在處理const變數跟一般變數時的區別

編譯器在處理const變數跟一般變數時的區別

C 編譯器錯誤資訊的Trick

相關推薦

一般編譯器錯誤 c 的好習慣開啟編譯器警告