> 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.
>>> 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
see http://stackoverflow.com/q/34554612.
What do you think?
Jeff
