Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!inmet!stt
From: stt@inmet
Newsgroups: comp.lang.c++
Subject: Abstract vs. Template classes
Message-ID: <21000004@inmet>
Date: 17 Oct 89 22:16:00 GMT
Lines: 83
Nf-ID: #N:inmet:21000004:000:3354
Nf-From: inmet!stt    Oct 17 18:16:00 1989



There are indications that parameterized/template
classes will be added to C++ someday soon.
I think this is too bad, because the concept
of a generalized "abstract" class seems more useful,
and could accomplish the same goal as parameterized
classes without introducing yet another concept.
(An "abstract" class is meant to be any class with some number
of virtual components which have no corresponding default definition,
indicated via "=0" in C++ 2.0 parlance).

Bertrand Meyer makes the point in "Object-oriented
Software Construction" that even multiple inheritance 
is not "enough" as far as he is concerned,
and a separate generic/parameterized class concept is
essential.

I would claim that a way to merge the concepts
of abstract classes and parameterized classes is
simply to allow classes to have "virtual" object components,
"virtual" typedef components, etc.  In other words, allow
a class to have per-class (i.e. "static") 
"virtual" components of any
sort, rather than simply virtual function
components.

The actual definition of these components may be provided/overridden
in any class derived from the original one.
Any reference to these components implies a level of
indirection through the equivalent of the virtual-function table.

Here is a small example, based on the Example
in Lippman's "C++ Primer":

class List {
public:
    virtual typedef PT;  /* was a template parameter */
			       /* detailed syntax TBD */
    List (PT *pt = 0, List *lpt = 0) /* constructor */
	: val(pt), next(lpt) {}
    PT *append(List *);   /* an operation */
private:
    PT *val;              /* instance variables */
    List *next;
};

The intention is that what would have been template parameters
become virtual components of the class.  The "virtual typedef"
would hopefully allow flexibility in defining the nature of the
actual type specified in derived classes.  For instance, it
could specify that the actual type specified be a class derived
from some particular (abstract) base class.  This allows
the remaining code within the class with the virtual typedef
to perform operations on instances of the virtual type
using this knowledge.   Similarly, it should be possible
say something like  "virtual typedef void* PT;" to indicate that
the actual type may be any pointer type.

Another useful kind of parameterization is to allow
"virtual" object components of an (abstract class).  
This would allow different
derivatives of a base class to have distinct class-wide
tables, for example, controlling the action of
the derived class.  Virtual object components would
be similar to static components of a class, except that they
could be overridden in a derived class.

An advantage of this approach over a distinct parameterization
mechanism is that partial instantiation is possible by
overriding some of the virtual object/type components, while
leaving others still undefined.
Furthermore, it is possible to provide default
bindings for the virtual object/type components, allowing
a derived class to only override those it wishes to and use
the defaults for the others.
Finally, it makes it clear that the code is intended to
be shared between distinct derivations/instantiations, whereas
with a template the tendency is to treat them as macros.

S. Tucker Taft     stt%inmet@uunet.uu.net
Intermetrics, Inc.
Cambridge, MA  02138