Re: [boost] [Review] Formal Review: Boost.Move - purpose + move enabling macros

Subject: Re: [boost] [Review] Formal Review: Boost.Move - purpose + move enabling macros
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2010-05-12 05:43:00

On Tue, May 11, 2010 at 12:48 AM, Jeffrey Lee Hellrung, Jr.
<jhellrung_at_[hidden]> wrote:
> 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.

I had similar thoughts pass through my mind, I look forward to if you
have a design style in your mind for later.

On Tue, May 11, 2010 at 12:48 AM, Jeffrey Lee Hellrung, Jr.
<jhellrung_at_[hidden]> wrote:
> 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.

Very good point, perhaps having both macros would provide the best
power, any thoughts anyone else?

On Tue, May 11, 2010 at 12:48 AM, Jeffrey Lee Hellrung, Jr.
<jhellrung_at_[hidden]> wrote:
> Hopefully this will be something to at least get discussion started.

A little slow due to BoostCon no doubt, but there are plenty of us
that are still stuck away, so please, anyone around, do test and give
input about the interface, use, efficiency, etc...