Re: How to determine when a C++11 move is synthesized?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7 January 2016 at 00:12, Jeffrey Walton wrote:
>> P.S. That example perfectly demonstrates why you should leave the
>> compiler to do its job.
>>
>> That move constructor is useless because you've declared the parameter
>> type as const, and even if you fixed that is probably imperfect
>> because you didn't declare it noexcept. The compiler would not make
>> either of those mistakes.
>
> OK, thanks. I was not aware a move had to be noexcept.

It doesn't have to be, but it should be whenever possible. Moves
should be lightweight, if you have to do something that can throw
(such as allocating memory) then it's an unusual move.

See https://vimeo.com/97337253 for a situation where it's important.


>>>> We have a lot of classes (1500 or so), and its going to take some time
>>>> to evaluate all of them. As a starting point, we would like to
>>>> identify where the compiler is synthesizing a move and then provide it
>>>> (especially for some fundamental/critical base classes).
>>
>> It occurs to me that I might have misunderstood what you mean by
>> "synthesizing a move". I interpreted it to mean you're trying to find
>> out where implicitly-defined move constructors are used, which is
>> pointless, as those are the cases where the right thing is already
>> happening.
>>
>> Are you actually asking where rvalues are copied instead of moved?
>> Those are the places where providing a move constructor would be
>> useful, because it would turn a copy into a move, and so those are the
>> places you should be interested in. But I don't see how that could be
>> described as "synthesizing a move".
>
> It basically originates form two things. First, we are having trouble
> with GCC 5. We get intermittent crashes that I have not been able to
> track down. X86 and x86_64 works fine, but, say, ARMEL will crash. I'm
> hoping more "conforming" or "adhering" code will help to resolve the
> issue.
>
> Second, we got a warning under Cygwin x86_64, and we really did not
> understand it. The warning is/was:
>
>     Warning: defaulted move assignment operator of X will move assign
>     virtual base class Y multiple times
>
> It seems to me the diagnostic is telling me I should provide it. Also

Yes, virtual bases are a special case (in more ways than just this!).
The warning tells you which class(es) you need to make that change to.


> see http://stackoverflow.com/q/34554612.
>
> What do you think?
>
> Jeff



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux