From: chandra@bongoaisg.com (Periannan Chandrasekaran)
Subject: C++ Product List - Version 2.03 - PART 4/5
Reply-To: chandra@bongoaisg.com (Periannan Chandrasekaran)
Organization: Accura Innovative Services Inc.
Date: Tue, 25 Aug 92 21:28:39 GMT



3.  Libraries
_   _________
 A List of Class Libraries are available below. Refer to the
individual  items  for  detail descriptions. The description
includes evaluation criteria on these libraries.  Evaluation
is based on Documentation, Usability, Extensibility, Permor-
mance, Sensibleness etc.

3.1.  OATH - Object-oriented Abstract Type Hierarchy.
_ _   ____   ______ ________ ________ ____ _________

+    Written by: Brian M. Kennedy

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

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

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

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

+    Information provided by Marco Pace  (MPACE@ESOC.BITNET)
     and Brian Kennedy (kennedy@intellection.com)

3.1.1.  OATH Introduction
_ _ _   ____ ____________

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

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

     Two main design goals of OATH were:

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

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

3.1.2.  Features
_ _ _   ________

     OATH's main features are the following:

It provides  heterogeneous container classes

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

It provides accessors to access OATH objects.

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

3.1.3.  Hierarchy
_ _ _   _________

     The class hierarchy provided by OATH is the following:

                + obj
                  + pos
                    * pdPos
                    + listPos
                      * dlPos
                      + stringPos
                        * minStringPos
                  + bag
                    + set
                      * hashSet
                      + finiteSet
                        # characterSet
                    + queue
                      + seq
                        + lifoQueue
                          * pdlQueue
                        + fifoQueue
                          + deq
                            + list
                              * dlList
                              + string
                                * minString
                    + table
                      # stringTable
                  + token
                    # character
                    # localToken
                    # stringToken
                  + complex
                    + real
                      + rational
                        + integer
                          * bigInteger

where the classes preceded by '+' are  abstract  types,  the
classes  preceded  by  '*' are implementation types, and the
classes preceded by '#' are "abstract implementation types".
(A  visually  more readable version of this hierarchy can be
found in [1], Figure 1 <see bibliography>.)

3.1.4.  Evaluation
_ _ _   __________

+    Documentation:

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

+    Usability:

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

+    Extensibility:

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

+    Sensibleness:

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

+    Miscellaneous:

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

3.1.5.  Bibliography
_ _ _   ____________

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

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

3.1.6.  NetComments
_ _ _   ___________

3.2.  COOL - C++ Object Oriented Library
_ _   ____   _   ______ ________ _______

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

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

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

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

3.2.1.  Introduction
_ _ _   ____________

     COOL is a collection of classes, templates, and  macros

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

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

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

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

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

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

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

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

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

3.2.4.  Evaluation
_ _ _   __________

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

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

     Performance not evaluated

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

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

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

3.2.5.  Bibliography
_ _ _   ____________

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

COOL User Manual, March 1990, Texas Instruments Inc.

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

3.2.6.  NetComments
_ _ _   ___________

     From: bergquis@gdc.com (Brett Bergquist)

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

3.3.  LEDA - Library of Efficient Data types and Algorithms
_ _   ____   _______ __ _________ ____ _____ ___ __________

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

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

+

     -    LEDA can be used with all cfront and GNU C++  com-
          pilers

     -    it is provided as source code

     -    there is no fee for non-commercial use

+    It consists of a sizeable collection of data types  and
     algorithm:  this  includes stacks, queues, lists, sets,
     dictionaries, ordered sequences,  partitions,  priority
     queues, directed, undirected, and planar graphs, lines,
     points, planes and basic algorithms in graph  and  net-
     work theory and computational geometry

+    Information  provided  by   Stefan   Naeher(stefan@mpi-
     sb.mpg.de) and MARCO PACE (MPACE@ESOC.BITNET)

3.3.1.  Introduction
_ _ _   ____________

3.3.2.  Features
_ _ _   ________

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

