[move semantics] Do we have any plan for move semantics emulation?

Hi to all, The rvalue reference is likely to be accepted for the next standard and the standard library is also likely to be modified to implement move semantics. Googling around, the only thing I've found related to Boost and move semantics is Jonathan Turkanis' Boost Move Ptr (http://www.kangaroologic.com/move_ptr/). This move ptr and Howard's unique_ptr emulation code (http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr_03.html) are similar and offer a good new smart pointer. However, I was wondering if we could try to sketch an emulation of "std::move()" for objects that are not unique_ptr/move_ptr. Something that would allow at least to define (portably, perhaps with a macro that in the future, with compilers that implement move semantics, can be expanded to the proper && signature) move constructors and assignments: boost::movable_t movable_source(...); boost::movable_t movable_target(boost::move(movable_source)); We won't have perfect forwarding but we could start playing with move semantics to see how it feels. We would need an explicit move from temporaries, if rvalue catching can't be emulated: boost::movable_t produce_movable(); boost::movable_t movable_target(boost::move(produce_movable())); The idea would be to define some macros that would allow some kind of emulation and that would become proper rvalue references in future compilers: my_class(BOOST_NAMED_RVALUE_REF(my_class) move_src) : m_member(BOOST_NAMED_RVALUE_REF_GET(move_src).member) {} BOOST_RVALUE_REF might be a class holding a pointer to the move sourceand BOOST_RVALUE_REF_GET an operator returning a reference to the pointed object: #define BOOST_NAMED_RVALUE_REF(class_name) rvalue_emulation<class_name> #define BOOST_NAMED_RVALUE_REF_GET(object_name) (*object_name) in the future those would be expanded to: #define BOOST_NAMED_RVALUE_REF(class_name) class_name && #define BOOST_NAMED_RVALUE_REF_GET(object_name) object_name As far as know, only Codewarrior (don't know if an experimental version or officially released one) has move semantics implemented under an explicit pragma. I've read about efforts to implement this on gcc but I haven't heard anything recently. Does any booster ideas for emulating move semantics or is there any ongoing effort? I'm ready to help a bit about this, but I would want to know if I might be duplicating efforts. Regards, Ion

Ion Gaztañaga wrote:
The rvalue reference is likely to be accepted for the next standard and the standard library is also likely to be modified to implement move semantics. Googling around, the only thing I've found related to Boost and move semantics is Jonathan Turkanis' Boost Move Ptr (http://www.kangaroologic.com/move_ptr/). There's also a great utility from Andrei Aleksandrescu: http://www.ddj.com/dept/cpp/184403855
I used it in my STL-compatible container library with great results. Also, there's NTL (http://upp.sourceforge.net/srcdoc$Core$Tutorial$en-us.html) which uses 'move constructors' by default. -- With respect, Alex Besogonov (cyberax@elewise.com)

Ion Gaztañaga <igaztanaga@gmail.com> writes:
Hi to all,
The rvalue reference is likely to be accepted for the next standard
and the standard library is also likely to be modified to implement move
semantics. Googling around, the only thing I've found related to Boost
and move semantics is Jonathan Turkanis' Boost Move Ptr
This move ptr and Howard's unique_ptr emulation code
(http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr_03.html) are
similar and offer a good new smart pointer. However, I was wondering if
we could try to sketch an emulation of "std::move()" for objects that
are not unique_ptr/move_ptr. Something that would allow at least to
define (portably, perhaps with a macro that in the future, with
compilers that implement move semantics, can be expanded to the proper
&& signature) move constructors and assignments:
I've been intending to get this into Boost: http://boost.cvs.sourceforge.net/boost-sandbox/boost-sandbox/boost/move.hpp http://boost.cvs.sourceforge.net/boost-sandbox/boost-sandbox/libs/move/test/ You can find a long thread about this work here: http://news.gmane.org/find-root.php?message_id=%3cc5mlde%24481%241%40sea.gma... -- Dave Abrahams Boost Consulting www.boost-consulting.com

I've been intending to get this into Boost:
Looks nice. Any intention to request a review? Inheritance approach (deriving from moveable) is a good idea, but Boost.Move code wouldn't be compatible with the standard C++0x syntax. Is inheritance necessary to get the desired rvalue/lvalue dispatching or is just a convenience? If you get a compiler with rvalue references (let's hope gcc gets this soon), and you have a library with Boost.Move it would be nice just to recompile. Just my 2 cents. Anyway, nice to know you are working on it. Regards, Ion

Ion Gaztañaga <igaztanaga@gmail.com> writes:
I've been intending to get this into Boost:
Looks nice. Any intention to request a review?
Yeah, sorta. I was planning on doing that after I wrote some code that uses it in anger.
Inheritance approach (deriving from moveable) is a good idea, but
Boost.Move code wouldn't be compatible with the standard C++0x syntax.
Is inheritance necessary to get the desired rvalue/lvalue dispatching or
is just a convenience?
IIRC, it's the latter. It's been a while since I worked on this code, though. Oh, the comment says: // CRTP base class for conveniently making movable types. You don't // have to use this to make a type movable (if, for example, you don't // want the MI non-EBO penalty); you just need to provide the // conversion to move_from<Derived> yourself in that case. template <class Derived> struct movable
If you get a compiler with rvalue references (let's hope gcc gets
this soon), and you have a library with Boost.Move it would be nice
just to recompile. Just my 2 cents. Anyway, nice to know you are
working on it.
I haven't been, really. The coding/testing work is done, as far as I'm concerned. It needs docs, of course. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (3)
-
Alex Besogonov
-
David Abrahams
-
Ion Gaztañaga