Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-07-08 11:57:04


Howard Hinnant wrote:
> On Jul 8, 2004, at 11:10 AM, David Abrahams wrote:
>
>> Are there really any repercussions from making a noncopyable type
>> into a moveable type, other than that you might want to find ways to
>> take advantage of the new moveability?
>
> If I had an rvalue reference available today, I would design the
> interface of the read and write locks differently.

[reordered]

> So the major repercussion that I see is that we're designing an
> inferior interface today that is not forward compatible with what I
> would propose if move semantics were available.

This is a concern. However, I'm not sure that the noncopyable lock interface
is necessarily inferior and cannot be made forward compatible.

> For example, instead of:
>
> void f(rw_mutex& m)
> {
> rw_mutex::upgradable_read_lock r(m);
> if (...)
> {
> rw_mutex::write_lock w(r);
> //...
> w.transfer_to(r);
> }
> //Point A
> }
>
> I would propose:
>
> void f(rw_mutex& m)
> {
> rw_mutex::upgradable_read_lock r(m);
> if (...)
> {
> rw_mutex::write_lock w(move(r));
> //...
> r = move(w);
> }
> //Point A
> }
>
> The original code would not compile: write_lock would not accept an
> lvalue upgradable_read_lock and transfer_to would not exist.

I see no harm in allowing the "legacy" interface to function unmodified
after the transition to moveable locks. (Or is it movable locks? You should
really decide on that -eable vs -able thing, non-native speakers are getting
confused. Think of the children.)

I know that

    Classes should never move with copy syntax [Hinnant]

but in this case the constructor that "moves" an upgradable_read_lock
(upgradeable_read_lock?) to a write_lock is explicit, and it isn't a copy
constructor. Likewise, I see no harm in retaining x.transfer_to( y ); as an
alias to y = move(x).


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk