[core] [noncopyable] Add nonmoveable?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[core] [noncopyable] Add nonmoveable?

Boost - Dev mailing list
In addition to noncopyable, I sometimes want to force classes to be
nonmoveable as well (mainly node-type classes in tree structures which
other classes point to). Therefore I'd suggest adding a cousin to
noncopyable; boost::nonmoveable which simply prevents an instance to be
nonmoveable (as well as noncopyable).


Note; even due the delete modifier were added in C++11 I still think
inheriting boost:noncopyable\nonmoveable syntactically nicer than manually
marking the copy\move constructors\assignment operators delete.


/Viktor Sehr

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [core] [noncopyable] Add nonmoveable?

Boost - Dev mailing list
On 04/25/17 13:10, Viktor Sehr via Boost wrote:
> In addition to noncopyable, I sometimes want to force classes to be
> nonmoveable as well (mainly node-type classes in tree structures which
> other classes point to). Therefore I'd suggest adding a cousin to
> noncopyable; boost::nonmoveable which simply prevents an instance to be
> nonmoveable (as well as noncopyable).
>
> Note; even due the delete modifier were added in C++11 I still think
> inheriting boost:noncopyable\nonmoveable syntactically nicer than manually
> marking the copy\move constructors\assignment operators delete.

I think in C++11 noncopyable should be considered deprecated and
generally avoided. It affects class hierarchy, adds an extra namespace
to ADL and may not be optimized away with EBO. I would even avoid it in
C++03 as well. It follows that nonmoveable makes no sense in C++11. Just
use the language features you have.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [core] [noncopyable] Add nonmoveable?

Boost - Dev mailing list
On 25/04/2017 22:23, Andrey Semashev via Boost wrote:

> On 04/25/17 13:10, Viktor Sehr via Boost wrote:
>> In addition to noncopyable, I sometimes want to force classes to be
>> nonmoveable as well (mainly node-type classes in tree structures which
>> other classes point to). Therefore I'd suggest adding a cousin to
>> noncopyable; boost::nonmoveable which simply prevents an instance to be
>> nonmoveable (as well as noncopyable).
>>
>> Note; even due the delete modifier were added in C++11 I still think
>> inheriting boost:noncopyable\nonmoveable syntactically nicer than
>> manually
>> marking the copy\move constructors\assignment operators delete.
>
> I think in C++11 noncopyable should be considered deprecated and
> generally avoided. It affects class hierarchy, adds an extra namespace
> to ADL and may not be optimized away with EBO. I would even avoid it in
> C++03 as well. It follows that nonmoveable makes no sense in C++11. Just
> use the language features you have.

boost::noncopyable has protection so it won't ADL to the boost:: namespace.

Also, since it does not explicitly declare move constructors either way,
anything that inherits from boost::noncopyable is also non-moveable by
default, which is usually what you want.


The C++11 way, however, would be to use a std::unique_ptr as a private
member of your class (eg. for PIMPL), which automatically makes your
class moveable but not copyable via Rule of Zero.

Or use shared_ptr if you want your class to be copyable but have all
copies point to a shared implementation (handle-body or reference idiom).



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [core] [noncopyable] Add nonmoveable?

Boost - Dev mailing list
On 04/26/17 03:00, Gavin Lambert via Boost wrote:
> On 25/04/2017 22:23, Andrey Semashev via Boost wrote:
>>
>> I think in C++11 noncopyable should be considered deprecated and
>> generally avoided. It affects class hierarchy, adds an extra namespace
>> to ADL and may not be optimized away with EBO. I would even avoid it in
>> C++03 as well. It follows that nonmoveable makes no sense in C++11. Just
>> use the language features you have.
>
> boost::noncopyable has protection so it won't ADL to the boost:: namespace.

Yes, but it doesn't remove the dummy namespace from ADL.

> Also, since it does not explicitly declare move constructors either way,
> anything that inherits from boost::noncopyable is also non-moveable by
> default, which is usually what you want.

Deleted copy constructor/assignment have the same property.

> The C++11 way, however, would be to use a std::unique_ptr as a private
> member of your class (eg. for PIMPL), which automatically makes your
> class moveable but not copyable via Rule of Zero.
>
> Or use shared_ptr if you want your class to be copyable but have all
> copies point to a shared implementation (handle-body or reference idiom).

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?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [core] [noncopyable] Add nonmoveable?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Viktor Sehr wrote:

> In addition to noncopyable, I sometimes want to force classes to be
> nonmoveable as well (mainly node-type classes in tree structures which
> other classes point to).

Every class that derives from noncopyable is also automatically nonmoveable,
so it's not clear what you're asking.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [core] [noncopyable] Add nonmoveable?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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?

> 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.

> 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?

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.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [core] [noncopyable] Add nonmoveable?

Boost - Dev mailing list
On 27/04/2017 11:23, I wrote:
> If your data members aren't the reason you're constraining movability,
> then why do it at all?

Incidentally, including a mutex in the class members (which is probably
fairly common in multithreaded applications or libraries) also
inherently constrains the class; mutexes (whether std::mutex or from
Boost.Thread) are also neither copyable nor movable, and these traits
pass on to the containing class by default.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [core] [noncopyable] Add nonmoveable?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost