Hacker News new | comments | show | ask | jobs | submit login

1a) not so sure, because it could be x+(+3)

But yeah, gcc throws an error

If you put the parenthesis it works

He didn't put it into parenthesis.

I know that, I'm using parenthesis to explain what the compiler "might think"

No decent compiler would attempt to correct that by adding parenthesis!

It's not about a parenthesis. It's about the compiler not understanding all valid possibilities.

x+ +3 works.

x++3 doesn't.

OK, I take it back. That's logical.

Technically speaking though, the compiler could see it as x+ +3, but it could equally see it as x ++3, which has two compiler errors: firstly, that's not actually a valid expression, and secondly (at least as I checked in the C99 standard, under section on postfix increment and decrement operators) the lvalue must be modifiable.

All I guess I'm saying here is that it could technically be a typo which leads to invalid syntax, or it could be technically correct, so most compilers will treat it as a syntax error.

Someone above said that gcc was being "closer to the standard", but the standard never attempts to cover this particular corner case. So the gcc devs have done something, to my mind, quite sensible. They treat it as a possible syntax error because it could either be:

  x+ +3;
  x++ 3;
  x ++3;
I'm more interested in how it handles x+++x; - I'd imagine that it's a syntax error. It could be:

  x++ + x;
  x + ++x;
  x+ + +x;
The C99 standard doesn't actually explain how to handle this. Perhaps they believe you shouldn't be so daft.

I'll stand by original statement that it's a syntax error and most good compilers will treat it as such, even if it is logical to treat x++3 as x+ +3.

Edit: scratch that ALL completely. I forgot about operator precedence.

If you take x++3, then suffix increment is a higher operator than suffix decrement and addition. In other words, the compiler will always try to evaluate the expression as

  x++ 3;
In other words, it's a syntax error. It can never evaluate to x + +3, because that's at a lower operator precedence.

Thus, it's a syntax error. Take that, downvoter of my original comment.

Edit x2: Definitive answer is here: https://news.ycombinator.com/item?id=5200523

Some days it just doesn't pay to get out of bed... :-)

Thanks for the pointer to my answer :-)

Similar text to that C++ text is in C99 at 6.4 [Lexical elements], paragraph 4. Paragraph 6 considers the example x+++++y (which is similar to your example), noting that it is to be parsed as x ++ ++ + y. (I guess it uses distinct variables x and y to avoid any distractions due to sequence point issues -- which are immaterial here as the thing fails to parse anyway.)

Sometimes I think that the C and C++ standards authors entered into the IOCCC before they wrote the examples :-)

> but it could equally see it as x ++3

What it could see is not a valid argument. A compiler could "see" all kinds of absolutely valid situations as invalid, but it doesn't.

Give me an example.

It could see

as two division operators and throw an error, but it considers it a comment (to be fair, comments are probably removed by a pre-processor).

No, it couldn't. That's a comment, and only a comment. It can't be anything else. Do you have any other examples?

It also works if you add a space:

    x+ +3;
I always thought the unary plus operator is a complete waste, and shouldn't be implemented. I can't imagine a situation when it's needed.

EDIT: technically, it's a bug in GCC. It sees "x++" and assumes it's a unary increment, followed by a hardcoded 3. It definitely should consider that it's an addition followed by a unary plus (which has higher precedence than addition). But I guess it's an ambiguous syntax, and GCC is just being strict.

This is not a bug in GCC. The compiler is required to interpret this as the syntactically-invalid "y = x ++ 3 ;" by the common so-nicknamed maximal-munch property of lexers for various languages. In the 1998 C++ standard, this is in section 2.4/3:

"If the input stream has been parsed into preprocessing tokens up to a given character, the next preprocessing token is the longest sequence of characters that could constitute a preprocessing token, even if that would cause further lexical analysis to fail."

This is the same reason why (prior to C++11) nested templates have to be written with an excess space: "std::vector<std::list<int> > foo". (C++11 has a lexer hack to allow a >> token to be valid here and equivalent to two > > tokens.)

For this ++ example, if you want the valid parse, you get to put the space in yourself, just like we're used to for nested templates. This is the trade-off for having a fast mostly conceptually-separate lexer.

Unary plus is nice if you want to write out the symmetry in things like "int signum[] = { -1, 0, +1 }" and I expect there are meaningful uses in ensuring desired conversions occur in some overloading situations (though there would of course be a case for being explicit...).

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact