OS/2 Shareware BBS: 10 Tools/10-Tools.zip/ledar34.zip/library.evaluations

Text File | 2002-01-24 | 71KB | 2,054 lines

Evaluation and Comparison of C++ Class Libraries (Draft)

                      Marco Pace

                     March 30, 1992


   Contents
   ========

Introduction

Evaluation Criteria

Environment

The Object-oriented Abstract Type Hierarchy (OATH)

  Introduction

  Requirements and Availability

  Evaluation

Library of Efficient Data types and Algorithms (LEDA)

  Introduction

  Requirements and Availability

  Evaluation

C++ Object Oriented Library (COOL)

  Introduction

  Requirements and Availability

  Evaluation

National Institute of Health Class Library (NIHCL)

  Introduction

  Requirements and Availability

  Evaluation

Comparison of the Evaluated Class Libraries

References

Appendix I - Collection of Answers Got from the Network

Appendix II - The Stack Exerciser

  The Stack Exerciser

    The Stack Exerciser - OATH version

    The Stack Exerciser - LEDA version


======================================================================


 Introduction

This document is an attempt to evaluate different available C++ class
libraries (to date only Public Domain (PD)/Shareware (SH) class
libraries have been evaluated) and to compare them.

The focus is on  base class libraries  (such as OATH, COOL, NIHCL, etc.)
and not on  UI libraries  (such as InterViews, StarViews, etc.).

The evaluation of the libraries is mainly a collection of impressions coming
from the practical experience of other people with the different class
libraries (and hopefully coming from an extensive usage of them) rather than
mainly a collection of impressions coming from a first-hand extensive usage of
the libraries themselves.  The reason for that is the limited time available
to carry out this investigation.

In fact, according to my opinion, it takes quite a long time to get a complete
"feeling" of the different and multifold aspects of each library, although a
"flavour" of it may be had in a shorter time.

The comments have been collected from the network after posting a request to
the newsgroup comp.lang.c++.

Some direct evaluation has been done, however, to a limited extent.

To-date this has consisted in the implementation of a simple program (the Stack
Exerciser) allowing to push, pop, etc. elements from a stack using the different
class libraries.

The overall evaluation work has consisted first in the definition of evaluation
criteria which seem of interest, then in the classification of each library
according to such criteria.

The comparison is simply a table containing a summary of the way the different
class libraries satisfy or not the criteria.

The following C++ class libraries have been evaluated:

OATH (Object-oriented Abstract Type Hierarchy)

COOL (C++ Object Oriented Library)

LEDA (Library of Efficient Data types and Algorithms)

NIHCL (National Institute of Health Class Library)

All of them are available on our system and have therefore been used directly.

More information on each of the libraries is presented in the relevant sections,
and a list of them is in document [10].

 Evaluation Criteria

The criteria defined are applicable to a class library in general or to its
component classes in particular.

The following have been defined:

  Documentation

The documentation of a class library is particularly important. It must be able
to convey in a clear and efficient way the basics that are needed to use the
classes in the proper way.

It should be concise enough and avoid non relevant details while focussing on
the fundamental aspects of the class being described (Appendix II, (1)).

In addition, it should be sufficient to allow use of the library in binary form
(Appendix II, (4)), i.e. it should not be necessary for the user to browse
through a class' implementation to understand how to use it.

I personally find examples important in the documentation since they provide
the user (especially the beginner) with a quick, effective and practical idea
of the way the classes have to be used.

  Usability

Under this term we mean several aspects which, although difficult to quantify,
are important, such as the set of classes provided, the easiness of use of a
class, the kind of the services provided, the simpleness and clarity of the
interface.

Of course, the more the interface is simple and clear the better.

  Extendibility

The extendibility of a class library means how easy it is to derive classes
avoiding at the same time problems such as name clashes, etc.

  Performance

Given a class, its performance could be computed according to certain criteria.

An idea could be to develop some benchmarking test programs exercising
selected services provided by the class.

For instance, given set, list, tree, graph, etc. classes the benchmarking
programs could check the time needed to insert, search, copy, etc. elements.

Other criteria other than time could be considered, though (main memory
occupation, for instance).

According to a post made to the newsgroup comp.lang.c++, Rogue Wave Software
sells a set of foundation classes (Tools.h++) including a timer class and a
benchmarking class.

It seems that the library already comes with some of the newer version of some
compilers.

Other similar PD classes might as well be available.

  Sensibleness

It is not easy to define precisely this evaluation criterium, but a tentative
definition of it could be the common sense with which the designers of the
class library have structured it and the kind of classes provided by the library
 (cf. also "Usability").

An example could be a class library providing a class for integers:

-- does it make sense to provide such a class when this basic data type is
already provided by the underlying programming language (C++) ?

Should not the library provide only higher-level classes which are not present
in the language (e.g. stacks, lists, etc.) ?

Our idea is that the class library should provide higher-level classes and not
necessarily classes redefining basic data types.

  Miscellaneous

Other aspects on which an evaluation could be based are the following:

-- is the class library hierarchy structure a tree or a forest ?

     It seems common opinion that to have a forest (i.e. a number of (possibly
     small) trees) is more useful than to have a (possibly big) tree (Appendix
     II, (1); (3.1)/COOL/remarks) and one of the reasons is that the mind is
     unable to grasp more that 3 or 4 levels in any useful manner ([9]).

-- does it provide single or multiple inheritance (MI)?

-- does it provide exception handling mechanisms ?

-- does it provide templates (parameterized types) or anonymous pointers to
   achieve genericity ?

-- does it include garbage collection (GC)?

  Others

In deciding which C++ class library to use, other criteria can be defined, such
as the following:

-- is it PD, shareware or commercial (do you have to pay for it, is it provided
   in source or object format) ?

-- if it is provided in source format, are there problems to compile it with the
   compiler I have ?

-- is the class library supported by the vendor/developer ?

Here the opinions vary, since some are inclined toward high quality commercial
support (Appendix II, (2)), some don't consider it to be a major issue provided
the library is in source format, so that it can be modified if necessary
(Appendix II, (3.2)).

Of course, without vendor/developer support you have to take into account the
risk of finding bugs you then have to fix yourself.

-- is it easy to install ?

-- is there a suite of tests to be run in order to make sure that no problems
   will occur when using the library ?

A criterium one could demand is to have at least one test case per method
(Appendix II, (4)).


There is something to add to the discussion made so far. The criteria defined
till now are somehow context-independent, in the sense that they are general
criteria against which a class library can be evaluated and found to be more
or less "desirable".

