Jonathan Turkanis wrote:

Jason Hise wrote:

...

The following specialization fails to compile on .NET 2002. Is there a good reason as to why, and if not, is there a suggested work around?

template < typename T > class A { };

template < typename T > class B { };

template < typename T > class A < B < T > > // this is the specialization { };

This is partial specialization, which VC didn't support until version 7.1.

If you're working from scratch, there are some workarounds using nested templates; see, e.g., http://www.boost.org/boost/pending/ct_if.hpp.

Using mpl, you might do:

template<typename T> struct is_B;

template<typename T> struct A_primary { /* ... */ };

template<typename T> struct A_specialized { /* ... */ };

template<typename T> struct A : mpl::if_< is_B<T>, A_primary <T>, A_specialized<T> >::type { /* Ctors, etc. */ }

Here it is often sufficient to implement is_B<> using the "sizeof trick". If you are the author of B, and you need is_B<T> to be defined exactly, you can give B<T> a typedef identifying T and use is_same<> together with has_xxx from mpl. I'd say more but I have to run.

Jonathan

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? (And if so, what boost macro should I check?) 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? -Jason