Re: [boost] [move] Library uploaded to sandbox

Subject: Re: [boost] [move] Library uploaded to sandbox
From: David Abrahams (dave_at_[hidden])
Date: 2009-02-18 12:11:30

on Tue Feb 17 2009, Ion Gaztañaga <igaztanaga-AT-gmail.com> wrote:

> Hi to all,
>
> I've uploaded a new version of the move emulation library to sandbox. I've put it
> temporarily in "move_semantics" folder to avoid overwriting current move code.
>
> I've put some quickbook documentation whose introduction is based in the article "A
> Brief Introduction to Rvalue References" by Hinnant, Stroustrup, Kozicki.
>
> http://svn.boost.org/svn/boost/sandbox/libs/move_semantics/index.html
>
> The library needs specially modified Interprocess containers (and Intrusive because of
> dependences), which I've also uploaded to sandbox. The examples show how movable only
> values can be inserted into containers.
>
> For those that don't like svn sandbox (I'm one of them) I've also put the code and the
> documentation here:
>
> http://www.drivehq.com/web/igaztanaga/move_semantics.zip
>
> And online documentation also here:
>
> http://www.drivehq.com/web/igaztanaga/libs/move_semantics/

Wow, this is way cool: you've found a way to allow the default
copy ctor and assignment operators to be in place, and yet still treat
rvalues specially!  I guess that's because overloading prefers derived
classes:

  template <class B>
  struct D : B
  {};

  template <class T>
  struct B {
     operator D<B>&() { return *static_cast<D<B>* >(this); }

     B() {}

     B(B const&) // move ctor
     { T::copy_ctor_called(); }

     B(D<B>& x) // move ctor
     { }

  };

  B<int> f()  { return B<int>(); } // <== most likely elided; otherwise move
  B<int> x(f());                   // <== calls move ctor
  B<int> y(x);                     // <== calls copy ctor, generating error

So you're relying on a wee bit of undefined behavior by downcasting your
B&, but that's alright with me.

The one thing I guess you give up when doing things this way is the
ultimate efficiency of copy elision for incoming parameters.  However,
we can tell people that when they're going to copy the rhs anyway, they
should pass by value.  That means

       self& operator=(self rhs)
       {
           swap(*this,rhs);
           return *this;
       }

should still be the canonical assignment operator (if your docs can rely
on universally-benign undefined behavior, surely they can also rely on
universally-implemented copy elision).

Hmm, and does this work?

  template <class T>
  struct C : B<T>
  {
      operator D<C>&();
      C(D<C>& rhs);
      C();
  };

  int g(B<int> const&);
  int test = g(C<int>());

Yes!  Pretty slick.

> The documentation is not in english, it's in my own english dialect so be careful when
> reading ;-) Patches and corrections welcome. I've documented some functions to create
> a little boostbook reference.
>
> I've invested some precious time in the library and testing different approaches to
> see if it plays well with containers but I would like to hear some comments on whether
> the direction is acceptable and if I should spend more time on it. 

Oh, yeah, you definitely should.  I think Howard has a move semantics
test suite we can throw at this library.  Howard?

> If someone else
> with more time wants to continue the library, please do it! ;-)
>
> I've personally added to the library all that I've seen useful for move-aware
> containers, so it might lack some features (move aware algorithms, for example).

Jah; those'll come in time.

> Anyway, my opinion is that we need some move library, better now than
> later even if it's too basic, so that we can unify all redundant move
> emulation that we already have in boost libraries. I hope this is a
> step in the right direction.

I like this, very very much.  It's so clean and obvious that it even
worries me a little: didn't I try and discard this approach once?  I
dunno, but if we can get it to pass a rigorous test suite, I think it's
totally awesome.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com