Re: [boost] [move] Unifying move emulation code in boost

Subject: Re: [boost] [move] Unifying move emulation code in boost
From: Howard Hinnant (hinnant_at_[hidden])
Date: 2009-01-04 18:18:29

On Jan 4, 2009, at 4:54 PM, Ion Gaztañaga wrote:

> 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. 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.
>
> 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) but I'm afraid entropy has  
> already grown too much ;-) and we can't continue waiting while we  
> add more and more emulation code to Boost.

I think a consolidated move library is a very good idea.  Thanks for  
working on it Ion.  Some minor comments:

* I think we need a move(t) for "non-movable" t (like int, int*,  
etc.).  Otherwise generic code can't move things.

* I've grown to dislike my "friend move" setup and like your namespace  
scope emulated move better.  But that does unfortunately expose rv at  
el.  What about putting rv (and company) in some sort of "don't touch"  
namespace?  Naturally the authors wanting to make their classes  
moveable will have to touch these types.  The hope is that clients of  
A won't be tempted to touch rv<A>.  Another solution might be  
accomplished with making more of rv private and friending rv<T> to T  
(I haven't tried this yet).  The concern is twofold:

1.  What is the interface of the move library to the author of the  
movable type?
2.  What is the interface of the move library to the client of the  
movable type?

My hope is that interface-1 will be as small as possible and that  
interface-2 will be much smaller than interface-1, and preferably  
compiler-enforced.

* On the one hand I have a strong personal distaste for macros like  
BOOST_ENABLE_MOVE_EMULATION.  On the other hand, I guess the author of  
the movable type is free to not use them (expand them manually) if  
desired.  So consider this more of stylistic comment than a technical  
one. :-)  Perhaps documentation could mention/demonstrate manual  
expansion for those of us with severe macro allergies. :-)

* I think we need some kind of forward emulation, and I'm afraid that  
no matter what, it is not going to be very good. :-(  It should  
probably strive to be perfect for BOOST_HAS_RVALUE_REFS, and with no  
code changes moderately acceptable without BOOST_HAS_RVALUE_REFS.

* This library should address both move-only types and movable- 
copyable types (probably in documentation only).  I've been using  
Dave's enable_if_same design for the latter.  I haven't looked at  
other designs though.

-Howard