NetNews Usenet Archive 1992 #27

home *** CD-ROM | disk | FTP | other *** search

/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / cplus / 16482 < prev next >

Wrap

Text File | 1992-11-17 | 18.7 KB | 544 lines

Newsgroups: comp.lang.c++ Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!elroy.jpl.nasa.gov!sdd.hp.com!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!att!dptg!ucs!skdutta From: skdutta@ucs.att.com (Saumen Dutta) Subject: C++ Product List - Version 2.04 - Part 4/8 Message-ID: <1992Nov18.022710.511@ucs.att.com> Organization: AT&T Universal Card Services, Jacksonville FL Date: Wed, 18 Nov 1992 02:27:10 GMT Lines: 534 3. Libraries _ _________ A List of Class Libraries are available below. Refer to the individual items for detail descriptions. The description includes evaluation criteria on these libraries. Evaluation is based on Documentation, Usability, Extensibility, Permor- mance, Sensibleness etc. 3.1. OATH - Object-oriented Abstract Type Hierarchy. _ _ ____ ______ ________ ________ ____ _________ + Written by: Brian M. Kennedy Freeware available via anonymous ftp from site csc.ti.com (192.94.94.1) in the file /pub/oath.tar.Z. + The Reference Manual states it has only been compiled with AT&T cfront 2.1 compatible compilers. No templates and no exception handling. + OATH (Object-oriented Abstract Type Hierarchy) was designed as an experiment in increasing object-oriented reuse. It has a fairly high learning curve, but poten- tially higher gains if you are looking for a more flex- ible and robust abstraction. It is completely unsup- ported. Please refer to the menu below to get to the detail information about OATH features. + Information provided by Marco Pace (MPACE@ESOC.BITNET) and Brian Kennedy (kennedy@intellection.com) 3.1.1. OATH Introduction _ _ _ ____ ____________ OATH instantiates an approach to C++ class hierarchy design that exploits subtyping polymorphism, provides greater implementation independence, and supports implicit memory management of its objects. It is implemented via parallel hierarchies of internal types and accessors (a concept similar to that of the "smart pointers", but improved compared to them). The internal types contain the object representation (the data members) and the virtual functions. The accessor types contain all of the externally accessible functions of the abstract types. Two main design goals of OATH were: To provide a meaningful abstract type hierarchy that is consistent with the concepts being modelled by utilizing a strict subtyping approach to hierarchy design. Starting from the the idea that a type hierarchy should be designed to reflect the behaviour of the objects being modelled and not to reflect the most convenient computer representation of objects, the designer of OATH gave priority to the sub- typing (inheriting functionality) aspect over the code reuse (inheriting implementation) aspect. Given a consistent abstract type hierarchy, implementation classes can be added at the leaves of the hierarchy (see figure later on) to implement the behaviour of the abstract types. Code reuse can be exploited at this phase, but should not enter into the design of the abstract type hierarchy. To provide robust garbage collection (GC) of OATH objects, fully implemented within a portable C++ class library. The garbage collection mechanism is a hybrid reference counting and marking algorithm capable of collecting all garbage (including circular references). The programmer can select one of four garbage collection modes at compile time: no GC, incremental GC, stop-and-collect, or combined. 3.1.2. Features _ _ _ ________ OATH's main features are the following: It provides heterogeneous container classes It provides dynamic type determination in the form of "safe casts" It provides accessors to access OATH objects. For each OATH type there is a corresponding accessor class (an accessor lies between a C++ pointer and a C++ refer- ence). The accessors can be initialized and assigned OATH objects to access. However, any other operation on an acces- sor is applied directly to the abstract object it accesses. 3.1.3. Hierarchy _ _ _ _________ The class hierarchy provided by OATH is the following: + obj + pos * pdPos + listPos * dlPos + stringPos * minStringPos + bag + set * hashSet + finiteSet # characterSet + queue + seq + lifoQueue * pdlQueue + fifoQueue + deq + list * dlList + string * minString + table # stringTable + token # character # localToken # stringToken + complex + real + rational + integer * bigInteger where the classes preceded by '+' are abstract types, the classes preceded by '*' are implementation types, and the classes preceded by '#' are "abstract implementation types". (A visually more readable version of this hierarchy can be found in [1], Figure 1 <see bibliography>.) 3.1.4. Evaluation _ _ _ __________ + Documentation: The documentation is very concise (probably too much) and lacks examples. Due to its conciseness sometimes it is not easy to understand and somehow it is cryptic. + Usability: OATH provides a wide set of classes. It does not seem easy to use the class services provided, especially for a beginner. Services that you would expect to find at a given level of the hierarchy sometimes are not there and you have to go upwards through the tree to find them, sometimes with names not directly related to what you are using. The services provided are not many, but their interface is simple to use. + Extensibility: This feature was not evaluated directly. However, a brief discussion on the way to extend the existing class library is present in the OATH Reference Manual [2] (OATH(30), section Developing New OATH Types). + Sensibleness: The available classes are perhaps too abstract. I would have preferred less abstract and more "practical" classes, but probably this would have been against the basic assumptions their designers of OATH made. Among the, there are classes for integers, rational, real, complex. + Miscellaneous: The provided hierarchy is that of a tree, where only single inheritance is supported. No templates (parameterized types) are provided, and no exception handling as well. Garbage collection is supported and appears to be even sophisticated in terms of the kinds of GC available. 3.1.5. Bibliography _ _ _ ____________ 1. Brian M.Kennedy, The Features of the Object-oriented Abstract Type Hierarchy, Computer Systems Laboratory, Computer Science Center, Texas Instrument, 26 August 1991 2. OATH Reference Manual (OATH 0.8), 26 August 1991 3.1.6. NetComments _ _ _ ___________ 3.2. COOL - C++ Object Oriented Library _ _ ____ _ ______ ________ _______ + It is available from csc.ti.com (192.94.94.1) in file /pub/COOL.tar.Z. + COOL can be used with the AT&T C++ translator (cfront) version 2.0. + COOL is a collection of classes, templates, and macros for use by C++ programmers writing complex applica- tions. It raises the level of abstraction for the pro- grammer to concentrate on the problem domain, not on implementing base data structures, macros, and classes. + Information provided by Marco Pace (MPACE@ESOC.BITNET) 3.2.1. Introduction _ _ _ ____________ COOL is a collection of classes, templates, and macros for use by C++ programmers writing complex applications. It raises the level of abstraction for the programmer to con- centrate on the problem domain, not on implementing base data structures, macros, and classes. In addition, COOL also provides a system independent software platform on top of which applications are built, since COOL encapsulates such system specific functionality as date/time and exception handling. For a more detailed description of COOL and its features, including a thorough discussion on the rationale for the design and implementa- tion choices see [5]. 3.2.2. Features _ _ _ ________ The class library hierarchy is basically forest, but it implements a rather flat inheritance tree. All complex classes are derived from the Generic class due to space efficiency concerns. COOL does not seem to provide multiple inheritance. COOL's exception handling provides a reise, handle, and proceed mechanism. Exception and exception handling classes are provided for this purpose. COOL provides parameterized templates. The peculiarity of COOL is that to allow this it extends the standard C++ preprocessor to recognize the notation intro- duced to specify templates. In other words, the programs written using COOL are not com- piled using the standard CC, but using CCC (COOL C++ Control Program), which is an extension of the CC compiler. It does not seem to include garbage collection. 3.2.3. Subclasses _ _ _ __________ The classes provided by the library are several, and they are listed here: Pair <T1,T2> Range Range <Type> Rational Complex Generic String Gen_String Regexp Vector Vector <Type> Association <Pair<T1,T2>> List_Node List_Node <Type> List List <Type> Date_Time Timer Bit_Set Exception Warning Error System_Error Fatal System_Signal Verify_Error Excp_Handler Jump_Handler Hash_Table Set Hash_Table <Key,Value> Package Matrix Matrix <Type> Queue Queue <Type> Random Stack Stack <Type> Symbol Binary_Node Binary_Node <Type> Binary_Tree Binary_Tree <Type> AVL_Tree <Type> N_Node <Type> D_Node <Type> N_Tree <Type,Node,Child> 3.2.4. Evaluation _ _ _ __________ Easy to use, the services provided are really a lot. The extendibility has not been tested, although this seems to be one of the feature of the library, which issue is dealt with in part of section 14 of the User Manual (See Bibliography). Performance not evaluated It does not seem to be supported by the developers. The installation of COOL was a tragedy: several problems were found, ranging from files not found to compile errors to link errors, etc. After a couple of days of trials the installation was aban- doned, although a post was made to the net to see if some- body could help on that. I got some answers after some time and I found out that other people had similar installation problems. They sug- gested some solutions which I haven't tried yet. It is interesting to note that the authors of COOL have written a paper on which they analyse the lessons learned from the usage of the library, what they would keep of it and what they would change in its design, and so on (See Bibliogra- phy). 3.2.5. Bibliography _ _ _ ____________ M.Fontana et al., COOL - C++ Object-Oriented Library, Texas Instrument. COOL User Manual, March 1990, Texas Instruments Inc. M.Fontana & M.Neath, Checked Out and Long Overdue: Experi- ences in the Design of a C++ Class Library, Texas Instrument Inc. 3.2.6. NetComments _ _ _ ___________ From: bergquis@gdc.com (Brett Bergquist) Did you get the paper about COOL "Checked Out and Long Over- due: Experiences in the Design of a C++ Class Library". In this paper, the authors discuss the strengths and weaknesses of the design of COOL. A couple of points that they men- tioned that they would do differently would be to simplify the dependencies between classes by using MI. Also they would factor out the use of the symbolic and package mechan- ism. Performance is not mentioned as an issue. 3.3. LEDA - Library of Efficient Data types and Algorithms _ _ ____ _______ __ _________ ____ _____ ___ __________ + Writen by: Stefan Naeher (stefan@mpi-sb.mpg.de) Anonymous ftp from host ftp.cs.uni-sb.de (134.96.252.31) in directory pub/LEDA. + - LEDA can be used with all cfront and GNU C++ com- pilers - it is provided as source code - there is no fee for non-commercial use + It consists of a sizeable collection of data types and algorithm: this includes stacks, queues, lists, sets, dictionaries, ordered sequences, partitions, priority queues, directed, undirected, and planar graphs, lines, points, planes and basic algorithms in graph and net- work theory and computational geometry + Information provided by Stefan Naeher(stefan@mpi- sb.mpg.de) and MARCO PACE (MPACE@ESOC.BITNET) 3.3.1. Introduction _ _ _ ____________ 3.3.2. Features _ _ _ ________ LEDA is a library of efficient data types and algo- rithms. Its main features are: a sizable collection of data types and algorithms: this includes stacks, queues, lists, sets, dictionaries, ordered sequences, partitions, priority queues, directed, undirected, and planar graphs, lines, points, planes and basic algorithms in graph and network theory and computa- tional geometry; the precise and readable specification of data types and algorithms; the inclusion of many of the most recent and efficient implementations; a comfortable data type graph; its extendibility; its ease of use. The library employs a strict separation between abstract data types and the con- crete data structures used to implement them, parameterized data types, and object oriented programming. 3.3.3. Classes _ _ _ _______ The classes provided by the library are several, and they are listed here: Simple Data Types Boolean (bool) Real Numbers (real) Strings (string) Real-valued vectors (vector) Real-valued matrices (matrix) Basic Data Types One Dimensional Arrays (array) Two Dimensional Arrays (array2) Stacks (stack) Queues (queue) Bounded Stacks (b_stack) Bounded Queues (b_queue) Lists (list) Sets (set) Integer Sets (int_set) Partitions (partition) Dynamic collections of trees (tree_collection) Priority Queues and Dictionaries Priority Queues (priority_queue) Bounded Priority Queues (b_priority_queue) Dictionaries (dictionary) Dictionary Arrays (d_array) Hashing Arrays (h_array) Sorted Sequences (sortseq) Persistent Dictionaries (p_dictionary) Graphs and Related Data Types Graphs (graph) Undirected Graphs (ugraph) Planar Maps (planar_map) Parametrized Graphs (GRAPH) Parametrized Undirected Graphs (UGRAPH) Parametrized Planar Maps (PLANAR_MAP) Node and Edge Arrays (node_array, edge_array) Two Dimensional Node Arrays (node_matrix) Node and Edge Sets (node_set, edge_set) Node Partitions (node_partition) Node Priority Queues (node_pq) Two-Dimensional Geometry Two-Dimensional Dictionaries (d2_dictionary) Sets of Points (point_set) Sets of Intervals (interval_set) Sets of Parallel Segments (segment_set) Planar Subdivision (subdivision) Graphic Windows (window) 3.3.4. Evaluation _ _ _ __________ The class library hierarchy is a forest, and it does not seem to provide multiple inheritance. Some exception handling is provided, but it seems to be quite raw, in the sense that it usually ends with the program abortion. However, the user can write its own error handler, but its function prototype has to be void handler(int, char*) where the first parameter is an error number and the second is an error message. LEDA provides parameterized templates. It does not seem to include garbage collection. It is not clear whether it is supported in some way by the developers. The installation of LEDA was quite simple and took a couple of hours. One problem only was found dur- ing the execution of the makefile, namely some include files needed for the creation of the graphics library for Sunview (in which we were not interested). After this the test pro- grams were created without problems. The execution of the test programs was carried out, but no description of what they are supposed to do and/or what input they expected was found. A few of them run without problems, others issued error messages, others aborted after a core dump. The set of classes provided is quite large, the classes themselves are easy to use, the services provided sufficient (although sometimes the set is not "rich" enough), the interface simple when the user has gone through section 1 of the User Manual [4], which explains the basics. The extendibility has not been tested, although this seems to be one of the features of the library, on which issue a brief discussion appears in section IV of the manual (See Bibliography). After some time spent trying to format the documenta- tion (it is available only in TEX format), we managed to have it printed. The documentation appears to be linear, easy to read (as promised by the authors), concise. It does not contain, however, examples of the way the classes have to be used. 3.3.5. Bibliography _ _ _ ____________ S.Naeher, LEDA User Manual (Version 2.1), Max-Planck- Institut fuer Informatik, Saarbruecken 3.3.6. NetComments _ _ _ ___________