Re: Copy-assignment and C++0x move-assignment operator ambiguous?
On Sep 13, 4:29 pm, "Niels Dekker - no return address"
<unkn...@this.is.invalid> wrote:
When implementing the assignment operator of a class by copy-and-swap,
it's often preferable to have its argument passed "by value", instead of
by const-reference. As was discussed here, "Re: Is self assignment test
valid?",http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/...
Now when such a class is "upgraded" to C++0x, would it be okay to just
add a move-assignment, without having to change the original
copy-assignment operator? For example:
////////////////////////////////////////////////////////////
class foo {
public:
foo & operator=(foo); // Argument passed "by value".
foo & operator=(foo &&); // C++0x rvalue reference.
};
int main() {
foo obj;
obj = foo(); // Okay?
return 0;
}
////////////////////////////////////////////////////////////
So far, I've only tried GCC 4.3.0 (ConceptGCC - BoostCon Edition), which
says (unfortunately):
error: ambiguous overload for 'operator=' in 'obj = foo(0u)'
note: candidates are: foo& foo::operator=(foo)
note: foo& foo::operator=(foo&&)
While I would have appreciated the compiler to select the
move-assignment operator in this case.
I'm especially interested because I've just submitted a few tickets tohttp://svn.boost.org, requesting a by-value argument for the
copy-assignment operator of various Boost types, as was suggested by
David Abrahams.
Yes, these two signatures are ambiguous. But it really is ok that
they are. If you wanted to treat lvalues and rvalues in different
ways you could:
foo&
foo::operator=(const foo& f)
{
foo tmp(f);
swap(tmp, *this);
return *this;
}
foo&
foo::operator=(foo&& f)
{
swap(f, *this);
return *this;
}
But with the by-value version:
foo&
foo::operator=(foo f)
{
swap(f, *this);
return *this;
}
you effectively achieve the same thing as the two-overload-reference
version. If an lvalue binds to f, it is copied in, and then you swap
with the copy. If an rvalue binds, the copy is typically
(universally?) elided, and you swap with the rvalue. Thus if you use
the by-value version, you don't have motivation to overload it with an
rvalue-ref version. There is no efficiency gain.
Disclaimer for others: Not every class benefits from this style of
assignment operator. For example this would be a poor design for
std::vector assignment. The reason is that the lhs of a vector
assignment can often make use of existing resources (capacity) during
the assignment from the rhs. If vector assignment were implemented
with pass-by-value-and-swap, it would /always/ trigger a heap event
(either allocation and/or deallocation). If vector assignment
attempts to take advantage of existing capacity, then some vector
assignments will not trigger a heap event (if there is sufficient
capacity - resources - in the lhs to handle the rhs value). One of
the most expensive things you can do on a modern computer is allocate/
deallocate memory.
-Howard
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]