??? 06/23/07 00:18 Read: times |
#141171 - The real reason??? Responding to: ???'s previous message |
Jeff said:
Some operators are assumed to be associative and commutative (^ is one of them). The compiler is permitted to evaluate in any order it sees fit, which if for whatever reason it decided not to evaluate right to left would give a different result than what you expect.
The compiler will, or should, generate a warning message that the result is undefined, though most will evaluate the operations in the order you'd expect. x^=y^=x^=y; // Don't try this at home!!!Well, darn. That little trick sure looked innocent enough when I posted it. I'm also learning a lot more from this "quiz" than I expected to. After doing a little research, I agree with Jeff that the code is not proper C. However, I don't agree that the compiler is free to apply the operators in any order. First of all, the operator in question is ^= and not plain ^. The table in section 2.12 of K&R gives the associativity of ^= (and all the other assignment operators, too) as "right to left". I'm pretty sure that means that the ^= operations in the example are guaranteed to be executed from right to left. So what's the problem with the example? As far as I can tell (based on the closing paragraphs of K&R, section 12), it seems that the real problem is that the compiler is free to perform the actual variable assignments in any order and at any time it wants. So, while the value of the rightmost instance of "x^=y" is unquestionably x^y, the language doesn't specify whether that value will be or won't be actually assigned to x prior to the execution of the remaining two operators. Similarly, after the execution of the middle operator, there is no guarantee one way or the other if the result will be assigned to y before the execution of the leftmost operator. Given that, it's pretty clear that the example is ambiguous. In trying to figure this out, I found that we are not breaking any new ground here. A discussion in comp.lang.c of the exact same problem quickly degenerated into a war of words (big surprise) because the poor guy who originally posted it hadn't read the newsgroup's FAQ. And it turns out that the comp.lang.c FAQ does explain it (see question 3.3b), albeit in terms more geared to students of the actual C standard than to us mere mortals who can barely understand K&R. Anyway, I learned something today (there's always that risk!), and I apologize if I confused anybody with the example. -- Russ |