[cfe-dev] Move constructor forces copy assignment to be implicitly defaulted?
hhinnant at apple.com
Tue May 29 12:18:15 PDT 2012
On May 29, 2012, at 12:35 PM, Suman Kar wrote:
> Let me summarize my understanding (along with what you've already
> written) w.r.t move members:
>  While both copy and move members can be implicitly
> defaulted/deleted only move members can be suppressed.
>  A move member can never be implicitly defined to be deleted
> because of the presence of a copy member or a destructor.
Sounds right to me.
> Finally, there's this bit about 12.8/9 that I need help with:
> When the move constructor is not implicitly declared or explicitly
> supplied, expressions that otherwise would have invoked the move
> constructor may instead invoke a copy constructor.
> This, I believe, keeps the compiler happy about compiling the example
> I posted?
> Also, is
> 'When the move constructor is not implicitly declared or explicitly
> standardese for suppressed/inhibited/deprecated?
Yes for suppressed/inhibited. Deprecated means something different. When something in the standard is deprecated, it means that it might be removed in a future version of the standard.
> Is it correct to consider the case where move members are deprecated
> as C++98/03 fallback mode?
It is correct to consider the case where move members are suppressed/inhibited/absent as just like you would write in C++98/03.
More information about the cfe-dev