[boost] Yo, move semantics anyone?

From: David Abrahams (dave_at_[hidden])
Date: 2004-04-14 09:04:51

Hi,

I'm just wondering if the deafening silence indicates a lack of
interest or whether something else is going on?  
Feedback would be appreciated.

Thanks!

David Abrahams <dave_at_[hidden]> writes:

> I have to stop playing with this stuff and get back to work now, but
> over the weekend I started a library that allows a "reasonably
> convenient, useful amount" of move semantics.  Many compilers
> implement enough (N)RVO that implicit moving from rvalues is
> unneccessary, and those seem to coincide roughly with the compilers
> where we have to internally shut off some capability because of the
> compiler's interpretation of 8.5.3/5 (**).  So it seems you can pretty
> much eliminate all needless copies.
>
> Here's what you can do with the current state of the move library,
> which supplies macros (eeeeew!) to avoid code duplication:
>
> struct X
>   : boost::movable<X> 
> {
>     BOOST_LVALUE_COPY_CTOR(
>         X, (rhs)(: initializers...),
>     {
>         // copy ctor body
>     })
>
>     BOOST_LVALUE_ASSIGN(
>         X, (rhs), 
>     {
>         // copy assign body
>     })
>     
>     X(move_from<X> rhs)
>     {
>         // move ctor logic
>     }
>
>     X& operator=(move_from<X> rhs)
>     {
>         // move assign logic
>     }
> };
>
> boost::movable<X> just encapsulates the conversion to move_from<X> and
> makes the copy ctor/assignment private, so you can always replace it
> with a written-out conversion to move_from<X> if you don't like the
> "MI non-EBO" (or other) impact of library-mandated inheritance.
>
> This work owes inspiration to Rani Sharoni's "improved auto_ptr"
> (http://tinyurl.com/2rxpj) and of course one must acknowledge Andrei
> Alexandrescu for being crazy enough to even try doing this in a
> library in the first place (Mojo).  Eric Friedman had an earlier
> boost/move.hpp in the sandbox based on Mojo (which I replaced with his
> permission), and I adapted his tests, in addition to my own, to work
> with the new code.
>
> It might make sense to use this library to optimize selected Boost
> components; shared_ptr, any, and dynamic_bitset come to mind, just off
> the top of my head.
>
> You can find the code in boost/move.hpp and tests in
> libs/move/test/*.cpp.  It "basically works" with all MSVC versions,
> Borland, gcc-2.95, gcc-3.3.1, comeau (strict warnings mode only, until
> I find out how to detect that we're in strict errors mode), and all
> intel-win32 versions.  I don't know how to make gcc-3.2 work yet.
> The places where it fails, certain things seem to compile which one
> would prefer to cause an error.
>
> Enjoy,
> Dave
>
> (**) see http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1610.html
> -- 
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com