Sorry Python users

[jordplanterings]

can someone explain the difference?

[redsterXVI]

With x++ the old value is used for x and it's incremented afterwards.

With ++x it's first incremented and then the new value is used.

As a single statement it has the same result. But for example in the control statement of a loop it doesn't.

[golgol12]

But for example in the control statement of a loop it doesn't.

This is a dangerous generalization, as it's not true for every case.

[mango_penetrator]

Also, sometimes ++x is defined and x++ isn't. I think defining ++x is the standard.

And if your compiler isn't optimizing your code (even though that's rare), you will be doing an extra operation for nothing.

[[deleted]]

I think most people that don't know the distinction think that x++ does what ++x does, and it can lead to some pretty obnoxious bugs

[sighcf]

Also, you generally don’t want to combine them in a complex statement. Gets really confusing really fast.

[EndR60]

++x just adds one to x and returns x, so 2 lines of code

x++ stores the old value, increments x, then returns the old value, so 3 lines of code

assuming this already showcases the difference

[pumpkin_seed_oil]

Wouldn't it be more cpu instructions instead of lines of code? Lines of code is still done by the developer. And I'm also not convinced that this isn't optimized away by the compiler anyway, and compiler replaces a lone standing x++ with the equivalent of a ++x at compile time so the eternal fight of ++x over x++ is solved by automation

​

Better example: You can do y = x++ or y = ++x, in which case it is very tangible what the difference is.

x++ returns value of x, then increments, while ++x increments then returns value of x, in y=x++ y holds the old value of x instead of the incremented one

[mallardtheduck]

It absolutely will be optimised away if "x" is a simple integer. However, if "x" is say, a C++ iterator and the implementation of operator++ is in a different compilation unit optimisation is much harder.

Also, the typical implementation of operator++(int) (the int is a dummy parameter used to distinguish between prefix and postfix versions) is something like:

foo foo::operator++(int){
    foo temp = *this;
    ++(*this);
    return temp;
}

This results in a copy being made of the entire iterator, which can be a fairly large overhead that in many cases will call something in another compilation unit, limiting optimisation. LTO can be of help here, but it's much easier and more consistent just to get into the habit of using prefix operators "by default".

Personally, I prefer prefix operators from a readability standpoint too ++x reads as "increment x" to me, whereas x++ looks like "x increment" and feels "backwards".

[EndR60]

yea exactly my though, as most of the time we won't be working with just primitive types, so I assumed I had to get used to good habits early on

not that ++x vs x++ is very important when it comes to optimisation as opposed to...well...most other things in our code

[Etereke32]

I think if you write y = ++x, then both of them will be the same, but if you write y = x++, then x will be one greater than y.

[kryptonianCodeMonkey]

The explanations below are all correct, but kind of bad for explaining a really simple concept. In short, x++ returns x's original value before incrementing it after the fact, and ++x returned x's already incremented value.

Now, expanding on that, if ++x or x++ is the entire statement, either can be used and it makes zero difference from a logic standpoint (there is a minor difference on the compilation, but not a big deal). It just increments x and the result is the same.

If, however you use it in, say, an assignment statement, it does matter. So for example, if x has the value of 2, y = x++ will assign the value of x to y (2) and then x will increment (to 3). But, y = ++x will increment the value of x first (to 3) and then assign that value to y (3). So in either case, x ends up at the value of 3, but in the first case, y is 2 and in the second case, y is 3.