gbaciu@watcgl.waterloo.edu (George Baciu [CGL]) (02/24/90)
As many people have sent me enquiries about the NIH library,
I have decided to post the replies I have accumulated so far,
to my posting on:
Subject: Re: Comments on the NIH classes
Newsgroups: comp.lang.c++
In-Reply-To: gbaciu@watcgl.waterloo.edu's message of 14 Feb 90 17:28:50 GMT
Maybe, some other people will find this info useful.
-- George Baciu -------------------------------------------------
| GBaciu@watcgl.Waterloo.edu GBaciu@watcgl.UWaterloo.ca |
| * Computer Graphics Lab * |
| University of Waterloo - Waterloo, Ontario, Canada - N2L 3B5 |
------------------------------------------------------------------
--------------------------------- Start ----------------------------------
From ahvermen@watcgl.waterloo.edu
Date: Thu Feb 15 10:10:30 1990
To: gbaciu@watcgl
Organization: U. of Waterloo, Ontario
I found NIH classes large and cumbersome. I got sick of waiting forever
for my compiles because it had to link in 300K of code. On the plus
side, everything worked, and the container classes are nice to use. But
on the whole, I prefer my own style of small and simple.
I suspect that the NIH classes have improved considerably since I used
them, so don't take my complaints too seriously.
- Al
------------------------------------------------------------------------
From: Dr. James Coggins <coggins@cs.unc.edu>
Date: Thu, 15 Feb 90 09:37:32 EST
Organization: University Of North Carolina, Chapel Hill
The NIH class library is a grafting of the Smalltalk class hierarchy
into C++. It was originally a demonstation and learning project, and
it served its purpose well. It is now being adopted for real use
by many people who think it's a good platform for rapid prototyping
of real systems. They are wrong.
The Smalltalk strategy does not graft well onto C++. I have found the
memory load on the programmer to be INCREASED when using the NIH
classes with their type-dependent macros and junk, as compared to
good old C or FORTRAN. The complexity of the library makes changing
implementation difficult, and the library as a whole violates one
of Stroustrup's C++ design criteria, "You shouldn't have to pay for
what you don't use."
I will be presenting a paper at the C++ Technical Conference arguing
strongly in favor of building class libraries for the application
area and not for computer hacker capabilities. Only by making the
classes relevant to the client's real problems can we elevate discussions
about implementations to the application level where the client can
contribute to the software design. Also, the custom classes approach
helps the computer people to be certain that their work is really
addressing their client's needs.
I don't know many clients who care about polymorphic stacks and lists.
I do know clients who care about images, network nodes, anatomical
structures, telescopes, geological structures, ocean basins, airplane
wings, fluid flows, and so on.
I don't expect my message to be appreciated by computer hackers.
I expect a standing ovation from clients.
James Coggins
------------------------------------------------------------------------
From: vaughan%cadillac.cad.mcc.com@mcc.com (Paul Vaughan)
Date: Thu, 15 Feb 90 12:39:23 CST
Organization: MCC VLSI CAD Program
We make some use of the NIH stuff. Actually, we took the old OOPS
stuff and just stripped out some of the Object and Class structure
that we wanted. We don't use the library per se, largely because it
didn't compile with gnu g++ at the time. We've been thinking about
upgrading to the newer NIHL, given that people have been trying to
compile it for some time now.
We found it useful mainly as a design to follow. High performance
wasn't required and we haven't tried to port. Since we just stripped
out our own subset, we haven't had any problems modifying or
extending. Documentation was a problem at first--we learned to just
read the code. We're still waiting on the all encompassing book.
--
Paul Vaughan, MCC CAD Program | ARPA: vaughan@mcc.com | Phone: [512] 338-3639
Box 200195, Austin, TX 78720 | UUCP: ...!cs.utexas.edu!milano!cadillac!vaughan
------------------------------------------------------------------------
From: itkin@nrl-5570-gw.itd.nrl.navy.mil (David Itkin)
Date: Wed, 14 Feb 90 15:55:37 EST
We have developed a parallel event driven simulator. All our objects
are built as extensions to OOPS's OBJECT. This gives us for "free"
the printOn and storeOn and readFrom methods (assuming we have redifined
things correctly). Because we are running in parallel our objects
ctor must use shared memory. Therefore we can not use the existing OOPS
classes without modifying how they do memory allocation. (A 2.0 compiler
should solve this for us by allowing the overloading of new)
In general:
-usefulness
Very. Even if I don't use a class I get to see a lot of good
code. The read/write to disk is invaluable to our project.
-performance
Not a problem for us. Our bottlenecks are elsewhere.
-portability
The project was ported from a GP1000 to a TC2000. Very similar
architectures but very different compilers. The port was trivial.
-modification
As explained, all our objects are derived from OBJECT. Once you
have a template it is mechanical.
-limitations
As explained we can not make general use of existing classes because
of our memory allocation schemes. Again, this should go away with
a 2.0 compiler.
-documentation
Not bad considering this was free and so far bug free.
david itkin
------------------------------------------------------------------------
From: Jari Alasuvanto <jaa@hutcs.hut.fi>
Date: Thu, 15 Feb 90 09:55:19 +0200
Organization: Helsinki University of Technology, Finland
In article <13379@watcgl.waterloo.edu> you write:
>
We've been using OOPS (NIHlib) for two-three years in our project and have
been really satisfied with it. Our hardware has been:
- SUN-3s
- HP9000/300s
And we have also ported our software to SUN386i. We have been using the
Glockenspiel (Oasys) C++ (1.2 compatible).
> - usefulness vs in-house developed (semi) general object classes
- Useful classes - most of the stuff is already done there and so
there is no need for own classes. Most of our own classes are
derived from Object and use OOPS classes in their members. I guess
you could also develop a class library of your own - if you feel
like reinventing the wheel - Keith Gorlen has done a good job:
I have not found more than one real bug in OOPS (in OrderedCltn -
if you added objects to that until 16 objects and then started
removing, you ended up with an endless loop).
> - performance
- Fast enough for our problems.
> - portability
- Disgarding the coroutine stuff (Process etc.) totally portable.
Some modification to your native (C++) headers may be necessary.
If you need a port of the assembler stuff, I think most of the
UNIX hardware has already been done by someone. Porting to non-
UNIX platforms may be more laborous.
> - ease of modifying/expanding the classes.
- Just take a look at the TEMPLATES supplied with the library.
Writing a NIHlib class requires a few members so that the instances
of that class can be used by the library (hash, compare etc.).
HINT: Never leave a virtual function first defined in Object empty
thinking that it will not be used. At least make it write to
cout or something else. This saves some debugging !!!
> - limitations
- Impossible to directly stick non-NIHlib objects to collections
(a wrapper class is needed)
- nil name conflict when using a library with "#define nil 0"
(always include one NIHlib (derived) class first)
- Storing objects to files has some limitations, like only one file
stream can be used at the same time.
Hope this was helpful,
Jari Alasuvanto
Lab. of Information Proc. Science, Helsinki Univ. of Techology, Finland
Internet: jaa@hutcs.hut.fi Bitnet: jaa%finhutcs.bitnet
tel: +358-0-451 3236 fax: +358-0-465 077
------------------------------------------------------------------------
From: lisch@mentor.com (Ray Lischner)
Date: Fri, 16 Feb 90 11:15:55 PST
>I am interested in knowing how other people may have found the NIH
>classes in their projects. Things of general interest would be:
> - usefulness vs in-house developed (semi) general object classes
My employer has a division working on C++ classes. The classes are
meant to be general purpose (lists, hash tables, strings, etc.). I
use the NIH classes because they are more useful and are easier to use.
For example, the in-house hash tables are designed to work only with
integer keys or character string keys. Hash tables cannot grow once
created. We use NIH Dictionaries instead, letting us use any object
as a key, with a table that can grow as needed.
- performance
I have not made any measurements yet. One problem is that the NIH classes
use inline functions a lot more than cfront can handle. The result is many
static functions. Our programs are therefore rather large. I intend
to remove most of the inlines to see what kind of difference it makes.
- portability
The NIH classes are more portable than the in-house classes. Many of the
programmers here have used only Apollos, or mostly Apollos, and do not
know how to write portable software. The party line is that it will take
about three months to port the in-house classes from the Apollo to the Sun.
I claim I can port my local modifications to the NIH classes in one day.
- ease of modifying/expanding the classes.
I had to rename all the classes to prevent clashes with the in-house names.
I also added some things, such as a Filename class (derived from String).
Understanding and modifying the NIH classes has proved easy. So far, I have
not encountered any defects in the NIH classes themselves.
- limitations
What limitations?
- documentation
What documentation?
--------------------------------- End ----------------------------------