Re: [boost] [non-instrusive move] interest in new library?

Subject: Re: [boost] [non-instrusive move] interest in new library?
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2013-01-09 12:39:07

On Wed, Jan 9, 2013 at 3:35 AM, THOMAS JORDAN <tomjordan766_at_[hidden]>wrote:

> Apologies, my previous email I sent incomplete by mistake, please ignore
> that in favour of the following:
> Hi,
> Would there be interest for Boost in a small library providing a simple,
> non-instrusive emulation of basic move semantics for
> C++03 (though one which could also be used without harm in a C++11
> environment)?
>
> The library currently consists of a small number of 'move' function
> overloads, plus a trait class. It can be used to facilitate
> move semantics/efficient value-orientated software design in environments
> which lack, or forbid C++11 or other, more intrusive
> C++03-aware move libraries  (e.g., old/buggy compiler, learning curve
> prohibitive, etc.).
> In conjunction it facilitates/forces copy-elision and return-value (RVO)
> optimisations in certain situations where they might
> otherwise not be feasible.
>
> It works as follows: it detects at compile-time if the type of the
> argument(s) has a member swap function, and if so, it
> performs a swap, otherwise it calls the regular assignment operator ('move
> if possible, copy otherwise').
>
> It can be used to provide an emulation of:
> - move-assignment between lvalues
> - moving an rvalue to an lvalue
> - moving an lvalue to a temporary
> It also supports moving between built-in arrays.
>
> Example use-cases are (ignoring namespace):
>
>
> #include "non_intrusive_move.h"
>
>
> //returning a value
>
> std::string foo(std::string s)
> {
>      //e.g., append something to s
>      //...
>      //compiler can perform rvo (compiler would likely not perform nrvo if
> just used 'return s;')
>      return move(s);
> }
>
>
>
> //moving a value to a function/ctor, when the value is not required by the
> calling code after the
> //function/ctor call
>
> std::string s("hello");
> void bar(std::string s){...}
> bar(s);           //copy
> bar(move(s));  //move
>
>
> //moving a value into place
>
> void MyClass::MyClass(std::string s)
> {
>       //move value from s into default constructed member s_
>       move(s, s_);
> }
>
> Note that the combination of both moving a value to a function/ctor and
> then moving it into place
>
> e.g.,
> std::string lv;
> //...
> MyClass mc(move(lv));
> //lv no longer needed
>
> effectively results in a zero-copy invocation, with just a small number of
> fixed size swap, default ctor and shallow dtor
> calls, so this is pretty efficient.
>
> //moving a temporary into an lvalue
> std:: string lv;
> move(foo(), lv);   //nicer than foo().swap(lv)
>
> The moved-from value is left in a 'valid' but undefined state, i.e., it can
> be destructed, assigned/moved to, swapped, etc.
>
> The library is non-intrusive and generic, it will perform an efficient move
> in terms of swap for any type providing a member
> swap operation, e.g, std::vector, boost::array, user-defined types etc.

You didn't really expound on the implementation, but, if I had to guess,
you'd also require your types to be default constructible, and it would
perform suboptimally (worse than leaving the move call out) if the swap
member function was equivalent to std::swap. I think this might preclude
its use in generic contexts and limit its use to situations where you
*know* the type is std::vector-like. Let me know if I'm presuming
incorrectly :)

It
> also performs an efficient move for built-in arrays.
> The library is header-only and currently depends only on boost::enable_if
> and boost::swap as external dependencies.
> It is portable between C++03 and C++11 and has a gentle learning curve -
> the code is brief and easy to understand
> (with possible exception of the traits class) - I think that is quite an
> important feature of the library.
>
> It might be feasible to add a few other things, e.g., move, move_backward
> algorithms.
>
> The library is not intended to be standard-compliant (though similar where
> possible), and is not intended to compete with a
> much richer, but 'intrusive' library like Boost.Move.
>
> I've called it 'non-intrusive move' for the moment but it could of course
> be called something else (e.g., simple_move).
>
> Regards,
> Tom
>

- Jeff