Features of the Debug C Run-Time Library

The main claim to fame for the DCRT library is its wonderful heap memory tracking support. All the memory allocated through standard C/C++ memory allocation functions, such as new, malloc, and calloc, can be tracked in debug builds. The tracking checks for memory underwrites, in which your program writes past the beginning of a block of memory, and memory overwrites, in which your program writes past the end of a block of memory. All those errors are reported through an assertion from the DCRT itself. The tracking also monitors and reports memory leaks in your application when the application ends because of calls to OutputDebugString, whose output appears in the Output window of the debugger. If you've been writing Microsoft Foundation Class (MFC) library programs, you've probably noticed the memory leak reports when your application ends; those leak reports come from the DCRT library. MFC partially turns on the DCRT library for you automatically.

Another neat feature of the DCRT library is the reporting subsystem, which you and I would call trace, through its _RPTn and RPTFn macros and assertion support. I introduced the DCRT library assertion support in Chapter 3 and explained some of the issues associated with using it. As I mentioned, the DCRT library assertions are good, but they destroy the last error value and therefore could cause debug and release builds to behave differently. For your assertions, I strongly recommend that you use the SUPERASSERT assertion code that's part of BUGSLAYERUTIL.DLL.

Another nice feature of the DCRT library is that its source code is included with the compiler. Table 17-1 lists all the files that make up the DCRT library. If you elected to install the CRT library source code when you installed Microsoft Visual Studio .NET, which I highly recommend doing, you can find all the CRT and DCRT library source code in the <Visual Studio .NET Installation Directory>\VC7\CRT\SRC directory.

Table 17-1: Debug C Run.Time Library Source Files

Source File	Description
DBGDEL.CPP	The debug global delete operator.
DBGHEAP.C	All the debug heap-handling functions.
DBGHOOK.C	The stub memory allocation hook function.
DBGINT.H	The internal debug headers and functions.
DBGNEW.CPP	The debug global new operator.
DBGRPT.C	The debug reporting functions.
CRTDBG.H	The header file you include. This file is in the standard include directory.

Common Debugging Question: Why do I need the debug C run-time library if I'm using an error detection tool like BoundsChecker?

Error detection tools such as Compuware's BoundsChecker and Rational Software's Purify automatically handle memory underwrites, memory overwrites, and memory leaks. If you use one of these tools, you might think that using the DCRT library isn't worth your time and effort. Technically, that's true, but to ensure that you find all your memory problems, you need to run your application under your error detection tool every time anyone on the team runs a debug build of the application. "Anyone" includes you, your fellow developers, and if you followed my advice from Chapter 2, even your quality engineers. I just don't see everyone being that vigilant.

Using the DCRT library is like having good fire or theft insurance. You hope you'll never need to use the insurance, but if you do, it can be a lifesaver. Any time you can validate data in your application, you should. The DCRT library doesn't impose a drastic performance hit, and it can unearth some outstanding bugs. You should always use it—even if you have all the tools in the world.