[cfe-dev] Move constructor forces copy assignment to be implicitly defaulted?

Howard Hinnant hhinnant at apple.com
Sat May 26 09:17:09 PDT 2012

On May 26, 2012, at 6:07 AM, Suman Kar wrote:

> Howard,
> 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.

> <off-topic>
> 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.)
> </off-topic>

I'm purposefully ignorant of all gcc past 4.2.


More information about the cfe-dev mailing list