Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at