side effects

[CornedBee]

This is incorrect. The implementation (I'll drop into C++ standard lingo for now) is required to evaluate the (x=0) before the ^, but it is not required to do so before the x; nor is it required to do so afterwards. The implementation could, for instance, evaluate x, fetching its value into a CPU register, then evaluate (x=0), fetching the result into another register, but not writing the value back yet, then executing the ^. If x is declared volatile, the implementation must write the value of x back at this point, as the call of a function constitutes a sequence point. If it is not, the implementation can, in theory, delay until the next time x is actually used after the sequence point.

The second example follows the same principle, but it's more obvious.

In essence, you are violating clause 5.1 of the standard, which, in the final draft, says:

Between the previous and next sequence point a scalar object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored.

Emphasis mine. You are accessing the prior value (but is it?) for purposes other than determining the value to be stored. Your program is ill-formed.


This is based on my understanding of the standard, which is far from trivial. If you want an answer you can really trust, you should ask the question on comp.lang.c++.moderated and watch the ensuing flame war

[aewarnick]

I assumed the same as riis. In my opinion, parenthesied expressions should always be evaluated first.

By the way, kedaman, thanks for turning me on to Opera! It is so much better than Firefox!!

[riis]

This is incorrect. The implementation (I'll drop into C++ standard lingo for now) is required to evaluate the (x=0) before the ^, but it is not required to do so before the x; nor is it required to do so afterwards. <snip/>

Ah, I see, the ^ isn't relevant here. Any binary operator could've caused this "effect".

It's pretty much the same as that the evaluation order of function parameters doesn't have a fixed order, but can also be compiler-optimized, right?

[CornedBee]

Ah, I see, the ^ isn't relevant here. Any binary operator could've caused this "effect".

Not quite. The , && || operators create sequence points.

It's pretty much the same as that the evaluation order of function parameters doesn't have a fixed order, but can also be compiler-optimized, right?

Right.