* Forwarded by Nick Bezrukov (2:463/10.1) using GoldED 2.31p+
* Area : SU.C_CPP (SU.C_CPP)
* From : Anthony Parfyonov, 2:5020/11.3 (09 Jul 92 13:37)
* To   : All
* Subj : Library of classes: OATH
=====================================================================
3.1.  OATH - Object-oriented Abstract Type Hierarchy.
_ _   ____   ______ ________ ________ ____ _________

+    Written by: Brian M. Kennedy

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

+    The Reference Manual states it has only  been  compiled
     with AT&T cfront 2.1 compatible compilers. No templates
     and no exception handling.

+    OATH  (Object-oriented  Abstract  Type  Hierarchy)  was
     designed as an experiment in increasing object-oriented
     reuse.  It has a fairly high learning curve, but poten-
     tially higher gains if you are looking for a more flex-
     ible and robust abstraction.  It is  completely  unsup-
     ported.

     Please refer to the menu below to  get  to  the  detail
     information about OATH features.

+    Information provided by Marco Pace (MPACE@ESOC.BITNET)

3.1.1.  OATH Introduction
_ _ _   ____ ____________

     OATH instantiates an approach to  C++  class  hierarchy
design   that   exploits  subtyping  polymorphism,  provides
greater implementation independence, and  supports  implicit
memory  management  of  its  objects.  It is implemented via
parallel hierarchies of internal  types  and  accessors   (a

concept  similar  to  that  of  the  "smart  pointers",  but
improved compared to them).  The internal types contain  the
object  representation  (the  data  members) and the virtual
functions.  The accessor types contain all of the externally
accessible functions of the abstract types.

     Two main design goals of OATH were:

To provide a meaningful  abstract type  hierarchy   that  is
consistent  with  the concepts being modelled by utilizing a
strict subtyping approach  to  hierarchy  design.   Starting
from  the  the idea that a type hierarchy should be designed
to reflect the behaviour of the objects being  modelled  and
not  to  reflect the most convenient computer representation
of objects, the designer of OATH gave priority to  the  sub-
typing (inheriting functionality) aspect over the code reuse
(inheriting  implementation)  aspect.   Given  a  consistent
abstract  type  hierarchy,   implementation  classes  can be
added at the leaves of the hierarchy (see figure  later  on)
to implement the behaviour of the abstract types. Code reuse
can be exploited at this phase, but should  not  enter  into
the design of the abstract type hierarchy.

To provide robust  garbage collection (GC)  of OATH objects,
fully  implemented within a portable C++ class library.  The
garbage collection mechanism is a hybrid  reference counting
and  marking   algorithm  capable  of collecting all garbage
(including circular references).  The programmer can  select
one of four garbage collection modes at compile time: no GC,
incremental GC, stop-and-collect, or combined.

3.1.2.  Features
_ _ _   ________

     OATH's main features are the following:

It provides  heterogeneous container classes

It provides  dynamic type  determination   in  the  form  of
"safe casts"

It provides accessors to access OATH objects.

For each OATH type there is a corresponding  accessor  class
(an  accessor  lies  between  a C++ pointer and a C++ refer-
ence).  The accessors can be initialized and  assigned  OATH
objects to access. However, any other operation on an acces-
sor is applied directly to the abstract object it accesses.

3.1.3.  Hierarchy
_ _ _   _________

     The class hierarchy provided by OATH is the following:

        obj
          pos
           pdPos
           listPos
           dlPos
           stringPos
           minStringPos
        bag
          set
            hashSet
            finiteSet
            characterSet
        queue
          seq
          lifoQueue
            pdList
          fifoQueue
            deq
        list
          dlList
        string
          minString
        plist<T>
        ring
        grid
        table
        stringTable
          capsule<T>
        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 read-
able version of this hierarchy can be found in [1], Figure 1
<see bibliography>)

3.1.4.  Evaluation
_ _ _   __________

+    Documentation:

     The documentation is very concise (probably  too  much)
     and lacks examples. Due to its conciseness sometimes it
     is not easy to understand and somehow it is cryptic.

