Does writing the new value form part of the "value computation" of a pre-increment expression, or is it a "side effect"?

Question

Consider the following expression (with declaration for exposition):

int n = 42;
--n &= 0x01;

Does this fall foul of sequencing rules?

In my opinion, the pre-increment is needed as part of the "value computation" of the left-hand operand. If this is true, there's no UB here since C++11 (and, since C++17, both value computations and side effects are sequenced relative to the assignment).

If it were a post-increment, then the modification of n would be merely a side-effect and we'd not have good sequencing (until C++17).

@SombreroChicken My cat was beamed into a black hole a few years ago by someone writing a program with undefined behaviour :( — Lightness Races in Orbit, Oct 22 '19 at 11:34
No that's not undefined behavior, there was just something wrong with the microchip. Your cat ran fine on my laptop. — Hatted Rooster, Oct 22 '19 at 11:36
_"...If it were a postincrement, ..."_: postincrement won't compile as it does not return a lvalue. — Richard Critten, Oct 22 '19 at 11:55
@RichardCritten Well, granted, though we could still rationalise about the distinction between value computation and side effect :) — Lightness Races in Orbit, Oct 22 '19 at 12:35

score 3 · Answer 1 · edited Jun 20 '20 at 09:12

3

I suppose you are right, here's what standard says:

8.5.18 Assignment and compound assignment operators

All require a modifiable lvalue as their left operand; their result is an lvalue referring to the left operand. [...] 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 from above it seems assignment is value expression and both left and right of assignment are evaluated before assignment.

From standard about the preincrement:

8.5.2.2 Increment and decrement

The result is the updated operand; it is an lvalue, and it is a bit-field if the operand is a bit-field. The expression ++x is equivalent to x+=1.

Which means that even before C++17 its side effect is sequenced before value computation.

edited Jun 20 '20 at 09:12

Community

1
1

answered Oct 22 '19 at 11:06

bartop

9,971
1
23
54

Right, but is the preincrement part of the value computation? – Lightness Races in Orbit Oct 22 '19 at 11:08
@LightnessRacesinOrbit edited, hopefully it's better – bartop Oct 22 '19 at 11:24
Ooh that's interesting – Lightness Races in Orbit Oct 22 '19 at 11:29

score 0 · Answer 2 · answered Oct 22 '19 at 11:27

0

As far as I can tell the wording in C++11 doesn't mention the "value computation" of preincrement and predecrement in relation to the update:

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

There is nothing in the above paragraph from which I'd conclude the modification has to come first. An implementation may very well compute the updated value (and use it) prior to writing it into the object by the next sequence point.

In which case we will have ourselves a side-effect that is indeterminately sequenced with another modification. So I'd say since the standard doesn't specify if there is a side-effect, nor how such potential side-effect is to be sequenced, the whole thing is undefined by omission.

With C++17, we of course get well defined sequencing with or without this potential side-effect.

answered Oct 22 '19 at 11:27

StoryTeller - Unslander Monica

165,132
21
377
458

Interesting; that's the angle taken by someone I was speaking to (which in turn spawned this question). What do you think about bartop's point? – Lightness Races in Orbit Oct 22 '19 at 11:30
1

@LightnessRacesinOrbit - I think it hinges on how exactly "equivalent" is defined. If it means we can derive the sequencing from `x += 1`, then sure. But I'm not too comfortable making that assertion of equivalence. I think it just means that in a well-behaved program, the two expressions have identical value. – StoryTeller - Unslander Monica Oct 22 '19 at 11:32
2

I think I agree – Lightness Races in Orbit Oct 22 '19 at 11:35
@LightnessRacesinOrbit I think it is valid and fully defined since "The result is the updated operand". So it seems it is guaranteed to be updated when returned – bartop Oct 22 '19 at 11:45
@bartop I think I agree with that too! – Lightness Races in Orbit Oct 22 '19 at 12:35

Does writing the new value form part of the "value computation" of a pre-increment expression, or is it a "side effect"?

2 Answers2

8.5.18 Assignment and compound assignment operators

8.5.2.2 Increment and decrement