The function compares the current memory state with the one at the program start, and if any unnalocated memory block is found, it returns
TRUE
and prints some debug information on the output window. So, to use it effectively, without false positives, one must call it when all objects are out of scope. Here’s an example:#include <crtdbg.h> #include <string> int WINAPI wWinMain(HINSTANCE, HINSTANCE, LPWSTR, int) { std::wstring name = L"abcdef"; _CrtDumpMemoryLeaks(); // will accuse a leak! return 0; }In the code above, there will be a false positive, because the string object didn’t go out of scope yet, therefore its destructor wasn’t called so far, so there’s still memory allocated. But this would rather lead to our expectations:
#include <crtdbg.h> #include <string> int WINAPI wWinMain(HINSTANCE, HINSTANCE, LPWSTR, int) { { std::wstring name = L"abcdef"; } _CrtDumpMemoryLeaks(); // no leaks! return 0; }Now, since the string was declared within the scope of the nested block, its destructor will be called when the nested block ends, and no memory will remain allocated after it. This way, _CrtDumpMemoryLeaks will correctly report no leaks; indeed, nothing will be printed to the output window.
And the function is removed when
_DEBUG
is not defined, so you don’t need to worry about it on your release builds.I particularly found it useful to use the _CrtDumpMemoryLeaks call inside an _ASSERT macro, so that when a memory leak is found, a huge popup will honk right in my face, in addition to the debug messages. So I actually proceed like this:
_ASSERT(!_CrtDumpMemoryLeaks());