[cfe-dev] Move constructor forces copy assignment to be implicitly defaulted?
hhinnant at apple.com
Sat May 26 09:17:09 PDT 2012
On May 26, 2012, at 6:07 AM, Suman Kar wrote:
> Thanks a ton for taking the time to explain this. I need to update my
> references asap!
>> On Fri, May 25, 2012 at 7:45 PM, Howard Hinnant <hhinnant at apple.com> wrote:
>> In summary, if you declare either copy member or the destructor,
>> implicit move members are inhibited.
> I am assuming that by inhibited you mean something other than deleted.
Right. I mean that they don't exist, just as in C++98/03. Deleted move members are generally problematic as they inhibit "copying" from rvalues. If you have valid copy members and deleted move members, you can't return such an object from a function.
>> If you declare either move
>> member, the copy members are implicitly deleted unless you
>> declare them otherwise.
> This makes sense. It looks like this is as a direct result of core
> issue #667 and is tracked by most compiler vendors as N3053: Defining
> move special member functions. However, I wasn't able to trace a
> particular document that could provide me with a rationale on this
> shunning of the copy assignment operator. This is perhaps asking for
> too much and not relevant to this group, but if you could point me in
> the right direction I'd be much obliged.
My eyes were glazing over during this phase of standardization. But you might take a look at N3201.
> Should I consider this a bug in gcc 4.6? (Status of N3053 is marked as
> complete in http://gcc.gnu.org/gcc-4.6/cxx0x_status.html. Also, I
> wasn't able to find a relevant bug file against gcc 4.6 on bugzilla.)
I'm purposefully ignorant of all gcc past 4.2.
More information about the cfe-dev