Boost logo

Boost :

Subject: Re: [boost] [move] Unifying move emulation code in boost
From: David Abrahams (dave_at_[hidden])
Date: 2009-01-05 12:27:57

on Sun Jan 04 2009, Ion Gaztañaga <> wrote:

> Howard's unique_ptr contribution has shown again the need for a
> unified move emulation in Boost.


> We already have move emulation at
> least in 5 libraries:
> -> Interprocess: based on sandbox boost.move library, return types are wrapped in a
> move_return type.
> -> Unordered: based on Adobe's move library. It's more advanced than the previous one,
> but Adobe's own library says ( that a
> Movable type must satisfy the requirements of concept Regular, which has copy
> constructor (thus disabling move-only types!). I don't know if the move emulation
> itself uses Regular requirements.

That can easily be overcome. Adobe insists on Regular for reasons of
purity, not practicality. The important thing about the Adobe approach
is that for movable/copyable types, they don't have adverse effects on
their containers, derived classes, or containing classes: they have
regular copy ctors and assignment with const rhs. That has huge
implications for interoperability with code that isn't specifically
move-aware in whatever particular way we choose to express "move-aware"
in C++03.

> I think code changes in boost::thread and boost::unordered would be minimal if we
> adopt a solution similar to the one used by Howard's unique_ptr. Interprocess changes
> are heavier but I'm reading to adapt the library to that solution.


> I've written (attached) a small, surely not complete, but usable
> boost/move.hpp header (ok, it could go to boost/detail/move.hpp until
> a decent review is done) that is tested with a movable class in the
> file movable_test.cpp, both with Visual 7.1 and move-enabled GCC 4.3.
> The goal of this post is to know if that header file would be enough
> for all current libraries using move emulation.

What's really needed before I'd be happy to sign off on it is **a
complete suite of correct tests**. That's much more important to me
even than having an implementation that passes the tests :-)

> I have more suggestions (new traits like
> has_trivial_destructor_after_move<>...) but the main question is if
> that header can be used to agree a common protocol between us. It
> would be really nice if we could rework our code for Boost 1.39.


> If the header contains enough for everyone, I'm ready to write some
> documentation and tests. I know that this Move library is not what
> many expect (common macros and utilities to write the same code for
> rvalue-enabled and older compilers)

That can come later. We have to get the C++03 implementation right
before it can be macro-ized.

Thanks for working on this,

Dave Abrahams
BoostPro Computing

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