Ruling out arbitrary cost copy construction?

[Michel Fortin]

On 2010-10-06 21:58:42 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> 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
michel.fortin at michelf.com
http://michelf.com/