+    Usability:

     OATH provides a wide set of classes.  It does not  seem
     easy to use the class services provided, especially for
     a beginner.  Services that you would expect to find  at
     a  given level of the hierarchy sometimes are not there
     and you have to go upwards through  the  tree  to  find
     them, sometimes with names not directly related to what
     you are using.  The services provided are not many, but
     their interface is simple to use.

+    Extensibility:

     This feature was not evaluated  directly.   However,  a
     brief  discussion  on  the  way  to extend the existing
     class library is present in the OATH  Reference  Manual
     [2] (OATH(30), section Developing New OATH Types).

+    Sensibleness:

     The available classes are perhaps too abstract. I would
     have  preferred  less  abstract  and  more  "practical"
     classes, but probably this would have been against  the
     basic  assumptions their designers of OATH made.  Among
     the, there are classes for  integers,  rational,  real,
     complex.

+    Miscellaneous:

     The provided hierarchy is that of a  tree,  where  only
     single   inheritance   is   supported.    No  templates
     (parameterized types) are provided,  and  no  exception
     handling  as well.  Garbage collection is supported and
     appears to be even sophisticated in terms of the  kinds
     of GC available.

3.1.5.  Bibliography
_ _ _   ____________

1.   Brian M.Kennedy, The Features  of  the  Object-oriented
     Abstract  Type  Hierarchy, Computer Systems Laboratory,
     Computer Science Center, Texas  Instrument,  26  August
     1991

2.   OATH Reference Manual (OATH 0.8), 26 August 1991


-!- msgedsq 2.0.5
 ! Origin: Alan BBS, Free Town Zelenograd
(tony@insight.pczz.msk.su) (2:5020/11.3)
=====================================================================


--- GoldED 2.31p+, FroDo 2.02
 * Origin: SP Editor (2:463/10.1)

----------------------------------------------------------------------
(921)   Thu 6 Aug 92  8:21
By: Nick Bezrukov
To: All
Re: Library of classes: COOL
St: Local Sent
----------------------------------------------------------------------
@MSGID: 2:463/10.1 2a811959
=====================================================================
* Forwarded by Nick Bezrukov (2:463/10.1) using GoldED 2.31p+
* Area : SU.C_CPP (SU.C_CPP)
* From : Anthony Parfyonov, 2:5020/11.3 (11 Jul 92 11:41)
* To   : All
* Subj : Library of classes: COOL
=====================================================================
3.2.  COOL - C++ Object Oriented Library
_ _   ____   _   ______ ________ _______

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

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

+    COOL is a collection of classes, templates, and  macros
     for  use  by  C++  programmers writing complex applica-
     tions.  It raises the level of abstraction for the pro-
     grammer  to  concentrate  on the problem domain, not on
     implementing base data structures, macros, and classes.

+    Information provided by Marco Pace (MPACE@ESOC.BITNET)

3.2.1.  Introduction
_ _ _   ____________

     COOL is a collection of classes, templates, and  macros
for use by C++ programmers writing complex applications.  It
raises the level of abstraction for the programmer  to  con-
centrate  on  the  problem  domain, not on implementing base
data structures, macros, and classes.

In  addition,  COOL  also  provides  a  system   independent
software  platform  on  top of which applications are built,
since COOL encapsulates such system  specific  functionality
as  date/time  and  exception handling.  For a more detailed
description of COOL and its features, including  a  thorough
discussion  on  the rationale for the design and implementa-
tion choices see [5].

3.2.2.  Features
_ _ _   ________
 The class library hierarchy is  basically  forest,  but  it
implements a rather flat inheritance tree.

All complex classes are derived from the Generic  class  due
to space efficiency concerns.  COOL does not seem to provide
multiple inheritance.  COOL's exception handling provides  a
reise, handle, and proceed mechanism.

Exception and exception handling classes  are  provided  for
this  purpose.   COOL  provides parameterized templates. The
peculiarity of COOL is that to allow  this  it  extends  the
standard  C++  preprocessor to recognize the notation intro-
duced to specify templates.

In other words, the programs written using COOL are not com-
piled using the standard CC, but using CCC (COOL C++ Control
Program), which is an extension of the CC compiler.  It does
not seem to include garbage collection.

3.2.3.  Subclasses
_ _ _   __________
 The classes provided by the library are several,  and  they
