Boost logo

Boost :

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 <> wrote:

> Hi to all,
> Sorry for the delay, but finally I've found some time to uploaded a new version of
> Boost.Move:
> Sandbox:
> ZIP file with docs:
> Online docs:


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_)) { }


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


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


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


Dave Abrahams
BoostPro Computing

Boost list run by bdawes at, gregod at, cpdaniel at, john at