Re: [boost] [pool] pool-based allocators and order of destruction

Subject: Re: [boost] [pool] pool-based allocators and order of destruction
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-05-23 12:59:04

John Maddock wrote:
>
> I'm looking for second opinions on this bug report:
> https://svn.boost.org/trac/boost/ticket/5526#comment:1
[snip]
> I see a number of solutions:
>
> * Document the limitation and leave it at that.
> * Make the singleton eternal and leak the pool's memory at
> program exit.
> * Use some kind of complex reference counting scheme so the
> pool is only
> destroyed when all it's memory has been released *and* main has
> exited.
>
> To be honest, I'm not thrilled by any of the above, but any
> opinions?

I leak Singletons to avoid late referencing problems.  The OS cleans up the memory, of course, so the only problem is memory checking tools that complain about the leak.  Those can be configured to ignore the Singleton, and the docs can describe the behavior and rationale, so I consider that a quick, safe, and practical solution to the problem.

If you want to avoid most memory leak complaints, you could create a second object that, upon destruction, asks the Singleton to release its dynamic resources.  Then, if the Singleton is not actually used further, only the Singleton itself is leaked.  OTOH, if there is a late use of the Singleton, it is still valid and can reacquire, and subsequently leak, whatever dynamic resources it then needs.  (Then again, many memory checking tools look for leaks before statics are destroyed, in which case you are better off just letting the Singleton leak without extra steps.)

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.