http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57319
Richard Smith <richard-gccbugzilla at metafoo dot co.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |richard-gccbugzilla@metafoo
| |.co.uk
--- Comment #5 from Richard Smith <richard-gccbugzilla at metafoo dot co.uk> ---
(In reply to Jason Merrill from comment #1)
> (In reply to Paul Pluzhnikov from comment #0)
> > However, this particular case *isn't* the problematic case, because
> > (a) this sample code should not trigger the definition of C's move
> > assignment operator, and
>
> True, the warning is given at declaration time; it would be possible to move
> the warning to when the move assignment is used, but that might mean design
> errors don't get caught until later.
OK, that makes sense. However, delaying the check until the operator= is lazily
declared does not fully achieve this goal. Could the check be performed at the
end of the definition of class C (rather than, presumably, when looking for a
virtual C::operator= for D::operator= to override)?
> > (b) there is only one inheritance path from C to B, so it won't be
> > move-assigned multiple times, and
>
> True, the warning is given at the point of first virtual derivation rather
> than when it appears in a diamond-shaped hierarchy. But the purpose of
> virtual derivation is to support diamond-shaped hierarchies, so again it
> seems appropriate to warn sooner rather than later.
OK. The class which brings together the diamond may provide a move assignment
operator which does not blindly call the move assignment operators on the base
classes, so this can still have some false positives even if every virtual base
is involved in diamond inheritance.
