Re: [boost] [Review] Formal Review: Boost.Move

Subject: Re: [boost] [Review] Formal Review: Boost.Move
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2010-05-31 07:55:29

Jeffrey Lee Hellrung wrote:
> Ah, okay, I was thinking of the distinction between the 2
> move emulation modes described in the proposed Boost.Move
> documentation, neither of which use a copy assignment
> operator with signature operator=(const T&).

The description of the non-optimized mode in
<http://igaztanaga.drivehq.com/libs/move/doc/html/move/two_emulation_modes.html>
says "Users can use the usual copy-assignment or the compiler-generated one". This is exactly the copy assignment operator with signature "T& operator=(const T&)". The text goes on to explicitly say "But this emulation mode does not optimize the non-const rvalue move assignment example". This is what I mean by "breaking move-assignment from temporaries for the non-optimized mode".

> By "exact impact", you mean the "recommended resolution" to define,
> implicitly or explicitly, a standard copy assignment operator in the
> enclosing class...?

No, I mean the problems that will impact the enclosing class in profound ways. As long as there are reasonable solutions to these problems (having more than just one solution won't hurt), everything should be fine.
 

> If I understand correctly, optimal move emulation for
> boost::container::vector is the best choice if we ignore the effect on
> (future) enclosing classes.  Are you/we necessarily against just going
> with this, documenting the fact that enclosing classes will have to
> deal with the non-standard compiler-generated copy assignment operator
> (either by defining it explicitly, perhaps conditionally; or wrapping
> member vars in a wrapper, also perhaps conditionally)?  

I'm not necessarily against it. But I would like to hear Ion's opinion on this.

> We don't have any backwards compatibility concerns,
> since boost::container::vector is
> not actually released yet, right?

Yes and no. If I understand it correctly, boost::container::vector will be the successor of
boost::interprocess::vector (= boost::interprocess_container::vector). And these interprocess containers are meant as replacements for stl containers with extended allocator support, as required for boost.interprocess. Changing the behavior of the copy assignment operator might make them less suitable as replacements for stl containers.

Requiring wrapping members into a macro or applying some other "purely syntactic changes" should be OK on the other hand.

Regards,
Thomas