Reply to thread

Message: [QUOTE="Keith Thompson, post: 3783961"] [i] I disagree. In fact, I honestly don't understand how you've reached that conclusion. The full expression is: (SomeFunc(Item[i], Col) <= Limit) == (V == 1) which can be broken down to two subexpressions, both operands of "==": SomeFunc(Item[i], Col) <= Limit) (V == 1) Breaking each of those down, we get 4 subexpressions: SomeFunc(Item[i], Col) Limit V 1 (I could break it down further, but this suffices.) There are 12 possible orders in which those 4 subexpressions can be evaluated. The order *doesn't matter*. The result will be exactly the same regardless of the order of evaluation, and assuming that they must be evaluated left-to-right is not helpful in understanding what it means. (Unless SomeFunc has side effects that can change the value of Limit or V, but if it does then the fact that order of evaluation is unspecified becomes very significant.) [...] It's true at *every* level. I wasn't talking about compilers, I was talking about what the expression actually means based on the language definition. Sure, left-to-right is one of the legal evaluation orders, and if mentally processing it that way is helpful, that's fine. It's your assertion that the expression is necessarily evaluated that way that I dispute. If the OP's understanding depends on assuming a left-to-right order of evaluation, then the OP doesn't really understand it. Nope. (Well, I'd take into account the fact that it's probably a trick question, since hardly anybody would ask such a question seriously, and I might go off a tangent about modular arithmetic or base 3 -- or, more likely, I might make a joke like "What kind of answer did you have in mind?" But I digress.) Not at all. Again, I didn't mention compilers at all. The fact that evaluation order is, in many cases, unspecified is a vital fact about the C language (though some might wish it weren't).[/i][/i][/i][/i] [/QUOTE]

Verification