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: jcc@gna.axis-design.fr (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!kpt@fig.citib.com (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: scott@scam.Berkeley.EDU (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,
scott@xcf.berkeley.edu
Long posting follows:
*******************************************************************************
(3.1)
% From: bergquis@gdc.com (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: eyckmans%imec.be@imec.be
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: eyckmans%imec.be@imec.be
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: dsr@bnr.co.uk
Subject: Summary - Class Libraries
In article <5307@stl.co.uk> 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, (503) 754-2311.
---------------------------------------
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
+11-44-81-587-7711
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
(stefan@mpi-sb.mpg.de)
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
+11-44-81-567-7711
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: David.S.Riches@bnr.co.uk
Smail: BNR Europe Ltd, London Road,
Harlow, Essex. CM17 9NA. England
Phone: +44 (0)279-429531 x2496
Fax: +44 (0)279-454187
=========================================================================
----- 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.
=======================================================