Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!riedl
From: riedl@cs.purdue.EDU (John T Riedl)
Newsgroups: gnu.g++
Subject: problems with genclass
Message-ID: 
Date: 26 Sep 89 22:51:40 GMT
Sender: riedl@cs.purdue.EDU
Organization: Department of Computer Science, Purdue University
Lines: 44

We've been unhappy with the classes generated by genclass because each
type needs to be separately generated, including the entire
super-class hierarchy for the new class.  For instance, to create a
set class containing elements of class intElement we have to generate
SLSet, Set, and SLList classes for intElement.  If we have another
type intElement1 for which we need similar sets, we have to generate
an additional three clasees for intElement1.

Ideally we would like to have a single class Set which takes a member
type as an argument to its constructor.  Thus we would only need code
for a container class once, no matter how many different types it was
used for.  Being able to share code would be one advantage, but the
biggest advantage is in making it easy for programmers to use
container classes.

The libg++ manual (User's Guide to GNU C++ Library) suggests in
section six, introduction to container class prototypes, that
a container class can be instantiated using 'void *' as the type.
Then, any pointer can be stored in the container.  This approach is
based on Stroustrup, pp 204-210.  

Unfortunately, these containers cannot use methods of the contained
class.  In particular, comparison operators are not available.  These
operators may be needed for building data structures such as heaps or
AVL-trees from ordered sets.  A partial solution is provided through
the .defs.h files.  These files contain #defines for comparison
operators for .  However, only one set of comparisons can be
active for a given compilation,  Hence, this trick only supports one
base type per container type at a time.

We are thinking of building a new Set class that would take as an
argument of its constructor the comparison functions for the contained
type.  These functions would be stored in the private area of the
class, and could be used by the methods of the class in place of the
#define'd types.  This way, a single void * class hierarchy could be
shared between members of any number of base types.

Has anyone done something like this?  Is there an easier solution to
the problem?  When are real C++ generics coming?

Thanks!
John Riedl
Jagannathan Srinivasan