Solving leaks
-
Although they don't replace something like SoftICE, the diagnostic tools in VC are sometimes nice. I have just found a short-indexed loop with a "delete *obj" which caused a leak in my app. The tool I used was _CrtDumpMemoryLeaks(). The documentation has this to say: "_CrtDumpMemoryLeaks is frequently called at the end of program execution to verify that all memory allocated by the application has been freed. The function can be called automatically at program termination by turning on the _CRTDBG_LEAK_CHECK_DF bit field of the _crtDbgFlag flag using the _CrtSetDbgFlag function." This is typical MSDN doublespeak. It's not exactly wrong, just highly misleading. The two methods give different results. If you call _CrtDumpMemoryLeaks() at the end of your app InitInstance for example, it will detect the main window context and your dynalinks (and I suppose any other external linkage blocks as well) and report them as leaks. Even if you overload your WinApp destructor and put the dump as the very last thing you do in the app, the dynalinks are still detected. You may learn to live with this but I wan't only real leaks reported. If you include the following code as suggested above, int tmpDbgFlag = _CrtSetDbgFlag( _CRTDBG_REPORT_FLAG ); tmpDbgFlag |= _CRTDBG_LEAK_CHECK_DF; _CrtSetDbgFlag( tmpDbgFlag ); you will get the correct result and all reported leaks will be your own doing only. I don't pretend to be a Windows guru but this might help some poor sod trying to plug the leaks on the moth-bitten MFC object arrays or the poxy MS STL.
-
Although they don't replace something like SoftICE, the diagnostic tools in VC are sometimes nice. I have just found a short-indexed loop with a "delete *obj" which caused a leak in my app. The tool I used was _CrtDumpMemoryLeaks(). The documentation has this to say: "_CrtDumpMemoryLeaks is frequently called at the end of program execution to verify that all memory allocated by the application has been freed. The function can be called automatically at program termination by turning on the _CRTDBG_LEAK_CHECK_DF bit field of the _crtDbgFlag flag using the _CrtSetDbgFlag function." This is typical MSDN doublespeak. It's not exactly wrong, just highly misleading. The two methods give different results. If you call _CrtDumpMemoryLeaks() at the end of your app InitInstance for example, it will detect the main window context and your dynalinks (and I suppose any other external linkage blocks as well) and report them as leaks. Even if you overload your WinApp destructor and put the dump as the very last thing you do in the app, the dynalinks are still detected. You may learn to live with this but I wan't only real leaks reported. If you include the following code as suggested above, int tmpDbgFlag = _CrtSetDbgFlag( _CRTDBG_REPORT_FLAG ); tmpDbgFlag |= _CRTDBG_LEAK_CHECK_DF; _CrtSetDbgFlag( tmpDbgFlag ); you will get the correct result and all reported leaks will be your own doing only. I don't pretend to be a Windows guru but this might help some poor sod trying to plug the leaks on the moth-bitten MFC object arrays or the poxy MS STL.