The Dark

No, I'm not getting pre/post increment confused.

Yes, the i++ gets run after the expression is evaluated. But is that before or after the assignment is evaluated.

The Dark

My mistake - the whole assignment is the expression. So the ++ is done at the end of the whole thing.

But I would definitely mark it down as bad style.

Game_Ender

Sorry there Dark, edited my post you were right and GCC agrees. But from the face of it, I would call it valid if bad style like yourself.

DaWei

The fact that one compiler acts as you deem properly does not mean that all compilers will. If the language says it's undefined, then you can't count on a compiler implementation being any specific thing. Anything at all might happen, or nothing. What ever did (or didn't) happen would be okay.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

grumpy

I suppose you could describe;
as bad style, but that's an understatement. It actually yields undefined behaviour, as it modifies i twice between two sequence points.

In practice, it is a subtle form of undefined behaviour (i.e. it is unlikely to cause a crash). To understand why it is undefined behaviour, consider what happens with this;
This code can (simplistically, assuming i and j are distinct variables) be translated into;
or into;
depending on how the compiler works. Consider what happens if j is actually i in the above two cases.

There are technically more possibilities, depending on how the compiler works (eg exploiting machine instructions or other features, aggressiveness of optimisation). The C and C++ standards deliberately avoid specifying how a compiler must work internally, and the first option will be the best implementation choice on some machines and the worst on others. But specifying what happens when code is modified multiple times between sequence points (as in i = i++;) unfairly limits the freedom of the compiler to optimise performance of its output code (in the sense that it will be good for one compiler vendor but penalise another). Which is why such things are described as undefined behaviour: there is no end of possibilities for how compilers might work internally when they see such code.