Memory AllocationsTracking
This topic applies to:
Edition |
Visual Basic |
C# |
C++ |
Web Developer |
|---|---|---|---|---|
Express |
.gif "Topic does not apply") |
|
Native only |
|
Standard |
|
|
Native only |
|
Pro and Team |
|
|
Native only |
|
Table legend:
.gif "Topic applies") |
Applies |
|
Does not apply |
.gif "Topic applies but command hidden by default") |
Command or commands hidden by default. |
In MFC, you can use the macro DEBUG_NEW in place of the new operator to help locate memory leaks. In the Debug version of your program, DEBUG_NEW keeps track of the file name and line number for each object that it allocates. When you compile a Release version of your program, DEBUG_NEW resolves to a simple new operation without the file name and line number information. Thus, you pay no speed penalty in the Release version of your program.
If you do not want to rewrite your entire program to use DEBUG_NEW in place of new, you can define this macro in your source files:
#define new DEBUG_NEW
When you do an object dump, each object allocated with DEBUG_NEW will show the file and line number where it was allocated, allowing you to pinpoint the sources of memory leaks.
The Debug version of the MFC framework uses DEBUG_NEW automatically, but your code does not. If you want the benefits of DEBUG_NEW, you must use DEBUG_NEW explicitly or #define new as shown above.