[comp.lang.c++] A question on pure virtual function members and MI

rfg@ics.uci.edu (Ron Guilmette) (01/03/90)

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.

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

// rfg

randolph@ektools.UUCP (Gary L. Randolph) (01/08/90)

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
!
!
:
-
)