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

Subject: Re: [boost] [move] Unifying move emulation code in boost
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2009-01-05 04:53:44

Howard Hinnant wrote:
> On Jan 4, 2009, at 4:54 PM, Ion Gaztañaga wrote:
> I think a consolidated move library is a very good idea.  Thanks for 
> working on it Ion.

I spoke too fast! a) The header has no move guards b) emulation is not 
working properly when trying to port some Interprocess classes to the 
new emulation.

Although I add the conversion operator (either manually or by macro) 
functions returning by value don't work sometimes and the private copy 
constructor is selected by the compiler (Visual 7.1). I know little 
about conversion operators but the difference between the old move 
emulation and the new one is that there is no need for a move_return<> 
type that holds movable-only types. Should the emulation work in these 
cases?

MovableOnly factory();

int main()
{
   MovableOnly m1(factory());
   MovableOnly m2(MovableOnly(arg));
   return 0;
}

Maybe I'm doing something wrong but I just gave up after several tries 
to fix this ;-)

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

Ok.

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

Seems the way to go. The header was just a fast prototype to see if that 
header elements were enough for all.

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

Ok.

> * 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. :-)

Yes, I added macros at the last minute because I saw I had a lot of 
similar code around but they are perfectly replaced with manual expansion.

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

Ok.

Regards,

Ion