Boost logo

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk