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

Subject: Re: [boost] [move] Reason for BOOST_COPY_ASSIGN_REF?
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-04-21 00:50:39

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/20/2010 11:56 PM, Jeffrey Hellrung 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?

(Sorry, I meant to write operator=, not copy-constructor, there.)

> 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.

I'm obviously missing some key concept, because very little of that
parses. I don't know of any efficient way to determine what that concept
might be, so here are some possibly-nonsensical questions to try to
scare it into view:

- - How is the "copy assignment operator" different from the normal
operator=(const T&)?

- - *Why* does it expand to const T& if if BOOST_HAS_RVALUE_REFS and const
rv<T>& otherwise? rv<T> is an rvalue representation, if I understand
correctly, and that isn't equivalent to const T&, is it?

- - What undesirable thing(s) would happen if you ignored
BOOST_COPY_ASSIGN_REF and simply created a normal operator=(const T&)?

>> 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>&.

Let me rephrase the question. The current Boost.Move library has been
discussed on this list since at least January of 2009, and it's still
not approved. So how can I adopt anything regarding boost::rv if the
library that defines boost::rv might still not be available if/when my
library is ready for inclusion into a Boost release? Would I have to
bundle move.hpp with XInt in that case? Or yank out the move stuff
completely?
- -- 
Chad Nelson
Oak Circle Software, Inc.
*
*
*
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvOhBwACgkQp9x9jeZ9/wRbqQCg5cIqPohTlv0h0T5VuPR1jxJ+
iQoAn3FhlwZOW411Zci9Y1rlzwfhyId4
=tj0y
-----END PGP SIGNATURE-----