Chris Newbold <Chris.Newbold <at> mathworks.com> writes:
From: boost-bounces <at> lists.boost.org [mailto:boost-bounces <at>
lists.boost.org]
On Behalf Of JOAQUIN M. LOPEZ MUÑOZ Sent: Friday, July 11, 2008 11:35 AM
BTW, have you tried the fix I was proposing?
Not yet. I'm on vacation this week, but I will try it as soon as possible. My only concern is whether referencing singleton_default from the constructor for fast_pool_singleton will guarantee proper initialization ordering.
3.6.2 doesn't really shed any light on how ordered and unordered initialization may be coupled. There isn't, for example, any expressed guarantee that non-locals will be initialized prior to first reference.
There is no such guarantee indeed, but the fix does NOT rely on initialization 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 static 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). The non-local object involved in singleton_default<T>, namely singleton_default<T>::create_object is there to guarantee that singleton_default<T>::instance() is invoked, and thus the singleton created in dynamic initialization time *if no one has done it before*. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo