Re: [boost] singleton_ptr

From: Jason Hise (chaos_at_[hidden])
Date: 2005-07-19 02:16:58

Pavel Vozenilek wrote:

>"Peter Simons" wrote:
>
>  
>
>>>Others have expressed (perhaps not publicly) that their
>>>preferred method would be that secondary destructions are
>>>simply no-ops, rather than being errors or asserting at all.
>>>Such conflicting interests make it seem like a policy is
>>>indeed necessary.
>>>      
>>>
>>Well, having a policy mechanism won't hurt. I'm all for it. ;-)
>>
>>    
>>
>
>Adding one more policy reduces number of people who
>will use a template. This is equivalent of adding one more
>parameter to a function and seeing people writing their
>own homemade version.
>
>/Pavel
>
Except that I plan to use a different policy mechanism with the new 
version, so that client code need only concern itself with relevant 
policies.  Client code will be able to specialize specific policies for 
a given category, and then just choose a category for each singleton, 
like so:

struct MySingletonCategory;

// must provide specializations in singleton namespace
namespace boost { namespace singleton {

// the following specifies that multi threading will be used for 
singletons which use MySingletonCategory
template <  >
struct threading_policy < MySingletonCategory >
{
    typedef multi_threaded type;
};

// no other specializations provided, so defaults for other policies are 
used automatically

// now tie our specific singleton type to this category
template <  >
struct category < MySingletonType >
{
    typedef MySingletonCategory type;
};

} } // close namespace

void test (  )
{
    singleton_ptr < MySingletonType > ptr; // no policies are specified here
}

Granted, defining a category like so is a bit more work, but client code 
can completely ignore policies that it doesn't care about, and reuse 
useful categories that it has defined for multiple different singleton 
types.  Perhaps macros could be used to make this a cleaner process for 
client code.  With this model, introducing many policies shouldn't cause 
any problems, and policies can even be added retroactively without 
breaking existing code.

-Jason