Reprise with the correction in:
On 10/6/10 16:38 CDT, Michel Fortin wrote:
On 2010-10-06 16:14:58 -0400, Andrei Alexandrescu
<[email protected]> said:
On 10/6/10 13:59 CDT, Michel Fortin wrote:
Could algorithms use "move" when possible (when "front" returns a ref)
and do a copy when move isn't available? That'd be a good compromise I
think.
T tmp = moveOrCopy(r1.front);
r1.front = moveOrCopy(r2.front);
r2.front = moveOrCopy(tmp);
Then problem is, people sort ranges of their own objects and are
amazed at the unbearable performance.
I'll repeat myself in clearer terms:
I agree with you that copy-constructor should be of *constant* complexity.
I agree that you should use a copy when you can't do a move (when front
doesn't return a ref).
I disagree that you should use a copy even when you can do a move (when
front *does* return a ref).
Therefore, I suggest that you use "move" when you can (when front
returns a ref) and fallback to a copy otherwise (when front doesn't
return a ref). Hence "moveOrCopy", which moves when it can move and
copies when it cannot move.
How can this result in poorer performances than to always copy? It can
only increase performance because you're copying less. (I understand
that it was probably just a misunderstanding of my suggestion.)
Once the copy constructor has constant complexity, moving vs. copying
becomes a minor optimization.
Andrei
