clang上的C ++模板定义失败，适用于GCC

Question

The following code compiles on GCC (doesn't even require a recent version), but it fails on clang 3.4:

template <int N>
struct T_unsigned {
    typedef typename T_unsigned<N>::Type Type;
};

template <> struct T_unsigned<8> {
    typedef unsigned char Type;
};

Using the above definition of T_unsigned, GCC allows you to use "T_unsigned<8>::Type" instead of "unsigned char". When I try to compile this using clang 3.4, I get:

test.cpp:3:41: error: no type named 'Type' in 'T_unsigned<N>'
    typedef typename T_unsigned<N>::Type Type;
            ~~~~~~~~~~~~~~~~~~~~~~~~^~~~
1 error generated.

Is clang failing to compile correct C++11 code, or is this code doing something non-standard that GCC happens to support?

Answer 1

In your general case T_unsigned<N> , we have:

A name is a member of the current instantiation if it is

[...]

• A qualified-id in which the nested-name-specifier refers to the current instantiation.

   [ Example: template <class T> class A { static const int i = 5; int n1[i]; // i refers to a member of the current instantiation int n2[A::i]; // A::i refers to a member of the current instantiation int n3[A<T>::i]; // A<T>::i refers to a member of the current instantiation int f(); }; 

Within T_unsigned<N> , T_unsigned<N> is just another name for itself. So basically you have something like:

class Foo {
    typedef Foo::Type Type;
};

and the "correct" error message should be approximately ( http://ideone.com/FvJHBF ):

     prog.cpp:2:17: error: ‘Type’ in ‘class Foo’ does not name a type
     typedef Foo::Type Type;
             ^

However, you write that you have problems with using your specialization T_unsigned<8> , which is seemingly not found by clang.

Your testcase is not too exhaustive, so my answer depends on an if-statement:

If at the point of instantiation, your specialization for N=8 is visible, than clang is doubly wrong. If not, gcc and clang should both fail, but with aforementioned error message (though the error message itself is in no way defined by the standard, so this is a tool's should , not a standard's).

Answer 2

The name that you use as the typedef is not dependent (see the clauses that define dependent names) and the namelookup in definition context at that place will not find a declaration. That in itself is an error already.

But since there is no declaration for the name yet, the name is also not a member of a class that is the current instantiation or a base class thereof. Therefore the name is not a member of the current instantiation and therefore we have another reason to reject it by a rule that says that if the qualifier is the current instantiation, the name either must refer to a member of that instantiation, or to a member of an unknown specialization (which would be the case if the class had dependent base classes).

Note the notion of "current instantiation": the meaning of the qualifier is fixed to refer to the result of instantiating the surrounding template, we don't wait for resolving the template arguments. Hence the term is not called "current specialization", since we know that it refers to an instantiated specialization, as opposed to a later declared explicit specialization.

The thing is different for C++03 I think. The name will be dependent and the template definition is harder to deem illformed with the rules available. The illformed, no diagnostic required, behavior will however happen when you try to instantiate the template before providing the explicit specialization. I think such code refering to itself makes no sense because you never are able to actually instantiate the template validly (and there is a rule that allows rejecting a template straight away in such cases).