From: skdutta@ucs.att.com (Saumen Dutta)
Subject: C++ Product List - Version 2.04 - Part 4/8
Organization: AT&T Universal Card Services, Jacksonville FL
Date: Wed, 18 Nov 1992 02:27:10 GMT

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
_ _ _   ___________

Newsgroups: comp.lang.c++