Order of evaluation
Order of evaluation of the operands of any C operator, including the order of evaluation of function arguments in a function-call expression, and the order of evaluation of the subexpressions within any expression is unspecified (except where noted below). The compiler will evaluate them in any order, and may choose another order when the same expression is evaluated again.
There is no concept of left-to-right or right-to-left evaluation in C, which is not to be confused with left-to-right and right-to-left associativity of operators: the expression a + b + c is parsed as (a + b) + c due to left-to-right associativity of operator+, but the subexpression c may be evaluated first (or last, or at the same time as a or b) at run time.
Contents |
[edit] Definitions
[edit] Evaluations
There are two kinds of evaluations performed by the compiler for each expression or subexpression (both of which are optional):
- value computation: calculation of the value that is returned by the expression. This may involve determination of the identity of the object (lvalue evaluation) or reading the value previously assigned to an object (rvalue evaluation)
- side effect: access (read or write) to an object designated by a volatile glvalue, modification (writing) to an object, modifying a file, modifying the floating-point environment (if supported), or calling a function that does any of those operations.
If no side effects are produced by an expression and the compiler can determine that the value is not used, the expression is not evaluated.
[edit] Ordering
"sequenced-before" is an asymmetric, transitive, pair-wise relationship between evaluations within the same thread (it may extend across threads if atomic types and memory barriers are involved).
- If a sequence point is present between the subexpressions E1 and E2, then both value computation and side effects of E1 are sequenced before every value computation and side effect of E2
- If evaluation A is sequenced before evaluation B, then evaluation of A will be complete before evaluation of B begins. (since C11)
- If A is not sequenced before B and B is sequenced before A, then evaluation of B will be complete before evaluation of A begins. (since C11)
- If A is not sequenced before B and B is not sequenced before A, then two possibilities exist: (since C11)
- evaluations of A and B are unsequenced: they may be performed in any order and may overlap (within a single thread of execution, the compiler may interleave the CPU instructions that comprise A and B)
- evaluations of A and B are indeterminably-sequenced: they may be performed in any order but may not overlap: either A will be complete before B, or B will be complete before A. The order may be the opposite the next time the same expression is evaluated.
[edit] Rules
1) There is a sequence point after the evaluation of all function arguments and of the function designator, and before the actual function call.
2) The value computations (but not the side-effects) of the operands to any operator are sequenced before the value computation of the result of the operator (but not its side-effects). (since C11)
3) There is a sequence point after evaluation of the first (left) operand and before evaluation of the second (right) operand of the following binary operators: && (logical AND), || (logical OR), and , (comma).
4) There is a sequence point after evaluation of the first (left) operand and before evaluation of the second or third operand (whichever is evaluated) of the conditional operator ?:
5) The side effect (modification of the left argument) of the direct assignment operator and of all compound assignment operators is sequenced after the value computation (but not the side effects) of both left and right arguments. (since C11)
6) The value computation of the postincrement and postdecrement operators is sequenced before its side-effect. (since C11)
7) There is a sequence point at the end of a full declarator. (since C99)
8) There is a sequence point after the evaluation of a full expression (an expression that is not a subexpression: typically something that ends with a semicolon or a controlling statement of if/switch/while/do) and before the next full expression.
9) There is a sequence point immediately before the return of a library function. (since C99)
10) There is a sequence point after the action associated with each conversion specifier in formatted I/O. (since C99)
11) There are sequence points before and immediately after each call to a comparison function made by the library functions qsort and bsearch, as well as between any call to the comparison function and the movement of the associated objects made by qsort (since C99)
12) A function call that is not sequenced before or sequenced after another function call is indeterminately sequenced (CPU instructions that constitute different function calls cannot be interleaved, even if the functions are inlined) (since C11)
13) In initialization list expressions, all evaluations are indeterminately sequenced (since C11)
14) With respect to an indeterminately-sequenced function call, the operation of compound assignment operators, and both prefix and postfix forms of increment and decrement operators are single evaluations. (since C11)
[edit] Undefined behavior
1) If a side effect on a scalar object is unsequenced relative to another side effect on the same scalar object, the behavior is undefined.
i = ++i + i++; // undefined behavior
i = i++ + 1; // undefined behavior
f(++i, ++i); // undefined behavior
f(i = -1, i = -1); // undefined behavior
2) If a side effect on a scalar object is unsequenced relative to a value computation using the value of the same scalar object, the behavior is undefined.
f(i, i++); // undefined behavior
a[i] = i++; // undefined bevahior
3) The above rules apply as long as at least one allowable ordering of subexpressions permits such an unsequenced side-effect.
[edit] See also
Operator precedence which defines how expressions are built from their source code representation.
