[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
statement.
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