From: Chris Newbold (Chris.Newbold_at_[hidden])
Date: 2008-07-23 07:37:40
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> On Behalf Of Joaquin M Lopez Munoz
> Sent: Tuesday, July 15, 2008 9:42 AM
> There is no such guarantee indeed, but the fix does NOT rely on
> rules for non-local objects, but on the initialization rules for *local*
> objects with static storage duration (6.7/4): the singleton is a local
> object inside the function singleton_default<T>::instance(), which is
> explicitly invoked inside fast_pool_allocator ctors via
> singleton_pool<...>is_from() (if you apply the fix, that is).
Quite right. I now agree your suggested fix is completely sound.
And, in fact, making your suggested fix re-orders the construction of the pool and allocator objects as expected. I tried the experiment with GCC 4.1.2.
The next step is for me to audit the remainder of the pool library and see if there are other clients of singleton_pool which are subject to the same potential failure mode.
Are there any "better" suggestions out there for handling the singleton needs of the pool library?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk