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