Operator Precedence?

I just noticed something a bit strange at the bottom of this page:
http://www.cppreference.com/operator_precedence.html

For this code:

Code:

---

float x = 1;
x = x / ++x;

---

It says:

Quote:

---

The value of x is not guaranteed to be consistent across different compilers, because it is not clear whether the computer should evaluate the left or the right side of the division first. Depending on which side is evaluated first, x could take a different value.

---

But the ++ pre-increment operator is 2 levels above the / division operator, so I don't see why there would be any confusion about what to do first?
Is that page incorrect? If not, how can it be true?

Yes, but when should the compiler grab the value of x to use on the left side of the division: before anything happens, or just when it is needed? You don't know, and I don't know.

>because it is not clear whether the computer should evaluate the left or the right side of the division first.
So is the x on the left side of the division the original x, or the new x? The following suffers from the same ambiguity:

Code:

---

float x = 1;
x = x / x++;

---

Quote:

---

Originally Posted by cpjust

But the ++ pre-increment operator is 2 levels above the / division operator, so I don't see why there would be any confusion about what to do first?
Is that page incorrect? If not, how can it be true?

---

The relative precedence of the operators has nothing to do with it. Precedence only comes into play when there is an ambiguity about which operator should be applied first -- in other words, which expression the operator binds to most tightly. There is no ambiguity here in that regard. The preincrement operator clearly must bind to 'x' and nothing else.

What is ambiguous is whether the left side or the right side of the division expression will be evaluated first.

Quote:

---

Originally Posted by brewbuck

The relative precedence of the operators has nothing to do with it. Precedence only comes into play when there is an ambiguity about which operator should be applied first -- in other words, which expression the operator binds to most tightly. There is no ambiguity here in that regard. The preincrement operator clearly must bind to 'x' and nothing else.

What is ambiguous is whether the left side or the right side of the division expression will be evaluated first.

---

I thought it would have done it in steps:
First do ++x
Then do x / x

If I was writing a compiler, I'm sure that's how I'd make it work.

And since ++ happens before /, I don't see the problem.
x was 0, then it gets incremented to 1, so you have 1 / 1.
The compiler can't see it as 0 / 0 because ++ has a higher precedence, and it would never see it as 0 / 1 would it?

Quote:

---

Originally Posted by cpjust

I thought it would have done it in steps:
First do ++x
Then do x / x

---

What's so special about the right hand side -- why should it get evaluated first?

Quote:

---

If I was writing a compiler, I'm sure that's how I'd make it work.

---

The order of evaluation of subexpressions was deliberately left unspecified so that compilers could actually optimize stuff.

Quote:

---

And since ++ happens before /, I don't see the problem.

---

Why do you think the ++ happens before / ? The order of evaluation is unspecified.

Quote:

---

The compiler can't see it as 0 / 0 because ++ has a higher precedence, and it would never see it as 0 / 1 would it?

---

Again, precedence has absolutely nothing to do with this. If the precedence of / and ++ were reversed the exact same ambiguity would remain.

Quote:

---

The compiler can't see it as 0 / 0 because ++ has a higher precedence, and it would never see it as 0 / 1 would it?

---

Actually, I know a few compilers that will see it as "0/0" with optimizations turned on, but it's unusual for a compiler to try that. Anyway, it depends on how the compiler was designed.

The compiler might see this source as:

Code:

---

++x;
x /= x;

---

or

Code:

---

y = x;
++x;
y /= x;

---

Soma

Quote:

---

Originally Posted by brewbuck

The order of evaluation of subexpressions was deliberately left unspecified so that compilers could actually optimize stuff.

---

OK, maybe I'm not understanding the point of the Order of Evaluation correctly, but I thought it was the same as the order of operations that they teach us in math class.
i.e. 2*4+5/2-6*9 = (2*4) + (5/2) - (6*9) instead of 2 * (4+5) / (2-6) * 9 or anything in between.

Quote:

---

Originally Posted by brewbuck

Why do you think the ++ happens before / ? The order of evaluation is unspecified.

---

A higher precedence means that operation will be evaluated before ones with a lower precedence, right? So how can it be unspecified if ++ is 2 levels higher than /

