Re: Specialization oddities
* Daniel Kr?gler:
I always wondered about the following restriction
differences between explicit and partial specialisations
of member templates of class templates.
Consider the following snippets (A) and (B):
(A) Explicit specialization of member template:
template<class T> class A1 {
template<class U> class B1;
};
template<class T>
template<> // ERROR!
class A1<T>::B1<float>{};
(B) Partial specialization of member template:
template<class T> class A2 {
template<class U> class B2;
};
template<class T>
template<class U>
class A2<T>::B2<U*>{}; // OK
The rules which forbid (A) but allow (B) are
mainly specified by
1) 14.7.3/18:
"In an explicit specialization declaration for a
member of a class template or a member template
that appears in namespace scope, the member
template and some of its enclosing class templates
may remain unspecialized, except that the
declaration shall not explicitly specialize a class
member template if its enclosing class templates
are not explicitly specialized as well.[..]"
2) 14.5.4.3/2:
"If a member template of a class template is partially
specialized, the member template partial
specializations are member templates of the enclosing
class template;[..]"
-------------------------------------------------------------------
The point I want to discuss is: How come that we
have more restrictions here for explicit specializations
compared to partial specialization?
First, for other readers: the standard's "explicit specialization"
really means "full specialization", that all template parameters have
been fixed to actual types or values.
And one different between a full specialization and a partial one is
that machine code can be generated for the full specialization, it's a
real class or function, but not for the partial one, which is still just
a pattern to be fleshed out by actual template parameters.
Note: this is just a guess of mine, noting what the seemingly main
difference is.
Consider now
template< typename T >
struct Argh
{
template< typename U > struct Bah {};
};
template< typename T >
template<> // Not allowed.
struct Argh<T>::Bah<float> { T ahum; };
Well, there's no way that machine code can be generated for Bah<T,
float>, because it's not fully specialized (not considering here the
kind of code that would be generated for "export").
So, my hypothesis goes, instead of allowing that, the standard landed on
giving "template<>" the clear, unambigious meaning of "fully
specialized" (which it calls explicit specialization), meaning that the
class or function can be instantiated, that machine code can be generated.
And if something like the above is desired, then it can always be
rewritten as partial specialization, like
template< typename T, typename U > struct ArghBah {};
template< typename T >
struct Argh
{
template< typename U >
struct Bah { typedef ArghBah<T, U> Type; };
};
template< typename T >
struct ArghBah<T, float> { T ahum; };
It's just a little notational inconvenience, writing
"Argh<bool>::Bah<float>::Type" instead of "Argh<bool>::Bah<float>".
And perhaps adding a friend declaration if necessary.
So, essentially, my guess for the rationale is that the standard forces
partial specialization to be expressed as partial specialization,
reserving the notation "template<>" for full specialization, without
limiting what you can achieve, only how you express it.
I speculated for a minute or so that without this rule one could risk
exponential or infinite code generation, but then I failed to come up
with any example, so I don't think it's that, just clear notation.
Hth.,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]