Re: [Boost-users] noncopyable and move semantics

Subject: Re: [Boost-users] noncopyable and move semantics
From: Nathan Ridge (zeratul976_at_[hidden])
Date: 2011-07-28 19:12:02

> On 28 July 2011 13:58, Nathan Ridge  
> <zeratul976_at_[hidden]<mailto:zeratul976_at_[hidden]>> 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.