Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uxc.cso.uiuc.edu!garcon!garcon.cso.uiuc.edu!grunwald
From: grunwald@flute.cs.uiuc.edu (Dirk Grunwald)
Newsgroups: comp.lang.c++
Subject: Re: C++ Parameterization Progress?
Message-ID: <GRUNWALD.89Jun23130240@flute.cs.uiuc.edu>
Date: 23 Jun 89 18:02:40 GMT
References: <6590158@hplsla.HP.COM> <9511@alice.UUCP> <GRUNWALD.89Jun20221024@flute.cs.uiuc.edu>
Sender: news@garcon.cso.uiuc.edu
Reply-To: grunwald@flute.cs.uiuc.edu
Distribution: comp
Organization: University of Illinois, Urbana-Champaign
Lines: 72
In-reply-to: grunwald@flute.cs.uiuc.edu's message of 21 Jun 89 03:10:24 GMT


Several people asked me to define ``delegation by pointer.''

The meaning I use is that published in the paper ``Multiple Inherietence
for C++'' by Stroustrup in section 8 ``Delegation through a Pointer''.

This allows you to specify inheritence of interface without having to
specify inheritence of instance.

For example, consider class Bar, with subclass FooBar, DryBar, WetBar.

Now, consider class Gnu, with subclass Gnat and Gnome.

We would like Gnat and Gnome to be subclasses of *any kind* of Bar;
we care not whether it be a FooBar, DryBar or WetBar.

You can do this under C++ MI by declaring:

	class GnatBar : Gnu, Bar
	class GnomeBar : Gnu, Bar

but, let us conjecture that Bar is really an abstract class, represinting
an interface, not an instance.

Then, to get an actual *instance* we have to define:

	class GnatFooBar : Gnu, FooBar
	class GnatDryBar : Gnu, DryBar
	class GnatWetBar : Gnu, DryBar

But that's not good; want to treat this set of classes as similar things,
so we can pass them around & have people treat them as the union of a Bar
and a Gnu....So, we use...

	class GnatBar: Gnu, Bar
	class GnatFooBar : Gnu, virtual FooBar
		...etc...

So, now, at the expense of introducing three class definitions, we
can finally do what we want.

Delegation by pointer says that we can declare a class via:

	class FooBar : Foo, Bar *p

Now, all interface accesses through a FooBar are delegated to a Bar object
via the pointer ``p''. You can restrict the semantics slightly and force
``p'' to be bound at instance creation time, or you can allow ``p'' to
be changed on the fly.

In this case, you only need to introduce a *single* class to do this;
you can effect the same results using the ``virtual'' class mechanism,
but it's clumsy, at best, and introduces many bogus classes & class
definitions.

What are my realistic examples?

Consider a thread library, were Bar represents the abstract class of
``things that order threads for execution'' and Foo represents the
set of ``things that need threads to be ordered,'' e.g.,

Semaphores, Facilities, ReadyLists, whatever.

Either you create a panoply of subclasses,
e.g.,	PrioritySemaphore, FifoSemaphore, LifoSemaphore,
	PriorityFacility, FifoFacility, LifeFacility, etc

or, with delegation, you allow the user to bind instances of
ThreadContainers to instances of ThreadSchedulers.

--
Dirk Grunwald -- Univ. of Illinois 		  (grunwald@flute.cs.uiuc.edu)