This is the mail archive of the egcs@egcs.cygnus.com mailing list for the EGCS project. See the EGCS home page for more information.
Nathan Sidwell (me) wrote:
> stuff about -Woverloaded-virtual
I'm not too surprised there were some objections to warning about missing
`virtual' on a derrived class virtual function. As the language permits that, I
don't think it sensible warn about. There seem to be no objections to warning
when a virtual function overrides a non-virtual function -- that's more likely
to be a mistake.
In looking at warn_hidden, which implements this flag, it seems the behaviour
is at variance with the documentation. gcc.info-2 says
`-Woverloaded-virtual'
Warn when a derived class function declaration may be an error in
defining a virtual function (C++ only). In a derived class, the
definitions of virtual functions must match the type signature of a
virtual function declared in the base class. With this option, the
compiler warns when you define a function with the same name as a
virtual function, but with a type signature that does not match any
declarations from the base class.
This seems to be saying that if A contains 'virtual int foo()', and B (derived
from A) contains 'virtual int foo(int)', I'll get a warning. If A contains both
'virtual int foo()' and 'virtual int foo(int)', but B contains only 'virtual
int foo()', I won't get a warning. The documentation isn't quite correct WRT
the language, a virtual function in a derrived class does not _have_ to match
the type signature in a base class, it's just that if it does not, it is not
overriding that base function.
However, the actual behaviour and the changelog entry are at variance with
this. Both are warned about.
Wed Jan 24 13:01:26 1996 Mike Stump <mrs@cygnus.com>
* class.c (finish_struct_1): Call warn_hidden if we want warnings
about overloaded virtual functions.
(warn_hidden): New routine to warn of virtual functions that are
hidden by other virtual functions, that are not overridden.
From the documentation, I thought the intention was to catch cases were
'virtual T A::foo(A *)', had been overridden by 'virtual T B::foo(B *)', (which
indeed is caught). It does not catch it when the derrived class omit's the
virtual specifier, as in 'T B::foo(B *)'.
It does not seem to be sensible to warn about cases where the programmer has
only overloaded a subset of the parent's virtual functions.
Which should be fixed, documentation or implementation?
I would have thought that it would be sensible to catch the cases where a
derrived class's virtual member function's type signature did not match a base
class member (virtual or non-virtual), but it could be coerced through normal
(not allowing user conversion operators) overload resolution rules into that
signature. We'd also warn about a derrived class's virtual member function
which matched a base class's non-virtual member function.
Thus we'd warn about
'virtual T A::foo(A)' and 'virtual T B::foo(B)' (type signature similar)
'virtual T A::foo(A)' and 'T B::foo(B)' (type signature similar)
'T A::foo(A)' and 'virtual T B::foo(B)' (looks like non-virtual base)
'T A::foo(A)' and 'virtual T B::foo(A)' (matches non-virtual base)
We would not warn about
'T A::foo(A)' and 'T B::foo(B)', (neither is virtual)
'virtual T A::foo(X)' and 'virtual T B::foo(Y), (Y and X have no relation)
'virtual T A::foo(X)' and 'T B::foo(Y), (Y and X have no relation)
'virtual T A::foo()' and 'T B::foo()', (because there's nothing wrong)
comments?
nathan
--
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
You can up the bandwidth, but you can't up the speed of light
nathan@acm.org http://www.cs.bris.ac.uk/~nathan/ nathan@cs.bris.ac.uk