Michael
Michael

Reputation: 7819

Double closing angle brackets (>>) generates syntax error

Eclipse (Luna, 4.4.2) tells me that I have a syntax error on the following line:

static_cast<Vec<int, DIM>>(a.mul(b));

I remembered that double closing angle brackets >> can lead to problems with some compilers, so I put a blank in between: > >. The syntax error disappears.

However, I have many >> in my program where no syntax error is detected, such as:

Node<Element<DIM>> * e= a.get();

Why do I get an error the above mentioned specific case? This is related to error: 'varName' was not declared in this scope, but I don't know why my compiler does accept a >> sometimes, but not always.

Upvotes: 6

Views: 4519

Answers (2)

T.C.
T.C.

Reputation: 137425

The "right angle bracket fix" is found in §14.2 [temp.names]/p3 (emphasis mine):

When parsing a template-argument-list, the first non-nested > is taken as the ending delimiter rather than a greater-than operator. Similarly, the first non-nested >> is treated as two consecutive but distinct > tokens, the first of which is taken as the end of the template-argument-list and completes the template-id. [ Note: The second > token produced by this replacement rule may terminate an enclosing template-id construct or it may be part of a different construct (e.g. a cast).—end note ]

If the static_cast is otherwise valid, then both pieces of code in the OP are perfectly valid in C++11 and perfectly invalid in C++03. If your IDE reports an error on one but not the other, then it's a bug with that IDE.

It's difficult (and also somewhat pointless) for us to speculate on the source of the bug. A potential cause can be that the second > are closing different constructs (the first case it's closing a cast, the second is closing a template argument list) and the parser's implementation somehow missed the "second > being part of a different construct" case. But that's just wild speculation.

Upvotes: 4

πάντα ῥεῖ
πάντα ῥεῖ

Reputation: 1

You have used a pre c++11 standard compiler. The older standard had a problem letting the parser disambiguate a pair of closing angle brackets >> used in a nested template type specifier, from the operator>>(). Thus you had to write a space between them.

The samples like >>> or >>* are falling under a different case for the old parsers, thus they work without error message.


I have to admit, I don't actually know what exactly was done in the c++11 (the current) standards definitions, that this situation can be clearly disambiguated by a c++11 compliant parser.

Upvotes: 8

Related Questions