are listed here:

        Pair <T1,T2>
        Range
          Range <Type>
        Rational
        Complex
        Generic
          String

          Gen_String
          Regexp
          Vector
            Vector <Type>
              Association <Pair<T1,T2>>
          List_Node
            List_Node <Type>
          List
            List <Type>
          Date_Time
          Timer
          Bit_Set
          Exception
            Warning
            Error
              System_Error
            Fatal
            System_Signal
            Verify_Error
          Excp_Handler
            Jump_Handler
          Hash_Table
            Set
            Hash_Table <Key,Value>
              Package
          Matrix
            Matrix <Type>
          Queue
            Queue <Type>
          Random
          Stack
            Stack <Type>
          Symbol
          Binary_Node
            Binary_Node <Type>
          Binary_Tree
            Binary_Tree <Type>
              AVL_Tree <Type>
          N_Node <Type>
          D_Node <Type>
          N_Tree <Type,Node,Child>

3.2.4.  Evaluation
_ _ _   __________

     Easy to use, the services provided are really a lot.

     The extendibility has not been  tested,  although  this
seems  to  be one of the feature of the library, which issue
is dealt with in part of section 14 of the User Manual  (See

Bibliography).

     Performance not evaluated

     It does not seem to be  supported  by  the  developers.
The  installation  of  COOL  was a tragedy: several problems
were found, ranging from files not found to  compile  errors
to link errors, etc.

After a couple of days of trials the installation was  aban-
doned,  although  a post was made to the net to see if some-
body could help on that.

I got some answers after some time  and  I  found  out  that
other  people  had  similar installation problems. They sug-
gested some solutions which I  haven't  tried  yet.   It  is
interesting  to note that the authors of COOL have written a
paper on which they analyse the  lessons  learned  from  the
usage  of  the  library, what they would keep of it and what
they would change in its design, and so on  (See  Bibliogra-
phy).

3.2.5.  Bibliography
_ _ _   ____________

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

COOL User Manual, March 1990, Texas Instruments Inc.

M.Fontana & M.Neath, Checked Out and Long  Overdue:  Experi-
ences in the Design of a C++ Class Library, Texas Instrument
Inc.

3.2.6.  NetComments
_ _ _   ___________

     From: bergquis@gdc.com (Brett Bergquist)

Did you get the paper about COOL "Checked Out and Long Over-
due:  Experiences in the Design of a C++ Class Library".  In
this paper, the authors discuss the strengths and weaknesses
of  the  design  of COOL.  A couple of points that they men-
tioned that they would do differently would be  to  simplify
the  dependencies  between  classes  by using MI.  Also they
would factor out the use of the symbolic and package mechan-
ism.  Performance is not mentioned as an issue.


-!- msgedsq 2.0.5
 ! Origin: Alan BBS(2:5020/11), Free Town Zelenograd
(tony@insight.pczz.msk.su) (2:5020/11.3)
=====================================================================


--- GoldED 2.31p+, FroDo 2.02
 * Origin: SP Editor (2:463/10.1)

----------------------------------------------------------------------
(922)   Thu 6 Aug 92  8:22
By: Nick Bezrukov
To: All
Re: Library of classes: LEDA
St: Local Sent
----------------------------------------------------------------------
@MSGID: 2:463/10.1 2a811978
=====================================================================
* Forwarded by Nick Bezrukov (2:463/10.1) using GoldED 2.31p+
* Area : SU.C_CPP (SU.C_CPP)
* From : Anthony Parfyonov, 2:5020/11.3 (11 Jul 92 11:42)
* To   : All
* Subj : Library of classes: LEDA
=====================================================================
3.3.  LEDA - Library of Efficient Data types and Algorithms
_ _   ____   _______ __ _________ ____ _____ ___ __________

+    Writen by: Stefan Naeher (stefan@mpi-sb.mpg.de)

     Anonymous    ftp     from     host     ftp.cs.uni-sb.de
     (134.96.252.31) in directory pub/LEDA.

+    The library can be used under UNIX with  the  C++  com-
     pilers AT&T cfront 2.0, cfront 2.1 and GNU g++ (version
     1.37).  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 consists of a sizeable collection of data types  and
     algorithm:  this  includes stacks, queues, lists, sets,
     dictionaries, ordered sequences,  partitions,  priority
     queues, directed, undirected, and planar graphs, lines,
     points, planes and basic algorithms in graph  and  net-
     work theory and computational geometry

