Order of evaluation and undefined behaviour

Question

Speaking in the context of the C++11 standard (which no longer has a concept of sequence points, as you know) I want to understand how two simplest examples are defined.

int i = 0;

i = i++;   // #0

i = ++i;   // #1

There are two topics on SO which explain those examples within the C++11 context. Here it was said that #0 invokes UB and #1 is well-defined. Here it was said that both examples are undefined. This ambiguity confuses me much. I've read this well-structured reference three times already but the topic seems to be way too complicated for me.

.

Let's analyze the example #0: i = i++;.

Corresponding quotes are:

• The value computation of the built-in postincrement and postdecrement operators is sequenced before its side-effect.

• The side effect (modification of the left argument) of the built-in assignment operator and of all built-in compound assignment operators is sequenced after the value computation (but not the side effects) of both left and right arguments, and is sequenced before the value computation of the assignment expression (that is, before returning the reference to the modified object)

• If a side effect on a scalar object is unsequenced relative to another side effect on the same scalar object, the behavior is undefined.

As I get it, the side effect of the assignment operator is not sequenced with side effects of it's left and right arguments. Thus the side effect of the assignment operator is not sequenced with the side effects of i++. So #0 invokes an UB.

.

Let's analyze the example #1: i = ++i;.

Corresponding quotes are:

• The side effect of the built-in preincrement and predecrement operators is sequenced before its value computation (implicit rule due to definition as compound assignment)

• The side effect (modification of the left argument) of the built-in assignment operator and of all built-in compound assignment operators is sequenced after the value computation (but not the side effects) of both left and right arguments, and is sequenced before the value computation of the assignment expression (that is, before returning the reference to the modified object)

• 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 can not see, how this example is different from the #0. This seems to be an UB for me for the very same reason as #0. The side effect of assignment is not sequenced with the side effect of ++i. It seems to be an UB. The topic liked above says it is well-defined. Why?

.

Question: how can I apply quoted rules to determine the UB of the examples. An as simple as possible explanation would be greatly appreciated. Thank you!

Answer 1

Since your quotes are not directly from the standard, I will try to give a detailed answer quoting the relevant parts of the standard. The definitions of "side effects" and "evaluation" is found in paragraph 1.9/12:

Accessing an object designated by a volatile glvalue (3.10), modifying an object, calling a library I/O function, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment. Evaluation of an expression (or a sub-expression) in general includes both value computations (including determining the identity of an object for glvalue evaluation and fetching a value previously assigned to an object for prvalue evaluation) and initiation of side effects.

The next relevant part is paragraph 1.9/15:

Except where noted, evaluations of operands of individual operators and of subexpressions of individual expressions are unsequenced. [...] The value computations of the operands of an operator are sequenced before the value computation of the result of the operator. If a side effect on a scalar object is unsequenced relative to either another side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined.

Now let's see, how to apply this to the two examples.

i = i++;

This is the postfix form of increment and you find its definition in paragraph 5.2.6. The most relevant sentence reads:

The value computation of the ++ expression is sequenced before the modification of the operand object.

For the assignment expression see paragraph 5.17. The relevant part states:

In all cases, the assignment is sequenced after the value computation of the right and left operands, and before the value computation of the assignment expression.

Using all the information from above, the evaluation of the whole expression is (this order is not guaranteed by the standard!):

• value computation of i++ (right hand side)
• value computation of i (left hand side)
• modification of i (side effect of ++)
• modification of i (side effect of =)

All the standard guarantees is that the value computations of the two operands is sequenced before the value computation of the assignment expression. But the value computation of the right hand side is only "reading the value of i" and not modifying i, the two modifications (side effects) are not sequenced with respect to each other and we get undefined behavior.

What about the second example?

i = ++i;

The situation is quite different here. You find the definition of prefix increment in paragraph 5.3.2. The relevant part is:

If x is not of type bool, the expression ++x is equivalent to x+=1.

Substituting that, our expression is equivalent to

i = (i += 1)

Looking up the compound assignment operator += in 5.17/7 we get that i += 1 is equivalent to i = i + 1 except that i is only evaluated once. Hence, the expression in question finally becomes

i = ( i = (i + 1))

But we already know from above that the value computation of the = is sequenced after the value computation of the operands and the side effects are sequenced before the value computations of =. So we get a well-defined order of evaluation:

1. compute value of i + 1 (and i - left hand side of inner expression)(#1)
2. initiate side effect of inner =, i.e. modify "inner" i
3. compute value of (i = i + 1), which is the "new" value of i
4. initiate side effect of outer =, i.e. modify "outer" i
5. compute value of full expression.

---

(#1): Here, i is only evaluated once, since i += 1 is equivalent to i = i + 1 except that i is only evaluated once (5.17/7).