Order of evaluation
Order of evaluation of any part of any expression, including order of evaluation of function arguments is unspecified (with some exceptions listed below). The compiler can evaluate operands and other subexpressions 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++. This 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 function call to
c may be evaluated first, last, or between
b() at run time:
b c a c a b
 Sequenced-before rules (since C++11)
 Evaluation of Expressions
Evaluation of each expression includes:
- value computations: calculation of the value that is returned by the expression. This may involve determination of the identity of the object (glvalue evaluation, e.g. if the expression returns a reference to some object) or reading the value previously assigned to an object (prvalue evaluation, e.g. if the expression returns a number, or some other value)
- Initiation of side effects: access (read or write) to an object designated by a volatile glvalue, modification (writing) to an object, calling a library I/O function, or calling a function that does any of those operations.
"sequenced-before" is an asymmetric, transitive, pair-wise relationship between evaluations within the same thread.
- If A is sequenced before B, then evaluation of A will be complete before evaluation of B begins.
- 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.
- If A is not sequenced before B and B is not sequenced before A, then two possibilities exist:
- 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 indeterminately 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.
- an entire initializer, including any comma-separated constituent expressions
- the destructor call generated at the end of the lifetime of a non-temporary object
- an expression that is not part of another full-expression (such as the entire expression statement, controlling expression of a for/while loop, conditional expression of if/switch, the expression in a return statement, etc),
|The rule 11 has one exception: function calls made by a standard library algorithm executing under std::execution::par_unseq execution policy are unsequenced and may be arbitrarily interleaved.||(since C++17)|
13) When returning from a function, copy-initialization of the temporary that is the result of evaluating the function call is sequenced-before the destruction of all temporaries at the end of the operand of the return statement, which, in turn, is sequenced-before the destruction of local variables of the block enclosing the return statement.
14) In a function-call expression, the expression that names the function is sequenced before every argument expression and every default argument.
15) In a function call, value computations and side effects of the initialization of every parameter are indeterminately sequenced with respect to value computations and side effects of any other parameter.
16) Every overloaded operator obeys the sequencing rules of the built-in operator it overloads when called using operator notation.
17) In a subscript expression
18) In a pointer-to-member expression
19) In a shift operator expression
20) In every simple assignment expression
21) Every expression in a comma-separated list of expressions in a parenthesized initializer is evaluated as if for a function call (indeterminately-sequenced)
 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 + 2; // undefined behavior until C++11
i = i++ + 2; // undefined behavior until C++17
f(i = -2, i = -2); // undefined behavior until C++17
f(++i, ++i); // undefined behavior until C++17, unspecified after C++17
i = ++i + i++; // 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.
cout << i << i++; // undefined behavior until C++17
a[i] = i++; // undefined behavior until C++17
n = ++i + i; // undefined behavior
 Sequence point rules (until C++11)
Evaluation of an expression might produce side effects, which are: accessing an object designated by a volatile lvalue, modifying an object, calling a library I/O function, or calling a function that does any of those operations.
A sequence point is a point in the execution sequence where all side effects from the previous evaluations in the sequence are complete, and no side effects of the subsequent evaluations started.
1) There is a sequence point at the end of each full expression (typically, at the semicolon).
2) When calling a function (whether or not the function is inline and whether or not function call syntax was used), there is a sequence point after the evaluation of all function arguments (if any) which takes place before execution of any expressions or statements in the function body.
3) There is a sequence point after the copying of a returned value of a function and before the execution of any expressions outside the function.
4) Once the execution of a function begins, no expressions from the calling function are evaluated until execution of the called function has completed (functions cannot be interleaved).
5) In the evaluation of each of the following four expressions, using the built-in (non-overloaded) operators, there is a sequence point after the evaluation of the expression
a && b
a || b
a ? b : c
a , b
 Undefined behavior
1) Between the previous and next sequence point a scalar object must have its stored value modified at most once by the evaluation of an expression, otherwise the behavior is undefined.
i = ++i + i++; // undefined behavior
i = i++ + 1; // undefined behavior (until C++17)
i = ++i + 1; // undefined behavior (until C++11)
++ ++i; // undefined behavior (until C++11)
f(++i, ++i); // undefined behavior (until C++17)
f(i = -1, i = -1); // undefined behavior (until C++17)
2) Between the previous and next sequence point, the prior value of a scalar object that is modified by the evaluation of the expression, must be accessed only to determine the value to be stored. If it is accessed in any other way, the behavior is undefined.
cout << i << i++; // undefined behavior (until C++17)
a[i] = i++; // undefined behavior (until C++17)
 Defect reports
The following behavior-changing defect reports were applied retroactively to previously published C++ standards.
|DR||Applied to||Behavior as published||Correct behavior|
|CWG 1885||C++14||sequencing of the destruction of automatic variables on function return was not explicit||sequencing rules added|
- C++11 standard (ISO/IEC 14882:2011):
- 1.9 Program execution [intro.execution]
- 5.2.6 Increment and decrement [expr.post.incr]
- 5.3.4 New [expr.new]
- 5.14 Logical AND operator [expr.log.and]
- 5.15 Logical OR operator [expr.log.or]
- 5.16 Conditional operator [expr.cond]
- 5.17 Assignment and compound assignment operators [expr.ass]
- 5.18 Comma operator [expr.comma]
- 8.5.4 List-initialization [dcl.init.list]
 See also
- Operator precedence which defines how expressions are built from their source code representation.
C documentation for Order of evaluation