+    Information provided by Marco Pace (MPACE@ESOC.BITNET)

3.3.1.  Introduction
_ _ _   ____________

3.3.2.  Features
_ _ _   ________

     LEDA is a library of efficient  data  types  and  algo-
rithms. Its main features are:

a sizable collection of  data  types  and  algorithms:  this
includes  stacks, queues, lists, sets, dictionaries, ordered
sequences,   partitions,    priority    queues,    directed,
undirected,  and  planar  graphs,  lines, points, planes and
basic algorithms in graph and network  theory  and  computa-
tional geometry;

the precise and readable specification  of  data  types  and
algorithms;

the inclusion of many  of  the  most  recent  and  efficient
implementations;

a comfortable data type graph;

its extendibility;

its ease of use.

The library employs

a strict separation between abstract data types and the con-
crete data structures used to implement them,

parameterized data types, and object oriented programming.

3.3.3.  Classes
_ _ _   _______

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

        Simple Data Types
                Boolean (bool)
                Real Numbers (real)
                Strings (string)
                Real-valued vectors (vector)
                Real-valued matrices (matrix)
        Basic Data Types
                One Dimensional Arrays (array)
                Two Dimensional Arrays (array2)
                Stacks (stack)
                Queues (queue)
                Bounded Stacks (b_stack)
                Bounded Queues (b_queue)
                Lists (list)
                Sets (set)
                Integer Sets (int_set)
                Partitions (partition)
                Dynamic collections of trees (tree_collection)
        Priority Queues and Dictionaries
                Priority Queues (priority_queue)
                Bounded Priority Queues (b_priority_queue)
                Dictionaries (dictionary)
                Dictionary Arrays (d_array)
                Hashing Arrays (h_array)

                Sorted Sequences (sortseq)
                Persistent Dictionaries (p_dictionary)
        Graphs and Related Data Types
                Graphs (graph)
                Undirected Graphs (ugraph)
                Planar Maps (planar_map)
                Parametrized Graphs (GRAPH)
                Parametrized Undirected Graphs (UGRAPH)
                Parametrized Planar Maps (PLANAR_MAP)
                Node and Edge Arrays (node_array, edge_array)
                Two Dimensional Node Arrays (node_matrix)
                Node and Edge Sets (node_set, edge_set)
                Node Partitions (node_partition)
                Node Priority Queues (node_pq)
        Two-Dimensional Geometry
                Two-Dimensional Dictionaries (d2_dictionary)
                Sets of Points (point_set)
                Sets of Intervals (interval_set)
                Sets of Parallel Segments (segment_set)
                Planar Subdivision (subdivision)
                Graphic Windows (window)

3.3.4.  Evaluation
_ _ _   __________

     The class library hierarchy is a forest,  and  it  does
not  seem  to  provide multiple inheritance.  Some exception
handling is provided, but it seems to be quite raw,  in  the
sense that it usually ends with the program abortion.

However, the user can write its own error handler,  but  its
function prototype has to be

        void handler(int, char*)

where the first parameter is an error number and the  second
is  an error message. LEDA provides parameterized templates.
It does not seem to include garbage collection.

     It is not clear whether it is supported in some way  by
the  developers.   The installation of LEDA was quite simple
and took a couple of hours.  One problem only was found dur-
ing the execution of the makefile, namely some include files
needed for the creation of the graphics library for  Sunview
(in which we were not interested).  After this the test pro-
grams were created without problems.  The execution  of  the
test  programs  was  carried out, but no description of what
they are supposed to do and/or what input they expected  was
found.   A  few  of them run without problems, others issued
error messages, others aborted after a core dump.

The set of classes provided  is  quite  large,  the  classes
themselves are easy to use, the services provided sufficient
(although sometimes the  set  is  not  "rich"  enough),  the
interface simple when the user has gone through section 1 of
the User Manual [4], which explains the basics.

     The extendibility has not been  tested,  although  this
seems  to  be  one  of the features of the library, on which
issue a brief discussion appears in section IV of the manual
(See Bibliography).

     After some time spent trying to format  the  documenta-
