Re: [boost] [Review] Formal Review: Boost.Move - purpose + move enabling macros

Subject: Re: [boost] [Review] Formal Review: Boost.Move - purpose + move enabling macros
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2010-05-18 07:56:28

Hi,

Sorry for the late reply, I've been on a trip

On 15/05/2010 8:37, Jeffrey Lee Hellrung, Jr. wrote:
>> Ok, perfect, so what do you think that protocol should look like? Just
>> trying to get which requirements would be essential for different
>> reviewers and try to merge them.
>
> It seems, to me, like the requirements for a type T to be move
> constructable are:
>
> - T is implicitly convertible to rv<T>& (this is a non-const conversion,
> and the rv<T>& references the same object as the "from" object)
> - T has a constructor which can accept a rv<T>&; this constructor is the
> move constructor, which has move semantics.

According to the latest draft MoveConstructible is defined as:

Table 34 — MoveConstructible requirements [moveconstructible]

//u is equivalent to the value of rv before the construction
T u(rv);
//T(rv) is equivalent to the value of rv before the construction
T(rv)
[ Note: rv remains a valid object. Its state is unspecified—end note ]

This means that an object with a copy constructor is move constructible 
in C++0x. In C++03 that would mean constructible from rv<T> &, from 
const rv<T> & (for optimized emulation), from an lvalue of T or from a 
const rvalue of T.

> Refining move constructable would be the concept of move assignable:
>
> - T has an assignment operator accepting a rv<T>&; this assignment
> operator is the move assignment operator, which has move semantics.
  Some additional requirements that I'm not sure how to categorize, but
> may be desirable, are:
>
> - T has an assignment operator that moves from rvalues (assuming RVO;
> thus, this could be T::operator=(T) or T::operator=(rv<T>&)).

Refining my first comment, MoveAssignable in C++03 would require 
assignable from [const] rv<T> &, from an lvalue of T or from a const 
rvalue of T.

> - const T is explicitly convertible to rv<T> const& (*).

I would definitely add this. We know this has some nasty consequence on 
compiler-generated assignments, but I think the advantages outweigh the 
disadvantages.

>
> Requirement (*) allows one to overload functions to capture rvalues of
> type T:[...]However, this prevents one from passing an object implicitly convertible
> to T, so I think a better recommendation for such overloading is
> something like
>
> template< class U >
> typename enable_if< is_convertible< U&, const T& > >::type
> f(U& x) { ...copy static_cast< const T& >(x)... }
> [...]

Right. Thanks.

> The emulation is very good, and I think its shortcomings are impossible
> to rectify in C++03. One thing that Boost.Move cannot do, and which I
> think is impossible in C++03, is capture rvalues as templated (emulated)
> rvalue references: template< class T > void f(rv<T>& x) will only
> capture explicitly created rvalue references. This makes forwarding more
> complicated and more restrictive. I can't think of any other "hard"
> restrictions on Boost.Move, though, i.e., things you can do in C++0x
> with rvalue references that you can't do with Boost.Move with sufficient
> machinery. Can you think of anything else?

Yes, this is a limitation that is not that bad for placements 
insertions, because most constructors will take const parameters or 
rvalue references, but an important limitation anyway. And according to 
the new rvalue reference rules, Boost.Move is unsafer, because rv<T> & 
can be assigned to T&. We'll find more limitations as we write more and 
more  rvalue references based code. But the emulation is quite good, 
IMHO ( unbiased view, of course ;-) )

> Perhaps we should consider a survey of past and present move emulation
> strategies to see how this one stacks up against it. This might also be
> prudent to include in the documentation. I know that Adobe has a move
> library that I studied some time ago; do you know of any others?

We had the old Boost.Move approach, which was based on a rv class that 
stored T and was convertible to T. Boost.Variant uses this in an 
internal file:

www.boost.org/boost/variant/detail/move.hpp

Best,

Ion