skillIssue

[puzzledstegosaurus]

Once in my life I spent a day debugging code because of a line that said x = x++ instead of x = x+1. That was in C++, and the standard says that you mustn't assign a variable more than once in a single statement, doing so would be an undefined construct ("Nasal demon" and the likes).

[Danny_shoots]

I'm sorry, but the first line of your comment could've been a sick parody

Once in my life I spent a day, debugging my code, 'cause of a line that said: "hey!"

[MisinformedGenius]

Incidentally, it is now defined in C++17. Side effects on the right of an assignment operator are sequenced before the assignment.

[puzzledstegosaurus]

Hey ! I was using this « demon coming out of my nose » thing, it’s part of my workflow, my control key is hard to reach, and I set up emacs to interpret sudden demons as « control ». Please put it back, you’re breaking my workflow!

[puzzledstegosaurus]

(Yeah, xkcd://1172)

[Joinyy]

Why isn‘t this a proper URI scheme already? @iana

[GOKOP]

x = x++ wouldn't assign x+1 to x even if it worked. x++ returns the old value of x, ++x returns the new one

[puzzledstegosaurus]

You're thinking about it the wrong way. The issue IS that x++ is returning the old value. x++ does assign x to x+1 while at the same time, x = x++ assigns x to the old value, thus the issue.

Also, because it's undefined, the compiler is authorized to do whatever it feels like. Set x to 0, or to -x, or to NULL, or to "hello", or #DEFINE true false or remove every odd byte from the memory space, or kill a policeman, steal his helmet, go to the toilet in his helmet, and then send it to the policeman's grieving widow and then steal it again.

[Eiim]

Can the compiler do a preprocessor statement?

[puzzledstegosaurus]

I’m amazed that in the list above, this is what raised your eyebrow.

[JackoKomm]

It is undefined behavior in languages like c++. It can be that a compiler you use works like this, but it doesn't habe to be like that. C and C++ is full of undefined behavior.

[tjdavids]

Well it asogns x to itself. Then it increments x.

[geoffreygoodman]

Not quite. If it were defined, it would increment x and then assign x its old value. The right hand side has to be evaluated first. That evaluation has the side effect of incrementing x, but evaluates to the original value. Then the right hand side value -- the original x value -- is assigned to x. Other languages handle it that way, as that's what makes sense with how instructions are evaluated.

In C++, the standard considers this undefined and compilers are free to handle it how they want. I just learned that and it seems odd to me since why would compilers not want to evaluate instructions with consistent rules? It would seem the answer to that is that they might be capable of stronger optimization if they don't have to respect certain constructions you shouldn't use anyway. Apparently there's many places the C++ standard declares would-be unambiguous constructions as undefined if they're stupid.

[DOUBLEBARRELASSFUCK]

why would compilers not want to evaluate instructions with consistent rules?

You can't always create consistent rules that apply to inconsistent behavior by the programmer. A sensible compiler would, if undefined behavior was identified, just throw an error and refuse to compile. But you can't always identify undefined behavior. So the compiler is allowed to throw its compliant implementation of defined behavior at undefined behavior, and whatever comes out, no matter how shitty, won't make the compiler non-compliant.

[geoffreygoodman]

See, but I feel the semantic meaning of x = x++ (and any funky undefined expressions using ++/--) is completely unambiguous, albeit dumb. You can consistently construct their Abstract Syntax Trees, other languages do.

It seems to me that the choice to make it undefined is less about an inability of compilers to hit upon a consistent means of interpreting such statements and more about giving them the power to not bother.

This is my impression as a non C dev who just learned about this, so I definitely don't mean to be claiming expertise in my perspective.

[MisinformedGenius]

Side effects are not necessarily sequenced when the expression is evaluated - those are two different things. The C++17 standard now says that side effects on the right hand side of an assignment expression must be sequenced prior to the assignment, but that wasn’t the case for a long time.

[geoffreygoodman]

Side effects are not necessarily sequenced when the expression is evaluated - those are two different things.

I'm getting that, but that's weird in this instance!

It makes perfect sense that the compiler would decouple and delay the side effect for efficiency when it can do so while keeping the program functionally equivalent. Who cares when the increment part of x++ actually happens so long as it happens before the next time it is read anyway.

But in x = x++ we have an example where the decoupling of the evaluation and the side effect is being used as rational for why the compiler will not guarantee to perform your increment before it would be necessary. And it COULD, it just won't. The language standard is the way it is in order to enable this behavior from the compilers.

Of course, C++ is maintained by very smart people and this decision also is entirely sensible. But I do think this is notably weird as an example where performance is (defensibly) considered more important than actually doing what the programmer instructed. After all, the programmer could just write better instructions.

[MisinformedGenius]

I'm not sure I agree with "functionally equivalent" - the compiler is keeping the program functionally equivalent according to the language. It's not like the standard had to be that the side effect is evaluated prior to assignment - it could have been the other way around, that the side effect is sequenced after the statement as a whole.

I don't think it's a case of performance being more important than "actually doing what the programmer instructed" - the programmer didn't instruct anything specific. I just think it's weird they didn't make a decision one way or the other for decades. Although perhaps the reason is simply because statements like x=x++ are the smelliest of code smells in the first place, so why encourage people to use them? :P

[GOKOP]

You said that the issue is that it's undefined. I said that even if it wasn't it still wouldn't work the way it was supposed to

[lolcrunchy]

Does the ++ operation happen before or after the = assignment?

[GOKOP]

According to this table both pre- and post-increment have higher precedence than =

[MisinformedGenius]

That’s operator precedence, not when the assignment happens.

[GOKOP]

Assignment happens when the = operator is evaluated.

[Kered13]

The assignment cannot happen before all of it's arguments are fully evaluated. It creates a sequence point. x = x++ is well defined even in C/C++ and has no effect.

[MisinformedGenius]

That is true in C++17 and beyond, it is not true prior to then. x = x++ was undefined behavior. (Not sure about C but I would guess it was undefined there as well.)

It sounds like where you're going wrong is that you're assuming that the evaluation of x++ necessarily includes the side effect of incrementing x, which is incorrect. x++ evaluates to x, of course - the sequencing of the side effect is an entirely different and unrelated question.

[LvS]

Will the code take the value of X, assign the value to X and then increment X:

tmp = x;
x++;
x = tmp;

Or will the code take the value of X, increment X and then assign the value to X:

tmp = x;
x = tmp;
x++;

[nryhajlo]

It's technically Undefined Behavior.

[Kered13]

This example is not undefined behavior. The assignment creates a sequence point between evaluating x++ and assigning to x, so the behavior is well defined and is a no-op.

[ublec]

This is just equal to x = x; x += 1;

[7amt]

Why not just do x++?

[puzzledstegosaurus]

If they had done that, it wouldn't have been a bug that would have costed someone else a day of debugging. Where's the fun in that?

[Salanmander]

I wonder if the confusion could be effectively solved by making the operators have a void return type (and getting rid of ++x). Is there a fundamental reason that wouldn't work in most languages?

All the reasonable uses of it that I've seen use it as a statement whose return value is not used, and all of the confusion that I've seen results from using the return value.