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