6

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.

Improve this question
8
  • "This is NOT a duplicate" I well explained the c++ parser ambiguity with the operator>>() for pre c++11 standard compilers. >>> doesn't fall into that parsing case, thus it works. Commented Mar 29, 2015 at 16:18
  • Ok, i removed the >>> case which is misleading. But there are still several >> cases in my program which do not lead to a syntax error. Your post does not say anything whether >> does lead to problems in any or in specific cases, and that's what I'm wondering about. Commented Mar 29, 2015 at 16:29
  • The asterisk * could also make well a difference for the parser. Essentially it boils down to that mentioned ambiguity with operator>>. Commented Mar 29, 2015 at 16:31
  • Better use a space between closing brackets, if you don't want to get the compiler to get confused with the shift operator >>, thus > >... Commented Mar 29, 2015 at 16:39
  • 1
    @Michael I have to agree your question is better by means of a more canonical way to ask about the problem. Upvoted. Commented Mar 29, 2015 at 16:40

2 Answers 2

Reset to default
8

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

I'm not really convinced. It's the same problem in all three cases - maximum munch means that >> is being parsed as one token, not two. Perhaps the problem is with the second > not actually closing a template argument list in the first case (it closes the static_cast instead), but it's hard to tell without extra testing.
@T.C. Well, you have a good point. I'm not even sure either. The OP's use cases seem to improve the answer, that it's basically about an ambiguity with operator>>(). Could even be compiler implementation dependent. I'm eager to see, how the c++11 standard actually fixed this (added the language-lawyer tag).
The fix is in N1757. The construct is perfectly valid in C++11; the problem is definitely with the parser used by the IDE.
4

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.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.