problems with genclass

Thread View: gnu.g++

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by John T Riedl Tue, 26 Sep 1989 22:51

#145

Author: John T Riedl
Date: Tue, 26 Sep 1989 22:51

43 lines
2582 bytes

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 <type>.defs.h files.  These files contain #defines for comparison
operators for <type>.  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

problems with genclass

#149

Author: Doug Lea
Date: Thu, 28 Sep 1989 13:01

32 lines
1527 bytes

> We've been unhappy with the classes generated by genclass because each
> type needs to be separately generated, including the entire
> ... 
 
First, please use bug-lib-g++ for libg++-related questions. (There is
no info-lib-g++, just use the bug list.)

Possibly the best solution in your case would be to

    1) have all your classes be derived from a common base, that
        includes a virtual int compare(Base* b);

    2) Have all your containers be of Base*'s (suitably typedef'ed)

    3) Edit the CMP(a, b) macro to call a->compare.

And/Or similarly for the EQ macros, etc.


This gets you heterogenous containers. If you want homogenous
containers, then you probably want to live with multiple implementations.

The main disadvantage of the current container library is that you can't
readily set things up so that you can have subclasses of Set, each of
which shares the basic Set code but operates on pointers of an
*unrelated* different type.

I don't think that full C++ support for generics will happen in the
near future.

-Doug

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads