Use of typename keyword with typedef and new

C++ syntax is more crazy than that.

// typedef NOT followed by a type!
int typedef A;

// new NOT followed by a type!
new (0) int;

Others have commented about your example. The typename specifier does not yield to lookup ignoring non-type names. So if you say new typename T::X, and there is an object name X in T, it will still be found instead of the type name X (GCC however ignores non-type names in looking up a name after a typename. But that’s not Standards compliant).


Answers to edits:

Consider this,

T::X typedef *x;

So from the context, it’s still clear enough to the compiler that T::X is a type, no matter whether it appears before typedef,or after typedef.

The compiler has to know when the declaration specifiers and (i.e the “type section” and when the declarator section start (i.e the “names” section). There are declarations where the type section is empty:

// constructor definitions don't need a type section
MyClass::MyClass() { }

// conversion function definitions don't need a type section
MyClass::operator int() { }

If the first name you specify is not a type, the type section ends, and the name section starts. Saying T::X tells the compiler:

Now I want to define T::X.

It reads from left to right, so it will think you forgot a semicolon when it then encounters the typedef. Inside classes the interpretation is slightly different but much like this too. That’s a simple and effective parse.

Same argument holds true for new as well.

I tend to agree with you here. Syntactically it should be unambiguous if you leave off parentheses. As I’ve never written a C++ parser, there may be hidden pitfalls I’m not seeing, though.

Every addition of typename in corner cases of the language like in new will potentially require substantial amount of design for both compilers and standards writers, while still requiring typename for the vast majority of other cases where it’s needed. I don’t think that this pays off.

Leave a Comment