C/C++的注意事項

         最近調試C語言程序,出了一些錯誤,費了很大的力氣才找到這些BUG。如今把這些錯誤記錄下來,同時作一些編程上的原則上的約束,但願能達到兩個目的:(1)看到相似的狀況,能立刻定位知道是什麼錯誤。(2)不在犯這種錯誤。編程

         將64位整型轉換爲32位整型,貌似是沒什麼問題。可是在作多結點間數據通訊的時候,這個不注意的細節將致使很嚴重的錯誤。例如在發送端使用的是64位的整型,接收端使用32位整型,這樣會致使接收端因爲接收緩衝區中的數據沒有徹底被反序列化阻塞。ide

        還有使用無符號數的時候必定要注意,由於無符號數減去一個比自身還要大的數,容易出現很嚴重的問題。原理你們都知道,內部是使用補碼存的,可是寫程序的時候不必定能注意到。函數

        使用一些底層的庫函數時必定要確保傳入的數據類型與接口要求的數據類型一致。我就發生過由於使用zlib的compress函數時要求傳入unsigned char * 和 unsigned long int *時,我使用了char *和 unsigned int *時出現一些莫名其妙的錯誤。單元測試

       在使用沒有接觸的技術或者是底層的庫函數的時候,必定要寫夠測試程序,充分的熟悉接口的使用,而不該該直接集成在軟件中,不然會出現很嚴重的問題。測試

        使用系統調用或者庫函數或者第三方軟件的函數時,若是有返回值,必定要檢查返回值的狀況,以判斷程序是否正確。可能就是這樣一個小小的問題就會致使×××打偏或者衛星脫軌,或者是火車站售票系統上常顯示的」XXXX位置的內存不能爲讀「之類的致命錯誤。若是函數可能會拋出異常,必定要捕獲異常。在調試階段,出現這樣問題時,必定要使用exit或者abort之類的方法,強制程序在此結束,並打出當前的行號、文件名稱,若是有必要的話還有堆棧信息等這些重要的調試信息。這些對於肯定程序出錯的位置很是有幫助。   調試

       養成讀文檔的好習慣,出現問題的不少一部分緣由都是沒有仔細閱讀文檔。文檔中詳細的說明了接口的使用和注意事項,沒有注意到這些細節,調試簡直就是自食其果。接口

       還有常作單元測試,確保縮寫的部分代碼可以正常運行。而後再集成到軟件中,不然出現問題的付出的代價要大的多。內存

相關文章
相關標籤/搜索