Prev: Evaluation(NIHCL)
Up: NIHCL
Top: Top
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 modified it to work with the Object Oriented Database
(ObjectStore from Object Design, Inc.).
Personally, I would consider buying a class library (such as the
Booch Componants) before getting a free copy of a class library
from 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 modified NIHCL
go, because we would not get anyone to buy it and others will
have modified their copy's of NIHCL soon to work with an OODBMS
anyway). The Booch componants cost well less than $1000 (and
you get source plus the reputation of a company behind it) and
will save thousands in development time. Even NIHCL is worth
considering. From experience, its not as slow as some people
make out. It does go against the "C++ philosophy" in some respects,
but it does have some advantages that fit well in some projects.
I feel that no current library will address all the needs off
all applications. Certainly NIHCL does not (and COOL, although I
have not seen it). But some projects will fit well with the
various libraries (ours fit with NIHCL very well). But also
be forwarned, getting a class library is like getting a new
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 interchangeably in the various
collections, such as sets, bags, dictionaries. You can use
a string as an key to a dictionary, as well as time, date, even
another collection.
- 2. It is relatively bug free and stable. We have encountered
very few bugs, and most of them dealt with bugs in the
particular C++ compiler we were using.
- 3. A fair number of people are using it. You can appeal to the
Internet and get timely help on questions and problems.
Keith Gorlen himself (one of the authors of NIHCL) will
assist time to time.
- 4. Run time type identification. While this is not always
useful or even advantagous to use, there are certain
times when run time type identification greatly simplifies
the design and use of certain capabilities. One of these
is being able to send heterogenious Inter-Process
Communication objects. Sometimes applications need
truely dynamic objects at run time (e.g., in some database
applications or applications where the operator needs
to manipulate and create lots of very flexable objects).
[soap box: this feature would be useful in the C++
language itself, in certain very limited situations, but one
reason it is not included is that programmers would be
tempted to abuse it. I feel that the philosophy of C and
C++ is to give you the power and you are responsible to
learn how to use it right.]
- 5. "Safe" virtual base castdowns. These classes can be used
in a multiple inheritence design (again, this has limited
use in good designs, but when you need it, its very
useful!). There is a consistent set of member functions
that allow you to safely castdown from a virtual base class
pointer to a derived class pointer. Normally you want to
use the virtual member function mechanism, but in certain
limited situations (e.g., where you are forced to use
heterogenous collections) this can be very useful.
- 6. Support for shallow and deep copies. If you follow the
discipline of NIHCL classes, your objects will be able
to de shallow and deep copies of itself and all of its
member pointers. Previously copied objects will be handled
"automagically".
- 7. Stream and file I/O. You can use the NIHCL I/O features
to make a "poor man's database". If you follow the NIHCL
discipline, all your objects can be written to a flat file
(and read in) very easily. You can also send your objects
via Inter-Process Communcation (IPC) very easily. All you
have to do is create a simple IPC mechanism.
- 8. A variety of polymorphic heterogenous collections.
- 9. Good documentation. First, understand that there is never
enough documentation in any package! But given this, Gorlen
and company have published a book and have a good
reference manual on the class library.
- 10. Complete source code.
- 11. Portable code. It can be built on a wide variety of
systems with a wide variety of C++ compilers.
- 12. No copyright or license (but beware of Regex). All of the
NIHCL library is public domain except Regex. There is some
controversy about Regex (since it has the GNU Copyleft
agreement). Some, like myself believe the simple removal
of Regex gets around the Copyleft problem. Others say
that is not enough. Check your legal counsel to be sure.
There are some disadvantages to NIHCL, to be sure. However there
has been a lot of NIHCL bashing around. As I stated, no class
library is a perfect fit for every application and care should
be taken not to force fit a class library into an application
not well suited for it. Some disadvantages of NIHCL include:
- 1. Name clashes with existing libraries. Names like "Object",
and "String" are used in other places (such as X-Windows and
Motif). We had to modify our copy of NIHCL so that the
classes were prepended with the letters "Nih", so Object and
String, for instance, became NihObject and NihString. This
eliminated the clash. There was a close call with the typedef
of bool in NIHCL, since X-Windows/Motif have a Bool, but
fortunatly the case is different. New class libraries
should consider how they can minimize name clashes.
- 2. The polomorphic single class hierarchy style of classes
evades compile time type checking. This means your
bugs are caught more often in run time than if you had
a librayy which used the derived classes more often.
This is a trade-off. The single class hierarchy provides
a number of advantages, but at a cost.
- 3. A class ultimately derived from the NIHCL Object class
(which is every class) cannot be defined as a template
class. This does not prevent you from having its member
be intances of template classes (which we have done a number
of times). There are many reasons this cannot be done,
part of which is the dynamic run time type identification
mechanism. Again, there is a trade-off.
- 4. There are some single-theaded (non-reentrant) sections of
code (such as in the deep copy mechanism). This is something
to watch for in any class library.
- 5. The NIHCL discipline. Many people 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 discipline is not that difficult,
and following it pays off with NIHCL's advantages.
- 6. Some execution inefficiencies. Due to the polymorhic, single
inheretence style of NIHCL, some things are done that other
class libraries would avoid (such as castdown and checking
an object's type before proceeding to do what you want in
some of the code). This does cost some execution overhead, but
we found for us that the library is fast enough). Again, these
are tradeoff issues.
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.