However, other criteria could be defined which are more context-dependent, and
could arise from particular needs related to the kind of application that has
to use the class library, in our case SCOSII.

The definition of such criteria is not included in the scope of this document,
but ought to be considered when making the final decision on which library
(libraries) to use.

 Environment

The different libraries have been installed on atos0.

The tests have been carried out on atos1, running SunOS 4.1.1 using the AT&T
C++ compiler version 2.1.

********
* OATH *
********

 The Object-oriented Abstract Type Hierarchy (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 were the main design goals of OATH:

-- 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 subtyping (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
   combined.

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++ reference).

The accessors can be initialized and assigned OATH objects to access. However,
any other operation on an accessor is applied directly to the abstract object
it accesses.

The class hierarchy provided by OATH is the following:

obj
  pos
     pdPos
    listPos
       dlPos
      stringPos
         minStringPos
  bag
    set
       hashSet
      finiteSet
        characterSet
    queue
      seq
        lifoQueue
           pdList
        fifoQueue
          deq
            list
               dlList
              string
                 minString
                plist
        ring
          grid
    table
        stringTable
    capsule
  token
      character
      localToken
      stringToken
  complex
     doubleComplex
     bigComplex
    real
       doubleReal
       bigReal
      rational
         longRational
         bigRational
          integer
             longInteger
             bigInteger

where the items in normal fonts are  abstract types , the ones in italics are
abstract implementation types , the ones in bold are implementation types
(a visually more readable version of this hierarchy can be found in
[1], Figure 1.)

OATH does not provide:

parameterized types (templates)

For a more detailed description of OATH and its features, including a
thorough discussion on the rationale for the design and implementation
choices see [1].

 Requirements and Availability

OATH has been developed by Brian M. Kennedy, Computer Systems Laboratory,
Computer Science Center, Texas Instrument.

The Reference Manual states it has only been compiled with AT&T cfront 2.1
compatible compilers.

To compile with AT&T cfront 2.0 based compilers the source code has to be
modified.

OATH is available via anonymous ftp from site csc.ti.com (192.94.94.1)
in the file /pub/oath.tar.Z.

 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.

  Extendibility

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).

  Performance

Not evaluated.

  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.

  Other

OATH is a public domain C++ class library, and it is provided in source format.

It seems to be experimental. It does not seem to be supported at all.

The installation is quite easy, just follow the instructions in the README file.

The total time needed to install OATH on atos1 was 4 hours, but this was due to
a couple of problems not related to the installation itself; 1.5-2 hours would
probably be enough in the majority of the cases (including a coffee pause).

No problems to compile it using the compiler available.

*********
* LEDA  *
*********

 Library of Efficient Data types and Algorithms (LEDA)

 Introduction

LEDA is a library of efficient data types and algorithms. 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 computational 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 concrete data
   structures used to implement them,

-- parameterized data types, and

-- object oriented programming.

The implementation language of LEDA is C++.

For a more detailed description of LEDA and its features see [3].

 Requirements and Availability

The library can be used under UNIX with the C++ compilers AT&T cfront 2.0,
cfront 2.1 and GNU g++ (version 1.37).

It is available from its authors for a handling charge of DM 100.

The copy we have has been got via anonymous ftp from the host
          ftp.th-darmstadt.de
where it is in directory
          pub/languages/C++
in the files
          LEDA-2.1.1.tar.Z and LEDA.README.

 Evaluation

  Documentation

After some time spent trying to format the documentation (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.

  Usability

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.

  Extendibility

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 [3].

  Performance

Not evaluated.

  Sensibleness

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)

  Miscellaneous

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.

  Other

LEDA is a shareware library, in the sense that you should pay a fee to use it,
and is provided in object format only.

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 during 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 programs 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.


********
* COOL *
********

 C++ Object Oriented Library (COOL)

 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 concentrate 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 implementation choices see [5].

 Requirements and Availability

COOL can be used with the AT&T C++ translator (cfront) version 2.0.

It is available from csc.ti.com (192.94.94.1) in file /pub/COOL.tar.Z.

 Evaluation

  Documentation

The documentation appears to be linear, easy to read, concise, accurately cared
for.

It also contains, basically for every class, examples of the way the classes
have to be used.

A glossary is also provided.

  Usability

The set of classes provided is wide, the classes themselves look easy to use,
the services provided are really a lot.

Although available in-house, I didn't manage to install COOL on my machine, so
the evaluation just collects impressions since no practical use of the classes
has been possible.

  Extendibility

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 [6].

  Performance

Not evaluated.

  Sensibleness

The classes provided by the library are several, and they are listed here:

Pair
Range
  Range
Rational
Complex
Generic
  String
  Gen_String
  Regexp
  Vector
    Vector
      Association >
  List_Node
    List_Node
  List
    List
  Date_Time
  Timer
  Bit_Set
  Exception
    Warning
    Error
      System_Error
    Fatal
    System_Signal
    Verify_Error
  Excp_Handler
    Jump_Handler
  Hash_Table
    Set
    Hash_Table
      Package
  Matrix
    Matrix
  Queue
    Queue
  Random
  Stack
    Stack
  Symbol
  Binary_Node
    Binary_Node
  Binary_Tree
    Binary_Tree
      AVL_Tree
  N_Node
  D_Node
  N_Tree

  Miscellaneous

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
introduced to specify templates.

In other words, the programs written using COOL are not compiled 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.

  Other

COOL is PD, provided in source format.

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 abandoned, although a
post was made to the net to see if somebody could help on that.

I got some answers after some time and I found out that other people had
similar installation problems. They suggested 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 ([7]).


*********
* NIHCL *
*********

 National Institute of Health Class Library (NIHCL)

 Introduction

NICHL (pronounced either N-I-H-C-L or "nickel") implements abstract data types
that have been designed to simplify object-oriented programming using C++. It
contains generally useful data types, such as String, Date, and Time, and it
provides a set of classes similar to the Smalltalk 80 collection classes
including OrderedCltn (indexed arrays), LinkedList (singly linked lists),
Set (hash tables), and Dictionary (associative arrays).

Classes Process, Scheduler, Semaphore, and SharedQueue implement multi-
programming with coroutines.

The set of Vector classes and a handful of others such as Random (random number
generator) and Range (range of integers) assist in various kinds of arithmetic
and mathematical problems.

