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.