On 31/05/2026 16:24, James Kuyper wrote:[...]On 2026-05-31 07:18, David Brown wrote:
>People might think they affect the order of evaluation, such as when you>
have function calls :
>
u = foo(x) + (foo(y) + foo(z));
>
Some people might think the use of parentheses means that "foo(y)" and
"foo(z)" are called before "foo(x)", when the order of all these calls
(and the additions) is unspecified. (Again, a given compiler might be
influenced by the parentheses, but the language does not require it.
You're correct with regard to the function calls, but the
parenthesized addition must be performed first, and the other one
second, which may make a difference, for the same reasons given in my
previous paragraph.
The parentheses do not dictate the order of evaluation. But you are
correct - and it's worth pointing out, so thank you for doing that -
that for floating point operations, the grouping of operations can
affect the result.
The parentheses do not dictate the order of evaluation *of the
operands*. Each "+" can be evaluated (the addition performed)
only after the values of its operands are known. But regardless
of parentheses or operator precedence, the three operands foo(x),
foo(y), and foo(z) can be evaluated in any of 6 possible orders.
(It's different when you have operations like "&&", "||", and ",",
which imposes additional sequence points.)
If you are talking about floating point arithmetic (I was thinking of
integer arithmetic, but did not specify), then the operations are not
necessarily commutative or associative, and the compiler cannot then
re-arrange the operations unless it knows that doing so does not
affect the result.
It's not just floating-point. Signed integer overflow is also relevant.
(INT_MIN + INT_MAX) + 1 is well defined. (INT_MIN + INT_MAX) +1
is equivalent, and is also well defined. INT_MIN + (INT_MAX +1)
has undefined behavior.
But except for specific cases, the order of evaluation - both for the
values and side-effects - of sub-expressions is unspecified. Indeed,
they are unsequenced - the evaluations can interleave.
>
Usually, both sub-expressions of a binary operator will be evaluated
before the operator itself, simply because usually the results of the
operator cannot be calculated until the sub-expression's values are
known. But this is not a requirement of the language - if the
compiler can get the same results without doing so, it is free to pick
a different order. "(a + b) * 0" does not need to evaluate "a", "b",
or "a + b" at all unless there is a possibility of a side-effect - and
it can perform the side-effects in any order. "a + (b + c)" can check
"a" for a trap representation and deal with that before looking at "b"
and "c" or the results of "b + c", even though it cannot (for floating
point operations) re-arrange the code to do "a + b" first.
Yes, a compiler can reduce (a + b) * 0 to just 0. But it's not
required to do so, and (INT_MAX + 1) * 0 still has undefined
behavior. Undefined behavior is determined by the rules of the
abstract machine *without* any adjustments permitted by the as-if
rule.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
Les messages affichés proviennent d'usenet.