No Subject

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