Re: auto-generated move assignment and base or member with a
by-value assignment
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' ;-)
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.
[...]
I'm not sure that I understand your proposal, because - as explained
above - copy/move assignment operators will anyway be selected by
overload resolution, so just adding this operator alone is fine. The
only problem was that this user-declared operator had negative effects
on "container classes" of A before CWG 1402 was accepted as
defect. But post-1402 C++ does not have this disadvantage.
HTH & Greetings from Bremen,
Daniel Kr??gler
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.
Thanks for the explanation, and sorry for delaying my response
Regards
Kris
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]