Is ++x %= 10 well-defined in C++?

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 > of the right and left operands, and before the value computation of > the assignment expression.

So this does constitute an exception to the first quote. Moreover, as stated in [expr.pre.incr]¹, ++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.
    
• 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.

---

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

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

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.

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

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:

1. a value computation (x+1)
2. modifying an object ( =, as in x = x + 1), e.g. a side effect per §1.9/12
3. 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 A and B, if A is sequenced before B, then the execution of A shall precede the execution of B. If A is not sequenced before B and B is not sequenced before A, then A and B are unsequenced.

So, UDB.

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

++x;
x%= 10;