问题
This question was inspired by this other question. While trying to answer that question, I understood that I have a lot of questions myself. So... Consider the following:
struct S1
{
enum { value = 42 };
};
template <class T> struct S2
{
typedef S1 Type;
};
template <class T> struct S3
{
typedef S2<T> Type;
};
template <class T> struct S4
{
typedef typename T::Type::Type Type; //(1)//legal?
enum {value = T::Type::Type::value }; //(2)//legal?
};
int main()
{
S4<S3<S2<S2<S1> > > >::value;
}
This compiles successfully with MSVC9.0 and Online Comeau. However, what's bothering me is that I don't understand what typename refers to in (1) and why wouldn't we need typename in (2).
I have tried these 2 syntaxes (syntaces?) of what I think it should be both of which fail on MSVC:
typedef typename T::typename Type::Type Type;
enum {value = typename T::typename Type::Type::value };
and
typedef typename (typename T::Type)::Type Type;
enum {value = (typename (typename T::Type)::Type)::value };
Of course, a workaround is to use consecutive typedefs like this:
typedef typename T::Type T1;
typedef typename T1::Type Type;
enum { value = Type::value};
Good style left aside, do we syntactically have to use the workaround I mentioned?
The rest is just an interesting example. No need to read. Not that relevant to the question.
Please note, that although MSVC accepts the original strange syntax without multiple typenames(I mean (1) and (2)), it leads to strange behavior as in the mentioned question. I think I'll present that example in concise form here as well:
struct Good
{
enum {value = 1};
};
struct Bad
{
enum {value = -1};
};
template <class T1, class T2>
struct ArraySize
{
typedef Bad Type;
};
template <class T>
struct ArraySize<T, T>
{
typedef Good Type;
};
template <class T>
struct Boom
{
char arr[ArraySize<T, Good>::Type::value]; //error, negative subscript, even without any instantiation
};
int main()
{
Boom<Good> b; //with or without this line, compilation fails.
}
This doesn't compile. The workaround I mentioned solves the problem, but I am sure the problem here is my initial question - missing typename, but you don't really know where to stick one. Thanks very much in advance.
回答1:
The name before the scope operator :: must always be a namespace or class (or enumeration) name, and namespace names can't be dependent. So you don't have to tell the compiler that this is a class name.
I'm not just making this up, the standard says (section [temp.res]):
A qualified name used as the name in a mem-initializer-id, a base-specifier, or an elaborated-type-specifier is implicitly assumed to name a type, without the use of the
typenamekeyword. In a nested-name-specifier that immediately contains a nested-name-specifier that depends on a template parameter, the identifier or simple-template-id is implicitly assumed to name a type, without the use of thetypenamekeyword. [ Note: Thetypenamekeyword is not permitted by the syntax of these constructs. — end note ]
T::, T::Type::, and T::Type::Type:: are nested-name-specifiers, they do not need to be marked with typename.
This section clearly could have, and arguably should have, included the type-specifier of a typedef declaration in the list of exemptions. But remember that type-specifiers can get really complicated, especially in typedef declarations. Right now it's quite possible to need the typename keyword multiple times in a typedef type-specifier, so a lot more analysis would be needed to convince me that typename is never necessary in a typedef.
In typedef typename T::Type::Type Type, T::Type::Type requires use of the typename keyword, because its nested-name-specifier (T::Type::) is a dependent name, and the standard says (same section):
When a qualified-id is intended to refer to a type that is not a member of the current instantiation (14.6.2.1) and its nested-name-specifier refers to a dependent type, it shall be prefixed by the keyword typename, forming a typename-specifier. If the qualified-id in a typename-specifier does not denote a type, the program is ill-formed.
回答2:
The point of typename is to allow basic checking of a template definition before it is instantiated. Parsing C++ is impossible without knowing whether a name is a type or not (is a*b; an expression statement or a declaration of a pointee b).
In a template definition the category (type or non-type) of a simple identifier is always known. But a qualified (dependent) name cannot be - for arbitrary T, T::x could be either.
So the language allows you to tell the compiler that a qualified name represents a type by using the typename keyword. If you don't, the compiler is required to assume it to be a value type. In either case it is an error to mislead the compiler.
The rule applies even in some cases where it is obvious a type is required (eg in a typedef).
Only the full qualified name requires this disambiguation - typename A::B::C tells you C is a type; there's no need to know anything about A or B to parse the context in which the qualified name appears.
In your example (1) the typename is saying that T::Type::Type is a type. In (2) you must not use typename, because T::Type::value is not a type. Neither case says anything about T::Type because this is irrelevant. (Although one can deduce that it must be a type, because otherwise you couldn't apply :: to it.)
I suspect your problem with MSVC is simply a bug in that compiler (it's notorious that it doesn't handle two-phase lookup properly), although I have to admit I'm not 100% certain.
回答3:
typedef typename T::Type::Type Type; //(1)//legal?
enum {value = T::Type::Type::value }; //(2)//legal?
in (1) you say that T::Type::Type is a type name
in (2) you say nothing about T::Type::Type::value and by default it will be parsed as non-type
回答4:
typedef typename T::Type::Type Type; //(1)//legal?
I myself don't understand the need of typename here. Becuase typedef can be applied only to a typename. Maybe C++ grammer is designed this way.
enum {value = T::Type::Type::value }; //(2)//legal?
You cannot use typename because, it's expected to be a value. It's implicitly logical, that when you write enum { value = ??? };, then ??? must always be a value only.
回答5:
The typename refers to the first dependent type. In your particular case :
typedef typename T::type1::type2 Type;
it refers to T::type1, telling it is a dependent name (depending on the template parameter T).
For a constant value, you do not need a typename, because it is a value - not a type. If the value is not defined, you'll get a compilation error.
EDIT
struct S1
{
enum { value = 42 };
};
template <class T> struct S2
{
typedef S1 Type;
};
template <class T> struct S3
{
typedef S2<T> Type;
};
template <class T> struct S4
{
typedef typename T::Type::Type Type; //(1)//legal?
enum {value = T::Type::Type::value }; //(2)//legal?
};
Lets go slowly through the example. What happens in this S4<S3<S2<S2<S1> > > > type is this : since T is S3<S2<S2<S1> > >, then typename T::Type expands to S2<S2<S1> >::Type, which is a full type (not depending in any way on the template parameter any further). For that reason you do not need to use typename after the first dependent typename.
来源：https://stackoverflow.com/questions/6642721/multiple-nested-dependent-names-where-to-stick-the-typename-keyword