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