Re: [boost] [move] Reason for BOOST_COPY_ASSIGN_REF?

Subject: Re: [boost] [move] Reason for BOOST_COPY_ASSIGN_REF?
From: Jeffrey Hellrung (jhellrung_at_[hidden])
Date: 2010-04-20 23:56:23

Chad Nelson wrote:
> I've been studying Boost.Move, with an eye toward using it to
> incorporate move semantics into the XInt library. Most of it looks
> pretty straightforward, but I don't understand the reason for the
> BOOST_COPY_ASSIGN_REF macro. If you already have a copy-constructor that
> takes a reference, what does it give you?

That's why it's called BOOST_COPY_*ASSIGN*_REF.  You use it to define 
the copy assignment operator.  It expands to const T& if 
BOOST_HAS_RVALUE_REFS, and const rv<T>& otherwise.  Boost.Move, in the 
absence of true rvalue references, depends on copy elision to 
efficiently construct from rvalues (and reasonably so), so there's no 
need to do anything special with the copy/move constructor combination.

> Also, how close is it to being official? I'd like to use it, but if it's
> not going to be accepted any time soon, I can't justify it.

I can't answer the "how close", but you can still use it in the sense 
that you can adopt its conventions regarding boost::rv, and (if you 
choose) ignore the rest of the library.  These conventions are:
- boost::rv<T>& emulates an rvalue reference (and hence may be safely 
moved from); and
- a move-enabled class T provides a non-const conversion operator to 
boost::rv<T>& and a const conversion operator to const boost::rv<T>&.

- Jeff