Teach Yourself Borland C++ in 14 Days - portal

Using the Debugger
The diagnostic macros are declared in a file called checks.h, so you need to add the line
#include
to your source code as well. If you neglect to include checks.h, you will get a compiler error
on any lines that contain TRACE or WARN.
Tracking Down GPFs
NOTE
All Windows programmers have encountered general protection faults and general protection
exceptions while developing their applications. For simplicity, I will refer to both
universally as GPFs.
The term GPF is a holdover from 16-bit Windows. Its use is still
prevalent in the 32-bit Windows programming world even though
32-bit Windows actually generates access violation errors rather than
general protection faults.
GPFs can be difficult to track down for beginning and experienced Windows programmers
alike. Often, as programmers gain experience in writing Windows programs, they develop
a sixth sense of sorts regarding locating the cause of GPFs. The following sections describe
some things to look for when trying to track down the elusive GPF. These are not the only
situations that cause a program to crash, but they are some of the most common.
Uninitialized Pointers
An uninitialized pointer is a pointer that has been declared but has not been set to point to
anything meaningful in your program. An uninitialized pointer will contain random data.
In the best case it points to some harmless spot in memory. In the worst cases the uninitialized
pointer points to a random memory location somewhere in your program. This can lead to
erratic program behavior because the pointer might point to a different memory location each
time the program is run. Always set pointers to NULL both before they are used for the first
time and after the object pointed to is deleted. If you try to access a NULL pointer, your program
will GPF, but the offending line in the source code will be highlighted by the debugger, and
you can immediately identify the problem pointer.
421
11