While browsing the code of some project I came across the following statement:

```
++x %= 10;
```

Is this statement well defined in C++ or does it fall into the same category as

```
a[i] = i++
```

?

As per C++11 `1.9 Program execution /15`

:

Except where noted, evaluations of operands of individual operators and of subexpressions of individual expressions are unsequenced.

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.

In this case, I believe `++x`

is a side effect and `x %= 10`

is a value computation so you’d think it would be undefined behaviour. However, the *assignment* section (`5.17 /1`

) has this to say (my bold):

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.

Hence that means that both sides are sequenced before the assignment and before the result of the assignment is made available. And since the standard also states (`5.17 /7`

) that `x OP = y`

is identical to `x = x OP y`

but with `x`

only being evaluated once, it turns out this *is* well defined behaviour, as it’s equivalent to:

```
++x = Q % 10; // where Q is the value from ++x, not evaluated again.
```

The only question then remains is which *side* of the assignment is evaluated since *they’re* not sequenced. However, I don’t think it matters in this case since both these will have the same effect:

```
++x = Q % 10; // LHS evaluated first
Q = ++x % 10; // RHS evaluated first
```

Now, that’s *my* reading of the standard. While I have a fair amount of experience in decoding complex documents, there *may* be something I’ve missed – I don’t think so because we’ve all had a lively discussion here in getting to this point 🙂 and I think we’ve all established the relevant sections.

But, regardless of whether it’s wel defined or not, decent coders *shouldn’t* be writing code like that. It’s been a long time since the low-memory/small-storage days of the PDP minis, it’s about time we wrote our code to be *readable.*

If you want to increment then take the modulo, use `x = (x + 1) % 10`

, if only to make it easier to understand for the next poor Joe reading that code.

**TL;DR**: It is well-defined because `x`

is guaranteed to be incremented before the assignment.

## Some C++11 standardese

[intro.execution]/15:

Except where noted, evaluations of operands of individual operators

and of subexpressions of individual expressions are unsequenced.

However, [expr.ass]/1 does note something:

In all cases, the assignment is sequenced after the value computation, and before the value computation of

of the right and left operands

the assignment expression.

So this does constitute an exception to the first quote. Moreover, as stated in [expr.pre.incr]^{1}, `++x`

is equivalent to `x += 1`

, which is also covered by the above quote: The assignment is sequenced before the value computation. Thus **for ++x the increment is sequenced before the value computation.**

Taking that into account it is not hard to see that in `++x %= 10`

, the increment is done before the assignment is.

So the increment side-effect is sequenced before the assignment side-effect, and thus all involved side-effects are sequenced.

To put it in another way, the standard imposes the following sequencing:

`++x`

and`10`

are evaluated – the order of which is unsequenced, but`10`

is just a literal so that’s not relevant here.`++x`

is evaluated:- First, the value of
`x`

is incremented. - Then the value computation is done, and we get an lvalue referring to
`x`

.

- First, the value of

- The assignment is done. The updated value of
`x`

is taken modulo`10`

and assigned to`x`

. - The value computation of the assignment might follow, which is clearly sequenced after the assignment.

Hence

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.

doesn’t apply as **the side-effects and value-computations are sequenced**.

^{1} Not [expr.post.incr] which would be for the postfix increment!

Let’s look at the unary increment operator:

## 5.3.2 Increment and decrement [expr.pre.incr]

1 The operand of prefix

`++`

is modified by adding 1, or set to`true`

if it is`bool`

(this use is deprecated). The operand shall be a modifiable lvalue. The type of the operand shall be an arithmetic type or a pointer to a completely-defined object type.The result is the updated operand; it is an lvalue, and it is a bit-field if the operand is a bit-field. If`x`

is not of type`bool`

, the expression`++x`

is equivalent to`x+=1`

.

[…]

Thus, all evaluations and side-effects pertaining to that unary operator are scheduled before its value, and thus cannot cause havoc.

All that’s left is evaluating `%= 10`

on that lvalue. Only evaluating the constant might be concurrent (which could not possibly do any harm), the rest is strictly sequenced after everything else.

I’m going to offer an alternative answer, without quoting the good book, as I think re-writing it slightly makes it obvious.

```
++x %= 10; // as stated
x += 1 %= 10; // re-write the 'sugared' ++x
```

This makes it clear enough in my eyes. As we know, the result of the assignment (which if we really want, the still ‘sugared’ `+=`

reduces to) is itself an lvalue, so there should be no doubt that by further reduction the expression is:

```
(x = x+1) %= 10 // += -> =1+
x = (x+1) % 10 // assignment returns reference to incremented x
```

In the expression

```
++x %= 10;
```

the most confusing part is that `x`

is modifying twice between two sequence points, once by prefix `++`

and once by assignment of result. This makes an impression that the above expression invokes undefined behavior as once we learned in old C++ that

Between the previous and next sequence point a scalar object shall have its stored value modified at most once by the evaluation of an expression.

In C++11, the rule is different (it is about *sequencing* instead of *sequence points*!):

If a side effect on a scalar object is

unsequencedrelative 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.

As we already know that `++x`

is the above expression will be evaluated only once (and will give a lvalue), because

### C++11: 5.17

The behavior of an expression of the form

`E1 op = E2`

is equivalent to`E1 = E1 op E2`

except that.`E1`

is evaluated only once

and also know that evaluation of operands `++x`

and `10`

will take place before computation of result of `%=`

operator as by standard:

The value computations of the operands of an operator are sequenced before the value computation of the result of the operator.

**Conclusion:**

`++x`

will be evaluated only once giving an lvalue and only after that `%=`

operation will be performed.

This means that, both modifications to `x`

is sequenced and the above expression is well defined.

Well, it is *defined*. As undefined behavior:

§1.9/15:

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.

There are two unsequenced side-effects here.

Given the expression `++x %= 10;`

moving from left-to-right, we have:

- a
*value computation*`(x+1)`

*modifying an object*(`=`

, as in`x = x + 1`

), e.g. a*side effect*per §1.9/12- an
*indeterminately sequenced*operation (`%=`

) that itself has both a value computation (‘`%`

‘) and an object-modification*side-effect*(‘`=`

‘) (*ibid from 1,2*) on the*same scalar object*(‘`x`

‘).

The two sub-expressions in the full-expression are unsequenced *relative to each other*. Although we started by reading it from left to right, these are *indeterminately sequenced*, so there is explicitly no partial-ordering bailout from §1.9/13:

Given any two evaluations

AandB, ifAis sequenced beforeB, then the execution ofAshall precede the execution ofB. IfAis not sequenced beforeBandBis not sequenced beforeA, thenAandBareunsequenced.

So, UDB.

The Prefix increment (++x) has highest precedence by the Modulus assignment (%= ). The statement: ++x %= 10; can be expressed as:

```
++x;
x%= 10;
```

Tags: c++