path: root/devdocs/c/language%2Feval_order.html

    <h1 id="firstHeading" class="firstHeading">Order of evaluation</h1>            <p>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.</p>
<p>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 <code>f1() + f2() + f3()</code> is parsed as <code>(f1() + f2()) + f3()</code> due to left-to-right associativity of operator+, but the function call to <code>f3</code> may be evaluated first, last, or between <code>f1()</code> or <code>f2()</code> at run time.</p>
<h3 id="Definitions"> Definitions</h3> <h4 id="Evaluations"> Evaluations</h4> <p>There are two kinds of evaluations performed by the compiler for each expression or subexpression (both of which are optional):</p>
<ul>
<li> <i>value computation</i>: calculation of the value that is returned by the expression. This may involve determination of the identity of the object (<a href="value_category" title="c/language/value category">lvalue evaluation</a>) or reading the value previously assigned to an object (rvalue evaluation) </li>
<li> <i>side effect</i>: access (read or write) to an object designated by a <a href="volatile" title="c/language/volatile">volatile</a> lvalue, modification (writing) to an object<span class="t-rev-inl t-since-c11"><span>, atomic synchronization</span><span><span class="t-mark-rev t-since-c11">(since C11)</span></span></span>, modifying a file, modifying the floating-point environment (if supported), or calling a function that does any of those operations. </li>
</ul> <p>If no side effects are produced by an expression and the compiler can determine that the value is not used, the expression <a href="as_if" title="c/language/as if">may not be evaluated</a>.</p>
<h4 id="Ordering"> Ordering</h4> <p>"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).</p>
<ul><li> If a <a href="https://en.wikipedia.org/wiki/Sequence_point" class="extiw" title="enwiki:Sequence point"><i>sequence point</i></a> is present between the subexpressions E1 and E2, then both value computation and side effects of E1 are <i>sequenced-before</i> every value computation and side effect of E2 </li></ul> <table class="t-rev-begin"> <tr class="t-rev t-since-c11">
<td> <ul>
<li> If evaluation A is sequenced before evaluation B, then evaluation of A will be complete before evaluation of B begins. </li>
<li> 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. </li>
<li> If A is not sequenced before B and B is not sequenced before A, then two possibilities exist: <ul>
<li> 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) </li>
<li> 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. </li>
</ul> </li>
</ul> </td> <td><span class="t-mark-rev t-since-c11">(since C11)</span></td>
</tr> </table> <h3 id="Rules"> Rules</h3> <div class="t-li1">
<span class="t-li">1)</span> There is a sequence point after the evaluation of all function arguments and of the function designator, and before the actual function call.</div> <div class="t-li1">
<span class="t-li">2)</span> 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: <code>&amp;&amp;</code> (logical AND), <code>||</code> (logical OR), and <code>,</code> (comma).</div> <div class="t-li1">
<span class="t-li">3)</span> 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 <code>?:</code>
</div> <div class="t-li1">
<span class="t-li">4)</span> 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 <a href="statements" title="c/language/statements">controlling statement</a> of <code>if</code>/<code>switch</code>/<code>while</code>/<code>do</code>) and before the next full expression.</div> <table class="t-rev-begin"> <tr class="t-rev t-since-c99">
<td> <span class="t-li">5)</span> There is a sequence point at the end of a full declarator. <span class="t-li">6)</span> There is a sequence point immediately before the return of a library function. <span class="t-li">7)</span> There is a sequence point after the action associated with each conversion specifier in formatted I/O (in particular, it is well-formed for <code><a href="../io/fscanf" title="c/io/fscanf">scanf</a></code> to write different fields into the same variable and for <code><a href="../io/fprintf" title="c/io/fprintf">printf</a></code> to read and modify or modify the same variable more than once using <code>%n</code>) <span class="t-li">8)</span> There are sequence points before and immediately after each call to a comparison function made by the library functions <code><a href="../algorithm/qsort" title="c/algorithm/qsort">qsort</a></code> and <code><a href="../algorithm/bsearch" title="c/algorithm/bsearch">bsearch</a></code>, as well as between any call to the comparison function and the movement of the associated objects made by <code><a href="../algorithm/qsort" title="c/algorithm/qsort">qsort</a></code> </td> <td><span class="t-mark-rev t-since-c99">(since C99)</span></td>
</tr> <tr class="t-rev t-since-c11">
<td> <span class="t-li">9)</span> 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). <span class="t-li">10)</span> 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. <span class="t-li">11)</span> The value computation of the postincrement and postdecrement operators is sequenced before its side-effect. <span class="t-li">12)</span> 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) <span class="t-li">13)</span> In <a href="initialization" title="c/language/initialization">initialization</a> list expressions, all evaluations are indeterminately sequenced <span class="t-li">14)</span> 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. </td> <td><span class="t-mark-rev t-since-c11">(since C11)</span></td>
</tr> </table> <h3 id="Undefined_behavior"> Undefined behavior</h3> <div class="t-li1">
<span class="t-li">1)</span> If a side effect on a scalar object is unsequenced relative to another side effect on the same scalar object, the <a href="behavior#UB_and_optimization" title="c/language/behavior">behavior is undefined</a>. <div class="c source-c"><pre data-language="c">i = ++i + i++; // undefined behavior
i = i++ + 1; // undefined behavior
f(++i, ++i); // undefined behavior
f(i = -1, i = -1); // undefined behavior</pre></div>
</div> <div class="t-li1">
<span class="t-li">2)</span> 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. <div class="c source-c"><pre data-language="c">f(i, i++); // undefined behavior
a[i] = i++; // undefined bevahior</pre></div>
</div> <div class="t-li1">
<span class="t-li">3)</span> The above rules apply as long as at least one allowable ordering of subexpressions permits such an unsequenced side-effect.</div> <h3 id="See_also"> See also</h3> <p><a href="operator_precedence" title="c/language/operator precedence">Operator precedence</a> which defines how expressions are built from their source code representation.</p>
<table class="t-dsc-begin"> <tr class="t-dsc"> <td colspan="2"> <span><a href="https://en.cppreference.com/w/cpp/language/eval_order" title="cpp/language/eval order">C++ documentation</a></span> for <span class=""><span>Order of evaluation</span></span> </td>
</tr> </table>           <div class="_attribution">
  <p class="_attribution-p">
    &copy; cppreference.com<br>Licensed under the Creative Commons Attribution-ShareAlike Unported License v3.0.<br>
    <a href="https://en.cppreference.com/w/c/language/eval_order" class="_attribution-link">https://en.cppreference.com/w/c/language/eval_order</a>
  </p>
</div>