Path: utzoo!attcan!uunet!jarthur!usc!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!purdue!haven!adm!lhc!nih-csl!helix.nih.gov!kgorlen
From: kgorlen@helix.nih.gov (Keith Gorlen)
Newsgroups: comp.lang.c++
Subject: Re: Nonvirtual base classes in MI
Message-ID: <909@nih-csl.nih.gov>
Date: 1 Feb 91 18:54:42 GMT
References: <1159@zinn.MV.COM>
Sender: news@nih-csl.nih.gov
Reply-To: kgorlen@helix.nih.gov (Keith Gorlen)
Lines: 66

In article <1159@zinn.MV.COM>, mjv@objects.mv.com (Michael J. Vilot) writes:
|> Scott Meyers asked for an example of using multiple inheritance without using
|> virtual base classes.  I used exactly this approach in the design of the C++
|> Booch Components library, to use mixin classes to achieve a couple of purposes.
|> 
|> First, let me point out that the Booch Components library has a ``forest'' 
|> architecture, and thus avoids the common base class arrangement that leads to
|> the complexities of using MI in that context.  Second, I used private and 
|> public base classes for different design purposes.
|> 
|> The first use I made of MI was to create ``concrete'' classes from abstract
|> base classes (ABCs).  These concrete classes had both the ABC and a base class
|> for representation.  With this arrangement, the library can provide alternate 
|> implementations of the ABC, each with different time/space complexity.  In this
|> case, the base class for representation is a second, private base class.

It seems to me that there is little, if any, advantage to using private
inheritance as opposed to simply including an instance of the class as a member
variable, e.g.:

	class Concrete: public ABC, private Rep {
	// ...
	public:
		void foo();
	};

	void Concrete::foo() { Rep::f(); // ... }

versus:

	class Concrete: public ABC {
		Rep rep;
	// ...
	public:
		void foo();
	};

	void Concrete::foo()  { rep.f(); // ... }
		
Are there more compelling reasons for using private inheritance than this?

|> The second use I made of MI was to mix in specific behavior for Node classes in
|> the unbounded representations.  Some of the Booch Components are what we call
|> ``polylithic'' structures.  That is, they can share their representation among
|> several objects.  Shared_Nodes are kinds of Nodes that mix in a Shared base
|> class.  This approach let me build the Shared class once (implementing reference
|> counting), and mix it in as needed.  The library also supports Managed 
|> components, which take over free list management from the global operators new
|> and delete.  A Managed_Node mixes in a base class Managed, which provides the
|> class-specific operators new and delete.  Again, I only had to build that 
|> mechanism once to use it in various places.
|> 

Is this also a case of private inheritance?

|> --
|> Mike Vilot,  ObjectWare Inc, Nashua NH
|> mjv@objects.mv.com  (UUCP:  ...!decvax!zinn!objects!mjv)



-- 
	Keith Gorlen			phone: (301) 496-1111
	Building 12A, Room 2033		FAX: (301) 402-0007
	National Institutes of Health	uucp: uunet!kgorlen%alw.nih.gov
	Bethesda, MD 20892		Internet: kgorlen@alw.nih.gov