a+++b

Quote:

---

Originally Posted by DL1

But surely the compiler doesn't recogize white space?!

---

You're right, it doesn't, but it does solve your "replace ++ with §" problem.

Quote:

---

If the code were unambiguous, it wouldn't matter what order the terms were evaluated in, since they don't affect each other.

---

Would it? I showed an example of how, depending on the order of the parsing, it might give different results. That's because it could be either ++var or ++var! Don't take it for granted ;)
(But I still don't know if it's undefined or not. The easiest way is to just put it in your compiler, compile, see the result and duplicate in another compiler. If it's the same, it's defined, if not, it's undefined.)

If I'm not mistaken the compiler first has to break source code into tokens and obviously it does recognize spaces in the process. A space is a delimiter between tokens.

And also you cannot write:

Code:

---

i+ +;

---

It is possible that the compiler has to follow some well-defined rules. For example here the author quite boldly claims how the compiler would treat an even and odd series +.

>How or why do C compilers know that the expression a+++b evaluates as (a++)+ b?
Normally I don't think the parentheses would be needed here, but the problem with this expression is does it mean:
a++ + b
or
a + ++b?
If either preincrement or postincrement didn't exist, I don't think the parentheses would be necessary. Also I would expect a compile error the above. If not then my guess is it's perfectly ok without the parentheses.

Of course it's OK without them, but the question is: what will the order of evaluation be?
Is it defined? Is it undefined?
That's the problem.
And I don't know if spaces helps resolve that ambiguity.

Consider C99 section 6.4 paragraph 4: "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."

Therefore, C compilers match greedily. Hence a+++b is (a++)+b.

EDIT:
In fact, C99 gives a related example in paragraph 6 of that section:

Quote:

---

The program fragment x+++++y is parsed as x ++ ++ + y, which violates a constraint on increment operators, even though the parse x ++ + ++ y might yield a correct expression.

---

When in doubt, paranthesis eliminate ambiguity.

Excellent.

Max Munch in anon's link above says much the same:

"Similarly, >>> is always interpreted as >> >, never as > >>, and so on."

Of course, this assumes that compilers parse from left to right.

Don't rely on it. It makes code difficult to read.
Use spaces and ()s.

Quote:

---

Max Munch in anon's link above says much the same:

---

Herb Sutter was talking about C++, though for now the rules are the same. (There may be an exception in the next version of the C++ standard so as to allow std::vector<std::vector<int>> and the like, if I remember correctly.)

Quote:

---

Of course, this assumes that compilers parse from left to right.

---

It is quite clear that they do, or perhaps more accurately they parse preprocessing tokens from the first to the last character. Note the C99 example as it is authoritative.

Related item.

Quote:

---

Originally Posted by DL1

But surely the compiler doesn't recogize white space?!

And I don't see that this is an problem of order of evaluation.

If the code were unambiguous, it wouldn't matter what order the terms were evaluated in, since they don't affect each other.

---

My point was to write code for people, not for computers.
Compilers can parse strings in the blink of an eye, but it takes our brains a LOT longer. If you write code that easy for people to read, it will save a lot of time and prevent a lot of bugs.

Not a single post so far contains code that has undefined behaviour. In fact this does not even come into it. The issue here is lexical analysis, not semantic analysis. There are two very distinct phases of a compiler being discussed here.

Nothing about lexical analysis of code is ever undefined. It is either acceptable or not acceptable, and not acceptable means a syntax error.

All that is needed to convey the meaning you intend is to use a space in the right place to force the text to parse into the tokens you intended.

Thanks to lasarlight and Dave we are now certain how the compiler will interpret such expressions. And I'm sure most of us would write the example as:

Code:

---

a++ + b

---

But I'm sure from time to time we'll encounter code written by someone who isn't yet aware that whitespace is free (or is written for obsfucation). And now we'll be able to read such code and know how it's parsed.