Boost logo

Boost :

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2004-07-08 11:26:44


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

This would allow, among other things, locks to be returned from
functions (as long as they were auto-local within the function). It
would also allow for containers of locks.

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.

We could possibly fake the desired move syntax today, but the thought
makes me tired. :-( Especially in the light that the proposed move
syntax is by no means a sure deal.

-Howard


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