NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/lang/cplus/17947

Text File | 1992-12-14 | 8.0 KB | 275 lines

Newsgroups: comp.lang.c++
Path: sparky!uunet!rosevax!camax01!kotula
From: [e-mail] (Jeff Kotula)
Subject: Virtual base classes summary
Message-ID: <[e-mail]>
Organization: CAMAX Systems, Inc.
Date: Mon, 14 Dec 1992 21:29:48 GMT
Lines: 265

Here is a summary of the responses to my post a few weeks ago about virtual
base classes.  Good stuff!  Thanks for the responses...


From pat@frumious  Thu Dec  3 06:52:22 1992
Date:     Wed, 2 Dec 1992 18:45:13 -0500
From: pat@frumious (Patrick Smith)
To: [e-mail]
Subject: Re: Virtual base classes

You wrote:
|Me and this other guy (who shall remain nameless) have been trying to
|figure out the appropriate use for virtual base classes.  Given the
|following inheritance hierarchy:
|        A
|       / \
|       B C
|       | |
|       D E
|       \/
|        F
|
|where we only want one copy of A, which set of inheritances should be
|virtual?
|
|    1) A to B  and  A to C

This one.



|    2) D to F  and  E to F

This won't work; if you do (2) but not (1), then every D object will
contain its own A subobject (not sharable with any other A object),
and every E object will contain its own A subobject (also not sharable).
So in an F you will have a D subobject (containing one A object)
and an E subobject (containing a different A object).

After (2), if you then created a new class,

   class G : public F, public virtual D {};

then G would only contain one D subobject (because of virtual
inheritance).

--
Patrick Smith
uunet.ca!frumious!pat
[e-mail]

From [e-mail]  Wed Dec  2 18:51:40 1992
Date: Wed, 2 Dec 92 18:01:02 CST
From: [e-mail] (John Eric Meyer)
To: [e-mail]
Subject: Re: Virtual base classes
Organization: Vanderbilt University School of Engineering, Nashville, TN, USA
Cc:

   A
  / \
 B   C
 |   |
 D   E
  \ /
   F

As I understand the nature of the beast, A to B and A to C must be virtual,
while D to F and E to F need not be.  Declaring D to F and E to F as virtual
*without* virtualizing A will not have the desired effect.  The virtual
state of inherited objects applies only to the object inherited as virtual,
not to the object and all its ancestry.

   A
   |
   B
  / \
 C   D
  \ /
   E

In this case

   class B : public A;
   class C : virtual public B;
   class D : virtual public D;
   class E : public C, public D;

would result in E containing only one copy of B and one copy of A (within B,
if you will).  A is in a sense virtualized by association. On the other hand

   class B : virtual public A;
   class C : public B;
   class D : public B;
   class E : public C, public D;

would result in E containing two copies of B but just one copy of A.

Hope this helps ( moreover, I hope this it correct! )

Eric
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
As I tell my friends, never listen to me when I'm wrong.
---------------------------------------------------------------------------

From [e-mail]  Thu Dec  3 06:52:28 1992
Date: Wed, 2 Dec 92 20:24:29 PST
From: [e-mail] (Doug Landauer)
To: [e-mail]
Subject: Re: Virtual base classes
Organization: Sun Microsystems, Mt. View, Ca.

>       A
>        / \
>        B C
>        | |
>        D E
>        \/
>       F
>
> where we only want one copy of A, which set of inheritances should be
> virtual?
>
>     1) A to B  and  A to C
>        or
>     2) D to F  and  E to F
>
> I suspect that either will work, but which is best, and why?

No, only the #1 choice is appropriate.  One way to state the rule is to
say that if you want a base class to be shared, its closest derived
class must inherit it virtually.  Using the #2 choice, there will be
two A's.

Another way to look at it is the cfront way:  think of the most likely
implementation, and it will show you the semantics.  In this case,
virtual inheritance means a pointer instead of inclusion.  To share a
base class, we must have a pointer to *that* base class.  In your #2
choice above, we have only pointers to D and to E -- we cannot share
those.  We do *not* have any pointer to any A.

