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