Post increment and decrement

[deadalnix via Digitalmars-d]

On Sunday, 15 March 2015 at 08:45:55 UTC, Jonathan M Davis wrote:
> On Saturday, March 14, 2015 15:35:24 Ali Çehreli via 
> Digitalmars-d wrote:
>> On 03/14/2015 03:23 PM, deadalnix wrote:
>>
>>  > But, for some reason, the topic come up again and again 
>> from C++ devs
>>  > that have no idea the optimization guys solved the issues 
>> for years now.
>>
>> If we are talking about C++, it is not possible to not take 
>> that copy
>> for user-defined types. Due to separate compilation, the 
>> compiler does
>> not even see the definition of operator++(int).
>>
>> And the compiler cannot replace calls to operator++(int) with 
>> calls to
>> operator++() (when the return value is not used) because the 
>> programmer
>> may have done different things than the canonical 
>> implmentation of
>> post-increment.
>
> Exactly. In C++, there isn't even a guarantee than an overloaded
> postincrement operator is even related to an overloaded 
> preincrement
> operator. One could do addition while the other does 
> subtraction - or
> nothing at all. Sure, bad code won't do that, but the compiler 
> doesn't know
> whether you're being an idiot or not. So, it can't assume that 
> overloaded
> preincrement and postincrement are at all related and therefore 
> can't
> optimize a postincrement to a preincrement for overloaded 
> operators.
>
> The result is that simply always using preincrement when you 
> need to
> increment but don't specifically need to postincrement is a 
> good habit to
> get into. Its impact is likely to be minimal in most cases, but 
> it doesn't
> cost you anything, and you can't rely on the compiler's ability 
> to optimize,
> because the C++ standards committee didn't restrict the 
> overloaded increment
> (or decrement) operators enough to enable the compiler to 
> optimize them
> properly.
>
>> C++ needs a rule like D's, which will never be there.
>
> Yep. By making it so that you only overload a single operator 
> for both
> versions of increment, we avoid the whole problem in D, similar 
> to how
> having opCmp avoids bugs related to having to define each 
> comparison
> operator individually as is the case in C++.
>
> It'll likely always bug me though when I see i++ when ++i would 
> work, even
> if it doesn't matter in D. It's just too ingrained in me, I 
> guess. :)
>
> - Jonathan M Davis

Yeah, one can rationalize all he/she wants. Thing is:
  - Either the operator implementation is simple and the optimizer 
will see through it.
  - Or it is quite complex and the extra copy will barely show up 
in benchmark anyway.

The only case where it makes sense is with separate compilation, 
as Ali mentioned. But in which case, same as above, either the 
thing is simple, and you loose way more in calling convention 
than you could save by optimizing a copy away, or the 
implementation is complex so that the calling convention or the 
extra copy do not matter.