This has nothing to do with order of operations[*] and everything to do with the fact that you have the same letter in two different places. If it was y/++x, everything would be completely spiffy. But you have x/++x. Does the first x refer to the x we had when we started, or the x we get after incrementing? Yes, ++ happens before /, but that has nothing to do with the problem -- why should what appears on the right side of the division sign affect what appears on the left side of the division sign? The view of the standard is that there is no legitimate use of the expression "x/++x" and consequently the compiler can do whatever it wants.

Quote:

---

Originally Posted by cpjust

OK, maybe I'm not understanding the point of the Order of Evaluation correctly, but I thought it was the same as the order of operations that they teach us in math class.
i.e. 2*4+5/2-6*9 = (2*4) + (5/2) - (6*9) instead of 2 * (4+5) / (2-6) * 9 or anything in between.

---

That's not the question. The question is, do you evaluate the (4+5) first, or the (6*9)? Clearly it doesn't matter, since the result does not depend on that.

Maybe a very simple example will help.

Code:

---

foo() + bar();

---

Will foo() get called first, or bar()? It is unspecified. There is no issue of precedence, since only a single operator is involved here.

Quote:

---

A higher precedence means that operation will be evaluated before ones with a lower precedence, right? So how can it be unspecified if ++ is 2 levels higher than /

---

Precedence has nothing to do with order of evaluation. It has to do with how the operators bind to operands.

Quote:

---

Originally Posted by tabstop

This has nothing to do with order of evaluation and everything to do with the fact that you have the same letter in two different places.

---

No, it is the reuse of the same variable which causes the order of evaluation to start making a difference, whereas in most other situations it would not matter.

Quote:

---

Originally Posted by brewbuck

No, it is the reuse of the same variable which causes the order of evaluation to start making a difference, whereas in most other situations it would not matter.

---

Yes, that's right. I meant order of operations and will edit to reflect that.

http://c-faq.com/expr/evalorder2.html

Perhaps this will explain it better. Take a look at the following line:

Code:

---

result = a() * b() + c() * d();

---

Precedence rules tell us that the parse tree looks like this:

Code:

---

        +
      /    \
    *        *
  /  \    /  \
a()  b() c()  d()

---

instead of for example this:

Code:

---

    *
  /  \
a()    +
      /  \
    b()    *
        /  \
      c()  d()

---

However you don't know what order a(), b(), c() and d() will be called. That's evaluation, not precedence.
It could call c() then d(), then do the second *, then call a, then b, then do the first *, then do the +. If the functions a, b, c, and d all make certain modifications to a global variable and then return the current value of that global variable for example, then different evaluation orders would produce different results.

However, no compiler would be allowed to generate the second parse tree I showed as it has incorrect precedence rules applied to it. Only using brackets could allow such a parse tree to result.

>If it was y/++x, everything would be completely spiffy.
That would be undefined as well if there's an x left of the assignment operator.

The fog is starting to clear, but only slightly. :confused:
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.

Quote:

---

Originally Posted by brewbuck

Precedence has nothing to do with order of evaluation. It has to do with how the operators bind to operands.

---

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?

Quote:

---

Originally Posted by cpjust

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

---

Because they are. But what operator is involved in evaluating "x"? None at all.

Quote:

---

Originally Posted by cpjust

The fog is starting to clear, but only slightly. :confused:
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.

Quote:

---

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.

Quote:

---

Originally Posted by Dave_Sinkula

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

---

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?

Quote:

---

Originally Posted by iMalc

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

---

Well I was thinking about the old value being returned and used in the other lower precedence operation, then incremented, so who knows when the other occurances of that variable should change to the incremented value... But now it's starting to make sense.

Quote:

---

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. :p

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 :p
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 :p
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.

Quote:

---

Originally Posted by Salem

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.

---

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

Using an example that uses only variables & operators like this helps explain things better:

Code:

---

int x = 0;
y = ++x / x++;

---

My previous line of thinking was that since ++ has a higher precedence than /, x would be incremented (so x on both sides now equals 1), then it would do y = 1 / 1, then increment x again.
But since that would be confusing for developers and harder to optimize, I guess that's why they just threw their hands up and said "ah screw it, lets just make it undefined".

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

