From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nathan Sidwell To: egcs@cygnus.com Subject: No Subject Date: Sun, 28 Feb 1999 22:53:00 -0000 Message-id: <9506.950506667.0@NO-ID-FOUND.mhonarc.org> X-SW-Source: 1999-02n/msg00215.html 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