Re: [boost] [core] [noncopyable] Add nonmoveable?

Subject: Re: [boost] [core] [noncopyable] Add nonmoveable?
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2017-04-27 08:53:21

On 04/27/17 02:23, Gavin Lambert via Boost wrote:
> On 26/04/2017 20:53, Andrey Semashev wrote:
>> Yes, but it doesn't remove the dummy namespace from ADL.
>
> As long as no other symbols are defined in that namespace, what does it
> matter?

It adds more work to the compiler.

>> Deleted copy constructor/assignment have the same property.
>
> Yes, and that's better if you're writing a class that (or in a library
> that) otherwise does not depend on Boost in any way.  But if you're
> taking a dependency on Boost anyway, then boost::noncopyable is less
> typing than explicitly deleting constructors.

Well, the gain in the number of keystrokes does not outweigh the 
drawbacks, IMO.

>> That's fine if your design already employs pimpl (or you're willing to
>> change it that way). But otherwise why would you want to add a data
>> member to implement movability?
>
> If your data members aren't the reason you're constraining movability,
> then why do it at all?

Because the class is _supposed_ to be non-moveable according to its 
semantics. For example, std::mutex is non-movable not because its 
pthread_mutex_t member is non-movable (it's not) but because mutexes 
should not be movable or copyable as that doesn't make sense and plainly 
dangerous in the intended pattern of use.

Frequently, I mark my types non-copyable, and by consequence 
non-movable, because I have not yet determined the use case and 
semantics for copying/moving the object, and the default implementation 
would be inappropriate. Better mark it non-copyable/non-movable for now 
and think about it later, when the need appears.

> And if they *are* the reason you're constraining movability, then you
> should separate the memory-management concerns of the class from the
> other concerns (SRP), which is where the smart pointer types come in. It
> doesn't have to be "true" PIMPL (where the pointer is the only published
> member) to take advantage of these behaviours.

IMO, movability or non-movability is not the reason to convert a class 
to pimpl (pure or not). Very rarely I see a case when an object is not 
movable because of its members (e.g. a mutex) yet it is required to be 
movable by the rest of the program. When that happens it's usually a 
sign of a design problem.