NIHCL includes an object I/O facility in its class implementation which can
make program- and machine-independent representations of arbitrarily complex
data structures comprising NIH Library and user-defined objects.

Client applications can then save these representations on disk files or move
them between programs running on the same or different (via network) machines.

For a more detailed description of NIHCL and its features see [8].

 Requirements and Availability

The NIH Class Library is intended to be portable to a UNIX system compatible
with either System V or 4.2/4.3BSD and which supports the AT&T C++ translator
Release 2.00, Release 2.1, or other compatible C++ compiler.

The library has been tested by the authors on Sun-3 with SunOS 3.5,
Sun-3 with SunOS 4.0 and on Sun-4 with sunOS 4.0.

It is via anonymous ftp from alw.nih.gov (198.231.128.251) in file
pub/nihcl.tar.Z.

 Evaluation

  Documentation

NIHCL is documented in [8], which is a book in data abstraction and object
oriented programming in C++ within whose framework the class library is
described.

Therefore the documentation has not the form of a reference manual, but it
provides a short description of the different classes with some examples.

This approach has the drawback that when you are developing code and you already
have some knowledge of the library you would probably use more profitably a real
reference manual.

  Usability

Not evaluated.

  Extendibility

This feature was not evaluated directly. However, chapter "Designing Library
Classes" of [8] is devoted to the way to extend the class library writing
user-defined classes.

  Performance

Not evaluated.

  Sensibleness

The classes provided by the library are several, and they are listed here:

NIHCL
  Object
    Bitset
    Class
    Collection
      Arraychar
      ArrayOb
      Bag
      SeqCltn
        Heap
        LinkedList
        OrderedCltn
          SortedCltn
            KeySortCltn
        Stack
      Set
        Dictionary
          IdentDict
        IdentSet
    Date
    FDSet
    Float
    Fraction
    Integer
    Iterator
    Link
      LinkOb
      Process
        HeapProc
        StackProc
    LookupKey
      Assoc
      AssocInt
    Nil
    Point
    Random
    Range
    Rectangle
    Scheduler
    Semaphore
    SharedQueue
    String
      Regex
    Time
    Vector
      BitVec
      ByteVec
      ShortVec
      IntVec
      LongVec
      FloatVec
              DoubleVec
  OIOifd
  OIOin
    OIOistream
      OIOninhin
  OIOofd
  OIOout
    OIOostream
      OIOninhout
  ReadFromTbl
  StoreOnTbl

Note that, in addition to the normal general-purpose classes that are found in
other libraries as well you find a semaphore class, I/O classes, a process class
and a scheduler class.

  Miscellaneous

The hierarchy provided by NIHCL is that of a tree.

Multiple inheritance is optionally supported (i.e. NIHCL can be compiled to
support multiple inheritance if desired).

