On Wed, 12 Dec 2018 at 16:52, Jason Merrill <ja...@redhat.com> wrote:
> > For what it's worth, I find it unfortunate that this deprecation and its > > resulting warnings end up > > making the decision on whether a "rule of 5" must be followed; correct code > > needs to be adjusted > > to cope with a fairly stylistic matter, with false positives and all. > > I don't see it as a stylistic matter. If you need a user-provided > copy constructor to get proper copy semantics for a class, you almost > certainly need the same thing for copy assignment. This was too noisy > for destructors, for which it's fairly common to define a virtual > destructor just to make a class polymorphic, not because there are > significant destruction semantics. But I don't see a similar argument > for copy constructors: in your example, there was no need for > QVariant::Private to define a copy constructor, and that seems like a > situation where a warning is reasonable, even if the code is in fact > correct. I have other cases where the compiler warns besides QVariant::Private. I don't have a good grasp of what those cases are like, yet, because I'll look at those warnings some time later, possibly next year. :) Thus I don't have any idea whether there are practical cases where the copy constructor allocates but the assignment can just blast bits, although I find that rather plausible. (Side note: disabling warnings in Qt is painful; it's not really more or less painful than doing code changes and regtesting those on all platforms; that's not your problem, though.)
