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:24:53

On Jan 4, 2009, at 6:18 PM, Howard Hinnant wrote:

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

* Oh, one more thought:  Templatized tests (one for move-only and one  
for movable/copyable) such that clients could instantiate the test  
with their own move-enabled type to ensure that they've done it right  
(covered all the bases) would be cool.  Double-cool if they could run  
it without knowing anything about the boost testing harness (or even  
having to build boost).  Though it would need to include both passing  
and compile-time failing tests (complicating the ability to make it  
simple and portable).

-Howard