Re: auto-generated move assignment and base or member with a
by-value assignment
Am 24.02.2014 15:23, schrieb Krzysztof Czai??ski:
On Monday, February 17, 2014 9:35:29 PM UTC+1, Daniel Kr??gler wrote:
Krzysztof Czainski:
So the standard treats A's assignment operator taking A by value as
copy-assignment.
Yes, this needs to be the case, because a operator= overload of the form
T& T::operator=(T)
was already a copy-assignment operator in previous versions of C++.
I think that's a shame. It works equally well as copy-assignment,
move-assignment or any other assignment from a type convertible to
A. That's the point of taking by value here.
Could you explain what the particular problem is caused by this? If
you declare such an operator=, if will anyway be selected according to
overload resolution rules, so what harm does it do to A, if there is
no additional move-assignment operator?
Or are your concerns related to the effects on B given the C++11 rules
modulo the applied fix by CWG 1402?
Well the applied fix by CWG 1402 does fix my problem. (I'm not sure
what you mean by 'modulo the applied fix by CWG 1402' ;-)
I was not sure whether you complained about the state even after
applying CWG 1402 to C++11 or whether your complaints were still about
the pre-fix wording.
It's just that when I write:
T& T::operator=(T)
I intend it to be a universal assignment operator. Typically:
T() = default;
T( T const& ) = default;
T( T&& ) = default;
T& T::operator=( T x ) { swap(*this,x); return *this; }
Here, I see T& T::operator=( T ) as a replacement for:
T& T::operator=( T const& )
T& T::operator=( T&& )
Notice, that the following sets of overloads are ambiguous:
T& T::operator=( T )
T& T::operator=( T&& )
or
T& T::operator=( T const& )
T& T::operator=( T )
Therefore I believe
T& T::operator=( T )
is both the copy and move assignment operator.
Sure, it is possible to consider it conceptually this way, but
technically it is a copy assignment operator (as it had been in C++03)
and this difference becomes obvious, if you consider the effects on
"container" types - that is types, that either contain T as non-static
data member or as a direct base class: Because T& T::operator=(T)
declares a copy-assignment operator, the corresponding "container" type
will (implicitly) always declare a copy-assignment operator as well.
But like I mentioned above, the applied fix by CWG 1402 does fix my
problem, and I don't see any other problematic examples this could cause.
But then, calling:
T& T::operator=( T )
"copy assignment" is misleading to me, because it seems no more a copy
assignment than a move assignment.
I would argue that describing this function as copy assignment character
of T makes sense, because you can apply an lvalue of T as argument, but
for any move-assignment operator this would not be possible. And if the
argument is an lvalue, this function will never modify it, so it truly
is non-mutating for lvalues. But I understand the point that you are
trying to make: For non-constant rvalues this function behaves
potentially mutating and has therefore some aspects of a typical move
operation.
HTH & Greetings from Bremen,
- Daniel Kr??gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]