Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!att!att!westmark!mole-end!mat
From: mat@mole-end.UUCP (Mark A Terribile)
Newsgroups: comp.lang.c++
Subject: Re: real example of MI
Summary: THIS is what templates were made for ...
Keywords: multiple inheritance, real example
Message-ID: <464@mole-end.UUCP>
Date: 2 Jan 91 07:15:38 GMT
References: <1990Dec31.182239.23486@cbnewsm.att.com>
Organization: mole-end--private system.  admin: mole-end!newtnews
Lines: 60

In article <1990Dec31.182239.23486@cbnewsm.att.com>, carroll@cbnewsm.att.com (martin.d.carroll) writes:
> A little while back, Bjarne posted a request for people to submit
> real examples of multiple inheritance (MI) in C++.  Tom Cargill 
> has been making the same request for a while.  Here is my contribution.  
> 
> The following code implements an abstract Map interface via an underlying
> Skiplist data structure.  The use of MI appears in the following:
> 
>     template <class T, class U> 
>     class Map_via_skiplist : private Skiplist<T>, public Map<T,U> { /* ... */ };

I encourage EVERYONE to look this over very, very carefully.  Templates and
MI work together here in a particularly potent way.  If the algorithms for
the Skiplist are particularly interesting and involve data structures of
their own, it might even make sense to derive  Skiplist<T>  from a
Skiplist_manager whose algorithms can be shared instead of being recompiled
for every template-type expansion.  (A sufficiently smart compiler might
be able to determine what member functions can be common to all  Skiplist<T> ,
but it would have to be a VERY smart compiler).

There is something of a problem here:

> template <class T, class U> 
> class Map_via_skiplist_node : 
> 	public Skiplist_node<T> {
> 	friend Map_via_skiplist<T,U>;
> protected:
> 	// The value associated with this node's key.
> 	U value;
> 
> 	// Construct a Skiplist node with nlevels and the given <key,value> 
> 	// pair.
> 	Map_via_skiplist_node(int nlevels, const T& key, const U& value);

The problem is that we have to provide an already-constructed  U  to the
constructor, and we have to have a default constructor for the  U that is
a member, or this code will not work.  There's no way to say `substitute
here the parameters to the constructors for U .'  I suspect that doing this
using C++'s present constructor syntax would be a horrific problem, especially
as regards ambiguities.  All is not lost; we can write

	typedef Map_via_skiplist_node< Name, Widget > mvns_Widget;

	new mvns_Widget( levs, Name( name_arg_1, name_arg_2 ),
					Widget( Widget_arg_1, Widget_arg_2 ) );

but that seems a bit clumsy, as if we can do better.

Finally, if this is compiled using 3.0, wouldn't it be possible to make
some (or all but one) of these templates for classes internal to just one
of them, so that the program namespace is kept a bit cleaner?
 
If I wore a hat I would take it off to anyone who can debug a compiler with
all these different levels of names expanding to names with various, sundry,
and generally sundered meanings!  In the feral and furry world of templates,
we are asking an awful lot of the compiler.
-- 

 (This man's opinions are his own.)
 From mole-end				Mark Terribile