Re: [Boost-users] noncopyable and move semantics

On 28 July 2011 13:58, Nathan Ridge mailto:zeratul976@hotmail.com> wrote:

...

That's fine, but then could we introduce a different class that inhibits copying but not moving? I think this would be useful, as in a large percentage of cases, when you want an object to be non- copyable, you still want it to be movable.

I don't see anything wrong with that. I'm not sure how useful it is, as it only makes a real semantic difference when you want the implicitly declared move constructor and move assignment operator but no copying, which I'm guessing is rare (but I really don't have enough experience with r-value references to say more than that).

On the other hand, I think that is the most common case: - you don't want to allow copying, either because it doesn't make sense   semantically, or because it's too inefficient - you want to allow moving so that e.g. you can store the object in a   container without having to add a layer of indirection such as unique_ptr - the default move constructor does the correct thing (just like in   most cases, the default copy constructor does the correct thing) Regards, Nate.