Subject: Re: [boost] [Review] Formal Review: Boost.Move - purpose + move enabling macros
From: Jeffrey Lee Hellrung, Jr. (jhellrung_at_[hidden])
Date: 2010-05-11 02:48:00
On 5/6/2010 8:36 PM, OvermindDL1 wrote:
> Greetings Boost Developers and Users,
> It's my pleasure to announce that the review of Ion GaztaÃ±agas' Move
> library starts May 10th and lasts until May 24th, 2010, unless an
> extension occurs.
First, again, I want to thank you, Ion, for putting this library
together and listening to all the comments up to this point. The
documentation is very well done, as it always has been.
Also, thank you OvermindDL1 for volunteering as review manager.
Second, I have to admit that I do have some reservations with this
incantation of the library. I will be trying to post multiple comments
over the next couple days, as I think of things and get around to
expressing my ideas.
In my opinion, *the* primary goal of this library is to provide a
standardized convention by which data structures and algorithms within
and outside of boost can make use of move semantics in c++03 (there is
already such a convention in c++0x). All the macros, moving and
forwarding functions, move iterators, etc., are, I believe, secondary to
introducing boost::rv<T>& and what that little class is suppose to
represent and how T should interoperate with it. What I would like to
see are a set of requirements for a type to be MovableCopyable, or
MovableNoncopyable. I'd imagine this would essentially consist of a
conversion operator to boost::rv<T>&, constructor accepting a
boost::rv<T>&, an assignment operator accepting a boost::rv<T>&, and the
semantics associated with these member functions. This means, for
example, that, as an author of some class, I am not restricted to using
the macros provided by this library to enable move emulation, or the
forwarding functions this library provides, or whatever else, if they
don't meet my requirements. For example, one may want to only
conditionally enable move emulation, depending on whether its member
objects are movable or not. Why might one not want to enable move
emulation? If you enable optimal emulation, you wind up with a class
that doesn't play well with enclosing classes that don't explicitly
define an assignment operator. Minimizing the proliferation of such
classes could be a good idea. Also, if you're just gonna define copy
assignment in terms of a copy-and-move or a copy-and-swap, there's no
point in using optimal move emulation, since your copy assignment
operator may as well accept by value anyway. I'm hoping these
considerations might convince you that there is no "one size fits all"
macro to enable move emulation. I believe an itemization of the
nitty-gritty requirements that a class must satisfy to be move-aware
will encourage alternative, more targeted methods to enable move
emulation while remaining inter-compatible with each other.
Regarding the macro BOOST_MOVE_OPTIMIZED_EMULATION: I think this is a
bad idea, but perhaps I'm missing something. It seems like as soon as
you mix in some move-enabled class into your code that *must* use the
non-optimal move emulation (either by design, or through its interaction
with other enclosing classes that fail to explicitly define a copy
assignment operator), *all* your move-enabled classes will have to use
the "safe" (i.e., non-optimal) move emulation. The only serious use
case I see is when BOOST_MOVE_OPTIMIZED_EMULATION is always left
undefined. Am I missing something? If not, then I think we should
either 1) offer *only* the "safe" option, for simplicity; or 2) offer
both options as separate move emulation enabling macros.
Hopefully this will be something to at least get discussion started.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk