Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uwm.edu!zaphod.mps.ohio-state.edu!sunybcs!uhura.cc.rochester.edu!rochester!kodak!ektools!randolph
From: randolph@ektools.UUCP (Gary L. Randolph)
Newsgroups: comp.lang.c++
Subject: Re: A question on pure virtual function members and MI
Message-ID: <2374@ektools.UUCP>
Date: 8 Jan 90 14:31:33 GMT
References: <25A0EE48.4643@paris.ics.uci.edu>
Sender: randolph@ektools (Gary L. Randolph)
Reply-To: randolph@ektools.UUCP (Gary L. Randolph)
Organization: Eastman Kodak, Dept. 47, Rochester NY
Lines: 59

In article <25A0EE48.4643@paris.ics.uci.edu> rfg@ics.uci.edu (Ron Guilmette) writes:
>I have a question regarding pure virtual functions and multiple
>inheritance.
>I'd like to know why the following short example should be illegal.
>(Both Cfront 2.0 and G++ 1.36.1 say that it is illegal.)
>class abstract {
>public:
>    abstract ();
>    virtual void method () = 0;
>};
>class concrete {
>public:
>    concrete ();
>    virtual void method () { }
>};
>class derived : public abstract, public concrete {
>public:
>    derived ();
>};
>The language rules require that a class which is derived from an abstract
>class must define (or again declare as pure virtual) any and all pure
>virtual functions that are inherited from its parents.

That's correct. " class which is derived from an abstract class must define",
NOT "class which is derived from *or sibling* must define".  Since concrete
is not a derived class of abstract, its definition is completely independent!
In other words, there exist
              abstract::method() //which is pure
                       and
              concrete::method() //which is distinct from abstract::method()

The derived class, derived, is still responsible for defining or keeping pure,
abstract::method().

I beleive this is the sort of problem I get myself into frequently.  I have
two mindsets (schizo?); one that knows how I *want* things to work, and
another that knows better.

Gary

>Fine.  But in the case shown above, why doesn't concrete::method become
>the definition of derived::method (thereby satisfying the requirement)?

I hope that answered (correctly) this question.

i
t

b
e
t
t
e
r
!
!
:
-
)