You jest, but I always found it puzzling that there was a time (supposedly?) that compilers were dumb enough to assemble ++c and c++ differently in cases where they simply occur as stand-alone expressions, despite their obvious semantic equivalence.

Even stranger: people that insist on writing their (loops; like; ++this) in 2021 as if doing so is in any way superior or something.

Optimizing integer increment might be easy. Hard thing is optimizing overloaded increment operator. ++c is naturally faster, because it does not have to make a copy of its previous value. Especially if that operator implementation is inside another library. So it makes sense to use fast-by-default approach.

Yeah, I should have specified that I was referring to plain-old-data types such as integers. Custom objects overloading their operators certainly allow any number of differentiated rabbit holes to be dug.

With complex iterator types that carry additional state themselves (for example think iterators to sparse data or generators), it definitely makes a difference

a++; means do nothing then increment a, ++a means increment a then do nothing, what should be the difference? (Of course you can define operator++ to format the hard drive. )

If you have a single-pass compiler (for speed) then it will not know on pass #2 that the old value is to be used for something or not and can drop it.

In a single-pass run, you must generate code to keep the previous value in case the line actually was foo = ++a; or foo = a++; so that foo gets the pre-inc or post-inc value.

The small part that creates the code for the small "a++" part of the line will then produce a dead store of the pre-inc value, and no 2nd pass will remove it.

Allow me introduce operator overloading, where I have suddenly defined a ++ operator on my god object that contains a 50MB pool. This operator increments a single field in it, and I really need it because I do it so often.

++godobject will simply increment that value.

godobject++ will make a copy of that object, returning it to you along with allocating another 50MB pool, purely to increment the value.

That's what I meant with operator++ being redefined to do anything.

but when you write generic algorithms (as you should), you don't know beforehand with which "operator++" your a will be called. So you have to go for the one which will give the best performance.

> a++; means do nothing

only if a is a very simple thing. plenty of "advanced" containers actually do things ; in the "a++" case they have to save the previous state to return a copy, in the "++a" case they don't. If your iterator for instance contains a std::vector<int> to maintain some internal state for a multidimensional dynamic matrix, then in one case you'll get a simple increment, in the other a whole dynamic allocation / free which may be optimized out by the compiler in release mode and definitely won't in debug mode

That is increment a part, for whatever is being defined as incrementing for this class. If you define different things for post and pre increment they will cost differently, sure. If the compiler decides to do more than what I told to, it will be longer. But will a++ always cost more than ++a?

> If you define different things for post and pre increment

They are defined as different things. One returns the current value and increments, the second increments the current value and returns it. In the first case you have to cache the previous value, in the second you don't. If your operators don't do that they are bugged and wrong.

Only C++ programmers will appreciate this joke.

Thank you for laughter.