Boost logo

Boost :

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-04-22 14:33:26


Jason Hise wrote:

> Here's the context of my question: I recently added a new lifetime
> policy for my singleton class. However, instead of providing an
> interface which the general definition of singleton accepts, it is an
> empty class. Directly underneath this empty class I provide a partial
> specialization of singleton in which all the changes are made. It is
> a partial specialization because all of my lifetime policies have sub
> policies of their own. I do this because the general version of the
> singleton definition will automatically have the overhead of
> maintaining the lifetime of the lifetime, which is unnecessary overhead for
this
> policy and actually gets in the way (the whole point of this lifetime
> policy is to be as low overhead as possible). Right now, this policy
> class and the specialization it offers are in a separate include file
> from the primary singleton definition. My fear is that the method
> above will require that both implementations be defined in the same include
> file, and be tightly bound together, making the code less organized
> and more difficult to maintain.

> Would it be terrible of me to disable compilation of this lifetime in
> cases when partial template specialization is not supported?

No -- in fact you're free to disregard such compilers if you want.

> (And if
> so, what boost macro should I check?)

BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION

>Another lifetime exists which
> essentially offers the same functional behavior (destruction in
> reverse order of creation). The only difference is that it has more overhead
> in terms of memory usage (another hidden singleton living in the
> background), and as a result has a few more features (can create and
> destroy at an arbitrary time) and is a bit safer to use (supports
> phoenix behavior). When space is not an issue, losing this new
> lifetime will not really result in the loss of any features.

> Is it worth uglifying my code to support a low overhead lifetime on
> compilers that do not support partial template specialization? Should
> this question wait until the formal singleton review?

You might be able to implement this policy without partial specialization, using
the tricks I discussed; however, there's no need to do so if you don't want to.
It sounds like all you need to do may be to add an #error directive if the
header containing the new lifetime policy is included but the compiler doesn't
support partial specialization.

Jonathan


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