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