On 7/26/2011 11:35 AM, Nevin Liber wrote:
Doesn't the problem go away if you don't use boost::noncopyable at all? If one agrees
that the C++0x mechanism is superior, is there still a use case under C++0x for
boost::noncopyable?
You don't need =delete (or any) syntax for this. If you declare a move constructor, the copy constructor is implicitly declared (by the compiler) as deleted.
Admittedly, this doesn't address the case for older compilers that don't implement the rules that came out of the C++0x Batavia meeting.
In my mind "no copy" does not say anything about the ability to move. In fact, move will typically be just dandy if the compiler handles it. So I would like that meaning.
In order to reduce the chances of silently breaking existing code, the rules of C++0x were chosen so that a C++03 "noncopyable" (in quotes because in C++03 the closest we can get to that is to have an unimplemented private copy constructor and copy assignment operator) class automatically is a noncopyable+nonmoveable class under C++0x. I really don't think we should mess with that.