r263732 - Remove defaulted move ops, the type is zero-cost copyable anyway, so there's no need for specific move ops

don hinton via cfe-commits cfe-commits at lists.llvm.org
Thu Mar 17 14:55:08 PDT 2016


btw, in each case, the derived class's move ctor was called.

On Thu, Mar 17, 2016 at 5:36 PM, don hinton <hintonda at gmail.com> wrote:

> I just did some tests, and when a derived class is explicitly moved, e.g.,
> with std::move(), the current behavior is (clang++/g++/vc++):
>
> 1) if base has implicit move, it gets called
> 2) if base doesn't have an implicit move (because a copy ctor was define,
> etc) copy ctor is called
> 3) if base class move was explicitly deleted, compile time error
>
> I was surprised by #2.
>
> On Thu, Mar 17, 2016 at 4:51 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
>>
>>
>> On Thu, Mar 17, 2016 at 1:41 PM, don hinton <hintonda at gmail.com> wrote:
>>
>>> Dave:
>>>
>>> Won't this prevent UnresolvedSet from being movable?
>>>
>>> I was under the impression that all subobjects (base class in this case)
>>> had to be movable in order for the compiler to generate implicit move ops.
>>> Is that not the case?
>>>
>>
>> Yeah, I think you're right (I thought the language had been fixed/changed
>> here, so that a type with a copyable-but-not-movable member, and a movable
>> (but possibly non-copyable member) could still be moved, and just move the
>> moveable parts and copy the non-movable parts - but I can't see any
>> evidence of that). Added explicit (empty) move ops in r263747
>>
>>
>>>
>>> thanks...
>>> don
>>>
>>> On Thu, Mar 17, 2016 at 2:28 PM, David Blaikie via cfe-commits <
>>> cfe-commits at lists.llvm.org> wrote:
>>>
>>>> Author: dblaikie
>>>> Date: Thu Mar 17 13:28:16 2016
>>>> New Revision: 263732
>>>>
>>>> URL: http://llvm.org/viewvc/llvm-project?rev=263732&view=rev
>>>> Log:
>>>> Remove defaulted move ops, the type is zero-cost copyable anyway, so
>>>> there's no need for specific move ops
>>>>
>>>> (addresses MSVC build error, since MSVC 2013 can't generate default move
>>>> ops)
>>>>
>>>> Modified:
>>>>     cfe/trunk/include/clang/AST/UnresolvedSet.h
>>>>
>>>> Modified: cfe/trunk/include/clang/AST/UnresolvedSet.h
>>>> URL:
>>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/UnresolvedSet.h?rev=263732&r1=263731&r2=263732&view=diff
>>>>
>>>> ==============================================================================
>>>> --- cfe/trunk/include/clang/AST/UnresolvedSet.h (original)
>>>> +++ cfe/trunk/include/clang/AST/UnresolvedSet.h Thu Mar 17 13:28:16 2016
>>>> @@ -61,9 +61,7 @@ private:
>>>>    template <unsigned N> friend class UnresolvedSet;
>>>>    UnresolvedSetImpl() = default;
>>>>    UnresolvedSetImpl(const UnresolvedSetImpl &) = default;
>>>> -  UnresolvedSetImpl(UnresolvedSetImpl &&) = default;
>>>>    UnresolvedSetImpl &operator=(const UnresolvedSetImpl &) = default;
>>>> -  UnresolvedSetImpl &operator=(UnresolvedSetImpl &&) = default;
>>>>
>>>>  public:
>>>>    // We don't currently support assignment through this iterator, so
>>>> we might
>>>>
>>>>
>>>> _______________________________________________
>>>> cfe-commits mailing list
>>>> cfe-commits at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160317/e234c1b9/attachment.html>


More information about the cfe-commits mailing list