0

Whats happening x after executing the code below;

int x = 10;
x += x--;

I'm expecting result 19 (adding x to x and then decrease x by 1) but result 20. How does it works behind the curtains? Thank your for your answers.

  • 4
    Why would you even write code like that? – StoryTeller - Unslander Monica Oct 23 '18 at 09:01
  • 1
    I got 19 as a result. – Cepheus Oct 23 '18 at 09:02
  • @Cepheus Same on clang, gcc and MSVC: https://godbolt.org/z/MPrtRN – Michał Łoś Oct 23 '18 at 09:03
  • 3
    It is undefined behaviour. You may get 19, but you are not guaranteed to. GCC will report "warning: unsequenced modification and access to 'x' [-Wunsequenced]" for `int main() { int x = 10; x += x--; }`. – Amadan Oct 23 '18 at 09:04
  • what do you want it to do? and then write code that clearly expresses that instead of something that you dont understand yourself ;). Of course it is good trying to understand any code, but as a matter of fact, some code is just so obfuscated that nobody should have to write it – 463035818_is_not_an_ai Oct 23 '18 at 09:04
  • You may get 20 if you enable optimization due to compiler reorderings. – Cepheus Oct 23 '18 at 09:09
  • @Cepheus That's what I actually did in all 3 compilers. It's exactly what they return on every level of turned-on optimization: 19. – Michał Łoś Oct 23 '18 at 09:12
  • @Stephane: I think that author stated problem that doesn't exist, so your answers are explaining something that is not true! First of all: http://eel.is/c++draft/expr.ass#1 "The right operand is sequenced before the left operand." Second: no common compiler would leave x with value "20" as I pointed out above: godbolt.org/z/MPrtRN – Michał Łoś Oct 23 '18 at 09:25
  • please, don't down votes answers that you don't match your expectations. This is not the purpose of downvote.@Mert Arısoy It would be useful to have the compiler and compiling options you user as most of us get the expected result. – Stephane Oct 23 '18 at 09:27
  • 7
    @Stephane The purpose of downvotes is to mark answers incorrect. All answers that are downvoted here (also those that are now deleted) were wrong. You don't get points for making an effort; you get points for writing correct answers. – JJJ Oct 23 '18 at 09:30
  • My compiler (clang) emitted a warning explaining the undefined behavior. I don't think the warning is required by the standard, rather I've turned on warnings for clang, and the folks behind clang have kindly put in a check and emit a warning (if warnings are enabled) for this undefined behavior situation. – Eljay Oct 23 '18 at 12:05

2 Answers2

6

The behavior in this case was undefined before C++17, see e.g., https://en.cppreference.com/w/cpp/language/eval_order#Undefined_behavior , so if your compiler does not conform to it, it is no use testing or trying to understand it: it will depend on implementation, or even version of the compiler.

If your compiler conforms to C++17, it is guaranteed that in a simple or compound assignment (= or e.g. +=, respectively) all of the side effects of right hand side will be dealt with before evaluating the left hand side.

In your case, x-- is evaluated to be 10 accompanied by setting x=9 as its side effect, then the computer will add 10 to x=9 resulting in x=19.

Thanks to Michał for his correction, which I incorporated into the answer.

tif
  • 1,424
  • 10
  • 14
0

Having an older c++ might probably not do the job as the behaviour is literally defined to be undefined, by the older standard. (Thanks to @LightnessRacesinOrbit)

If you just try out an online compiler which will have the latest version, it works just fine and the result is 19 as you expected (x+=x-- is the same as x= x+x--. This means for getting the new "x", it has to sum the old "x"+the old "x" -1. So it will do x+(x--), which is x=10+(9).

Try it out here: with:

#include <iostream>

using namespace std;

int main()
{
    int x = 10;
    x += x--;
    cout<<x<<endl;
}
M.K
  • 1,464
  • 2
  • 24
  • 46
  • 1
    "might not be able to handle it" is incorrect. The behaviour is literally defined to be undefined, by the [older] standard. It's not a limitation of the compiler, it's how C++ is specified. – Lightness Races in Orbit Oct 23 '18 at 10:12
  • Okay thanks for the correction! I'll edit the answer right away! @LightnessRacesinOrbit – M.K Oct 23 '18 at 10:13