[cfe-dev] A question about when a defaulted move assignment operator is deleted

[David Blaikie]

On Wed, May 15, 2013 at 9:03 PM, Richard Smith <richard at metafoo.co.uk>wrote:

> This is not a forum for learning about C++; stackoverflow.com would be a
> better place to ask such questions.
>
> On Wed, May 15, 2013 at 8:42 PM, ZhangXiongpang <zhangxiongpang at gmail.com>wrote:
>
>> Platform: linux, x86_84, clang++3.3 (trunk 178517), g++4.7.2
>>
>> I'm learning C++11 standard, and often write some code to test clang++.
>> But sometimes I'm not sure whether my understanding is right when clang++
>> does not work as my expecting.
>>
>> 12.8/p23 in N3290:
>> --------------------------------------------------------
>> A defaulted copy/move assignment operator for class X is defined as
>> deleted
>> if X has:
>>   ...
>>   -- for the move assignment operator, a non-static data member or direct
>> base class with a type that does
>>      not have a move assignment operator and is not trivially copyable, or
>> any direct or indirect virtual
>>      base class.
>> --------------------------------------------------------
>> Does it partially mean that the defaulted move assignment operator for
>> class
>> X is defined as deleted if X has any direct or indirect virtual base
>> class?
>>
>
> In the latest draft of the standard, that bullet has been removed. (Since
> virtual bases can be assigned multiple times by defaulted assignment
> operators, this means that the compiler might generate a broken move
> assignment operator for classes which inherit from the same virtual base
> through multiple inheritance paths. I argued against this, but the
> committee seemed to prefer the simpler rule.)
>
> We also have this (which doesn't help in your example, but is relevant in
> general):
>
> "A defaulted move assignment operator that is defined as deleted is
> ignored by overload resolution (13.3, 13.4)."
>

OK, that's weird. How is that different to having it not provided at all?
(& it seems really unfortunate that deleted definitions do anything other
than cause compilation errors - affecting overload resolution, etc, adds
some substantial wrinkles to the model)


>
> Clang doesn't implement this correctly in all cases yet, though.
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130516/0bb2157b/attachment.html>