C語言難點揭秘4_第1頁
C語言難點揭秘4_第2頁
C語言難點揭秘4_第3頁
全文預覽已結束

下載本文檔

版權說明：本文檔由用戶提供并上傳，收益歸屬內容提供方，若內容存在侵權，請進行舉報或認領

文檔簡介

C語言難點揭秘[4]語言

軟件工具

硬件檢查器

在這整個領域中，我始終認為最有用并且投資回報率的是考慮改良源代碼的風格。它不需要昂貴的代價或嚴格的形式；可以始終取消與內存無關的段的解釋，但影響內存的定義固然需要顯式解釋。添加幾個簡潔的單詞可使內存結果更清晰，并且內存編程會得到改良。

我沒有做受控試驗來驗證此風格的效果。假如您的經受與我一樣，您將發覺沒有說明資源影響的策略簡直無法忍受。這樣做很簡潔，但帶來的好處太多了。

檢測

檢測是編碼標準的補充。二者各有裨益，但結合使用效果特殊好。機智的C或C++專業人員甚至可以掃瞄不熟識的源代碼，并以極低的本錢檢測內存問題。通過少量的實踐和適當的文本搜尋，您能夠快速驗證平衡的*alloc()和free()或者new和delete的源主體。人工查看此類內容通常會消失像清單7中一樣的問題。

清單7.麻煩的內存泄漏

staticchar*important_pointer=NULL;

voidf9()

{

if(!important_pointer)

important_pointer=malloc(IMPORTANT_SIZE);

...

if(condition)

/*Ooops!Wejustlostthereference

important_pointeralreadyheld.*/

important_pointer=malloc(DIFFERENT_SIZE);

...

}

假如condition為真，簡潔使用自動運行時工具不能檢測發生的內存泄漏。認真進展源分析可以從今類條件推理出證明正確的結論。我重復一下我寫的關于風格的內容：盡管大量公布的內存問題描述都強調工具和語言，對于我來說，的收獲來自“軟的”以開發人員為中心的流程變更。您在風格和檢測上所做的任何改良都可以幫忙您理解由自動化工具產生的診斷。

靜態的自動語法分析

固然，并不是只有人類才能讀取源代碼。您還應使靜態語法分析成為開發流程的一局部。靜態語法分析是lint、嚴格編譯和幾種商業產品執行的內容：掃描編譯器承受的源文本和目標項，但這可能是錯誤的病癥。

盼望讓您的代碼無lint。盡管lint已過時，并有肯定的局限性，但是，沒有使用它（或其較高級的后代）的很多程序員犯了很大的錯誤。通常狀況下，您能夠編寫忽視lint的優秀的專業質量代碼，但努力這樣做的結果通常會發生重大錯誤。其中一些錯誤影響內存的正確性。與讓客戶首先發覺內存錯誤的代價相比，即使對這種類別的產品支付最昂貴的許可費也失去了意義。去除源代碼。現在

溫馨提示

  • 1. 本站所有資源如無特殊說明，都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等，如果需要附件，請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙，網頁內容里面會有圖紙預覽，若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間，僅對用戶上傳內容的表現方式做保護處理，對用戶上傳分享的文檔內容本身不做任何修改或編輯，并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容，請與我們聯系，我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論