Re: [boost] [move] New version with move-aware containers library

Subject: Re: [boost] [move] New version with move-aware containers library
From: David Abrahams (dave_at_[hidden])
Date: 2009-04-15 18:46:26

on Sun Apr 12 2009, Ion Gaztañaga <igaztanaga-AT-gmail.com> wrote:

> Hi to all,
>
> Sorry for the delay, but finally I've found some time to uploaded a new version of
> Boost.Move:
>
> Sandbox:
>
> https://svn.boost.org/trac/boost/browser/sandbox/move
>
> ZIP file with docs:
>
> http://www.drivehq.com/web/igaztanaga/move.zip
>
> Online docs:
>
> http://www.drivehq.com/web/igaztanaga/libs/move/

Nice!

Here's one thing I don't love:

   Derived(BOOST_RV_REF(Derived) x)             // Move ctor
      : Base(boost::move(static_cast<Base&>(x))), 
        mem_(boost::move(x.mem_)) { }

is there a way to get rid of the static_cast and make

   Derived(BOOST_RV_REF(Derived) x)             // Move ctor
      : Base(boost::move(x)), 
        mem_(boost::move(x.mem_)) { }

work?

> Changes:
>
> -> Changed folder from boost/move_semantics to boost/move.
> -> I've extracted all the containers from Boost.Interprocess, put them in
> boost/container and they only depend on official Boost SVN code (I haven't tested it,
> but it should be also nice with Boost 1.38). There is no documentation for these
> containers.

w00t!

> -> Fixed a bug with EDG-based compilers.
> -> Note: I haven't applied yet the patch for non-sfinae compilers.
>
> With this changes, I think move emulation is quite portable (at least
> MSVC, EDG and GCC).

Super!

> Now that containers are independent from Boost.Interprocess, I would
> like to ask about the next step. If the move library is added, where
> should we put those containers? I would like to just drop common
> (vector, list, ...) Boost.Interprocess containers and just maintain
> these move-aware ones.

If these were originally just implementation details of another library,
then they would go in a detail/ directory until they are reviewed and
accepted.  On the other hand, since *these* are simply evolutionary
modifications of the containers in Interprocess, which /were/ reviewed
and accepted.

So this really becomes a question of how to go about breaking an
existing, accepted library into multiple libraries.  And I don't really
know the answer to that one.  I'm open to suggestions.

> If move emulation is considered mature enough, we should also plan
> when could we port all custom move-emulations present in several boost
> libraries to the "official" move library.

Yep.

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