schiebel@cs.wvu.wvnet.edu (Darrell Schiebel) (04/09/91)
We are designing a reuseable software library based on C++ components. Currently we are exploring the various (twisted) ways of implementing a "generics" layer on C++. The alternatives seem to be: 1) Pointer Based Objects on top of C++ (Smalltalkish) 2) Pre-processor based macro generics with type substitution and using the "generic header file." 3) A yacc/sed/awk preprocessor for implimenting the generics ((C++)++) Does anyone out there have any experience with these mechanisms? or better yet Does anyone have a better solution? These soulutions are poor, but C++ doesn't seem to have the flexibility to allow for a seemless integration of these sorts of constructs into the language. The type structure doesn't seem to be rich enough. Many Thanks, Darrell Schiebel (schiebel@a.cs.wvu.wvnet.edu) (drs@baks.bell-atl.com)
aed@netcom.COM (Andrew Davidson) (04/10/91)
In article <1410@h.cs.wvu.wvnet.edu> schiebel@cs.wvu.wvnet.edu (Darrell Schiebel) writes: > >We are designing a reuseable software library based on C++ components. >Currently we are exploring the various (twisted) ways of implementing >a "generics" layer on C++. The alternatives seem to be: > > 1) Pointer Based Objects on top of C++ (Smalltalkish) can you give more detas? Is this just polymorphism > 2) Pre-processor based macro generics with type substitution and > using the "generic header file." I would advice you avoid using macros, if for no other reason than they are hard to debug. Try using templeting instead > 3) A yacc/sed/awk preprocessor for implimenting the generics > ((C++)++) sound like this would be even worse than using generic.h. (At least using generic.h is in the domain of c++) > >These soulutions are poor, but C++ doesn't seem to have the flexibility >to allow for a seemless integration of these sorts of constructs into the >language. The type structure doesn't seem to be rich enough. have you looked at using polymorphism with inheritance and container classes? have you thought about using dynamic linking and loading. Under this sinario you would focus on building a flexable frame work which allows the user to add new classes or replace clases (or parts of them) to suit there particluar needs. There are several ways to do this. If you are on sun workstations, you might want to look at the way they use shared lib. If this is not enough, then you should look at supporting true dyanmic linking and loading. (SYS V R4, SUNOS 4.1, there are several other lib packages that also do this kind of think in SYS V r3 and BSD Andy -- ----------------------------------------------------------------- "bede-bede-bede Thats all Folks" Porky Pig Andy Davidson Woodside CA. aed@netcom.COM -----------------------------------------------------------------
jeenglis@alcor.usc.edu (Joe English) (04/10/91)
schiebel@cs.wvu.wvnet.edu (Darrell Schiebel) writes: >We are designing a reuseable software library based on C++ components. >Currently we are exploring the various (twisted) ways of implementing >a "generics" layer on C++. The alternatives seem to be: > 1) Pointer Based Objects on top of C++ (Smalltalkish) > 2) Pre-processor based macro generics with type substitution and > using the "generic header file." > 3) A yacc/sed/awk preprocessor for implimenting the generics > ((C++)++) >Does anyone out there have any experience with these mechanisms? or better >yet Does anyone have a better solution? I've had some success with solution #2 (in C, with a generic hash table and a generic AVL tree), but not the way that Stroustrup does it in "The C++ Programming Language". That method involves writing separate "declare_XXX(...)" and "implement_XXX(...)" macros for generic types, which I found distasteful since the macros tend to be long, multi-line beasts and the implementations have to use lots of casts to and from (void *). The scheme I used was something like this: #define AVL_BASETYPE int #define AVL_COMPARE(x,y) (x < y) /* ... other generic parameters ... */ #include "avl.gc" where avl.gc defines the relevant datatypes for AVL trees and (static) functions performing all the operations on them. The code was designed to be used as the implementation of a higher-level data structure (a symbol table, say); everything defined in the ".gc" file is only visible in the file which includes it, which in turn exports functions of its own to the rest of the program. This somewhat limits the useability of the generic code, but it worked pretty well for my purposes. I can probably dig up the source code if you'd like to take a look at it. Alternately, gcc has a pretty decent generic mechanism using #3, or you could just wait until current compilers implement section 14 of the ARM (or whatever that section ends up as when the revisions are complete...) What I'd really like to see in C++ are true polymorphic functions, a la SML and Haskell. (Haskell does this in a particularly nice way...) --Joe English jeenglis@alcor.usc.edu
mjv@objects.mv.com (Michael J. Vilot) (04/10/91)
>From cs.wvu.wvnet.edu!schiebel >Newsgroups: comp.lang.c++ >Keywords: generic >Message-ID: <1410@h.cs.wvu.wvnet.edu> > >We are designing a reuseable software library based on C++ components. >Currently we are exploring the various (twisted) ways of implementing >a "generics" layer on C++. The alternatives seem to be: > > 1) Pointer Based Objects on top of C++ (Smalltalkish) > 2) Pre-processor based macro generics with type substitution and > using the "generic header file." > 3) A yacc/sed/awk preprocessor for implimenting the generics > ((C++)++) > >Does anyone have a better solution? I faced exactly this problem when designing the C++ Booch Components library. I decided on: 4) A template filter program (written in C++) that implements the (essential parts of) template processing described in Chapter 14 of "The Annotated Reference Manual." The filter sits between cpp and the C++ compiler. This approach let me build the library using the syntax that will eventually be supported in all C++ implementations, and make the library available on any platform supporting C++. For more details, you might want to read the paper Grady and I presented: "The Design of the C++ Booch Components," OOPSLA/ECOOP Conference, Ottawa Canada, October 1990, p. 1. Hope this helps, Mike
kelley@mpd.tandem.com (Michael Kelley) (04/10/91)
> In article <1410@h.cs.wvu.wvnet.edu> schiebel@cs.wvu.wvnet.edu (Darrell Schiebel) writes: > > > >We are designing a reuseable software library based on C++ components. > >Currently we are exploring the various (twisted) ways of implementing > >a "generics" layer on C++. The alternatives seem to be: > > > > 1) Pointer Based Objects on top of C++ (Smalltalkish) > > can you give more detas? Is this just polymorphism > > > 2) Pre-processor based macro generics with type substitution and > > using the "generic header file." > > I would advice you avoid using macros, if for no other reason than > they are hard to debug. Try using templeting instead > > > 3) A yacc/sed/awk preprocessor for implimenting the generics > > ((C++)++) > > sound like this would be even worse than using generic.h. (At least > using generic.h is in the domain of c++) > You got it! There is a better way... I pulled a PD version of a Decus (???) cpp that Texas Instruments had extended to support templates a number of months ago -- I can't remember the internet address. (Mary, Dan -- you there?) The syntax for defining the templates is a bit different than E&S, and the mechanism for declaring/defining actual classes from templates may not be the same as that coming out of the ANSI-C++ committee. (By the way, just what is the status on this matter?) But, *using* them is consistent -- we've been doing so with the standard lists and dictionaries, and are getting to the point it's hard to imagine doing without. Hope this helps. Mike Kelley Tandem Computers, Austin, TX kelley@mpd.tandem.com (512) 244-8830 / Fax (512) 244-8247
stenger@csc.ti.com (Dan Stenger) (04/12/91)
In article <172@devnull.mpd.tandem.com> you write: > > In article <1410@h.cs.wvu.wvnet.edu> schiebel@cs.wvu.wvnet.edu > > > > > >We are designing a reuseable software library based on C++ components. > > >Currently we are exploring the various (twisted) ways of implementing > > >a "generics" layer on C++. The alternatives seem to be: > > You got it! There is a better way... > > I pulled a PD version of a Decus (???) cpp that Texas Instruments had > extended to support templates a number of months ago -- I can't remember > the internet address. (Mary, Dan -- you there?) Here I am. Following is the announcement that I sent out about this preprocessor. We continue to find it quite useful. There is also a paper describing this work in the "C++ at Work - 90 Conference Proceedings" (page 73). Dan Stenger Texas Instruments Computer Science Center stenger@csc.ti.com ------------------------------------------------------------------------------ To encourage additional experimentation with parameterized types in the C++ programming community we have made available an implementation of "templates" as described by Stroustrup in his 1988 USENIX C++ Conference paper "Parameterized types for C++". Here is a simple example of this syntax: template<class T> class Vector<T> { T* v; int sz; public: Vector<T>(int); T& operator[](int); inline T& elem(int i) { return v[i]; } }; template<class T> T& Vector<T>::operator[](int i) { if (i<0 || sz<=i) error("vector: range error"); return elem(i); }; template<class T> Vector<T>::Vector<T>(size) { v = new(T[size]); }; DECLARE Vector<char*>; // create definitions for a vector of strings IMPLEMENT Vector<char*>; // generate code to support vector of strings Vector<char*> vs(30); // declare a vector of 30 strings You should note that the syntax for templates is still evolving and the current proposed standard is slightly different from what is implemented. This implementation is provided through an enhanced macro facility in a portable C++ preprocessor. We started with the DECUS C preprocessor that is provided in the MIT X Consortium distribution. First, we made it compliant with ANSI C (except for tri-graphs). Next, we made it recognize a #pragma form with the syntax "#pragma defmacro NAME PROGRAM", where NAME is the macro keyword to use in the source text and PROGRAM is a program to execute to translate the macro. Finally, we wrote the defmacros to translate the template syntax to standard C++. Interested parties can find all of this available for anonymous ftp from: csc.ti.com (internet address 128.247.159.141) in compressed form in the file: /pub/cpp.tar.Z Be forewarned that this is experimental, research software (although we have used it extensively here at TI) and the standard syntax for parameterized types is still evolving. Also, I am willing to help and answer questions but I only have a limited capacity to deal with them.