Dear Ion,
thank you for your reply. I should have said, sorry, that I am using
Boost 1.49.0. I can see that such singletons would show up as memory
leaks. In your example, already including
boost/interprocess/managed_shared_memory.hpp seems to lead to the
creation of some singletons that are falsely reported as memory leaks.
However, there seems to be more than just these singletons, that is
additionally created when managed_shared_memory::construct is actually
used. Please consider the following example:
// The following three directives are required for MSVC's automatic
memory
// leak detection.
#define _CRTDBG_MAP_ALLOC
#include
El 25/04/2012 12:35, Michael Herrmann escribió:
Hello everyone,
the following trivial example highlights a memory leak according to MSVC 2010. Does anybody know why this is and how it can be avoided?
Interprocess creates some singletons for expensive operations and you are testing for leaks before those singletons are destroyed. The following test, in visual 10:
#define _CRTDBG_MAP_ALLOC #include
#include #include
static struct leak_detector { ~leak_detector() { _CrtDumpMemoryLeaks(); } } leak_detector_object;
int main(int argc, char *argv[]) { _CrtDumpMemoryLeaks(); return 0; }
The CrtDumpMemoryLeaks() call in main will be executed first and will report leaks (singletons are not still destroyed). The second _CrtDumpMemoryLeaks() called from the static variable will be called after interprocess singletons are destroyed (it's compiler dependent, but in my configuration the static variable is destroyed after interprocess singletons are destroyed) and reports no leaks.
Ion _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users