[Off topic] Re: C++ question: MI vs. pure virtuals

llewelly@198.dsl.xmission.com llewelly@198.dsl.xmission.com
Sat Jan 1 01:00:00 GMT 2000

On Fri, 31 Dec 1999, Chip Salzenberg wrote:

> According to llewelly@198.dsl.xmission.com:
> > On Fri, 31 Dec 1999, Chip Salzenberg wrote:
> > > 	class A { virtual void f() = 0; };  // PURE VIRTUAL
> > > 	class B { void f() {} };            // NON-VIRTUAL
> > >     class C {};                         // ??
> > > 
> > > Is class C abstract like A, or not?
> > 
> > So I am going to assume you meant to ask about this:
> > 
> >   struct A {virtual void f()=0;};
> >   struct B {void f() {}};
> >   struct C :public A,public B {};
> D'oh!  Yes.  Consider that my mistake for this millenium (GMT).  :-)

The y2k bug strikes again ... there is no telling what technologies it
  will affect ! :-) 

> > Since A is not a base class of B, B::f() does not overide (does not
> >   implement) A::f(). (See sections 10.2, p2 (for name lookup), 10.3 p2,
> >   (for overriding of virtual functions) 10.4 (abstract base classes), and 
> >   pay particular attention to all of the examples in these sections.)
> Thank you for the precise answer.  I shall examine those sections.
> In a related question, a slight variation that I tried with gcc 2.96 is:
>    struct A {virtual void f()=0;};
>    struct B {void f() {}};
>    struct C : public A, public B { using B::f; };
> That didn't work either (the compiler still considered C abstract).
> To your understanding, is the compiler still correct in this case?
> (I expect that it is, but it doesn't hurt to ask.)

Yes. I think the reasoning in my previous letter still applies (see sec
  10.4, paragraph 4, and section 10.3, paragraph 2), I think C is still
  abstract, though I can see the logic of trying / asking about the using

As for the using statement, footnote 96 in section 10.2 says '...
  using-declarations cannot be used to resolve inherited member
  ambiguities; see 7.3.3' , and sec 7.3.3, paragraph 14 agrees.

Section 7.3.3 left me with the impression that 'using' is really only
  intended to make a name availible for use without expilicit
  qualification; I don't think it plays a role in overriding. (I may be
  wrong here; 7.3.3 is long and complex ... but since it is part of the
  standard, I guess you already knew that. :-)

So I doubt the 'using B::f;' statement does anything (in this example) at
  all; certainly it makes no difference gcc 2.95.2 . I must say this
  footnote is contrary to what I expected; I would have thought a using
  statement *could* be used to resolve inherited member ambiguities. 

I think I would write a one-line forwarding function in class C to resolve
  this problem; but remember if it is named 'f()' it will be virtual
  whether you declare it as such or not.

(It suddenly occurs to me that since this discussion is not really about
  a bug in gcc, perhaps this list isn't the best place to discuss it ...
  but no-one has complained yet.)

More information about the Gcc-bugs mailing list