a sizable collection of  data  types  and  algorithms:  this
includes  stacks, queues, lists, sets, dictionaries, ordered
sequences,   partitions,    priority    queues,    directed,

undirected,  and  planar  graphs,  lines, points, planes and
basic algorithms in graph and network  theory  and  computa-
tional geometry;

the precise and readable specification  of  data  types  and
algorithms;

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

a comfortable data type graph;

its extendibility;

its ease of use.

The library employs

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

parameterized data types, and object oriented programming.

3.3.3.  Classes
_ _ _   _______

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

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

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

3.3.4.  Evaluation
_ _ _   __________

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

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

        void handler(int, char*)

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

     It is not clear whether it is supported in some way  by
the  developers.   The installation of LEDA was quite simple
and took a couple of hours.  One problem only was found dur-
ing the execution of the makefile, namely some include files
needed for the creation of the graphics library for  Sunview
(in which we were not interested).  After this the test pro-
grams were created without problems.  The execution  of  the

test  programs  was  carried out, but no description of what
they are supposed to do and/or what input they expected  was
found.   A  few  of them run without problems, others issued
error messages, others aborted after a core dump.

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

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

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

3.3.5.  Bibliography
_ _ _   ____________

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

3.3.6.  NetComments
_ _ _   ___________

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

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

3.5.  ObjectPM  OS/2 PM Class Library
_ _   ________  __ _ __ _____ _______

+    Platform OS/2

+    Commercial Product from Objective Solutions
     Cleveland, OH
     Phone: (216) 292-2546

+    Support for OS/2 1.3 now, OS/2 2.0 in beta now Supports
     Zortech C++, Glockenspiel (?) Will support JPI TopSpeed
     C++ in OS/2 2.0 version Contact vendor for  other  sup-
     ported compilers

+    Price is $499 L, $369 at Programmer's Connection Source
     ce version is $1,000 US available from vendor

+    Seems to be a mature product with support for  threads,
     and has (I believe) an interface builder.

+    Information      provided      by      Barry       King
     (bking@ersys.edmonton.ab.ca)

3.6.  zApp, DOS and Windows Portable Class Library
_ _   ____  ___ ___ _______ ________ _____ _______

+    Platform DOS

+    Commercial Product from Inmark Development Corporation
     2065 Landings Drive
     Mountain View, CA 94043
     (415) 691-9000
     (415) 691-9099 (FAX)
     (415) 691-9990) BBS  -  downloadable demo

+    Supports MSC++, BC++ 2.0 & 3.0, ZTC++ maybe others.
     $195 US for object modules, $295 US for source license

+    An evolving product which based in  single  inheritance
     classes.   Subclasses  controls  from  resource info at
     run-time, supports Windows GDI,can set  event  handlers
     for  buttons.  Not a bad product but may not be as com-
     plete as some others on the market.  Oh yeah,  has  XVT
     support, I think...

+    Information      provided      by      Barry       King
     (bking@ersys.edmonton.ab.ca)

3.7.  Interviews Class Library Version 3.01
_ _   __________ _____ _______ _______ _ __

+    Platform: Requires X-Windows and cfront at least 2.1

+    InterViews is an excellent GUI class library  developed
     by Stanford University.

+    Developed my Mark Linton and his team.

+    ftp  from  interviews.stanford.edu.  Version   3.1   is
     scheduled  to  be  released on june 15 1992. There is a
     separate newsgroup for sharing experiences with  inter-
     views comp.windows.interviews.

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.

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)

3.10.  Starview C++ Graphical User Interface Library
_ __   ________ _   _________ ____ _________ _______

+    Designed to be independent of OS and Hardware vendors