No parameterized types (templates) are provided, although they can be
implemented using macros (as [8] suggests in section "Parameterized types in
the NIH class library").

An experimental exception handling mechanism is provided by NIHCL, although the
authors of the library suggest not to use it since it is unsafe and inefficient.

Garbage collection is not implemented.

  Other

NIHCL is a public domain C++ class library, provided in source format.

No idea whether it is supported or not.

The installation step was not carried out by me (the library had already been
installed on atos0), so I cannot say whether problems occurred during the
installation.




 Comparison of the evaluated class libraries

The comparison of the class libraries evaluated so far is simply a
table containing the different evaluation criteria.

              OATH               LEDA             COOL             NIHCL
-------------------------------------------------------------------------------
Author        B.M.Kennedy        K.Mehlhom        M.Fontana        Several
              (TI Inc.)          S.Naeher         (TI Inc.)        (NIH)
Type          PD                 SH               PD               PD
Format        Source             Object           Source           Source
Supported     No                 ?                No (?)           ?
Installation  Easy               Easy             Problematic      N/E
Compiler      AT&T 2.1           AT&T 2.1         AT&T 2.0         AT&T 1.2
                                 AT&T 2.0                          AT&T 2.0
Doc           Poor               Fair             Good             Fair
Usability     Fair               Good             Good             N/E
Extendibility Possible           Possible         Possible         Possible
Performance   N/E                N/E              N/E              N/E
Hierarchy     Tree               Forest           Forest           Tree
                                                  (flat tree)
Mult.Inherit. No                 No               No               Optional
Paramet.Types No                 Yes              Yes              No
Exc.Handling  No                 Yes (raw)        Yes              Yes (raw)
Garb.Collec.  Yes                No               No               No

where PD = Public Domain
      SH = SHareware
      N/E = Not Evaluated



 References

[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] K.Mehlhorn & S.Naeher,
      LEDA - A Library of Efficient Data Types and Algorithms

[4] S.Naeher,
      LEDA User Manual (Version 2.1),
        Max-Planck-Institut fuer Informatik, Saarbruecken

[5] M.Fontana et al.,
      COOL - C++ Object-Oriented Library,
        Texas Instrument.

[6] COOL User Manual,
      March 1990, Texas Instruments Inc.

[7] M.Fontana & M.Neath,
      Checked Out and Long Overdue: Experiences in the Design of a C++
        Class Library, Texas Instrument Inc.

[8] K.E.Gorlen et al.,
      Data Abstraction and Object-Oriented Programming in C++,
        1990, Wiley

[9] N.Head, SCOS II WN 10:
      Policy issues for the use and development of Class libraries, Issue 1,
        November 1991

[10] Jean-Christophe Collet (Axis Design),
       C++ Products and Books List,
         August 1991





Appendix I - Collection of Answers Got from the Network


##############################################################################
(1)
From: [e-mail] (Jean-Christophe Collet)

Anyway, I did a lot of work with InterViews and I had a look to NihLib.
I Highly recommend InterViews 3.0 but found NihLib rather unusable (it's
a very big tree while we need more often a lot of small trees).

One very, VERY, important criteria of a class library is its documentation.
A very good library without a proper documentation is very hard to use
(if not useless). There is no need for the documentation to be thick and
verbose but it should gives all the info you need to use the class.

Then, there is reuse... (ako "how easy is it to derive a class ?")

InterViews is a VERY good example of a good library with appropriate doc.
##############################################################################
(2)
From: fig.citib.com![e-mail] (Kevin P. Tyson)

I am in the process of reviewing/selecting C++ class libraries for our shop.
We have reviewed two todate.  The Booch Components and Tools.h++.  We started
out by deciding, loosely, what our requirements are.  They major ones boil
down to:

(1) High quality commercial support is very important to us.
(2) Support for multi-threaded programming is only slightly less important.
(3) Sophsiticated and extensible memory management support is our third
    requirement.

We are a DCE/ENCINA shop and this is what has driven our requirements.  We do
distributed transaction processing based applications.  Someone who does
scientific programming will have different requirements and someone working on
parallel processors will have their own requirements.

The next libraries we intend to examine are COOL and the USL C++ Components
library.  So far Booch meet the three requirements listed above but was much
too low level and lacked good documentation.  Tools.h++ could be extended to
meet our thread safe and memory management requirements, but that would have
made support difficult as it would require modifying their source code.

##############################################################################
(3)
From: [e-mail] (Scott Silvey)

Well, here is a summary of the responses I got from people concerning my
question about public domain C++ libraries.  Mr Chuck Noren is a big
NIHCL fan, but he appears to be the only one who is really familiar with
one of the libraries I asked about.  There is some very helpful infomation
in these letters, so if you are considering one of the public domain
library packages, I suggest you read on...  Surely though, there must be
some other people out there with opinions they'd like to voice?  You know,
for the benefit of the naive neophyte masses out there hungering for
information about C++ and free software?

Thank you very much to everyone who responded, I really appreciate your time
and helpfulness!

Scott Silvey,
[e-mail]


Long posting follows:

*******************************************************************************
(3.1)
% From: [e-mail] (Brett Bergquist)

Did you get the paper about COOL

"Checked Out and Long Overdue:
    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 mentioned 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 mechanism.

Performance is not mentioned as an issue.

*******************************************************************************
(3.2)
% From: Chuck Noren

I have been a big user of NIHCL.  Its not the most elegant library, but there
are some big advantages in using it.

With any PD library, such as COOL (I have not looked at it), you will find
warts and major flaws.  I have found this with NIHCL.  However, what I did
find was that I could get major parts of the project going sooner than if I
had to develop a class library myself.

The "buyer" must beware on any of this stuff, for there will be hidden costs.

The first is some bugs in the library without vendor support.  You might get
some support from USENET, but if you really start using these packages you
will find that you have become one of the "experts".  You will need to develop
your in house expertise with some enthusiastic "hackers" who love to play with
these kind of things and track down bugs as they are found.  I've been an
enthusiastic hacker of NIHCL for our group and modified it to work with the
Object Oriented Database (ObjectStore from Object Design, Inc.).

Personally, I would consider buying a class library (such as the Booch
Componants) before getting a free copy of a class library from a private
company (NIHCL is from the U.S. Govt).  I take a cynical (and possibly wrong)
view of this.  If a private company has a REALLY GOOD class library, they may
be hesistant to make it freely available, because it becomes something they
could sell or use as a competetive advantage against other companies.  While
we have just made our version of NIHCL Public Domain, we have kept back the
really good classes we've developed so that our company can compete better
against others. (I would personally rather share more software for sharing
really benifits everybody, but I was lucky to convince my company just to let
our modified NIHCL go, because we would not get anyone to buy it and others
will have modified their copy's of NIHCL soon to work with an OODBMS anyway).

The Booch componants cost well less than $1000 (and you get source plus the
reputation of a company behind it) and will save thousands in development time.

Even NIHCL is worth considering.  From experience, its not as slow as some
people make out.  It does go against the "C++ philosophy" in some respects,
but it does have some advantages that fit well in some projects.

I feel that no current library will address all the needs off all applications.
Certainly NIHCL does not (and COOL, although I have not seen it).  But some
projects will fit well with the various libraries (ours fit with NIHCL very
well).

But also be forwarned, getting a class library is like getting a new language,
there is one hell of a learning curving, but it is well worth it.

*******************************************************************************
(3.3)
% From: [e-mail]


In article , you write:
|>   Now, has anyone actually used COOL and would you have any idea why the
|>   authors expressed reservations about it's quality?  How does it compare
|>   with other public domain libraries?  Are there any good ones out there
|>   that you would like to boast about?

I have not used COOL (yet). As a matter of fact, I have not yet actively
used any of the libaries mentioned below, but here goes anyway...

 COOL
 ====

   advantages
   ----------
   - uses templates
   - uses exceptions

   disadvantages
   -------------
   - COOL templates are not 100% ARM conformant
   - no garbage collection support at all
   - common root class (Smalltalk)
   - COOL uses an exception implementation which is not even close
     to the ARM

   remarks
   -------
   - I have not yet tried to compile it with DEC C++ v1.0.
   - I think that the main objection the COOL authors have against
     it, is that they feel that their class hierarchy is not optimal.
     (Almost) all COOL classes either directly or indirectly inherit
     from a common root class called Generic. In their documentation,
     the authors state that if they were to redo it, they would rather
     go for a forest of base classes.


 NIH
 ===

   advantages
   ----------
   - used in many applications, and therefor thoroughly tested

   disadvantages
   -------------
   - no garbage collection support at all
   - no templates
   - no exceptions
   - common root class (Smalltalk)

   remarks
   -------
   - I have not yet tried to compile it with DEC C++ v1.0.


 LEDA
 ====

   advantages
   ----------
   - well designed set of data types
   - looks as if it should be very efficient
   - uses some template-like construct

   disadvantages
   -------------
   - no exceptions
   - LEDA `templates' are not even close to the ARM
   - use is restricted to "research and education"
   - use is not for free (but it's cheap)
   - I cannot possibly get it to compile with DEC C++ v1.0


 OATH
 ====

   advantages
   ----------
   - garbage collection comes "for free"
   - focuses on a how to implement classes, instead of on yet another set
     of classes

   disadvantages
   -------------
   - common root class (Smalltalk)
   - no templates
   - no exceptions
   - garbage collection comes "for free"
   - nobody can possibly get it to compile with DEC C++ v1.0
     without major modifications

*******************************************************************************
(3.4)
% From: Chuck Noren

> What would you consider are NIHCL's strengths?  Perhaps a full,
> coherent system of objects?  Relatively stable and bug-free?
> Somewhat standardized because many people use it?  How is it's
> support for things like graphics and mathematics?

NIHCL's strengths:

 1.  Provides a coherent system of objects (I like your words).
     There are collections, date/time classes, variety of
     scaler types, string classes, and light-weight processing.
     Almost all the classes work interchangeably in the various
     collections, such as sets, bags, dictionaries.  You can use
     a string as an key to a dictionary, as well as time, date, even
     another collection.

 2.  It is relatively bug free and stable.  We have encountered
     very few bugs, and most of them dealt with bugs in the
     particular C++ compiler we were using.

 3.  A fair number of people are using it.  You can appeal to the
     Internet and get timely help on questions and problems.
     Keith Gorlen himself (one of the authors of NIHCL) will
     assist time to time.

 4.  Run time type identification.  While this is not always
     useful or even advantageous to use, there are certain
     times when run time type identification greatly simplifies
     the design and use of certain capabilities.  One of these
     is being able to send heterogenious Inter-Process
     Communication objects.  Sometimes applications need
     truely dynamic objects at run time (e.g., in some database
     applications or applications where the operator needs
     to manipulate and create lots of very flexible objects).
     [soap box: this feature would be useful in the C++ language
      itself, in certain very limited situations, but one reason
      it is not included is that programmers would be tempted to
      abuse it.  I feel that the philosophy of C and C++ is to give
      you the power and you are responsible to learn how to use it
      right.]

 5.  "Safe" virtual base castdowns.  These classes can be used
     in a multiple inheritence design (again, this has limited
     use in good designs, but when you need it, its very useful!).
     There is a consistent set of member functions that allow you
     to safely castdown from a virtual base class pointer to a
     derived class pointer.  Normally you want to use the virtual
     member function mechanism, but in certain limited situations
     (e.g., where you are forced to use heterogenous collections)
     this can be very useful.


 6.  Support for shallow and deep copies.  If you follow the
     discipline of NIHCL classes, your objects will be able
     to de shallow and deep copies of itself and all of its
     member pointers.  Previously copied objects will be handled
     "automatically".

 7.  Stream and file I/O.  You can use the NIHCL I/O features
     to make a "poor man's database".  If you follow the NIHCL
     discipline, all your objects can be written to a flat file
     (and read in) very easily.  You can also send your objects
     via Inter-Process Communcation (IPC) very easily.  All you
     have to do is create a simple IPC mechanism.

 8.  A variety of polymorphic heterogenous collections.

 9.  Good documentation.  First, understand that there is never
     enough documentation in any package!  But given this, Gorlen
     and company have published a book and have a good
     reference manual on the class library.

10.  Complete source code.

11.  Portable code.  It can be built on a wide variety of systems
     with a wide variety of C++ compilers.

12.  No copyright or license (but beware of Regex).  All of the
     NIHCL library is public domain except Regex.  There is some
     controversy about Regex (since it has the GNU Copyleft
     agreement).  Some, like myself believe the simple removal
     of Regex gets around the Copyleft problem.  Others say
     that is not enough.  Check your legal counsel to be sure.

There are some disadvantages to NIHCL, to be sure.  However there
has been a lot of NIHCL bashing around.  As I stated, no class
library is a perfect fit for every application and care should
be taken not to force fit a class library into an application
not well suited for it.  Some disadvantages of NIHCL include:

 1.  Name clashes with existing libraries.  Names like "Object",
     and "String" are used in other places (such as X-Windows and
     Motif).  We had to modify our copy of NIHCL so that the
     classes were prepended with the letters "Nih", so Object and
     String, for instance, became NihObject and NihString.  This
     eliminated the clash.  There was a close call with the typedef
     of bool in NIHCL, since X-Windows/Motif have a Bool, but
     fortunatly the case is different.  New class libraries
     should consider how they can minimize name clashes.

 2.  The polomorphic single class hierarchy style of classes evades
     compile time type checking.  This means your bugs are caught
     more often in run time than if you had a library which used the
     derived classes more often.  This is a trade-off.  The single
     class hierarchy provides a number of advantages, but at a cost.

 3.  A class ultimately derived from the NIHCL Object class
     (which is every class) cannot be defined as a template
     class.  This does not prevent you from having its member
     be intances of template classes (which we have done a number
     of times).  There are many reasons this cannot be done,
     part of which is the dynamic run time type identification
     mechanism.  Again, there is a trade-off.

 4.  There are some single-theaded (non-reentrant) sections of
     code (such as in the deep copy mechanism).  This is something
     to watch for in any class library.

 5.  The NIHCL discipline.  Many people think of NIHCL as hard to
     work with and hard to learn.  This is in part due to the
     things you must do in creating a class to work inside the
     NIHCL framework.  However, the discipline is not that difficult,
     and following it pays off with NIHCL's advantages.

 6.  Some execution inefficiencies.  Due to the polymorhic, single
     inheretence style of NIHCL, some things are done that other
     class libraries would avoid (such as castdown and checking
     an object's type before proceeding to do what you want in
     some of the code).  This does cost some execution overhead, but
     we found for us that the library is fast enough).  Again, these
     are tradeoff issues.

*******************************************************************************
(3.5)
% From: Chuck Noren

I forgot to answer a couple of questions...

 You also asked if NIHCL provided good graphics support and math support.
 The answer is no on both counts.  We evaluated InterViews over a year ago
 and rejected it (because we were familiar with X-Windows and want to hack
 it directly).  NIHCL does provide some vector classes which we have not
 looked at because I could not get them to build with an older version of
 our compiler.  NIHCL doesn't have any math matrix classes and some of the
 other useful mathematics classes.

*******************************************************************************
(3.6)
% From: [e-mail]

Hello,

First of all, let me start by giving you a bit of background information
on what my organisation is (and intends to be) doing. This will allow you
to read my answers to your questions in the correct context.

 IMEC is a research institute focusing on the (automation of the) design
 of VLSI chips. Part of the support we offer to the people who are doing
 research into the area of high level synthesis, currently consists of a
 C++ libary, written on top of NIH. At the moment, this libary is being
 redesigned from scratch (for various reasons), and this is where I (as
 a software expert) enter the picture. I should also add that we have to
 be able to distribute source code which ideally should run on different
 types of hardware. As you can see, using commercial class libraries is
 somewhat out of the question (although that may change).

 So, one of the many things I am doing now, is to investigate what C++
 libaries are available to build upon, and whether they at least partially
 fit our needs. My problem is that, although I do have some experience with
 OO, I have never used C++ for "real applications", so my current knowledge
 of C++ is limited (but growing rapidly).


Having said all that, here is what you are really after :

> How is it the various libraries won't with with DEC's C++?  Are they non
> standard C++ or do they just not comply with C++ 3.0?  How do you know
> that they do not work with DEC C++?

To my knowledge, DEC C++ v1.0 is *very* ARM compliant, while most other
C++ compilers are not. This is one of the reasons why we are switching
to the DEC compiler. Here is a list of what we have tried to compile
with it until now :

 - InterViews
 - LEDA
 - OATH
 - SPOOK (don't ask)
 - some of our own tools

Basically, in all cases we have discovered things which are not allowed
by the ARM, but somehow did compile on previous compilers (g++ as well as
various derivatives of cfront 2.0 and 2.1). Some of these were easy to fix,
but some weren't. As a matter of fact, the SPOOK tool set is the only thing
in the above list which, after modification, did make it all the way to
executable code.


> Are these notes impressions that you've gotten from people who have used
> these various libraries?

That depends on what libary we are talking about, so let's make a list :

 NIH  : As I have said, this has been used in the previous version of
        our Synthesis Backbone. In addition, I picked up some info on
        comp.lang.c++.

 COOL : This has not been used at our site, but I have received some
        info from other people (isn't usenet great?). I also looked at
        the manual.

 LEDA : I have looked at the manual, and have actually tried to compile
        it with DEC C++ v1.0.

 OATH : I have looked at the manual, and have actually tried to compile
        it with DEC C++ v1.0.


> Do you intend to get involved with one of these packages in the future?

I guess I've already answered this in my introduction.


> Does this mean that you've tried to get it to work with cxx but it
> won't compile?  Or do you just know that it won't work becuase it uses
> non standard C++?

This question was about LEDA, so here are the gory details of what happened :

 1: When compiling LEDA in its pure form, the compiler threw lots of
    warning and error messages at me.

 2: I was able to solve most (but not yet all) of these, but now each
    compilation ends with the following message (provided that it does
    not report syntax errors) :

     11, fatal: A bugcheck occurred in the compiler.

    This is true even for the smallest of files, so I suspect there
    must be some very ugly stuff in the header files, but I have
    no idea what this might be.

    Because of this, I just gave up. So I can't tell you whether the
    remaining syntax errors are solvable or not.


While I'm at it, allow me to elaborate a little bit on my statement
about compiling OATH with DEC C++ v1.0. The first time round, the
compiler flagged lots of errors. I was able to solve this, but than
I ran into an illegal downcast upon which, unfortunately, a large part
of the OATH library depends. This is why I said that major changes to
the code would be needed. However, after sending my mail, I realized
that there is a small possibility that this second problem (although
present in the code from the beginning) was actually activated by the
changes I made. So it looks like I will have to try again.

##############################################################################
(4)
From: [e-mail]
Subject: Summary - Class Libraries

In article <[e-mail]> I wrote:
>I'd like to know what libraries for C++ are available both
>commercially and public domain.  If possible, an opinion of
>the library would be nice.
>

This is a summary of the responses to my query.  Each library name
has a tag field called "Name:" for easy extraction.  This response is
sectioned into Public Domain and Commercial/Private domain.  Any
library whose domain was unknown has been placed in the Commercial/Private
domain.

The following class libraries are mentioned in this summary:-

Name: OATH (Object-oriented Abstract Type Hierarchy)
Name: COOL (C++ Object-Oriented Library)
Name: NIHCL (National Institute of Health's C++ Library)
Name: libg++ (GNU's C++ library)
Name: InterViews
Name: Unidraw
Name: ET++
Name: Classix
Name: NIHCL
Name: Linpack.h++
Name: Matrix.h++
Name: LEDA (Part 1)
Name: LEDA (Part 2)
Name: USL (UNIX System Laboratories Europe Ltd.)
Name: Rational
Name: Booch Components
Name: Open Dialogue
Name: Zinc Interface Library (Iconic user interface)
Name: C++/Views (Iconic user interface)
Name: MacApp (application development toolkit)
Name: ICpak101
Name: ICpak201
Name: NeXTStep (application development toolkit)
Name: CommonView (Iconic user interface)
Name: Analyst (Information Centre)
Name: Humble  (Expert system package)

When choosing a library, perhaps the following should be used as a
guideline to the library's "goodness":-

        1) Demand at least one test case per method
        2) Documentation should be sufficient to allow use in binary
        form.
        3) All "improvements" should be sent to supplier for
        integration into standard product (gets rid of maintenance :-)
        4) Cloning is not reusing.


Public Domain Libraries
~~~~~~~~~~~~~~~~~~~~~~~

Name: OATH (Object-oriented Abstract Type Hierarchy) was designed
as an experiment in increasing object-oriented reuse.
It has a fairly high learning curve, but potentially
higher gains if you are looking for a more flexible and
robust abstraction.  It is completely unsupported.

        anonymous ftp from csc.ti.com (192.94.94.1)
        in the file pub/oath.tar.Z
---------------------------------------------------------

Name: COOL (C++ Object-Oriented Library) was designed as an
experiment in templates and exception handling.  Templates
are implemented via a preprocessor with an advanced macro
capability.  It displays a different set of trade-offs
from OATH.  It is also completely unsupported.

        anonymous ftp from csc.ti.com (192.94.94.1)
        in the file pub/COOL.tar.Z
---------------------------------------------------------

Name: NIHCL (National Institute of Health's C++ Library) is
essentially a mapping of part of Smalltalk's library
into C++.  It lies somewhere between OATH and COOL.
It is a little better supported and there is a textbook
by the author, Keith Gorlen, that is fairly good documentation.
However, the Smalltalk hierarchy is not completely
consistent (IMO) with the C++ strong typing nature.
It is weakly supported.

        anonymous ftp from alw.nih.gov (198.231.128.251)
        in the file pub/nihcl.tar.Z
---------------------------------------------------------

Name: libg++ (GNU's C++ library) is probably only relevant if
you are using g++; and if so, you already know about it.
It does have some good implementations of bignum's and
of regular expressions and strings.

        anonymous ftp from aeneas.mit.edu (18.71.0.38)
        in pub/gnu/libg++-*
---------------------------------------------------------

Name: InterViews is an excellent GUI class library (IMO, the best)
developed by Stanford University.  Make sure you get v3.0 or
later (it is significantly improved from 2.6).  V3.1 should
be out in March, basically rounding out and solidifying the
3.0 approach.  This library contains excellent examples of
multiple inheritance used profitably.

        anonymous ftp from interviews.stanford.edu
---------------------------------------------------------

Name: Unidraw is a graphical editor building library based on top
of Unidraw.  I would suggest waiting to V3.1's release.

        anonymous ftp from interviews.stanford.edu
---------------------------------------------------------

Name: ET++ is a large GUI library and other C++ tools developed
in Europe

        anonymous ftp from apple.com
        in pub/ArchiveVol2/et++/*

        or nuri.inria.fr
        in gnu/et++-2.0.tar.Z
---------------------------------------------------------


Name: Classix

In addition to Rogue Wave, Empathy offers a good general-purpose
library called Classix.

----------------------------

Name: NIHCL

If you really want Public Domain, there is NIHCL, which is public domain
in the US, and apparently outside as well. Here's some information; if
no one mails you ftp directions for it, let me know and I'll see what I
can find.

------------------------------------

Commercial/Private Libraries
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Name: Linpack.h++
Name: Matrix.h++

  N E W    P R O D U C T    R E L E A S E

   C++ Version of Linpack Announced

Rogue Wave Software, Inc., November 1, 1991.  Rogue Wave Software,
Inc. announces today that it has started shipping two new C++ class
libraries, Matrix.h++ and Linpack.h++.  These new C++ class libraries
extend the C++ language to include numerical algorithms that were
previously available only in Fortran.

Linpack.h++ is an object-oriented C++ version of the widely used Fortran
library.  Linpack.h++ includes 100% of the functionality of the Fortran
version, plus much more.  Because Linpack.h++ is written in C++ it has
capabilities that far exceed the Fortran version.

C++'s unique position as an extensible object-oriented language that is
extremely efficient makes it one of the best languages for solving
complex  numerical problems.  Rogue Wave's new libraries take full
advantage of C++'s strengths:  operator overloading, object-orientation,
and speed.  Programmer productivity is boosted because you work with
whole objects that represent numerical data rather than low-level "DO"
loops.  The result is fewer, but more expressive, lines of code.  But,
because these libraries are based on highly-optimized low-level assembly
routines, they are extremely fast, frequently faster than the equivalent
Fortran.

Dr. Thomas Keffer, President of Rogue Wave Software, Inc. says
"Matrix.h++ and Linpack.h++ both represent major milestones for the
C++ and numerical communities.  Engineers, scientists, and financial
analysts now have the C++ tools needed to make their job easy.  The lack
of these tools has kept them chained to Fortran."

Charlie Finan of CRAY Research had this to say of Linpack.h++:
"Looks like you wrote the classes just the way I would...and my job is to
write fast code!  You did it right!"

Both Matrix.h++ and Linpack.h++ are completely compatible with Rogue
Wave's other C++ class libraries, Tools.h++ and Math.h++, which are
accepted standards in the industry.  Matrix.h++ and Linpack.h++ are
available for most machines, from MS-DOS to UNIX, including a
vectorized version for the CRAY.

Matrix.h++ includes all the funtionality of Math.h++.  For example:
general matrices, vectors, statistics, complex numbers, Fast Forier
Transformation (FFT's), etc.  Matrix.h++ adds specialized matrix classes
such as banded, symmetric, positive-definite, Hermitian, tridiagonal, etc.
Because Matrix.h++ includes Math.h++, it can take advantage of
Math.h++'s highly optimized low-level assembly routines, making it fast
as well as graceful.

Linpack.h++ is the jewel of C++ math classes.  Linpack.h++ includes all
of Matrix.h++, plus all of the functionality in the original and well-
established Fortran version; including solutions of systems of equations
for a variety of matrix types, solutions of over- and under-determined
systems of equations, incremental least squares solvers, etc.  But,
Linpack.h++ is a tru object-oriented library, not just a C version that
compiles under C++:  the traditional messiness of the Fortran version has
been replaced with high-level, yet efficient, objects that make code far
easier to write and maintain.

The classes are available now.  Prices range from $199 to $995 for
Matrix.h++ and $299 to $1195 for Linpack.h++.

Rogue Wave Software Inc. is a software company that develops and sells
high quality C++ class libraries.  Its customers include end users and C++
compiler manufacturers such as Borland, JPI, Oregon Software, Liant
Software, and others.  Rogue Wave Software Inc. is located at 1325 NW
9th Street, Corvallis, OR, 97330, [phone].

---------------------------------------

Name: LEDA (Part 1)

There is LEDA, Library of Efficient Datatypes and Algorithms, by Stefan
N"aher from Germany. It is available for educational purposes but its NOT in
the public domain.

Provides basic data-types like lists, stacks, queues, trees, sets,
partitions, priority queues and a few others. These are parameterizable
classes, you may add your own datatype and have a priority queue ...
An important datatype is a graph, these are also parameterizable and there
are useful algorithms for them like shortest path, transitive closure,
matching, maximum flow, spanning tree and others, we have implemented a few
algorithms for dealing with perfect graphs, but these ar not part of the
standard library.
The latest part deals with computational geometry, as we are a graph theory
group I have not looked at that part yet.

Opinion : very useful, has saved me a lot of work when messing around with
basic datastructures and simplifies notation quite a bit. It provides
exactly those things which you would need, but do not have the time to mess
around with when you need to solve a problem. It takes fairly little time
to know how to use it, but due to the implementation of generics as
preprocessor macros its not as flexible as a full blown class library with
templates for instance. (besides : which compiler has templates ?)

----------------------------------------------------

Name: USL (UNIX System Laboratories Europe Ltd.)


   UNIX System Laboratories Europe Ltd.
   International House
   Ealing Broadway
   London W5 5DB England
   [phone]

It appears quite complete (unless you have some specific, uncommon
needs); Booch may have an edge in supporting concurrency. USL may have
more installations and greater maturity.

----------------------------------------------------

Name: LEDA (Part 2)
                                  LEDA

             A Library of Efficient Data Types and Algorithms

                             Stefan Naeher
                   Max-Planck-Institut fuer Informatik
                  Im Stadtwald, 6600 Saarbruecken, FRG

                        ([e-mail])


LEDA is a library of the data types and algorithms of combinatorial computing.
The main features are:

1.  LEDA provides a sizable collection of data types and algorithms in a form
    which allows them to be used by non-experts. In the current version, this
    collection includes most of the data types and algorithms described in the
    text books of the area.

2.  LEDA gives a precise and readable specification for each of the data types
    and algorithms mentioned above.  The specifications are short (typically,
    not more than a page), general (so as to allow several implementations),
    and abstract (so as to hide all details of the implementation).

3.  For many efficient data structures access by position is important. In
    LEDA, we use an item concept to cast positions into an abstract form. We
    mention that most of the specifications given in the LEDA manual use this
    concept, i.e., the concept is adequate for the description of many data
    types.

4.  LEDA contains efficient implementations for each of the data types, e.g.,
    Fibonacci heaps for priority queues, red-black trees and dynamic perfect
    hashing for dictionaries, ...


5.  LEDA contains a comfortable data type graph. It offers the standard
    iterations such as ``for all nodes v of a graph G do'' or ``for all
    neighbors w of v do'', it allows to add and delete vertices and edges
    and it offers arrays and matrices indexed by nodes and edges,...
    The data type graph allows to write programs for graph problems in a
    form close to the typical text book presentation.

6.  LEDA is implemented by a C++ class library. It can be used with the C++
    compilers cfront 2.0, cfront 2.1, g++-1.37.1 or g++-1.40.3. It is
    distributed via anonymous ftp from

          sbsvax.cs.uni-sb.de (134.96.252.31),
          file: /pub/LEDA/LEDA-.tar.Z

---------------------------------------------------

Name: USL (UNIX System Laboratories Europe Ltd.)


   UNIX System Laboratories Europe Ltd.
   International House
   Ealing Broadway
   London W5 5DB England
   [phone]

It appears quite complete (unless you have some specific, uncommon
needs); Booch may have an edge in supporting concurrency. USL may have
more installations and greater maturity.

------------------------------------------------------

Name: Rational
Name: Booch Components

Rational markets the C++ Booch objects which are a somewhat bizarre,
but possibly quite innovative, set of library objects.

The US phone number for Rational is: Rational OO products 408-496-3700

It appears quite complete (unless you have some specific, uncommon
needs); Booch may have an edge in supporting concurrency. USL may have
more installations and greater maturity.

------------------------------

Name : StarView (long)

A Portable C++ Class Library for Graphical User Interfaces

Author:     Andreas Meyer, STAR DIVISION

Contact:    STAR DIVISION GmbH
            Andreas Junge
            Zum Elfenbruch 5-11
            D-2120 Lueneburg

            Phone: ++49 4131 700943
            Fax:   ++49 4131 700921
            Email: ...!unido!starlab!aj

The development of large applications for Graphical User Interfaces
(GUI's) like MS-WINDOWS, MS Presentation Manager or OSF/Motif is a very
time consuming job. In addition, the application programming interfaces
(API's) of the different GUI's are totally incompatible making a direct
port of source code to another GUI platform impossible, almost all code
driving the user's interface must be re-written by the programmer.

Two years ago, STAR DIVISION decided to develop a set of new applications
for GUI's which should fulfill the requirements of modern software
standards this entails:

-   portability between the operating systems MS-DOS, OS/2, Macintosh
    and different UNIX flavours
-   at  least portable between  the  GUI's MS-WINDOWS, MS-Presentation
    Manager, MacApp and OSF/Motif
-   fulfillment of the requirements of the different GUI Style
    Guide's
-   data  exchange and direct communication between the applications in
    homogeneous and heterogeneous networks (groupware approach)

Because of the indifferent "political" situation (i.e. MS-DOS or OS/2 or
UNIX or everything, WINDOWS or PM or X.11 or everything) we decided to
develop a set of tools which helps us to be mostly independent from the
decisions of the OS and hardware vendors. In addition tools help to
improve productivity and are the base for a successful software project.
C++ is the programming language of our choice because we could use our
large experiences in C programming and C++ provides all major advantages
of Object Oriented Programming (OOP) that is - from our point of view -
the best available paradigm for complex software development today.

In this report we want to introduce StarView, a portable C++ Class
Library for Graphical User Interfaces. StarView is one of the major parts
of our total Object Oriented programming environment (we call it SOLAR
system) and to give you an impression of the other tools of the SOLAR
system we will give you a short overview about the Object Management
System ObjectServer at the end of the report. But first we will take a
brief look on Star View


< See file StarView in current directory    zxl >

----------------------------

Name: Open Dialogue

HP/Apollo

------------------------------

Name: Zinc Interface Library (Iconic user interface)

Zinc

------------------------------

Name: C++/Views (Iconic user interface)

CNS : Windows/Mac/Motif/OS2
Nice clean interface, powerful and cheap.

------------------------------

Name: MacApp (application development toolkit)

Apple

------------------------------

Name: ICpak101
Name: ICpak201

Stepstone

-------------------------------

Name: NeXTStep (application development toolkit)

NeXT

--------------------------------

Name: CommonView (Iconic user interface)

Glockenspiel

--------------------------------

Name: Analyst (Information Centre)
Name: Humble  (Expert system package)

Xerox SIS : Smalltalk classes

======================================================

END OF THIS SUMMARY
   Dave Riches
   PSS:    [e-mail]
   Smail:  BNR Europe Ltd, London Road,
           Harlow, Essex. CM17 9NA.  England
   Phone:  [phone] x2496
   Fax:    [phone]
=========================================================================
----- End Included Message -----






Appendix II - The Stack Exerciser


 The Stack Exerciser
As a first program to develop in order to have a "flavour" of the different
class libraries I have chosen to implement a very basic stack exerciser,
providing such operations as push, pop, print stack, return number of
items in the stack, etc.
This program has been written in several versions, one for OATH, one for COOL,
one for LEDA, etc.
For each of the libraries the manual page explaining the usage of the
stack data type is presented, followed by the source code of the
program, so
that the reader may get acquainted with each library's
notation, followed by some personal impressions on the specific part
of the library used to implement the program.

 The Stack Exerciser - OATH version
As a first, natural action you look at the manual looking for a class with a
name similar to "stack" in order to see which methods are provided to work
with it.
After some browsing I discovered that what I was looking for was actually
named "lifoQueue".
When I came to the manual page for lifoQueue I found that a single method was
provided, called "insert", which is the push method.
A bit puzzled (I was expecting to find all the methods related to the
stack management in the class)
I had to look for the pop and top methods.
In class Queue (the grand
father of lifoQueue) I found the "remove" (pop) method, the top method
does not exist, and to access the top element you probably have to
"make" a position in the stack and access it dereferencing the
pointer.
I didn't really like all of this. I found the process of writing the
Stack Exerciser program lenghty, complicated, and non linear using
this class.
 The Stack Exerciser - LEDA version
I had a look at the manual page for the stack, declared and created it
according to the recommended syntax and I found available, in the
class, all the operations you would expect to find when dealing with
such a data structure.
Push, pop, top, clear, size and empty were there, easily available for
use, and it took moments to complete the program.


=======================================================