[Solved] Global shared_ptr
Author
This is a question that *really* makes me feel like a newbie, but...can anyone suggest a way to have a global boost::shared_ptr? My game uses only shared_ptrs, no raw pointers, but none of the global objects are getting deleted, since they're always defined as so:
--header file:
extern shared_ptr<Thingy> gCoolThingy;
--file scope in a .cpp file:
shared_ptr<Thingy> gCoolThingy;
--in actual code for the first time:
gCoolThingy.reset(new Thingy());
Is this a totally stupid question -- is "global shared_ptr" an oxymoron?
[Edited by - Sol Blue on January 4, 2008 9:22:48 PM]
Global shared pointers well be deleted when the program finishes execution provided the program exits normally by execution continuing off of the end of the main() function.
It's not an oxymoron, just a bit silly.
They SHOULD be deleted AFTER main returns ASSUMING you do indeed return instead of hard exiting ala exit(0) or some such. How are you determining they aren't getting deleted?
They SHOULD be deleted AFTER main returns ASSUMING you do indeed return instead of hard exiting ala exit(0) or some such. How are you determining they aren't getting deleted?
exit() may call some destructors. Usually for objects with static allocation, which includes globals, but it generally doesn't call the destructors for objects on the stack.
Author
Thanks for the responses. I do indeed do a normal return out of my main function.
I have a breakpoint in one of the destructors, and by breaking on a bunch of memory allocations that the debugger says is leaking.
Quote:Original post by MaulingMonkeyHow are you determining they aren't getting deleted?
I have a breakpoint in one of the destructors, and by breaking on a bunch of memory allocations that the debugger says is leaking.
How are you getting the debugger to tell you memory leaks? Some leak detection methods don't properly detect deletion of memory cleared by globals.
Author
Quote:Original post by SiCrane
How are you getting the debugger to tell you memory leaks? Some leak detection methods don't properly detect deletion of memory cleared by globals.
I have this code in my main function:
#if defined(DEBUG) | defined(_DEBUG) //_crtBreakAlloc = 49; _CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ); #endifThen in Visual Studio's output window, at the end of the program, I get stuff like this:
Detected memory leaks!Dumping objects ->c:\program files\microsoft visual studio .net 2003\vc7\include\crtdbg.h(689) : {298} normal block at 0x00FA6CE0, 16 bytes long. Data: <Hi Hi f h > 48 69 FA 00 48 69 FA 00 FC 66 FA 00 F8 68 FA 00 c:\program files\microsoft visual studio .net 2003\vc7\include\crtdbg.h(689) : {297} normal block at 0x00FA6C90, 16 bytes long.I think I may have a cyclical dependency somewhere in my shared_ptrs, though, so it may not be a problem with the components being global. : / I'm trying to untangle it ATM. I'll post again when/if that proves to be the solution.
You don't need the #if around the _CrtSetDbgFlag() call. _CrtSetDbgFlag() is a macro that compiles out to nothing in non-debug builds. In any case, that method should only trip on legitimate leaks given that your execution continues off of main().
Author
Oh, thanks -- I'll take the DEBUG guards out then.
I think I might have solved my problem...things are tentatively looking good without that cyclic dependency in there.
Thanks for everyone's help -- sorry for kinda wasting your time. :(
I think I might have solved my problem...things are tentatively looking good without that cyclic dependency in there.
Thanks for everyone's help -- sorry for kinda wasting your time. :(
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
