Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!hp-pcd!hplsla!jima
From: jima@hplsla.HP.COM (Jim Adcock)
Newsgroups: comp.lang.c++
Subject: Re: Wrapping inheritance hierarchies
Message-ID: <6590259@hplsla.HP.COM>
Date: 19 Sep 89 18:39:31 GMT
References: <3959@hplabsz.HPL.HP.COM>
Organization: HP Lake Stevens, WA
Lines: 38

Interesting issue.  A user of a derived class D decides that D really 
should have had a virtual base class B instead a non-virtual B.  

How does a user decide that without seeing the source?  How can a user 
be sure that D doesn't change the operation of B?

--This is far different from a class E whose base B is declared virtual. Which 
represents a contract by E not to use B in a way that would preclude the 
base instance "B-part" of E from being used by another class. E would 
typically only do things to the B-part in the E's constructors and destructors.
Thus E uses B by mere aggregation with B -- B's capabilities are not mixed with
E's, but rather B's and E's capabilities are orthogonal.  In which case B's and
E's capabilities should be implemented totally separately: implement the meat
of E instead in a class Eprime, and then create E via trivial derivation:

class E : public B, public Eprime
{
  E() : B(something), Eprime(somethingelse) {}
  ~E() {maybesomething();}
};

Then, if the user of your classes decides he/she needs something like E
but with a virtual B, the user can trivially make such a class:

class Evirt : public virtual B, public E
{
  Evirt() : B(something), Eprime(somethingelse) {}
  ~Evirt() {maybesomething();}
};

Or you could provide both flavors, virtual base "Evirt" and non-virtual base 
"E" to your users to use as they please.

But you complain: "I write my Eprime-meat as part of E because my Eprime-part
is not really orthogonal to B."  Fine, but then the user was never in
a situation where having B virtual would have done the user any good.  
Because E was never written in a way to let the B part be shared by another 
class.