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

Second-close-up observation (1)

1. Preparation prior to commissioning of the executable program

2. Project Options

3. Set breakpoints and break into executable programs

4. View the values stored in the variable

5. Use of Watches (observation)

6. Use of inspectors (patrol device)

7. Using evaluate/modify (for evaluation/modification)

8.Stepping through, over and Around Blocks of Code

Type of 9.Stepping

10.Stepping annotation

11. Other Tips

Okay, (a little bit more prepared) now is the time to start tracking and searching for bugs that are still hiding in the code after a previous effort, which is to start tracking the bug/exception that was marked in the previous article's code. The first is the preparation phase.

Preparation before debugging an executable program

Before we start debugging executable programs, we need to make sure that some of the settings are correct in most cases. I'll go through it one after another and explain briefly why I have to do that. (If you are interested in something, press the Help button, there are many more details). Let's start now, open the project|. Options option.

Project Options

First we stop at the "Compiler" (compile) tab. You simply click the Full debug mode button, and the vast majority of the rest of the setup we need is done. It's always good to set code optimization to None (none), which actually tells the compiler that everything is done, just generate the machine code. Instead of trying to do other intelligent optimizations to improve the speed of a little bit of running. (Of course, after everything is done, you can open this item.) The advantage of doing so is that it greatly reduces the difficulty of our debugging. Because the code in the program is the same as we write, it has not been optimized by the compiler. In the debugging panel, the debug information (debug information) is selected (click) and must be set to line number information (row count information). I also recommend that the "Disable inline expansions" (Disable inline extensions) be selected. Inline extensions are good for the published code, but it's best to turn off this when debugging, and he'll only make you more headache.

Then the "Pascal" tag, especially if you have a Pascal unit connected to your project or use a VCL control based on Pascal (if you own Pascal source, the compiler will automatically recompile with the settings in this section). Here you must disable the "Optimization" optimization option, and then normally I will select (Hook) all the options in the "Debugging" (Debug) section.

Next is the "Linker" (link) tab, where we need to select "Create Debug Information" (Generate debug information). "Use dynamic RTL" (using live RTL) and "Don t generate state Files" (Do not generate status files) are a hassle-causing option. I usually use a state file (which allows for incremental links, but produces a 4 times-fold executable or larger file in the compiled directory), which, in other words, increases the speed of the link-big project. The use of dynamic RTL itself is an argument, and there is much to agree on and oppose.

The next is the "directories/conditionals" (Path/condition) label. Here we want to set the value of the "Directories/conditionals" (Debug source path). We should always set this here to $ (BCB) \SOURCE\VCL, but if you have any additional components attached, it is often a good idea to add their paths as well (between the path and the path). Delimited or you can use the press ... Button Pop-up dialog box to set them up).

The last and most important setting is on the "Packages" (Package) tab. Based on all appropriate debugging experience, you must disable "build with runtime Packages" (compiled with runtime package). The reason for this is that the package itself does not contain and cannot contain debug information. Doing so may not help you track standard VCL code, such as looking at how the parameter x works in the VCL function Y. But most of the time, you'll find that the debugger boils down most of your "symptoms" to VCL, although the "cause" is in your source code (or in other components (which has happened to all of us)). Once you publish your official version, you can decide whether to use the package. (Translator Note: The nature of the package is a special DLL, with no running package (static) compilation allows your program to run independently from Cbuilder.) , but when debugging, disable it. Press the OK button, we are ready. The next dialog can only be opened once, but it's a good idea to check to see if the following settings are correct. All right, open the tools|. Debugger Options ... ".

The Integrated debugging (integrated debugger) option at the bottom of the dialog box is the key. Make sure that you have already taken the bait. Press the OK button to prepare to compile the executable program. I suggest a complete compilation again (choose Project| Build all), if you have modified your settings (especially after changing the "Building with Packages" mode). This will ensure that all of our program units are compiled as we wish.

Set breakpoints and break into executable programs

Like any of the other debuggers you've seen, C++builder provides powerful breakpoint setup capabilities. Basically, a breakpoint is a point in the code where the program stops (unlike exit, this is just a pause in execution) and returns control to the debugger. Setting a breakpoint is fairly easy. Just click on the gray slot area to the left of the line of code you want to set up, and you'll see a red dot appear and the line will turn red. When the program runs to this point, it pauses, returning control to the debugger.

You might ask if I don't want to stop every time? Sure, and it's easy to do it, depending on what the standard is for you to suspend the program? (Translator Note: conditional breakpoint). Right-click on the breakpoint (red dot) and choose Breakpoint Properties (breakpoint attribute) from the pop-up menu. Here you can set two property "Condition" (conditions) and "Pass Count" (number of passes). Condition (condition) properties are too convenient. You can enter almost any condition using the IF () statement. However, keep in mind all the variables in the condition, and this breakpoint should be visible. The Condition property is not compiled into the executor by the compiler, but at run time, when the program runs until the breakpoint is paused, the condition that the breakpoint is checked is satisfied. The condition is true, stop, otherwise let the program continue to run. Another attribute, pass count, is also easy to understand. The breakpoint will be stopped after pass count times. With these two properties in combination, you can set very strict breakpoints when you debug your code.

Another thing to keep in mind is that when you have an exception in the debugger, it appears in the form of a breakpoint on the line of code where the exception occurred. This situation is easy to make. Once you get an exception, the steps that should be taken will later show how to backtrack in the stack and track down the real cause of the exception (such as the small piece of code that caused the exception).

Another tip to keep in mind is that when you run your program, any line with a blue dot to the left of the code window can be set to a breakpoint. All illegal breakpoints will be turned into red dots with a yellow fork, and this line of code will also become tawny. A legitimate breakpoint becomes a small, green hook with a red dot. At run time, you can set/modify any point where the breakpoint takes effect immediately without recompiling.