Quote:

---

But since that would be confusing for developers and harder to optimize, I guess that's why they just threw their hands up and said "ah screw it, lets just make it undefined".

---

Erm, well, not quite like that. The reason that we have sequence points is to force you to be explicit about evaluation order. C is an imperative language, which means that computing an accurate result involves narrowing the number of possible outcomes.

a[i] = i++;
That's a statement that has at least a couple of outcomes for i. You're at the mercy of when the compiler executes the increment, before or after the assignment, because it's not exactly clear when i's state should change. That's what they mean when they say assignment has side effects: it changes the program environment.

a[i] = i + 1;
This one has only one outcome.

And like Salem said, f() + g() * h() will compute a result based on precedence, but the compiler can execute the functions in any order because there are no sequence points. This may be immaterial to the calculation and it may not be.

Quote:

---

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.

Quote:

---

Originally Posted by iMalc

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.

---

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

I haven't had to worry about precedence much in the past because I always use lots of parenthesis to be extremely explicit about how I want things evaluated. But since I started working with this crappy code at work, I found a ton of ambiguous statements like:

Code:

---

if ( rc = SomeFunc() == ERROR_SUCCESS )

---

I'm sure the person who wrote it, meant for it to mean:

Code:

---

if ( (rc = SomeFunc()) == ERROR_SUCCESS )

---

but when I checked the precedence rules, I found it actually means:

Code:

---

if ( rc = (SomeFunc() == ERROR_SUCCESS) )

---

Quote:

---

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.

> But giving an example using functions instead of values is a little off topic since functions aren't mentioned in the Operator Precedence rules.
If you wrote
f + g * h;
it wouldn't change anything, because evaluating a variable still involves say moving from a memory location to a register.

> I guess that's why they just threw their hands up and said "ah screw it, lets just make it undefined".
Pretty much.
It's all to easy to argue that it might be possible to make something simple like ++x / x++ defined, but remember the spec assumes arbitrary complex expressions. If you had like 10 side effects on 6 different variables, you'd be in a much tougher spot.
Then compiler writers would have a hell of a job writing and testing the code, and programmers would have a hard time understanding all the rules.

As it stands, it's a very simple rule which is very unambiguous.

Quote:

---

Originally Posted by Dave_Sinkula

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

---

Yet another thing that's missing from that http://www.cppreference.com/ site... :(

Are there any compilers that actually give you a warning that you're invoking undefined behavior?
I tried compiling this on Comeau and VC++ with max warning levels, and neither of them said a word:

Code:

---

int main()
{
  int x = 0;
  x = ++x / x++;

  return x;
}

---

gcc:

Quote:

---

../main.c:4: warning: operation on `x' may be undefined
../main.c:4: warning: operation on `x' may be undefined

---

Quote:

---

Originally Posted by Dave_Sinkula

gcc:

---

Cool. I wonder why the others don't complain?
Another thing that gcc does that I wish VC++ would is that it tells you if you're missing some cases in a switch statement on an enum type.

Quote:

---

Originally Posted by cpjust

Another thing that gcc does that I wish VC++ would is that it tells you if you're missing some cases in a switch statement on an enum type.

---

I believe PC-lint will do that.

A command-line tool that costs $230. Wow. Even more expensive than Visual Assist X.

Quote:

---

A command-line tool that costs $230

---

compiler is also command line tool... so? what's your point?

Quote:

---

Originally Posted by Elysia

A command-line tool that costs $230. Wow. Even more expensive than Visual Assist X.

---

Heh. Amortize that over the cost of bugs.

Point was that it was expensive. Very much so.
(And I cannot help but see how pretty much all recommended tools here are command-line based. PC-lint, gdb, valgrind, etc.)

Quote:

---

Originally Posted by Elysia

Point was that it was expensive. Very much so.
(And I cannot help but see how pretty much all recommended tools here are command-line based. PC-lint, gdb, valgrind, etc.)

---

Point is - the compiler used by VC is also command line tool - still you are recomending to use VC to compile code...

the best feature of command line utils is - you can easely integrate them into the IDE you are using...

