3.4.5. Bibliography

3.4.6. NetComments

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.

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

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.