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

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.

Newsgroups: comp.lang.c++