tion  (it  is  available  only in TEX format), we managed to
have it printed.  The documentation appears  to  be  linear,
easy to read (as promised by the authors), concise.  It does
not contain, however, examples of the way the  classes  have
to be used.

3.3.5.  Bibliography
_ _ _   ____________

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

3.3.6.  NetComments
_ _ _   ___________


-!- msgedsq 2.0.5
 ! Origin: Alan BBS(2:5020/11), Free Town Zelenograd
(tony@insight.pczz.msk.su) (2:5020/11.3)
=====================================================================


--- GoldED 2.31p+, FroDo 2.02
 * Origin: SP Editor (2:463/10.1)

----------------------------------------------------------------------
(923)   Thu 6 Aug 92  8:22
By: Nick Bezrukov
To: All
Re: Library of classes: NIHCL
St: Local Sent
----------------------------------------------------------------------
@MSGID: 2:463/10.1 2a811998
=====================================================================
* Forwarded by Nick Bezrukov (2:463/10.1) using GoldED 2.31p+
* Area : SU.C_CPP (SU.C_CPP)
* From : Anthony Parfyonov, 2:5020/11.3 (12 Jul 92 12:24)
* To   : All
* Subj : Library of classes: NIHCL
=====================================================================
3.4.  NIHCL - National Institute of Health Class Library
_ _   _____   ________ _________ __ ______ _____ _______

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

     Chuck Noren's modification  to  work  with  ObjectStore
     OODBMS   is  also  available  via  anonymous  ftp  from
     alw.nih.gov in file MartinNihcl3-101.tar.Z.

+    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++ com-
     piler.

     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.

+    Information provided by Marco Pace (MPACE@ESOC.BITNET)

3.4.1.  Introduction
_ _ _   ____________

     NICHL (pronounced either N-I-H-C-L or "nickel")  imple-
ments  abstract  data  types that have been designed to sim-
plify 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).

3.4.2.  Features
_ _ _   ________
 Classes  Process,  Scheduler,  Semaphore,  and  SharedQueue
implement multiprogramming 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 facil-
ity 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].

3.4.3.  Classes
_ _ _   _______
 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 sema-
phore class, I/O classes, a process class  and  a  scheduler
class.

3.4.4.  Evaluation
_ _ _   __________

     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 experi-
mental 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.

NIHCL is documented (see bibliography), 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 profit-
ably a real reference manual.

     No idea whether it is supported or not.

3.4.5.  Bibliography
_ _ _   ____________

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

3.4.6.  NetComments
_ _ _   ___________

     From: Chuck Noren <noren@pogo.den.mmc.com>

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 modi-
fied  it  to work with the Object Oriented Database (Object-
Store 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 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
advantange 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 modi-
fied 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 com-
pany 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  applica-
tions.   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
langauge, there is one hell of a learning curving, but it is
well worth it.

     From: Chuck Noren <noren@pogo.den.mmc.com>

> 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 inter-
     changeably 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  col-
     lection.

2.   It is relatively bug free and stable.  We have  encoun-
     tered  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  advantagous to use, there are certain
     times when run time type identification greatly simpli-
     fies  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 opera-
     tor needs to manipulate and create lots of  very  flex-
     able 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 vir-
     tual  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 "automagically".

7.   Stream and  file  I/O.   You  can  use  the  NIHCL  I/O
     features  to make a "poor man's database".  If you fol-
     low the NIHCL discipline, all your objects can be writ-
     ten  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 sim-
     ple 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  prob-
     lem.   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 applica-
tion  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 for-
     tunatly 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  librayy  which  used the derived classes more often.
     This is a trade-off.  The single class  hierarchy  pro-
     vides 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 thing  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 discip-
     line 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  cast-
     down 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.

     From: Chuck Noren <noren@pogo.den.mmc.com>

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.

-!- msgedsq 2.0.5
 ! Origin: Alan BBS(2:5020/11), Free Town Zelenograd
(tony@insight.pczz.msk.su) (2:5020/11.3)
=====================================================================


--- GoldED 2.31p+, FroDo 2.02
 * Origin: SP Editor (2:463/10.1)

----------------------------------------------------------------------
(924)   Thu 6 Aug 92  8:23
By: Nick Bezrukov
To: All
Re: Library of classes: ZINC
St: Local Sent
----------------------------------------------------------------------
@MSGID: 2:463/10.1 2a8119ba
=====================================================================
* Forwarded by Nick Bezrukov (2:463/10.1) using GoldED 2.31p+
* Area : SU.C_CPP (SU.C_CPP)
* From : Anthony Parfyonov, 2:5020/11.3 (14 Jul 92 12:37)
* To   : All
* Subj : Library of classes: ZINC
=====================================================================
3.9.  Zinc
_ _   ____

+    Platform: DOS

+    This was the most commonly mentioned library  for  DOS.
     It  was  generally  praised.  Several  people noted the
     documentation could be more helpful but the  tech  sup-
     port  phone  people seemed to make up for that failing.
     One respondent noted his release didn't handle variable
     fonts  but  said  that  may  be  fixed  in  the current
     release. The  only  respondant  to  explicitly  mention
     using  Zinc  in  graphics  mode  found  it "intolerably
     slow."

+    Information provided by bennett@math.ksu.edu

3.9.1.  Netcomments
_ _ _   ___________

      From abw@dsbc.icl.co.uk (Andy Wardley)

        POINTS FOR....

         The Zinc  Interface  Library  "...gives  a  fast  nice
GUI,  that
         somewhat  reminds me of windows.", "the library is
well-designed."
         and "you can get it to do most things and its Windows
capabilities
         are at last getting into shape."

         "I  will  also  add  that I'm very impressed with the
company.  My
         friend who has it told me he got an update  in  the  mail
without
         even  asking  and  he  was  offered a Windows version
(beta?) from
         their BBS for free.  Very impressive for a software
company."

         "For DOS I've heard it's very good but their  Windows
version  is
         buggy,  but  I  think  they're  coming  out  with  a
much-improved
         version"

         "See a recent c.l.c++ summary of PC GUI libs -- it did
well."

        "We are developing DOS applications using Zinc (with
Borland BC++)
         and are reasonably well-satisfied with it.  Our
application is not
         pushing Zinc very hard, however.  We  are  using  it  in
graphics
         mode,  although  we are mostly putting text objects &
menus on the
         screen."

         "They provide much sample code & studying it is essential."

         "Tech support is free & good; they have a BBS."

         "But as a UI library it is really great. They have  just
released
         version 2.01 with a lot of bug fixes this means it is
pretty solid
         now."

         "The design tool  saves  a  lot  of  time.  The
documentation  is
         extensive and good. There is a lot of good example code
too."

         POINTS AGAINST...

         "The  Zinc  designer  has lots of bugs and quirks, but you
can get
         around them"

         "Some things could have been better done,  and  is  surely
 better
         implemented in the OS of the Macintosh."

         "For  top-professional  use  there  are  some limitations.
We even
         considered returning the package. But if you can  live
without  a
         100% product, but rather a late beta, then this is for you."

         "It  took  me  a  while to get into their approach, partly
because
         their documentation goes  into  detail  but  seems  to
leave  out
         overviews."

         "The  library  is  somewhat  lower  level  than I would
like.  For
         example, check boxes and dialog boxes are not built-in,
but  they
         provide examples to show you how to build them."

         "They do not currently support variable fonts, although
their tech
         support told me it is planned for a future release."

         "Incidentally, applications seem to be pretty large with
it."

         "The major problem I have with it is I wish it worked with
 a  DOS
         extender under Zortech"

         OTHER POINTS...

         "If  you  can't  find  what you need in the docs, then
look in the
         sources"

         "Rumours says that they are working on Macintosh,  OS/2
and  UNIX
         version  too.  Apple  programmers has seen an early
version of the
         mac version."

         REVIEWS IN...

            Dr. Dobb's (12/90),

            Computer Language (12/90)
            PC Week (12/26?/91).
            Byte (01/91)

         SUMMARY...

         It seems that generally, people are happy with it and
think it's a
         good  UI  library.   The  older  version  (pre V2.01) was
slightly
         buggy, particularly in the designer and the MS windows
parts,  but
         this  has  mostly  been fixed in V2.01.  Most of the bugs
