Boost logo

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at