keith@nih-csl.UUCP (11/18/87)
The Object-Oriented Program Support (OOPS) class library for C++ will soon become easier to obtain. In the past, it has been necessary to send us a letter of request and a mag tape. However, we will submit the OOPS class library for distribution on the USENIX C++ library tape that is being assembled, and we will also make it available via anonymous ftp as soon as we get an Internet connection (probably during the first quarter of '88). The library currently consists of the following classes: Object Bitset Class Collection Arraychar String Arrayobid Bag Set Dictionary IdentDict SeqCltn Heap LinkedList OrderedCltn SortedCltn Stack Date Float Fraction Link Linkobid Process LookupKey Assoc AssocInt Integer Nil Point Random Rectangle Scheduler Semaphore SharedQueue Time -- Keith Gorlen phone: (301) 496-5363 Building 12A, Room 2017 uucp: uunet!mimsy!elsie!nih-csl!keith National Institutes of Health Bethesda, MD 20892
mitsu@well.UUCP (11/20/87)
In article <283@nih-csl.UUCP> keith@nih-csl.UUCP (keith gorlen) writes: > >The Object-Oriented Program Support (OOPS) class library for C++ will >soon become easier to obtain. In the past, it has been necessary to >send us a letter of request and a mag tape. However, we will submit >the OOPS class library for distribution on the USENIX C++ library tape >that is being assembled, and we will also make it available via >anonymous ftp as soon as we get an Internet connection (probably >during the first quarter of '88). . . . . > Keith Gorlen phone: (301) 496-5363 > Building 12A, Room 2017 uucp: uunet!mimsy!elsie!nih-csl!keith > National Institutes of Health > Bethesda, MD 20892 We would like to find out how to get a hold of the USENIX C++ library tape. (BTW, Keith, we never did get a copy of your OOPS library; did you get our letter?) We, too, have been thinking of using a pure object-oriented approach to using C++, but we have run into some difficulties. How does your OOPS library handle dynamic binding? I presume your Collection classes handle pointers to things of type Object, is that right? Does the caller have to type coerce the return value of the Collection class to get the correctly typed object, or do your objects handle that automatically via some sort of class object pointer? If your objects do have class object pointers, what's in those class objects? I presume some class variables and methods, but is there also a table of method pointers for the class, or do you use virtual functions to handle this? Do all of your methods universally return Object pointers (thus making the virtual function type difficulty moot?) Do you declare ALL methods virtual in that case? Can you handle multiple inheritance? How do you deal with the problems of virtual function table offsets in that case? Now presuming you don't declare all methods of all subclasses in class Object (thereby eliminating the type coercion problem and the multiple-inheritance virtual function table offset difficulty at once) what kind of macros do you use to do type coercion? What methods do you expect to be defined for all objects (aside from ==, =, Hash() or whatever, !=)? Do you use more general macros than those included in generic.h? Finally, what is the performance hit in using instances of class Float or Integer instead of built-in classes? If you use virtual functions heavily, do you feel this is an overly-large memory hit? -Mitsu Hadeishi CDI Research and Development Electronic Arts 1820 Gateway Drive San Mateo, CA 94404 ---------------------------- ucbvax!sun!elecarts!mitsu (415) 571-7171x505
keith@nih-csl.UUCP (11/21/87)
In article <4489@well.UUCP>, mitsu@well.UUCP (Mitsuharu Hadeishi) writes: > We would like to find out how to get a hold of the USENIX C++ > library tape. Please contact Peter Salus (usenix!peter) for further info. >(BTW, Keith, we never did get a copy of your OOPS library; > did you get our letter?) I think so. I'll check on it next week. > We, too, have been thinking of using > a pure object-oriented approach to using C++, but we have run into some > difficulties. How does your OOPS library handle dynamic binding? Vanilla virtual functions. > I presume your Collection classes handle pointers to things of type > Object, is that right? Does the caller have to type coerce the return > value of the Collection class to get the correctly typed object .. Yes. There are two ways to make sure that the cast is safe: 1) make a new class that uses the polymorphic class as a base class or member variable, and write member functions that statically type-check the objects added to the polymorphic class. Then provide member functions that return pointers cast to the desired type. This approach adds no run-time type checking overhead. 2) Check the class of the object at run time before doing the cast. OOPS has functions to facilitate this. A third approach, not implemented in OOPS, will be to have generic collection classes that have type parameters, and instantiate the generic class for the desired type. This will be possible when type parameters are implemented in C++. > If your objects do have class object pointers, what's in those > class objects? A pointer to the class object of the base class, the name of the class as a character string, a version number, the size in bytes of instances of the class, a pointer to a function for reading instances of the class from a stream, and some dull stuff. > I presume some class variables and methods, but is there > also a table of method pointers for the class, or do you use virtual > functions to handle this? Virtual functions. > Do all of your methods universally return > Object pointers (thus making the virtual function type difficulty moot?) Yes. (more or less) > Do you declare ALL methods virtual in that case? Most of the member functions of the collection classes are virtual. > Can you handle multiple > inheritance? How do you deal with the problems of virtual function > table offsets in that case? I have some ideas on how to make OOPS handle multiple inheritance under the next release of C++, which will automatically take care of the virtual function tables. > what kind of macros do you use to do type coercion? None, although I suppose I should have. I do have member functions that do type checking, however. > What methods do > you expect to be defined for all objects (aside from ==, =, Hash() or > whatever, !=)? storer(), reader(), compare(), deepenShallowCopy(), hash(), isA(), isEqual(), printOn(), species() should be defined by each OOPS class. Class Object implements isKindOf(), isMemberOf(), isSame(), isSpecies(), shouldNotImplement(), storeOn(), addDependent(), changed(), deepCopy(), dependents(), release(), removeDependent(), shallowCopy(), update(), and some others. > Do you use more general macros than those included > in generic.h? OOPS doesn't make much use of macros. I have some m4 macros that can generate a primitive container class for a fundamental type, but they are currently used to generate only class Arraychar. I used m4 macros most extensively for the APL-like Vector classes, but these are not practical, so I don't distribute them routinely. I don't recommend extensive use of C preprocessor macros such as those in generic.h -- they seem to break cpp on some machines. > Finally, what is the performance hit in using instances of > class Float or Integer instead of built-in classes? It is unacceptable, in my opinion, so I don't define the arithmetic operators for these. They are a hack to allow floats and ints to be stored in OOPS data structures. > If you use > virtual functions heavily, do you feel this is an overly-large > memory hit? In theory, no; in current practice, yes. Due to limitations of the UNIX loader, the virtual function pointer tables are unnecessarily replicated. I think I recall Bjarne saying he had a fix for this in the next release. -- Keith Gorlen phone: (301) 496-5363 Building 12A, Room 2017 uucp: uunet!mimsy!elsie!nih-csl!keith National Institutes of Health Bethesda, MD 20892