> Point was that it was expensive. Very much so.
Unless you're in the business of writing s/w, in which case $230 buys you a few hours of ONE engineer's time. Add up all those 'several hours' spent finding stupid bugs which pc-lint will find in a few seconds, and pretty soon it looks like a bargain.

Ya, for business maybe, but for a private dev (read: no business/company), it's very expensive for a software.

Quote:

---

Ya, for business maybe, but for a private dev (read: no business/company), it's very expensive for a software.

---

To put that in perspective, Visual Studio 2008 Standard edition costs $299. So, just as such a developer would be forced to do without PC-lint due to the cost issues, he/she would be forced to make do with Visual Studio 2008 Express edition, despite it being targeted at hobbyists and students instead of professional developers. That's life for a lone developer struggling to balance the budget, I guess :(

Quote:

---

Originally Posted by laserlight

To put that in perspective, Visual Studio 2008 Standard edition costs $299. So, just as such a developer would be forced to do without PC-lint due to the cost issues, he/she would be forced to make do with Visual Studio 2008 Express edition, despite it being targeted at hobbyists and students instead of professional developers. That's life for a lone developer struggling to balance the budget, I guess :(

---

Yeah, it's a shame. Thankfully there's Professional for students now :)
But $230 is still a lot for some extra tools...

PC-lint is a very complex tool, easily as complex as a compiler.

$230 is expensive. That doesn't mean it's priced incorrectly or not worth it.

Agreed, but I was never hinting at that it was incorrectly priced.
I just feel it's such a shame that the price is so high. Many will not be able to afford such a thing. To companies, it's like sticks and stones, but to private users who just develop on their free time...

Quote:

---

Originally Posted by laserlight

To put that in perspective, Visual Studio 2008 Standard edition costs $299. So, just as such a developer would be forced to do without PC-lint due to the cost issues, he/she would be forced to make do with Visual Studio 2008 Express edition, despite it being targeted at hobbyists and students instead of professional developers. That's life for a lone developer struggling to balance the budget, I guess :(

---

Well VC++ express is free. So if I'm just writting a program for myself at home, that's probably what I'm going to use since I don't really need all the bells & whistles of the Pro edition. But I'd still like to see if I have any bugs that the compiler (for some strange reason) doesn't tell me about. I think this would also be great for students who could barely even notice a simple bug, let alone these subtle ones.
Anyways, I hope someone at the VC++ team of Microsoft is reading this. ;)

I don't have a Windows port of gcc available, but do the errors Dave found also get reported on the Windows gcc compilers? If so, that might be one free alternative.

Quote:

---

Originally Posted by cpjust

I don't have a Windows port of gcc available, but do the errors Dave found also get reported on the Windows gcc compilers? If so, that might be one free alternative.

---

What I posted was from Code::Blocks' MinGW gcc.

Quote:

---

I just feel it's such a shame that the price is so high. Many will not be able to afford such a thing. To companies, it's like sticks and stones, but to private users who just develop on their free time...

---

A. cry all the way to the bank.
B. use splint.

Choose one.

$230 is really not a lot of money. It's a bargain! Even for the lone, struggling, non-student developer.

Cutting on Saturday nights, juggling here and there on spurious expenses, I can imagine a low income programmer being able to buy PC-Lint after, say, 6 months of saving for it. That's really a worst case scenario.

Looking at those $230 as an investment and not money you throw away in a pair of pants or getting out to the movies, is the key.

EDIT: The only annoying tidbit being perhaps that you get the same for free if you change to linux ;)

Er... what?! O_o

Splint isn't even comparable to PC-Lint for C++ source, and I don't know of anything Splint will catch that 'g++ -Wall -Wextra' will not. Heck, for one thing, Splint will happily pass invalid C++ source.

If you're not talking about Splint I'd love to know what you are talking about.

Soma

Quote:

---

Originally Posted by phantomotap

Splint isn't even comparable to PC-Lint for C++ source

---

That's because Splint doesn't analyze C++ code, but C. However it can, and will detect many problems common to both programming languages if you take the time to set it up to ignore most C++ constructs.

The point Citizen tried to put across, I believe, is cough up the money or go by with unsuitable tools that will demand a lot of configuration. Or, go by without 'em.