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
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
>> 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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk