Re: [boost] Re: Re: Re: FSM Review

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.
>
>/Pavel
>  
>

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 >
{
private:
    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.  (http://boost-sandbox.sourceforge.net/vault/)

-Jason