had work
         arounds.

         The library is fast and flexible, although  radio
buttons,  check
         boxes  etc,  are  not built in classes and have to be
derived from
         existing classes - fairly easy for the more advanced
programmer  -
         maybe slightly difficult for others..

         Documentation,  was  reasonable  in  the older versions
and is now
         greatly improved in the new one, with over 1100 pages.
Technical
         support from the company was generally regarded as VERY
good.

         Thanks to people who contributed...

            pope@daimi.aau.dk (Povl H. Pedersen)
            jamshid@emx.utexas.edu (Jamish Afshar)
            ferdie@coyote.datalog.com (fred jarvis)
            borkoles@dcs.qmw.ac.uk
            ajb@ee.wpi.edu (Arthur J Butler)


-!- msgedsq 2.0.5
 ! Origin: Alan BBS(2:5020/11), Free Town Zelenograd
(tony@insight.pczz.msk.su) (2:5020/11.3)
=====================================================================


--- GoldED 2.31p+, FroDo 2.02
 * Origin: SP Editor (2:463/10.1)

----------------------------------------------------------------------
(925)   Thu 6 Aug 92  8:23
By: Nick Bezrukov
To: All
Re: Library of classes: Menuet
St: Local Sent
----------------------------------------------------------------------
@MSGID: 2:463/10.1 2a8119cf
=====================================================================
* Forwarded by Nick Bezrukov (2:463/10.1) using GoldED 2.31p+
* Area : SU.C_CPP (SU.C_CPP)
* From : Anthony Parfyonov, 2:5020/11.3 (14 Jul 92 12:37)
* To   : All
* Subj : Library of classes: Menuet
=====================================================================
3.8.  Menuet III
_ _   ______ ___

+    Platform: DOS and Borland C++

+    Commercial Software available from:
     Autumn Hill Software
     1145 Ithaca Drive
     Boulder, Colorado 80303
     Voice: 303-494-8865
     FAX:   303-494-7802
     BBS:   303-494-8868

     or in Europe:

     Murray Communications Ltd
     53 Harrowby Lane
     Grantham
     Lincs
     NG31 9HZ
     Tel: 44-476-74108
     Email: pmurray@cix.compulink.co.uk

+    No idea on price

+    They send out free demo disks if you would like to take
     a  look at it. It's small, yet full featured, and works
     with Borland C++.

+    Information provided by joe@proto.com

3.8.1.  NetComments
_ _ _   ___________

     From: bennett@math.ksu.edu (Andrew G. Bennett)

     This package  was  found  too  inflexible  by  the  one
respondant who mentioned it. They had difficulty getting the
GUI to interact with their application  on  the  level  they
wanted.  The  respondant also noted this flaw appeared to be
present in graphic-Menu as well,  though  they  hadn't  used
that system.


-!- msgedsq 2.0.5
 ! Origin: Alan BBS(2:5020/11), Free Town Zelenograd
(tony@insight.pczz.msk.su) (2:5020/11.3)
=====================================================================

--- GoldED 2.31p+, FroDo 2.02
 * Origin: SP Editor (2:463/10.1)

----------------------------------------------------------------------
(926)   Thu 6 Aug 92  8:23
By: Nick Bezrukov
To: All
Re: Library of classes: comparing
St: Local Sent
----------------------------------------------------------------------
@MSGID: 2:463/10.1 2a8119e5
=====================================================================
* Forwarded by Nick Bezrukov (2:463/10.1) using GoldED 2.31p+
* Area : SU.C_CPP (SU.C_CPP)
* From : Anthony Parfyonov, 2:5020/11.3 (14 Jul 92 12:40)
* To   : All
* Subj : Library of classes: comparing
=====================================================================
4.  Comments
_   ________

     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 docu-
mentation 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.

     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  impor-
tant  to  us.  (2) Support for multi-threaded programming is
only slightly less important.  (3) Sophsiticated and  exten-
sible 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.

     From: eyckmans%imec.be@zimec.be

In article <p4fieINN7si@agate.berkeley.edu>, 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 a 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


-!- msgedsq 2.0.5
 ! Origin: Alan BBS(2:5020/11), Free Town Zelenograd
(tony@insight.pczz.msk.su) (2:5020/11.3)
