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 02:46:59

Jeffrey Lee Hellrung wrote:
> Thomas Klimpel wrote:
> > All that is needed to to wrap its type declaration with the
> >  BOOST_MOVE_ASSIGNMENT_WRAPPER macro.
> [snip]
> 
> Do you find this preferable to simply explicitly defining the
> copyassignment operator in the enclosing class?

The enclosing class might simply want to use the compiler generated copy constructor and copy assignment operator, for maintenance reasons. Another point is the behavior on compilers with rvalue references, as one of the goals of boost.move is to allow to write code that works on compilers with and without rvalue references, without scarifying the performance on new compilers for the compatibility with old compilers.

Apart from that, you are right in that the enclosing class could simply define
TYPE& operator=(TYPE t)
and be freed of all problems, without using the BOOST_MOVE_ASSIGNMENT_WRAPPER macro.

But as we are discussing the question whether classes like boost::container::vector should use the optimized move emulation, the exact impact on the enclosing class is quite important.

> > However, my position on breaking move-assignment
> > from temporaries for the non-optimized mode remains
> > that this is not a reasonable option, especially considering
> > that it would be a serious regression with respect
> > to the Adobe Move Library.
> 
> Is this a position based on technical semantics, rather than practical
> semantics?  Because I believe even the non-optimized emulation should
> effectively move-assign from temporaries via RVO...

If it were not practical semantics, it wouldn't be a serious regression. The practical problem is the following: If the "move enabled" class defines "TYPE& operator=(const TYPE& t)", then the "TYPE& operator=(BOOST_RV_REF(&) t)" overload won't kick in for move assignment from temporaries on C++03 compilers, as "TYPE& operator=(const TYPE& t)" is a better match. It also cannot define a "TYPE& operator=(TYPE t)" overload in addition to "TYPE& operator=(const TYPE& t)" (this would be ambiguous), so RVO can also no longer kick in.

The alternative is to just define "TYPE& operator=(TYPE t)", but Ion doesn't like this for classes like boost::container::vector, as this copy assignment operator cannot reuse existing resources. So his proposed non-optimized mode sacrificed move-assign from temporaries on C++03 compilers, to avoid non-optimal code on new compilers in C++0x mode.

Regards,
Thomas