Mastering C + + Builder Art of Debugging (2). 2

Second-close-up observation (2)

Using evaluate/modify (for evaluation/modification)

The last way to display the value of a variable or code block is the evaluate/modify (Evaluate/Modify) window. This window can be opened like a patrol, and the evaluate/modify (Evaluate/Modify) window will pop up when you right-click on the line of code you want to evaluate/modify (evaluate/modify) and select "Debug|evaluate/modify". This window is used to evaluate and/or modify an expression/variable. Watches and/or inspectors can also achieve the same function. But if you want to change it, this is probably the best place.

"Look at the variable has heard enough, and now I want to go to see what's wrong with my code instead of sitting here." "I heard what you said. In the next section, we'll step through the function body to the breakpoint (remember what's in front of you?). ）。

Stepping (step/trace) inside and outside the code block

One thing to keep in mind here is that most of the previous methods of viewing variables are dynamically updated. So when you trace to a new row, the value of the variable is automatically evaluated, and the value displayed in the window is updated to the new current value.

Okay, when you click on the breakpoint you set, you will see the variables you need to check. The next step is stepping through the code and looking closely at what actually happens to you as you guessed it (by using watches/inspectors and following the execution path of the code).

Type of Stepping

This part of the explanation seems quite simple. But most of the following is about what you can do with this (as if you haven't heard it anywhere else). ）。 You can tell the debugger five kinds of "stepping types" (single-step type). We'll explain them in the order we want on the Run menu. I'll also give them a shortcut key. The number of times you use a shortcut key while you are debugging is more than the menu option (comparing the 10 keyboard with the 10 menu, I want you to know what's better).

The first is "Step Over" (stepping on the outside of the function) or F8. This allows the debugger to execute code to stop the next line of visible code in the current function, or the debugger to return to the calling function when it runs to the last row of the current function. The stepping over feature is handy when you know that the function you are calling is not a problem.

The next one is "Trace into" (tracking to a function body) or F7. If the current line that is running is calling a function, the debugger will take us to the first line of the called function (even if the function is implicitly invoked, such as a write property). Otherwise, executes to the next line in the current row. This is handy when you want to see what this function does.

The next step is "Trace to Next" (tracked to the next source line) or SHIFT-F7. The debugger runs to the next line of code with debug information. This is the difference between "trace into", let's say for example. When we call a Windows API function with no source code and this API function calls a callback function in our code. "Trace to next source" will stop at the first line of the callback function, and "Trace into" ignores the callback function and stops at the next line in the current program.

Then "Run to Cursor" (runs to the cursor) or F4. The debugger will run the code until the line where the cursor is located. This makes it convenient to skip large chunks of code without having to set breakpoints (consider a pause).

There is also "run until return" (run to back) or Shift-f8. The debugger will run the code until the current function returns the function that called him. When you don't want to manually step into the end of a function (if you're stuck in a loop and the process becomes verbose), it's easy to skip to the end of the function.

The last one is "program reset" (Programs reset) or CTRL-F2. The debugger interrupts the running program and returns to the debugger. Do not do this unless you are compelled to do so because the resources used by the object are not freed!!! (In a database application, after you do this 2-3 times, you will have to shut down and restart the IDE because the BDE internal resources will be depleted.) You have been warned). This is useful when you have to abort the executable program.

The last (but in the top position of the menu) is "Run" (run) or F9. The debugger will run to the end of the program unless you hit a new breakpoint or an exception occurred.

Annotations of the stepping

Keep in mind that all of these steps are performed when the debugger passes a breakpoint, the debugger values the breakpoint and stops if the breakpoint is needed. If an exception occurs, the debugger will also stop.

As you can see, setting breakpoints in the right place, looking at the variables and stepping through the code, we are able to observe very closely what the program is doing as if it were actually running. These features are quite handy when tracing the most difficult bugs---logical bugs.

Other Tips

If you are really brave and have assembly language experience, you can open a CPU View CPU window by clicking "View|debug windows|cpu". This shows not only the assembly instructions for the current executable program's instructions, but also the image of CPU flags, registers, and constantly updated memory.

Using Call Stack ("View|debug windows|call stack") makes it easy to find out the history of function calls before an exception occurs or before a breakpoint is encountered. Remember, this is just a show of what functions have been called by what functions, not the history of the actual call process. Therefore, this window may be confusing to you first. But as long as you open it to stepping through step tracking code into the function body, a good look at you will fully understand.

C++builder4, 5, watch, local variable, and call stack windows can reside in the Code main window and are more convenient to use. Debug layouts can also be set in C++builder5 to be used during debugging (for the design layouts you use at design time).

With all the techniques I've advertised, plus a little patience and a pair of eyes, you should be able to fix 99% of bugs. Patience is necessary if you want to find a bug. Take a moment, breathe deeply, and don't let the frustration scare you. If necessary, go out for 5 minutes and do something else, and you'll be amazed to see that you have a new vision or find out what steps were missing at the beginning.

If you have other tips and hints that you should join this article, please do not hesitate to let us know and we will include your comments in future editions.

Well, I hope this article will help the patient reader in some way. If that's the case, I'd be happy to do a good job. Perhaps all your bugs are insignificant.

Original: Bill King

Translation: Spingyang-Cker