Boost logo

Boost :

From: Jason Hise (chaos_at_[hidden])
Date: 2005-03-12 07:02:27

Pavel Vozenilek wrote:

>"Andreas Huber" wrote:
>>>>2. At runtime. Each TU could have one static variable of a type with
>>>>a constructor. Inside the ctor you register your part of the FSM
>>>>with the FSM object. This sounds like it could work. Problem is that
>>>>the standard does not give many guarantees when exactly these static
>>>>objects are constructed. You can *hope* that they are constructed
>>>>before the FSM object and on some platforms they actually are
>>>>constructed at program startup but there's no guarantee for that.
>>>Just note: Singleton library (the one written by Jason Hise)
>>>allows guaranteed construction order for objects in multiple TUs.
>>I guess it does that with the Andrei's longevity technique? That would be
>>contrary to the scalability requirements, because you manually have to
>>give the parts unique ids.
>Either this or other technique available in Singleton.
>If the IDs could be generated and assigned dynamically
>then this could be done during statics initialization time too.

If any singleton A needs to be created before and live loner than any
singleton B, the code is as simple as:

class A : public basic_singleton < A >

class B : public basic_singleton < B >
    A::pointer a_ptr;

The first pointer to a singleton creates the singleton. Because B's
pointer to A is created before B completes construction, A is guaranteed
to be created first. In addition, it is guaranteed that basic_singleton
based singletons are destroyed in reverse order of creation, so A will
outlive B.

There are other ways provided to control the order of creation and
destruction, which are easy to use and explained at length in the docs
packaged with the library. The lib is available in the sandbox, under
the singleton folder. (


Boost list run by bdawes at, gregod at, cpdaniel at, john at