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

[Ion Gaztañaga]

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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Alex Besogonov]

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[David Abrahams]

Ion Gaztañaga <igaztanaga@...> 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

> (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:



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.gmane.org%3e



--

Dave Abrahams

Boost Consulting

www.boost-consulting.com


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Ion Gaztañaga]

> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[David Abrahams]

Ion Gaztañaga <igaztanaga@...> 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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost