Re: auto-generated move assignment and base or member with a
by-value assignment
Am 17.02.2014 10:49, schrieb Krzysztof Czai??ski:
W dniu poniedzia??ek, 17 lutego 2014 07:10:52 UTC+1 u??ytkownik Daniel
Kr??gler napisa??:
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?
[...]
This means, that based on C++11 rules class B does neither
implicitly declare a defaulted move-assignment operator nor a
move-constructor
But this is not the end of it. In fact, especially the
"non-trivial" exclusion rule had lead to the following core issue
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1402
and as result of accepting this issue as language defect, the
following behaviour changes happened:
Class A still does not implicitly declare a move-assignment
operator, but class B does and this move-assignment operator will
invoke the best matching A constructor (which is now the move
constructor) to construct an A object, followed by the call of the
selected copy-assignment operator of A. This explains why all newer
compiler output "move" instead of "copy".
I'm glad things are going this way - for me the above is expected
behavior.
But:
struct A
{
A& operator=( A ) { return *this; }
};
The point here is to implement the assignment in terms of a call to
an appropriate constructor (copy-, move-, or any other constructor),
and then swapping or moving the result into *this. Wouldn't it be
better to treat it as a universal-assignment, instead of just
copy-assignment?
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
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]