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