[boost] Re: Re: VC 7.0 template specialization problems

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