September 10, 2008

《The Art of Debugging》第一章開放下載


由 LinuxDevices.com 的新聞 [Free book chapter explains debugging],得知 Norman Matloff 與 Peter Jay Salzman 的大作《The Art of Debugging》已開放下載第一章的內容,正巧就是專門探討開放源碼的偵錯除錯工具,標題為〈Some Preliminaries For Beginners And Pros〉。

除了前述的新聞內容提供的下載位址,筆者則做了一份複製 [debugging_samplechapter.pdf] (17 Mb)。這章提到三個優秀的工具:
  • GDB : 還需要多談嗎?史上最強大的跨平台 Debugger
  • DDD (Data Display Debugger)
  • Eclipse CDT (透過 GDB-MI)
撇開工具能夠協助我們達到多大的功效,不妨先看看作者在 1.3.2 段落的精湛介紹:
    Of What Value Is a Debugging Tool for the Principle of Confirmation?

    The classic debugging technique is to simply add trace code to the program to print out values of variables as the program executes, using printf() or cout statements, for example. You might ask, “Isn’t this enough? Why use a debugging tool like GDB, DDD, or Eclipse?”

    First of all, this approach requires a constant cycle of strategically adding trace code, recompiling the program, running the program and analyzing the output of the trace code, removing the trace code after the bug is fixed, and repeating these steps for each new bug that is discovered. This is highly time consuming and fatigue making. Most importantly, these actions distract you from the real task and reduce your ability to focus on the reasoning process necessary to find the bug.

    In contrast, with graphical debugging tools like DDD and Eclipse, all you have to do in order to examine the value of a variable is move the mouse pointer over an instance of that variable in the code display, and you are shown its current value. Why make yourself even wearier than necessary, for longer than necessary, during an all-night debugging session by doing this using printf() statements? Do yourself a favor and reduce the amount of time you have to spend and the tedium you need to endure by using a debugging tool.

    You also get a lot more from a debugging tool than the ability to look at variables. In many situations, a debugger can tell you the approximate location of a bug. Suppose, for example, that your program bombs or crashes with a segmentation fault, that is, a memory access error. As you will see in our sample debugging session later in this chapter, GDB/DDD/Eclipse can immediately tell you the location of the seg fault, which is typically at or near the location of the bug.

    Similarly, a debugger lets you set watchpoints that can tell you at what point during a run of the program the value of a certain variable reaches a suspect value or range. This information can be difficult to deduce by looking at the output of calls to printf().
雖然是老生常談了,但「多想兩分鐘,您可以更開心地編寫、開發程式」,稍後的段落中,即可窺見善用除錯工具,對整體開發的效益。而,現在視覺化呈現也相當優秀,何不更深入採用呢?
由 jserv 發表於 September 10, 2008 08:41 PM
迴響

哇,這本書才剛發行唷,Amazon沒有書評,應該是好書吧。ddd好像很好玩的樣子,謝謝前輩的分享。

someguest 發表於 September 10, 2008 09:41 PM

學長,typo:優繡的工具

WM 發表於 September 11, 2008 12:19 AM

@WM,

Fixed now. Thanks!

jserv 發表於 September 11, 2008 08:56 AM

"達到多到的功效" may be "達到多大的功效"?

:)

Hsiao-Ting 發表於 January 13, 2010 08:48 PM
發表迴響









記住我的資訊?