Re: [boost] [move] Unifying move emulation code in 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 <igaztanaga-AT-gmail.com> wrote:

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

Agreed.

> 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 (http://stlab.adobe.com/group__move__related.html) 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.

Great.

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

Agreed.

> 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
http://www.boostpro.com