side effects

[kedaman]

I'm trying to get this to work:

int k=1;
assert(k^(k=0));

but it seems like the VC2003 compiler is assigning k first no matter which side i put it. When I do this however:

int k=1,j=0;
assert((j=k)^(k=0));

it evidently assigns k after evaluating the left side. Is this standard? Is there any way around it without using another variable?

[CornedBee]

There is no standard covering any of this. The variable values are only defined at sequence points, of which there are none within the statements you care about. The behaviour of your code is compiler-dependent in both cases. VC++ just happens to evaluate the inner parts from left to right - a different compiler might choose the right side first. Even VC++ might choose the right side first, if the optimizer thinks that's a good idea.

[riis]

Expressions within parentheses are always evaluated first, before the surrounding expression is evaluated. In case of assignments, they're executed during evaluation.
It would be an error if the compiler decides to do so otherwise (because of optimization or for another reason).

[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.

[kedaman]

Thanks everyone (esp. CB)
It seems like I have to do it the ugly way, that is by declaring another variable

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

So true You're welcome