Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk