If you are calling _CrtDumpMemoryLeaks()
at the end of the main function the behaviour is expected, since mp_data
will be deleted after _CrtDumpMemoryLeaks()
was called.
You would need to call _CrtDumpMemoryLeaks()
after the last destructor of you static objects has been called (or rather in the last destructor after the memory has been freed) if you don't want to see these leaks (quite a difficult task, I wouldn't try it).
The cleaner approach is to allocate all your static objects on the heap instead (at the beginning of main
), and de-allocate them at the end of main
, and then you can call _CrtDumpMemoryLeaks()
and won't see any memory leaks.
FYI static objects with constructors and destructors are considered bad anyways, because the order in which they are constructed/destructed is not deterministic, and because of that static objects often introduce bugs which can't be debugged easily.
Edit regarding Andrey's comment:
You could try to deactivate the automatic call to _CrtDumpMemoryLeaks
by calling _CrtSetDbgFlag to unset the _CRTDBG_LEAK_CHECK_DF
flag. If that works, you can add a static object which calls _CrtDumpMemoryLeaks()
in its destructor. To make sure that this object is destructed last, you can use the #pragma init_seg(compiler) directive.
No clue if this will work... Other than that, all other solutions will most likely require you to modify the ITK library (which should be possible, it's an open source library after all?!).
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…