Boost logo

Boost :

Subject: Re: [boost] [move] Unifying move emulation code in boost
From: Howard Hinnant (hinnant_at_[hidden])
Date: 2009-01-04 18:18:29

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

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


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