Coolquest, Inc.	Home	Products	Support	About	Contact
C++BOLD Reference Manual

17. Tips and Tricks

17.1. Debugging

17.1.1. Compile-Time Errors

This section discusses errors reported by your C++ compiler. Compilers are capable of detecting hundreds of types of errors. At times, these errors can seem less than helpful. Some tips regarding compile-time errors follow.

Seek additional help from your IDE. Some IDE's have help pages that explain error messages in more detail. For example, some versions of Borland C++ Builder will display context-sensitive help when you select an error message and then press F1.

Seek help on the World Wide Web. A search of usenet discussion forums for keywords from an error message will often yield sound advice.

Be sure your include path is complete. If your compiler is unable to open an include'd file (e.g., cb_base.h), you need to make sure the file exists and the file's directory is in the include path. Check your IDE's help to find out how to modify your project's include path. Note that the compiler usually knows where to find standard header files that are indicated with less-than/greater-than brackets (e.g., #include <iostream>).

Recognize Linker Errors. Some errors are caused by the linker not being told to link a required file. All .cpp files must be compiled and linked. Typically you must add each .cpp file to your project so that your IDE knows that the .cpp file is to be compiled and linked into the executable.

Avoid common mistakes that may lead to confusing error messages. Some mistakes may cause a misleading error message. The most common is omitting a required semicolon, e.g., after the closing brace of a class definition.

17.1.2. Runtime Errors

This section discusses errors that CBOLD reports as well as fatal errors such as crashing. The CBOLD error handling mechanism is described in the Error Handling section. CBOLD error messages attempt to provide you with sufficient information to locate the source of the error within your code. Sometimes, however, CBOLD lacks all the information that could help you pinpoint the error. For example, if your design attempts to make a connection to a port that you forgot to register, CBOLD cannot tell you the name of the port.

The following tips will help you find your errors.

Use your debugger. The most common source of errors for a new CBOLD user is failing to register a module, part, bundle or port. Because the object is not registered, CBOLD cannot tell you its name. But CBOLD will typically tell you where and when it first detected the non-registered object. For example, it might tell you that it detected an error while module MyModule was connecting. If you set a breakpoint at the first line of MyModule's Connect() function, re-run the program until it reaches the break point, and then single step until the error is again thrown, you can identify the statement that triggered the error.

If a module is not registered, then none of its members are registered. The registration pass descends automatically through the hierarchy. If you forget to register a module, none of the hierarchy within the module will be registered. So if your single-stepping with the debugger leads you to believe that a particular port is not registered, but then you find that it is registered, check that the port's parent module is registered. If it is, check its parent.

Use the auto_reg Support Tool. auto_reg will automatically register most members for you. See auto_reg.

If your design is crashing, hanging, generating access violations or the like, consider these tips:

Have enough memory allocated. If your design is large, the your IDE's default stack and heap size settings may not be sufficient for your design. Some signs that you may not have enough memory allocated are: (1) your design compiles but crashes when run, (2) your design used to work fine, but when you added to the design it began to crash or behave unusually. Check the project's memory settings in the IDE.

Consider moving your Root declaration to before main(). The Root instance of CM_Root is normally declared as a local variable within main(). This implies that Root and all of its members (i.e., your entire design) will be allocated on the stack. If you declare root outside of main(), it will be allocated on the heap. A minor advantage of declaring Root within main() is that the declaration can be made within the try{ } block. This allows handling of exceptions (e.g., error messages) thrown by CM_Root's constructor.