Boost logo

Boost :

From: Jason Hise (chaos_at_[hidden])
Date: 2005-02-14 17:23:43


In my singleton code, I have been using a template template parameter in
my lifetimes for the creator[1], so that client code does not need to
duplicate writing the type when specifying the creation policy. The
drawback to this is that the creators which provide additional policies
need to use a nested struct to avoid breaking the template signature
that creators are required to have. A perfect example is the
bool_creator[2]:

template < bool Value >
struct bool_creator{
    template < typename Type >
    class creator
    {
        // pass Value to Type's ctor in create method
    };
};

If I wanted to be consistent, I would be tempted to do the same with my
lifetime policies, separating the Type template parameter from the rest
and having the singleton use a template template parameter for the
lifetime. However, I suspect this would just make client code really
ugly when it tried to specify the lifetime it wanted to use. In
addition, I am willing to bet that a lot of compilers choke on template
template parameters.

As an alternative, I am thinking of switching the creator policy to a
non template template policy. Although this would make client code have
to plug the name of their class into the base singleton template yet a
third time, I am thinking that in the end it would be more portable and
cleaner. Thoughts?

-Jason

[1] Yes, I made the name change from allocator to creator in my code.
The change has not yet been uploaded though, so keep in mind that
creators in this message refer to allocators in the current online code,
and bool_creator is really bool_alloc at the moment.

[2] I'm thinking of dropping bool_creator from the library. Instead of
providing it directly, I'll develop it in the documentation as an
example custom creator and go on to show how it can be used to implement
a zombie singleton. Of course, if you think it should stay in the
library let me know, I can be persuaded to keep it.


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