2

The following statement does not really make sense:

value = value--;

I accidentially wrote this instead of just value-- or value = value-1 . But since it worked on my machine as intended, the error was not noticed.

Now I want to know, if this statement is well defined and will have the same result on all machines. Or can this lead to different results?

rkgghz
  • 456
  • 8
  • 19
  • 2
    Doesn't look like it : https://godbolt.org/z/ejzzTP3en (try different compilers and settings there) – Pepijn Kramer Jul 07 '23 at 11:36
  • It is a single statement that modifies `value` twice. That has been undefined behaviour in most C++ standards. Since C++17, there have been a number of cases that were previously undefined behaviour becoming unspecified. I haven't checked to determine if examples like this would be affected by such changes of standards, but suspect not. But, whichever way (undefined or unspecified) such things are almost certainly better avoided. – Peter Jul 07 '23 at 12:04
  • @PepijnKramer maybe that just proves some compilers are buggy? – Mark Ransom Jul 07 '23 at 12:04
  • No it is something about evaluation order not being specified – Pepijn Kramer Jul 07 '23 at 12:11
  • @Peter I thought that the side effects of an expression had to be fully achieved before a sequence point, and that `=` was such a sequence point. Are either of those things wrong? – Mark Ransom Jul 07 '23 at 12:23
  • @MarkRansom: The "sequence point" concept is outdated (from C++98) and `=` was not a sequence point back then (unless it was a user-defined `operator=`, in which case both the function call and function return were sequence points). Since C++11, we need the stronger notion of `sequenced-before` because two threads can be doing things that are unsequenced relative to each other. Since this is a stronger notion, older single-threaded C++98 code remained valid in C++11. – MSalters Jul 07 '23 at 12:36
  • @MarkRansom More recent standards don't have the notion of sequence points at all. When earlier standards referred to them, `=` was not a sequence point. With notions of sequencing (not sequence points) in more recent standards, it was possible to be more nuanced about what was undefined, unspecified, etc. – Peter Jul 07 '23 at 12:40

2 Answers2

4

No, this is not well-defined, even in C++17. (Assuming built-in =, not a function call). The assignment to the left side is sequenced-after the calculation of the value on the right side. But the side effects of the right-hand side (value--) are not sequenced relative to the assignment. And decrementing value is a side effect of value--.

MSalters
  • 173,980
  • 10
  • 155
  • 350
-3

You are correct.The statement value = value--; does not make sense because it is attempting to decrement the value of value and assign the result back to value in a single statement. However, the behavior of the decrement operator -- is to first return the current value of the variable and then decrement it. So in this case, value-- would return the current value of value and then decrement it, but the assignment value = would then set value to the original value before the decrement. As a result, the statement value = value--; would have no effect on the value of value. It would essentially be equivalent to writing value = value;.

sn01
  • 36
  • 6
  • 1
    This doesn't answer the question of whether the statement is _"well defined and will have the same result on all machines"_ – Brian61354270 Jul 07 '23 at 11:59
  • Re “However, the behavior of the decrement operator -- is to first return the current value of the variable and then decrement it”: No, that is not the specification of the behavior of the decrement operator. The specification is that, for purposes of evaluating the value of the expression, it has the value of the operand prior to decrement and that it, at some unspecified time (subject to some ordering constraints), it decrements the object in memory. That decrement in memory is a “side effect” that can come before, during, or after the main effect of expression evaluation. – Eric Postpischil Jul 07 '23 at 12:50