Hi

Below is my sample code :

<code/>

int main(int argc,char *argv[])
{
int i = 1 ;
printf("%d%d%d", i++,--i,i--);
return 0;
}

</code>

When I complied this code with version gcc version 3.4.6 output was -1 -1 1 (expected) as c++ comuptes from left to right.

However when I complied it with gcc version 4.6.2 . output was -1 0 1.

Please explain this beahviour .

Thanks

No, it does not. The order of evaluation depends on operator precedence and associativity. So, for example,
will be evaluated from left to right, but

will be evaluated from right to left.

You should also note that the C(++) standard does not specify order in which the function arguments will be evaluated, so this may very well depend on compiler and compile options such as optimization.

You may also examine the assembly code of your program to see what exactly happens there.

Edit: Also, read this

It is the order of evaluation of function arguments that is germane here. In this case, the ',' (comma) is not an operator, but simply a token separator. The C language says that the order of evaluation of function arguments is compiler dependent, therefore undefined.
This is a classic example of why you should not use such a construct.

--- rod.

1 members found this post helpful.

This is not just an order of operations issue.

C++ does not specify which sequence the parameters are computed in, so any change in the way you compile could change that sequence (optimization level, compiler version, platform, phase of the moon).

But the problem is more serious than that. Multiple changes to the same variable in one expression is expressly undefined behavior. You not only have no reasonable expection of what sequence i++, --i and i-- will occur in, you have no reasonable expectation that they will all even occur. The value of i when this expression completes is unpredictable.

If this were just an order of evaluation issue, the three values passed to printf would be unpredictable within a very narrow range, while the resulting value of i would be reliably reduced by a net 1. In actual C++ the values passed are unpredictable across a wider range and the resulting value of i is also unpredictable.

The standard goes even further in specifying that use of an undefined construct make the entire behavior of the whole program undefined. You can't rely on what three values get passed to printf. You can't rely on what value ends up in i. You also can't rely on anything else done by any part of your program. In my opinion, the first two of those are very real concerns in a case like this and the third is silly. But the standard says all three should be concerns.

1 members found this post helpful.

It is silly and wrong.
Concentrate on good practice - not bad.
Life is too short.