On 2010-10-06 21:58:42 -0400, Andrei Alexandrescu
<[email protected]> said:
Once the copy constructor has constant complexity, moving vs. copying
becomes a minor optimization.
But if your algorithm can work using only moves, it can support types
that are non-copiable, so it's not simply an optimization.
One reason a type might be non-copiable is to make it simpler (not have
to write some reference-counted copy-on-write logic). Also, even though
you call it a minor optimization when it doesn't affect complexity,
copying by incrementing/decrementing a reference counter requires
atomic operations so it'll be noticeably more efficient to move rather
than copy, even though both have the same algorithmic complexity.
So I think it's important that move be used each time it's possible to use it.
Or perhaps it's just me not liking the added requirement of reference
counters everywhere in a GC-managed environment. As I mentioned in my
other post, they're very tricky to implement correctly, at least as
long as you're allowed to put one of these ref-counting struct in the
GC-managed heap.
--
Michel Fortin
[email protected]
http://michelf.com/
