Finding memory leaks in a non-MFC app can be difficult
because the debugger doesn't display path and line number
info in the debug window. But, it's quite easy to
enable that info. Here's how:
Copy this to a file called LeakWatcher.h
void* operator new(size_t nSize, const char * lpszFileName, int nLine)
return ::operator new(nSize, 1, lpszFileName, nLine);
#define DEBUG_NEW new(THIS_FILE, __LINE__)
#define MALLOC_DBG(x) _malloc_dbg(x, 1, THIS_FILE, __LINE__);
#define malloc(x) MALLOC_DBG(x)
#endif // _DEBUG
#endif // #include guard
_CrtDumpMemoryLeaks(); at the end of your program
(or wherever you want to see outstanding memory allocations).
Add this to each of your source files (after your last
#define new DEBUG_NEW
static char THIS_FILE = __FILE__;
What does it do?
This does the same thing an MFC app does -
it provides the path and line number of each allocation
to the C-runtime allocation routines. Those routines store
the path and line number for each allocation, and spit
them out when you call
_CrtDumpMemoryLeaks();. You should
recognize that little chunk of code in step 3 from every source
file that the AppWizard (and ClassWizard, mostly) has ever created.
Why not just use _CRTDBG_MAP_ALLOC?
#define _CRTDBG_MAP_ALLOC will provide
file/line info for leaks caused by
malloc, but for leaks with
it ends up telling you that the leak occurred in
(because that's where MS defined their
new) - not really useful.
This represents about ten minutes of searching
through Microsoft's C runtime and MFC source files.
So, all of the credit goes to MS. But, all of the
blame goes to MS, too, for not making this part of the non-MFC headers.
Anyway, have fun and be excellent to each other.