a+++b

Hello all,

This is probably a trivially easy question, but here goes anyway:

How or why do C compilers know that the expression a+++b evaluates as (a++)+ b?

In the expression a+(++b), the prefix increment operator has a higher precedence than the binary + operator, which suggests to me that the parentheses are unnecessary and that a+(++b) too could be rewritten as a+++b. Also, associativity would appear to me to be irrelevant here, since we are dealing with operators of different precedence, which in itself should determine the sequence in which the operations are carried out.

Clearly I am missing something here but I have no idea what. I have been right through K&R and can't find any help there.

Sorry if this seems like a stupid question; I have only been learning C for a few weeks.

You will not find stuff like that in K&R because it is undefined behavior according to the C standard.

So does that mean that to comply with the standard you must use parentheses?

These gentlemen don't appear to think there is anything wrong with the expression without parentheses:

http://publications.gbdirect.co.uk/c...rithmetic.html


"Because the unary operators have very high precedence, you can work out what they do before worrying about the other operators. One thing to watch out for is the way that ++ and -- can be before or after their operands; the expression

a + -b++ + c

has two unary operators applied to b. The unary operators all associate right to left, so although the - comes first when you read the expression, it really parenthesizes (for clarity) like this:

a + -(b++) + c"

If you use more than one number and perform operations such as -, ++, -- with or without parenthesises, the result is undefined. The end.
The problem isn't about which operators goes first, but because the compiler is not required to finish the line is linear order.
If it looks like a b c, then the compiler can finish c first, then a and then b. But some other compiler may do it a, b, c. So the result is undefined.

Crappy code = crappy results.

Quote:

---

Originally Posted by Elysia

If you use more than one number and perform operations such as -, ++, -- with or without parenthesises, the result is undefined. The end.
The problem isn't about which operators goes first, but because the compiler is not required to finish the line is linear order.
If it looks like a b c, then the compiler can finish c first, then a and then b. But some other compiler may do it a, b, c. So the result is undefined.

---

I get your point, but in my example a+++b there are only two operands, and the question is surely not "what order should be operators be executed in?", but "what are the operators?"

Anyhow, if the answer is simply that this is crappy / non-standard code and therefore there is no definite answer to the question, I can accept that.

Quote:

---

Originally Posted by DL1

Anyhow, if the answer is simply that this is crappy / non-standard code and therefore there is no definite answer to the question, I can accept that.

---

The problem isn't the order of the operators. It's the order of the number and in what order the compiler assembles them.
And besides, in your example, is the code
(a++)+b or a+(++b)? How is the compiler supposed to know? The compiler doesn't necessarily execute the the result from left to right.

So the result can be (a = 10, b = 20), 10 + 20 or 10 + 21. There's no way to tell.

Quote:

---

Originally Posted by Elysia

If you use more than one number and perform operations such as -, ++, -- with or without parenthesises, the result is undefined. The end.
The problem isn't about which operators goes first, but because the compiler is not required to finish the line is linear order.
If it looks like a b c, then the compiler can finish c first, then a and then b. But some other compiler may do it a, b, c. So the result is undefined.

---

Are you actually sure that these expressions here are undefined? Otherwise you might just as well claim that the following idiomatic expression is undefined.

Code:

---

while ((*a++ = *b++));

---

If I'm not mistaken the undefinedness comes to play when you apply side-effects to the same variable more than once within sequence points.

I would definately use brackets for something like a+++b, though.

This might not be undefined:
(a++)+b
Or
a+(++b)

But I'm almost certain that...
a+++b
...is undefined, since the compiler can evaluate the expressions in any order.

(Or on second thought, the whole darn thing is mind-boggling, so I can't be sure. I haven't used any expression other than a++ = b++ or a = b++ or a++ = b.)

This strikes me as a deficiency in the language then: We have an expression that in itself is (or at least may be) meaningful and evaluable but is possibly uncompilable simply because the C tokens are themselves not distinguishable. If the increment operator were denoted by, say, § rather than ++, then you would have either a§+b or a+§b and no ambiguity.

This is rather disillusioning...

Quote:

---

Originally Posted by DL1

If the increment operator were denoted by, say, § rather than ++, then you would have either a§+b or a+§b and no ambiguity.

---

That is not the problem.
If all compilers read the code from left to right, it would become
(a++)+b
And if from right, it would be
a+(++b)

Actually, the problem, YOUR problem is that you don't use spaces:
a++ + b
a + ++b

No ambiguity there.
And the problem lies in the order of evaluation, as explained above.

At best it is undefined how the compiler parses that expression. (This has nothing to do with the undefinedness of i = ++i). You might also be able to remove the ambiguity by introducing whitespace: a++ +b vs a+ ++b.

There are other interesting parsing cases, e.g a++b (doesn't compile) vs a+ +b.

Even if the compiler could read it properly, I'm sure Humans couldn't.
If it was even like this I could understand it (although it would be easy to miss-read if I didn't have my coffee yet):

Code:

---

a + ++b or a++ + b

---

There's a reason spaces were invented. ;)

Order of operation. As the parser reads the equation it sees

a ok we are operating on the variable a
a++ ok we are incrementing the variable a after this operation

+b ok we are adign b to the equation.

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.

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.