《C語言程式設計進階教程》一3.3 後執行式和互動式調試

本文講的是<b>C語言程式設計進階教程一3.3　後執行式和互動式調試</b>,要調試一個程式是需要政策的。你需要把程式分為幾階段，在每一階段的基礎上隔離問題。在把不同部分整合起來之前確定程式在每一階段都是正确的。例如，把一個程式看作3個階段：①從一個檔案中讀取一些整數；②把整數排序；③把排好序的整數存到另一個檔案中。在整合之前測試每一部分叫作單元測試。對于單元測試，你經常需要寫一些額外的代碼作為單獨部分的“驅動”。例如，要在還未從檔案中獲得資料的情況下測試排序是否正常工作了，你就需要編寫能夠産生資料的代碼（也許使用一個随機數生成器）。調試可能是互動式或者是後執行式的。如果一個程式會花費幾個小時，你就不會想要用互動式來調試這個程式了。相反，你會想要程式列印出調試資訊（叫作日志）。這個資訊幫助你知道在長時間的執行期間發生了什麼。另一種情況是調試一個與其他程式有着即時通信要求的程式。例如，你調試一個程式，此程式與另一個程式通過網絡進行通信。如果你對這個程式進行互動式的調試就會讓它慢很多，其他程式會認為網絡中斷進而停止與你的程式進行通信。另一種情形是你的程式與實體世界進行關聯（例如控制一個機器人）。實體世界不會等待你的程式，它也不會慢下來。列印日志也會讓程式慢下來，是以不要添加過多的日志。

在許多其他情況下，你可以讓你的程式慢下來，對程式進行互動式的調試——運作程式的一些部分，觀察中間的結果，修改程式，再次運作它們，繼續這個過程直至你認為程式正确。對于互動式調試，列印調試資訊通常是低效費時的。對互動式調試而言列印調試資訊存在多個問題：

需要插入代碼來列印調試資訊。這将會耗費相當的精力。多數情況下，調試資訊必須在随後被移除，因為此資訊不應該出現在最終的代碼和它的輸出中。

如果隻有很少的資訊，那麼就會缺少足夠的資訊幫助你判斷是哪裡錯了。

如果有太多的資訊，一些資訊可能會是不相關的，應該被忽略。要得到恰好數量的資訊，不多也不少，是很困難的。

最糟糕的是，問題可能會出現在意想不到的地方，而那裡卻并未插入調試資訊。結果就是需要添加越來越多的調試資訊進來。這将會是耗時耗力的。

與在互動式調試中使用調試資訊相比，gdb（或DDD）在多數情況下是一個更好的工具。前文已經展示過一些gdb指令了。在本書後續部分會介紹更多指令。

原文标題：C語言程式設計進階教程一3.3　後執行式和互動式調試