Thread: Operator Precedence?

Originally Posted by cpjust

The fog is starting to clear, but only slightly.
I can see why post-incrementing could cause problems, but pre-increments are supposed to happen before the values are used...
As for functions like a() / b(), they aren't listed in the Operator Precedence, so they're definitely undefined.


Then why does that site (& MSDN...) say "The operators at the top of this list are evaluated first."?

By "how the operators bind to operands", are you talking about the Left to Right or Right to Left Associativity?

I think what you may be looking for are sequence points.

Originally Posted by cpjust

I can see why post-incrementing could cause problems, but pre-increments are supposed to happen before the values are used...

Used which time? One occurrence of x could be evaluated before it sees the one with the ++ in front of it.
The compiler doesn't have to make a pass over the entire expression beforehand to perform all preincrements and another pass afterwards to perform all the post increments. It is free to do each of these when it first encounters the per/post increments whilst it evaluates the expression, which is likely to be more efficient, and both ways are allowed by the standard.

I'm not sure why you can see there would be a problem with postincrement, and not see essentially the same problem with preincrement.

Originally Posted by cpjust

Aha! OK, now after my 2nd glass of wine, things are starting to make sense.

When I saw this statement:

Code:

a[i] = i++;

(assuming i = 0 before that line)
my first instinct would have been that it means something like this:

Code:

a[i] = i;  // i.e.  a[0] = 0;
i = i + 1;

but (if it wasn't undefined), since ++ is higher than = it would probably end up being something like:

Code:

temp = i;
i = i + 1;
a[i] = temp;  // i.e.  a[1] = 0;

So the reason why statements like that are undefined are:
1. To make compilers & optimizers easier to write.
and
2. To prevent us from making some stupid mistakes.

Is that about right, or did I miss anything?

I believe so. But then again I've read and re-read that FAQ dozens and dozens of time -- but the beer is just not helping.

What I try to take away is remembering where to revisit when I think certain constructs look suspect and to in general avoid such critters like the plague.

[aside]Perhaps my true epiphany was one day seeing that 'more C = less assembly, in some cases', and even being a minimalist this struck a chord.[/aside]

This may or may not help, but I think I'll throw it in just for the sake of it
Give a formula such as: x = y / z
In math, it would be easy: just divide y with z.

Now, let's try to try play a compiler
Because the data needed for the instructions needs to be stored inside the processor registers, the compiler needs to read the data, and then store it in a register before performing the opcode.

So, basically it should happen like:
Store the value of variable y into register A.
Store the value of variable z into register B.
Perform opcode.

But there's no telling in what order it might store the data, so it might just as well do:
Store the value of variable z into register B.
Store the value of variable y into register A.

So, if we re-write the formula as z = x / ++x
The compiler can do

(Left to right)
Store the value of x (left side) into register A.
Store the value of x (right side) into register B and increment it.
Perform opcode.

But on the other hand, it might do:

(Right to left)
Store the value of variable x (right side) in register B and increment it.
(At this point, the value of x is now original x + 1, which must be reflected inside the variable x. In debug mode, I assume the compiler will write back the new value to the variable x, but in release, I assume it might just try to move the contents of register B directly into register A.)
Store the value of variable x (left side) [which is now original x + 1] into register A.
Perform opcode.

Which would invoke undefined behaviour. Certainly, the compiler can do other optimizations, too. If the values are of different variables, then technically it shouldn't matter since the value of those variables would not affect each other during the phase the compiler fetches them and puts them into registers. So no bad behaviour there.

Anyway, I think that's a little of how I see it.
(Although I don't know if it's 100% what happens, especially with the ++x.)

Given
f() + g() * h();
The only thing the operator precedence table tells you is that * happens before +, and that's all.
In which order the 3 functions are called is totally up to the compiler (evaluating the operands).

On a register-rich machine, you could imagine f() being called first, but on a register-poor machine, perhaps it's called last.

The C/C++ standard has made a lot of behaviour undefined to make it work on as many platforms as possible and allow for optimizations =)
I remember reading bjarne would like to redo C++ and get rid of all that undefined if he could, but that would break literally every program out there, so that's something that was a big no-no

Originally Posted by cpjust

But giving an example using functions instead of values is a little off topic since functions aren't mentioned in the Operator Precedence rules.

Not really. For ++x, what if x is a class that provides a preincrement operator? Then evaluating ++x could be identical to evaluating x.foo() where foo has code that does a preincrement.
In both cases it is a unary function that applies to the immediate object.

Originally Posted by cpjust

But operator++() would be included in the precedence rules, since ++ is an operator, whereas SomeOtherFunc() isn't.

Most garden variety charts show the function call operator in the list of operators.