NetNews Usenet Archive 1992 #27

home *** CD-ROM | disk | FTP | other *** search

/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / cplus / 16483 < prev next >

Wrap

Text File | 1992-11-17 | 18.6 KB | 490 lines

Newsgroups: comp.lang.c++ Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!elroy.jpl.nasa.gov!sdd.hp.com!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!att!dptg!ucs!skdutta From: skdutta@ucs.att.com (Saumen Dutta) Subject: C++ Product List - Version 2.04 - Part 5/8 Message-ID: <1992Nov18.022826.624@ucs.att.com> Organization: AT&T Universal Card Services, Jacksonville FL Date: Wed, 18 Nov 1992 02:28:26 GMT Lines: 480 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.