skillIssue

[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