On 2026-05-31 07:18, David Brown wrote: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.On 31/05/2026 12:10, Bart wrote:...On 31/05/2026 10:49, David Brown wrote:On 31/05/2026 10:12, Richard Harnden wrote:On 31/05/2026 00:43, Keith Thompson wrote:But you might consider "(a + b) + c" to be "parsed differently" than "a(a + b) + c mandates adding a to b, then adding the result to c. a + (b
+ (b + c)", because of how a particular compiler implements its parser.
It's possible that this results in different code for a particular
compiler, but there is no difference in the meaning for the C language.
+ c) mandates adding b to c then adding the result to a. As far as
mathematics is concerned, that's the same thing, but in computer math it
can make a difference if one of the two results in overflow or
unnecessary loss of precision, and the other does not.
...You're correct with regard to the function calls, but the parenthesizedDo you have>
an example where they make no difference but people might think they do?
>
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.
addition must be performed first, and the other one second, which may
make a difference, for the same reasons given in my previous paragraph.
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.
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.
If an implementation provides additional semantics to signed integer arithmetic, such as saturating or trapping overflow, then signed integer arithmetic operations are no longer associative. But normal C undefined behaviour on overflow is fully associative (as is wrapping semantics, for addition, subtraction and multiplication).
So for non-associative operations, parentheses can affect the semantics - and therefore the most likely (but not required) order of evaluation of at least some parts of the sub-expressions. However, that also then means we are not longer talking about parentheses that do not affect the semantics of the expression, which is what this thread branch is about.
Les messages affichés proviennent d'usenet.