C/C++的注意事項

     最近調試C語言程式，出了一些錯誤，費了很大的力氣才找到這些BUG。現在把這些錯誤記錄下來，同時做一些程式設計上的原則上的限制，希望能達到兩個目的：（1）看到類似的情況，能馬上定位知道是什麼錯誤。（2）不在犯這種錯誤。

         将64位整型轉換為32位整型，貌似是沒什麼問題。但是在做多結點間資料通信的時候，這個不注意的細節将導緻很嚴重的錯誤。例如在發送端使用的是64位的整型，接收端使用32位整型，這樣會導緻接收端由于接收緩沖區中的資料沒有完全被反序列化阻塞。

        還有使用無符号數的時候一定要注意，因為無符号數減去一個比自身還要大的數，容易出現很嚴重的問題。原理大家都知道，内部是使用補碼存的，但是寫程式的時候不一定能注意到。

        使用一些底層的庫函數時一定要確定傳入的資料類型與接口要求的資料類型一緻。我就發生過因為使用zlib的compress函數時要求傳入unsigned char * 和 unsigned long int *時，我使用了char *和 unsigned int *時出現一些莫名其妙的錯誤。

       在使用沒有接觸的技術或者是底層的庫函數的時候，一定要寫夠測試程式，充分的熟悉接口的使用，而不應該直接內建在軟體中，否則會出現很嚴重的問題。

        使用系統調用或者庫函數或者第三方軟體的函數時，如果有傳回值，一定要檢查傳回值的情況，以判斷程式是否正确。可能就是這樣一個小小的問題就會導緻飛彈打偏或者衛星脫軌，或者是火車站售票系統上常顯示的”XXXX位置的記憶體不能為讀“之類的緻命錯誤。如果函數可能會抛出異常，一定要捕獲異常。在調試階段，出現這樣問題時，一定要使用exit或者abort之類的方法，強制程式在此結束，并打出目前的行号、檔案名稱，如果有必要的話還有堆棧資訊等這些重要的調試資訊。這些對于确定程式出錯的位置非常有幫助。   

       養成讀文檔的好習慣，出現問題的很多一部分原因都是沒有仔細閱讀文檔。文檔中詳細的說明了接口的使用和注意事項，沒有注意到這些細節，調試簡直就是自作自受。

       還有常做單元測試，確定縮寫的部分代碼能夠正常運作。然後再內建到軟體中，否則出現問題的付出的代價要大的多。

本文轉自hipercomer 51CTO部落格，原文連結:http://blog.51cto.com/hipercomer/861856