+    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 Presenta-
     tion 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 net-
          works (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.

+    Information provided by Dave Riches (dsr@bnr.co.uk)

3.11.  TEGL Library
_ __   ____ _______

+    Supported on Borland C++

+    Address not known

+    Price around $99

+    One respondant faulted  it  for  "ignoring  CUA"  while
     another  praised  it  as  having  the  look and feel of
     presentation manager. The source code apparently is not
     highly  polished  and it does recommend using more than
     one mouse button.

+    Information   provided    by    Andrew    G.    Bennett
     (bennett@math.ksu.edu)

3.12.  Linpack Math Library
_ __   _______ ____ _______

+    MSDOS, UNIX, and many other platforms including a  vec-
     torised version of CRAY

+    Commercial software from:
     Rogue Wave Software Inc.
     1325 NW 9th Street,
     Corvallis, OR, 97330,
     (503) 754-2311.

+    No information on the compatability with  the  proposed
     ANSI/ISO standard

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

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

     Both Matrix.h++ and Linpack.h++ are completely compati-
     ble  with  Rogue  Wave's  other  C++  class  libraries,
     Tools.h++ and Math.h++, which are accepted standards in
     the industry.

     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.

+    Information provided by Dave Riches (dsr@bnr.co.uk)

3.13.  Objectkit\C++ 1.0
_ __   ___________   _ _

+    Commercial software available from:

     ParcPlace Systems, Inc.
     999 E. Arques Ave.
     Sunnyvale, CA 94086
     Tel: (408)481-9090
     Sales: 1-800-759-7272
     email: info@parcplace.com

+    Features the AT&T Standard Library Extensions:

     -    variable length bit strings

     -    adjustable  1-d  vectors  of  parameterized   type
          (implemented via macros)

     -    classes for date, time-of-day, timezone and  time-
          duration arithmetic

     -    finite state machine classes

     -    simple exception handling using Objection classes

     -    parameterized linked lists  (parameterization  via
          macros)

     -    associative arrays (i.e., keys/value associations)

     -    fast memory allocation class: Pool

     -    program   execution   time   measurement    class:
          Stopwatch

     -    String class and specializations of  iostream  and
          streambuf for String

     As a convenience for purchasers, Objectkit\C++ 1.0 also
     includes  the  NIHCL  and InterViews class libraries as
     *unsupported* free software.

     Objectkit\C++ OI - based on  technology  licensed  from
     Solbourne, OI is a C++ class library for rapid develop-
     ment of graphical user-interfaces  that  allow  runtime
     selection of OSF/Motif or OPENlOOK look-and-feel.

+    Information provided by Mike Khaw (khaw@parcplace.com)

3.14.  MFC (Microsoft Foundation Class Library)
_ __   ___  _________ __________ _____ _______

+    Included with the MS C7 compiler. Please refer  to  the
     Microsoft Compiler section.

+    Includes complete source.  Supports all standard memory

     models.

     Supports  DLLs  [dynamic  link  libaries   aka   shared
     Libraries].

     Also  sometimes  referred  to   as   AFX   "Application
     FrameworX", and/or "The C++ API for Microsoft Windows"

+    Information provided by: jimad@microsoft.com

3.14.1.  Introduction
_ __ _   ____________

     MFC's primary design goals are to provide an efficient,
compact,  fast,  easy-to-use, typesafe, and portable version
of the Windows API for the C++ programmer.  A secondary goal
is  to provide Collection classes, diagnostic memory manage-
ment, etc, for DOS and Windows programmers.  MFC  is  imple-
mented  without the use of language-extensions, allowing the
library to be  ported  to  other  C++  conformant  compilers
[although  right  now  MFC is only shipping with the C7 com-
piler.]  MFC closely follows the naming conventions and  use
of  the  "C"  Windows API so that programmers experienced in
Windows programming find it easy to switch from C to the C++
APIs.  However the "lower level" aspects of Windows program-
ming are improved upon by MFC.  For example  wparam,  lparam
packing/unpacking  is  handled  automatically  and in a type
safe manner.  Also the main message loop is handled automat-
ically.  Switch statements are replaced with the use of vir-
tual functions and/or cached  message  dispatch  that  avoid
slow message searches.  Finally, the C++ Windows classes are
implemented in such a manner as to  remain  compatible  with
the   C  implementations,  such that Windows programmers can
still use the C APIs  where  desired,  and/or  can  mix  old
implementations  of  Windows classes implemented in "C" with
new Windows classes written  in  C++.  Namespace  collisions
with  other  libraries are avoided by using an uppercase "C"
prefix on the MFC Windows classes.  MFC includes support for
OLE, DDE, Multimedia, and Windows for Pen Computing.  Appli-
cations written using MFC are automatically pen aware.

3.14.2.  Window Application Classes
_ __ _   ______ ___________ _______

          CWinApp   Main windows application class

          Window Classes

          CWnd           Base class for all windows
          CFrameWnd      Main window base class for the SDI (Single Document
                           Interface) desktop window
          CMDIFrameWnd   Base class for the MDI (Multiple Document Interface)
                           desktop window
          CMDIChildWnd   Base class for MDI child windows
          CDialog        Base class for modeless dialog windows
          CModalDialog   Base class for modal dialog windows
          CButton        Button control windows
          CComboBox      Combo box control windows
          CEdit          Edit control windows
          CListBox       List box control windows
          CScrollBar     Scroll bar control windows
          CStatic        Static control windows

          GDI (Graphical Device Interface) Classes

          CDC           Base class for display contexts
          CClientDC     Display contexts for client areas of windows
          CMetaFileDC   Metafile device contexts
          CPaintDC      Display contexts used in <OnPaint> member functions
          CWindowDC     Display contexts for entire windows
          CGdiObject    Base class for GDI drawing tools
          CBitmap       GDI physical bitmaps
          CBrush        GDI physical brushes
          CFont         GDI physical fonts
          CPalette      GDI physical palettes
          CPen          GDI physical pens
          CRgn          GDI physical regions

          Other Windows Classes

          CMenu    Menu structures
          CPoint   (X, Y) points in a device context
          CSize    Relative positions or coordinate pairs
          CRect    Rectangular regions in a device context
          OLE (Object Linking and Embedding) Classes
          OLE Classes   Object Linking and Embedding Classes

          Run-Time Object Model Class

          CObject   Root class in the Foundation class hierarchy

          File Classes

          CFile        Binary disk files
          CMemFile     In-memory files
          CStdioFile   Buffered stream disk files, usually text mode

          Object Input/Output

          CArchive       Persistent storage for objects
          CDumpContext   Destinations for diagnostic output

          Exceptions

          CException               Abstract base class for exceptions
          CArchiveException        Archive-specific exceptions
          CFileException           File-specific exceptions
          CMemoryException         Out of memory exceptions
          CNotSupportedException   Function not supported exceptions
          CResourceException       Windows resource not found exceptions

          Collections

          CByteArray           Arrays of bytes
          CDWordArray          Arrays of 32-bit double-words
          CObArray             Arrays of CObject pointers
          CPtrArray            Arrays of void pointers
          CStringArray         Arrays of strings
          CWordArray           Arrays of 16-bit words
          <template array class>

          CObList              Lists of CObject pointers
          CPtrList             Lists of void pointers
          CStringList          List of strings
          <template list class>

          CMapPtrToWord        Mappings of void pointers to 16-bit words
          CMapPtrToPtr         Mappings of void pointers to void pointers
          CMapStringToOb       Mappings of strings to CObject pointers
          CMapStringToPtr      Mappings of void pointers to CObject pointers
          CMapStringToString   Mappings of strings to strings
          CMapWordToOb         Mappings of 16-bit words to CObject pointers
          CMapWordToPtr        Mappings of 16-bit words to void pointers
          <template map class>

          Miscellaneous Support Classes

          CString     Character strings
          CTime       Absolute time and date values
          CTimeSpan   Relative time and date values

          Global Functionality

          Diagnostic Services               Global memory diagnostic functions
                                              and macros (Debug only)
          Exception Processing              Global exception throwing and
                                              catching functions and macros
          Message-Map Reference             CWnd message map entries
                                              with message-handler function
                                              prototypes

3.15.  NetClasses
_ __   __________

+    Commercial software available from:

     PostModern Computing Technologies, Inc.
     1032 Elwell Court, Suite 240
     Palo Alto, California 94303
     Telephone: (415) 967-6169
     Facsimile: (415) 967-6212
     Email: plambeck@cs.stanford.edu

+    No information on compatability of the future  ANSI/ISO
     standard.

+    NetClasses is a set of C++ class libraries for  distri-
     buted  object-oriented  communications  that will begin
     beta testing June 15 and is  scheduled  for  production
     release in the 3rd quarter of 1992.

+    Information   provided    by    Thane    E.    Plambeck
     <plambeck@cs.stanford.edu>

3.15.1.  Introduction
_ __ _   ____________

     One of the major stumbling  blocks  of  developing  and
fielding  complex distributed applications is the difficulty
in implementing and debugging using  existing  communication
tools.  The focus of the NetClasses architecture has been to
provide the tools necessary for programmers to develop  com-
plex  distributed  applications  without having to deal with
the esoteric details of low-level communications.

NetClasses is a set of C++ class libraries that is organized
as  a  software toolkit.  The typical user of the NetClasses
libraries  will  be  a   distributed   systems   application
developer who requires an object-oriented framework for dis-
tributed, message-passing based programming.  By linking the
appropriate  NetClasses  libraries,  application programmers
are then able to:

+    Transport objects over a network.

     Currently, there are three object varieties that  NetC-
     lasses can transport:

     1.   Arbitrary   C++   objects---once   derived    from
          PostModern's TransObject class

     2.   arbitrary  NIH-derived  objects;  and  provide  an
          object-oriented data transport in which the struc-
          ture and  organization  of  network  transportable
          objects  is  specified  externally in configurable
          files  using  a   simple,   programming   language
          independent  abstract  syntax  notation, the NetC-
          lasses Abstract Syntax Notation (NASN).

+    Perform remote method invocations (RMI)

     Using RMI, an application on machine  B  can  invoke  a
     method on machine A. RMI insulates distributed applica-
     tions from  the  complexity  inherent  in  traditional,
     RPC-based distributed systems development tools such as
     protocol compilers, TCP/IP code writing,  and  detailed
     socket handling.  RMI makes fault tolerance and connec-
     tion management transparent to the application program-
     mer.   The RMI layer is built on top of the distributed
     services package that is described below.

+    Build complex information distribution systems  on  top
     of   Distributed   Services,   PostModern   Computing's
     object-oriented approach  to  client-server  connection
     management and fault tolerance.

+    Use the NetClasses application programmer interface  in
     order  to create, manipulate, and destroy typed objects
     given NetClasses Typed Object  data  type  definitions.
     (NIH-derived  and native C++ objects are created, mani-
     pulated and destroyed from C++ itself).

+    Read and  write  all  three  varieties  of  NetClasses-
     transportable   objects   on   streams  using  machine-
     independent  external   representations.    All   three
     varieties  of  objects  can  be stored to and read from
     files.

3.15.2.  Objects as transportable data
_ __ _   _______ __ _____________ ____

     One of the most common needs  in  distributed  applica-
tions development is the ability to ship objects over a net-
work.  Currently, when data has to move from one machine  to
another  this  is  usually  done using hard-coded structures
over a low-level communications interface such  as  Berkeley
sockets  or  the System V Transport Layer Interface.  Moving
data in this way has several disadvantages:

+    If the format of the data changes,  e.g.  a  new  field
     must  be  added to a structure, all programs using that
     structure must be recompiled, whether or not they actu-
     ally make use of this new field.

+    Developing programs using low-level interfaces  require
     programmers  to concentrate on details such as sockaddr
     structs, byte ordering routines  such  as  htonl,  port
     numbers,   and  so  on.  These  are  details  that  are
     irrelevant to most applications and simply stand in the
     way of efficient distributed application programming.

+    Because of the low-level nature of the interfaces,  the
     resulting  distributed  programs are generally not very
     scalable.  In order for distributed programs  to  scale
     up  to  large  size  implementations it is necessary to
     provide an infrastructure whereby  data  and  processes
     can be managed efficiently as the number of machines on
     the network grows.  This has proven to be  very  diffi-
     cult using low-level interface tools.

     Engineers developing distributed systems using  object-
oriented methodologies place great emphasis on data encapsu-
lation and clean interfaces.  One of the goals of NetClasses
has  been  to preserve these properties in the communication
interfaces.

Therefore, instead of shipping byte buffers  over  the  net-
work, NetClasses allows applications to ship objects.  In an
object-oriented program virtually all information is  stored
in objects, making objects the most natural form in which to
transfer information over a network.

3.15.3.  Varieties of object transport
_ __ _   _________ __ ______ _________

     PostModern Computing's NetClasses  package  provides  a
set of flexible C++ tools for object transport.

The NetClasses NIH-based and Typed  Object-based  transports
are  built  on  top  of the National Institutes Health (NIH)
class library.  However, the NetClasses Typed Object  appli-
cation  programmer  interface is not NIH-dependent.  In par-
ticular, the Typed Object interface does not in any way con-
strain  C++ developers who prefer not to use the NIH library
themselves.

The TransObject transport offers  C++  programmers  a  third
facility  for object transport that is entirely NIH indepen-
dent.  The TransObject class library offers end-user  appli-
cation  programmers  a  way  to  migrate  existing C++ class
definitions to a network-transportable framework.  The Tran-
sObject  facility  is  independent  of  both the NetClassses
Typed Object transport and the  NIH-based  object  transport
described above.

3.15.4.  Distributed Services
_ __ _   ___________ ________

     In addition to transporting  objects  over  a  network,
another  common  need in distributed application development
is the management of object  dissemination  and  connections
between clients and servers.

PostModern Computing's Distributed  Service  paradigm  is  a
connection  and  service management mechanism that is organ-
ized around the idea that network service  providers  should
not have to set up explicit port numbers and RPC connections
but rather should simply  ``advertise''  themselves  on  the
network.   ``Agents''  are  active  processes on the network
that monitor network service advertisements and manage  con-
nections  between  information producers and consumers.  The
Distributed Service package is organized as a combination of
C++  class  libraries  and  configurable ``dsagent'' execut-
ables.  The Distributed Services paradigm is a powerful  and
flexible  package that provides an object oriented framework
for integrating and connecting applications on a network.

Distributed Services provides the following features:

+    Fault Tolerance

+    Load Balancing

+    Multicasting

3.15.5.  Remote Method Invocation (RMI)
_ __ _   ______ ______ __________  ___

     The distributed services paradigm enables methods to be
invoked  on  objects from remote machines.  The RMI facility
is a higher level communications facility that again shields
the developer from port number and host name considerations.
The focus of RMI is on  ease  of  use.   An  RMI  invocation
requires  no  stub or skeleton files, protocol compilers, or
RPC mechanisms.  To enable object X of class C to  have  its
method  M  invoked  from a remote machine, a programmer uses
the RMI::advertise method to advertise method X.M.

If an application wants to invoke the M method on  object  X
from  a  remote  machine,  it  uses  the  RMI::invoke("X.M")
method.

Parameter passing in RMI can be based on any  of  the  three
NetClasses  object  transports  (generic C++, NIH-object, or
TypedObject).  Synchronous  and  asynchronous  RMI  versions
exist.

Multiple agents can advertise method X.M.  The one  that  is
actually  invoked  is  transparent  to the client.  RMI thus
provides an easy mechanism for developing  scalable  distri-
buted applications.

3.15.6.  Transport mechanisms
_ __ _   _________ __________

     In the first developer's release,  NetClasses  includes
TCP-    and    UDP-based    object   transport   mechanisms.
PostModern's Reliable Broadcast Protocol  (now  under  alpha
testing)  is a UDP-based layer for reliable object transport
in nonconnection-oriented environments.  The TCP,  UDP,  and
Reliable  Broadcast Protocol facilities are all organized as
C++ class libraries.

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

     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  ques-
tions in the correct context.

+    IMEC is a research institute focusing on  the  (automa-
     tion  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 ques-
     tion (although that may change).

+    So, one of the many things I am doing now, is to inves-
     tigate  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 pack-
     ages 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 mes-
     sage (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  actu-
ally  activated  by  the  changes I made. So it looks like I
will have to try again.