0

I got stuck in operator precedence problem...In the first look it looks quite easy but it is really hard ...and i run it on DEV as well as Visual studio but it gives different output and i m completely shocked .here is my code

#include<iostream>
using namespace std;
int main(){
int a=0;
a=++a*++a*a++;
cout<<a<<endl;
}

it gives 8 output in Dev and g++ but 9 in Microsoft Visual studio 2013, any help would be appreciated ...Also plz tell me in which order does these operators call each other so that to get the desired output on the console.

Mohsin Mushtaq
  • 93
  • 1
  • 8
  • Hmmm... I'm getting 9 on both MinGW-g++ and MS Visual Studio. g++ is giving warnings though: 'warning: operation on 'a' may be undefined [-Wsequence-point]' This seems to be the connonical SO answer to this: http://stackoverflow.com/questions/24853/what-is-the-difference-between-i-and-i – Will Jun 05 '15 at 17:12
  • but really i m getting 9 on visual studio 2013 and 8 on g++ – Mohsin Mushtaq Jun 05 '15 at 17:15
  • *Whatever* you intended `a=++a*++a*a++;`, even if its behavior were well defined, there is certainly a clearer way to express your intent. For example, you could replace both lines by `int a = 8;` or `int a = 9;`. – Keith Thompson Jun 05 '15 at 18:36

3 Answers3

1
a=++a*++a*a++;

Should be 

++a;++a; //a = 2, because you have the two pre-increments.
temp = a * a; //temp = 4
temp = temp * a; //temp = 8
a = temp; //a = 8
a++; //a = 9, for the post-increment.

So you should probably report this to the compiler teams along with your CPU specs.

However, according to gnu.org regarding operator precedence:

In C you cannot assume that multiple subexpressions are evaluated in the order that seems natural. For instance, consider the expression ++a * f(). Does this increment a before or after calling the function f? The compiler could do it in either order, so you cannot make assumptions.

(Note that the above is taken from the GNU c manual).

So technically this is not a bug, even though it's inconsistent.

Short term solution: 

a = 9;
Keith Thompson
  • 254,901
  • 44
  • 429
  • 631
JSideris
  • 5,101
  • 3
  • 32
  • 50
  • I'd like to see what your code compiles to in a assembly :). – JSideris Jun 05 '15 at 17:29
  • + for intermediate steps – Will Jun 05 '15 at 17:36
  • no it's not a bug - only if you consider the standard *the bug* – BeyelerStudios Jun 05 '15 at 17:41
  • Yes you may be right. I'll update my answer. – JSideris Jun 05 '15 at 17:44
  • consider `a = a++ - 1;`: is it `a = a - 1; ++a;` or `tmp = a; a = a - 1; ++tmp`? your answer suggests the first. – BeyelerStudios Jun 05 '15 at 17:49
  • No because the expression does not get assigned to a until it has fully evaluated. This is a more pathological example. It would be tmp = a - 1; a++; a += tmp; – JSideris Jun 05 '15 at 17:53
  • But I see your point there is actually an error in my expression above. The second *= would actually evaluate to 16. I'll fix it thanks. – JSideris Jun 05 '15 at 18:00
  • This isn't merely a matter of allowing different evaluation orders. The behavior is undefined; the possible results are not limited to evaluating the subexpressions in different orders. The standard joke is that it can legally make demons fly out of your nose. – Keith Thompson Jun 05 '15 at 18:34
  • Well, the answer is essentially based on what you would expect if compilers followed proper order of precedence. I know that's not how the compilers actually do it though, but this should at least result in the expected result (hopefully). Could you give an example of something completely unexpected that the expression might do, aside from evaluating sub expressions out of order? – JSideris Jun 05 '15 at 18:40
0

f you really wrote code like this, you are in trouble. Better you must to use aux variables like 

#include<iostream>
using namespace std;
int main(){
int a=0;
int aux = ++a;
a=aux*aux*a++;
cout<<a<<endl;
}

or something like this to solve the ambiguity.

If you question is for learning purposes, there are cases that has no an unique result, because is the way that the compiler solve this equation.

Dr.dobbs's Magazine show several cases like this, and all equations haven't an exact result.

I can't get now some page to show code you never will use, to avoid bugs like this.

Just for example: http://www.cplusplus.com/forum/beginner/26383/

FOP
  • 962
  • 1
  • 10
  • 21
0

This is a sequence-point issue, and should have warned you about it if you have -Wsequence-point enabled. In essence your statement is undefined, and is why different compilers give different results.

Please look at a previous answer to this problem: undefined-behavior-and-sequence-points

Community
  • 1
  • 1
Dave
  • 1
  • 2