title: Unsequenced value computations (a.k.a sequence points)
body: <p>Sorry for opening this topic again, but thinking about this topic itself has started giving me an Undefined Behavior. Want to move into the zone of well-defined behavior.</p>
  
  <p>Given</p>
  
  <pre><code>int i = 0;
  int v[10];
  i = ++i;     //Expr1
  i = i++;     //Expr2
  ++ ++i;      //Expr3
  i = v[i++];  //Expr4
  </code></pre>
  
  <p>I think of the above expressions (in that order) as</p>
  
  <pre><code>operator=(i, operator++(i))    ; //Expr1 equivalent
  operator=(i, operator++(i, 0)) ; //Expr2 equivalent
  operator++(operator++(i))      ; //Expr3 equivalent
  operator=(i, operator[](operator++(i, 0)); //Expr4 equivalent
  </code></pre>
  
  <p>Now coming to behaviors here are the important quotes from <strong>C++ 0x</strong>.</p>
  
  <blockquote>
    <p>$1.9/12- "Evaluation of an expression
    (or a sub-expression) in general
    includes both value computations
    (including determining the identity of
    an object for lvalue  evaluation and
    fetchinga value previously assigned to
    an object for rvalue evaluation) and
    initiation of side effects."</p>
    
    <p>$1.9/15- "If a side effect on a scalar
    object is unsequenced relative to
    either another side effect on the same
    scalar object <strong>or</strong> a value
    computation using the value of the
    same scalar object, the behavior is
    undefined."</p>
    
    <p>[ Note: Value computations and side
    effects associated with different
    argument expressions are unsequenced.
    —end note ]</p>
    
    <p>$3.9/9- "Arithmetic types (3.9.1),
    enumeration types, pointer types,
    pointer to member types (3.9.2),
    std::nullptr_t, and cv-qualified
    versions of these types (3.9.3) are
    collectively called scalar types."</p>
  </blockquote>
  
  <ul>
  <li><p>In Expr1, the evaluation of the expression <code>i</code> (first argument), is unsequenced with respect to the evaluation of the expession <code>operator++(i)</code> (which has a side effect).</p>
  
  <p><strong>Hence Expr1 has undefined behavior.</strong></p></li>
  <li><p>In Expr2, the evaluation of the expression <code>i</code> (first argument), is unsequenced with respect to the evaluation of the expession <code>operator++(i, 0)</code> (which has a side effect)'.</p>
  
  <p><strong>Hence Expr2 has undefined behavior.</strong></p></li>
  <li><p>In Expr3, the evaluation of the lone argument <code>operator++(i)</code> is required to be complete before the outer <code>operator++</code> is called.</p>
  
  <p><strong>Hence Expr3 has well defined behavior.</strong></p></li>
  <li><p>In Expr4, the evaluation of the expression <code>i</code> (first argument) is unsequenced with respect to the evaluation of the <code>operator[](operator++(i, 0)</code> (which has a side effect).</p>
  
  <p><strong>Hence Expr4 has undefined behavior.</strong></p></li>
  </ul>
  
  <p>Is this understanding correct?</p>
  
  <hr>
  
  <p>P.S. The method of analyzing the expressions as in OP is not correct. This is because, as @Potatoswatter, notes - "clause 13.6 does not apply. See the disclaimer in 13.6/1, "These candidate functions participate in the operator overload resolution process as described in 13.3.1.2 and are used for no other purpose." They are just dummy declarations; no function-call semantics exist with respect to built-in operators."</p>