Reputation: 7819
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
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