operator precedence problem?

Question

Possible Duplicate:
Compilers and argument order of evaluation in C++

i have a print statement like below...

  int i=0;
  printf("%d,%d,%d,%d,%d,%d",i++,i,++i,i--,++i,i);

according to precedence i++,i,++i,i--,++i,i should be evaluated like below step by step...

0,i,++i,i--,++i,i   // after this i=1;

0,i,++i,1,++i,i    //  after this i=0;

0,i,++i,1,1,i      //  after this i=1;

0,i,2,1,1,i       //   after this i=2;

0,2,2,1,1,2       //   after this i=2;

and final result as i think from this logic should be...

 0,2,2,1,1,2

but i am getting 2,2,2,1,2,2 what is the reason behind this?

btw i m using visual c++ 2010...

The behavior you observe has absolutely no relation to operator precedence. Moreover, operator precedence does not determine order of evaluation "step by step". Where did you get that strange idea? — AnT, Aug 31 '11 at 17:54
I get 1,1,1,1,1,0 for my turbo c compiler well i can explain the order of evaluation for the turbo c compiler i dont know about vs 2010 as guys saying it depends on compiler mostly1 — niko, Aug 31 '11 at 17:55
@niko i know how it works on turbo c evalution starts from right to left one variable at a time; but on vs2010 it's not rational answera s i don't see any logic! — teacher, Aug 31 '11 at 17:57
in any order. The program with such code is not allowed by C/C++ standards, and standards can't say what result will be printed. — osgx, Aug 31 '11 at 17:58
@teacher: Nobody knows how it executes it. In C/C++ languages the notion of "step" is defined by so called *sequence points*. Everything that happens between sequence points is one single indivisible step. It cannot be decomposed into smaller steps and, therefore, it cannot be meaningfully analyzed further. — AnT, Aug 31 '11 at 18:08

score 8 · Answer 1 · answered Aug 31 '11 at 17:50

That's undefined behavior. The order of evaluation of the arguments to a function is specifically left unspecified by the C and C++ language standards in order to let the compiler produce the most optimal machine code across a broad range of hardware.

You're not allowed to modify a variable more than once between sequence points. The language standard says that sequence points only come at particular points in your code, such as at the semicolons that delimit statements. There is a sequence point after the initial assignment int i=0;, there is a sequence point after printf returns, and there is a sequence point after all of the arguments to printf have been evaluated but before printf actually gets called, but there is not a sequence point in between the evaluation of each of the arguments.

More important, it is an implementation decision as to when the increment/decrement operators are executed. The implementation may at their discretion: — Nicholas Carey, Aug 31 '11 at 17:54

score 2 · Answer 2 · answered Aug 31 '11 at 17:49

Not.

The comma operator here:

a,b;

and the comma which separates functions arguments:

f(a,b);

are different.

Only real comma operator will be a sequence point and will order evaluation of left and right arguments (a and b expressions in my example).

And the comma between function arguments is not a sequence point and order of argument evaluation is undefined (even same compiler may evaluate them in different order in different call sites). Also, it is illegal (undefined behaviour) to change the same lvalue (i variable in your example) twice or more times in the part of program between sequence points. Every modification of same object must be separated by sequence point (e.g. with ;) from another modification of the same object.

Christian Rau · Answer 3 · 2011-08-31T18:00:06.947

1

The comma in your case is not the , operator that guarantees evaluation in sequence, but belongs to the function call syntax and the sequence in which function arguments are evaluated is undefined. So your code should surely exhibit undefined behaviour (which it seemingly does).

edited Aug 31 '11 at 18:00

answered Aug 31 '11 at 17:49

Christian Rau

43,206
10
106
177

1

Correct, those aren't comma operators. – Keith Thompson Aug 31 '11 at 17:51

score 0 · Answer 4 · answered Aug 31 '11 at 17:49

0

It's up to the compiler what code it generates. Evaluation order of the arguments of a function call is not defined.

answered Aug 31 '11 at 17:49

Karoly Horvath

88,860
11
107
169

operator precedence problem?

4 Answers4