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