Could someone explain why the second one is move-constructible and move-assignable while the first one is not?<div><br></div><div>How does explicitly defaulting the move-constructor and move-assignment cause A to *not* be move-constructible nor move-assignable, while omitting them makes A be move-constructible and move-assignable?<div>
<br></div><div>--Sean Silva<br><br><div class="gmail_quote">On Wed, Mar 28, 2012 at 2:28 PM, Howard Hinnant <span dir="ltr"><<a href="mailto:hhinnant@apple.com">hhinnant@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Mar 28, 2012, at 2:14 PM, David Blaikie wrote:<br>
<br>
> On Wed, Mar 28, 2012 at 11:08 AM, Howard Hinnant <<a href="mailto:hhinnant@apple.com">hhinnant@apple.com</a>> wrote:<br>
>> In a few instances the implicit definition of a defaulted copy constructor and copy assignment operator is deprecated in C++11.  E.g.:<br>
>><br>
>> struct A<br>
>> {<br>
>>  // A(const A&) = default;  // deprecated<br>
>><br>
>>  // A& operator=(const A&) = default;  // deprecated<br>
>><br>
>>  ~A();<br>
>> };<br>
>><br>
>> Should we warn when both -std=c++11 and -Wdeprecated is given?<br>
><br>
> I believe we should, yes - just that no one's gotten around to<br>
> implementing this (it's been somewhere on my mental list).<br>
><br>
> Aside: It'd be rather nice if these rules actually implemented the<br>
> classic "rule of three" (if you implement any of the three you should<br>
> implement all three - or 5 in C++11) but I don't think the standard<br>
> wording goes quite that far.<br>
<br>
</div>It comes pretty close to the rule of 3:<br>
<br>
The implicitly default copy constructor is deprecated if there is a user-declared copy assignment or destructor.<br>
<br>
The implicitly default copy assignment is deprecated if there is a user-declared copy constructor or destructor.<br>
<br>
One needs to be more careful with defaulting the move members.  It is easy to default them and have them get implicitly deleted:<br>
<br>
struct member<br>
{<br>
    member();<br>
    member(const member&);<br>
    member& operator=(const member&);<br>
    ~member();<br>
};<br>
<br>
struct A<br>
{<br>
    member m_;<br>
<br>
    A() = default;<br>
    A(const A&) = default;<br>
<div class="im">    A& operator=(const A&) = default;<br>
</div>    A(A&&) = default;<br>
    A& operator=(A&&) = default;<br>
    ~A() = default;<br>
};<br>
<br>
A is neither move constructible nor move assignable.  The following is probably what was intended:<br>
<br>
struct A<br>
{<br>
    member m_;<br>
<br>
    A() = default;<br>
    A(const A&) = default;<br>
<div class="im">    A& operator=(const A&) = default;<br>
</div>    ~A() = default;<br>
};<br>
<br>
which, ironically, *is* move constructible and move assignable. :-)  But I'm not suggesting a warning for this.<br>
<div class="HOEnZb"><div class="h5"><br>
Howard<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div></div>