>  3) Are there hidden gotchas?

One gotcha is the one-way nature of virtual base class pointers.  For
instance, in one common OOP idiom, you have a class which implements
"list-of-ptr-to-base-class", and you populate that list with ptrs to
various derived classes, and upon extraction from the list, you
downcast the pointer to the type you happen to know it really is.
This idiom works fine *only in the absence* of virtual inheritance.
Because the pointer is one-way, you *cannot* cast a ptr-to-base into
being a ptr-to-derived if the inheritance is virtual.

One other gotcha is in debugging:  if your debugger's C++ support is
weak, you must understand this virtual-base-pointer business, else
the bits in memory make no sense.  (Sun's dbx support is pretty
reasonable in this respect.)
--
Doug Landauer -- [e-mail]               _
Sun Microsystems, Inc. -- STE, SunPro, IPE         La no ka 'oi.

From [e-mail]  Tue Dec  8 14:57:49 1992
Path: trmphrst.demon.co.uk!nikki
From: [e-mail] (Nikki Locke)
Subject: Re: Virtual base classes
Reply-To: [e-mail]
To: [e-mail]
Date: Tue, 08 Dec 92 19:24:41  GMT
Organization: Trumphurst Ltd.

In article <[e-mail]> you write:
> Me and this other guy (who shall remain nameless) have been trying to
> figure out the appropriate use for virtual base classes.  Given the
> following inheritance hierarchy:
>
>     A
>        / \
>        B C
>        | |
>        D E
>        \/
>     F
>
> where we only want one copy of A, which set of inheritances should be
> virtual?
>
>     1) A to B  and  A to C
>                or
>     2) D to F  and  E to F
>
> I suspect that either will work, but which is best, and why?
Only 1 will work.

> My understanding is that the semantics of diamond inheritance is an inherent
> problem in OO techniques.  At the moment I'm more concerned about
> pragmatics, though.  For instance:
>
>     1) Are most implementations of virtual base classes reliable?
No.

>     2) What compilers are not reliable in this respect?
To my knowledge, Zortech C++ 3.0r4 and Borland C++ 3.0. I have heard that
at least one cfront based compiler also has problems.

--
Nikki Locke,Trumphurst Ltd.(PC and Unix consultancy) [e-mail]
trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.

From [e-mail]  Thu Dec 10 12:58:16 1992
Path: trmphrst.demon.co.uk!nikki
From: [e-mail] (Nikki Locke)
Subject: Re: Virtual base classes
Reply-To: [e-mail]
X-Mailer: cppnews $Revision: 1.30 $
Date: Wed, 09 Dec 92 19:22:15  GMT
Organization: Trumphurst Ltd.

In article <[e-mail]> you write:
> > >     1) Are most implementations of virtual base classes reliable?
> > No.
>
> Do you know if the errors are at compile-time or run-time?  What are
> some of the manifestations?
Borland gives errors at compile time for the following ...

class base {
public:
    virtual void abstract() = 0;
    };

class d1 : virtual public base {
public:
    virtual void abstract() { }
    };

class d2 : virtual public base {
    };

class d3 : public d1, public d2 {
    };

d3 Ad3;        // Borland thinks this is an abstract class. I don't.

Zortech gives runtime errors (i.e. sometimes crashes horribly) with
similar code (but which does some real work). This is caused by the thunk
which adjusts the offset to the this pointer getting the adjustment
wrong.

I don't know about cfront, I can't afford it :-)

--
Nikki Locke,Trumphurst Ltd.(PC and Unix consultancy) [e-mail]
trmphrst.demon.co.uk is NOT affiliated with ANY other sites at demon.co.uk.




Markku Sakkinen also forwarded several interesting papers he's written on
the general subjects of problems with multiple inheritance.


--
-------------------------------------------------------------------------------
jeff                |   The doctors say there's a 50-50 chance that he'll
[e-mail]    |   live...although there's only a 10 percent chance of
Camax Systems, Inc. |    that.