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.