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

[Richard Smith]

On Thu, May 16, 2013 at 9:55 AM, David Blaikie <dblaikie at gmail.com> wrote:

>
>
>
> 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)
>

You can still name it in a friend declaration. And it seemed weirder for
"blah = delete;" to not declare 'blah' at all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130516/9d72f83b/attachment.html>