NetNews Usenet Archive 1992 #19

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

/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / cplus / 12876 < prev next >

Wrap

Text File | 1992-08-25 | 73.0 KB | 1,982 lines

Newsgroups: comp.lang.c++ Path: sparky!uunet!decwrl!concert!accura_nc!news From: chandra@bongoaisg.com (Periannan Chandrasekaran) Subject: C++ Product List - Version 2.03 - PART 4/5 Message-ID: <1992Aug25.212839.3237@aisg.com> Sender: news@aisg.com Reply-To: chandra@bongoaisg.com (Periannan Chandrasekaran) Organization: Accura Innovative Services Inc. Date: Tue, 25 Aug 92 21:28:39 GMT Lines: 1970 3. Libraries _ _________ A List of Class Libraries are available below. Refer to the individual items for detail descriptions. The description includes evaluation criteria on these libraries. Evaluation is based on Documentation, Usability, Extensibility, Permor- mance, Sensibleness etc. 3.1. OATH - Object-oriented Abstract Type Hierarchy. _ _ ____ ______ ________ ________ ____ _________ + Written by: Brian M. Kennedy Freeware available via anonymous ftp from site csc.ti.com (192.94.94.1) in the file /pub/oath.tar.Z. + The Reference Manual states it has only been compiled with AT&T cfront 2.1 compatible compilers. No templates and no exception handling. + OATH (Object-oriented Abstract Type Hierarchy) was designed as an experiment in increasing object-oriented reuse. It has a fairly high learning curve, but poten- tially higher gains if you are looking for a more flex- ible and robust abstraction. It is completely unsup- ported. Please refer to the menu below to get to the detail information about OATH features. + Information provided by Marco Pace (MPACE@ESOC.BITNET) and Brian Kennedy (kennedy@intellection.com) 3.1.1. OATH Introduction _ _ _ ____ ____________ OATH instantiates an approach to C++ class hierarchy design that exploits subtyping polymorphism, provides greater implementation independence, and supports implicit memory management of its objects. It is implemented via parallel hierarchies of internal types and accessors (a concept similar to that of the "smart pointers", but improved compared to them). The internal types contain the object representation (the data members) and the virtual functions. The accessor types contain all of the externally accessible functions of the abstract types. Two main design goals of OATH were: To provide a meaningful abstract type hierarchy that is consistent with the concepts being modelled by utilizing a strict subtyping approach to hierarchy design. Starting from the the idea that a type hierarchy should be designed to reflect the behaviour of the objects being modelled and not to reflect the most convenient computer representation of objects, the designer of OATH gave priority to the sub- typing (inheriting functionality) aspect over the code reuse (inheriting implementation) aspect. Given a consistent abstract type hierarchy, implementation classes can be added at the leaves of the hierarchy (see figure later on) to implement the behaviour of the abstract types. Code reuse can be exploited at this phase, but should not enter into the design of the abstract type hierarchy. To provide robust garbage collection (GC) of OATH objects, fully implemented within a portable C++ class library. The garbage collection mechanism is a hybrid reference counting and marking algorithm capable of collecting all garbage (including circular references). The programmer can select one of four garbage collection modes at compile time: no GC, incremental GC, stop-and-collect, or combined. 3.1.2. Features _ _ _ ________ OATH's main features are the following: It provides heterogeneous container classes It provides dynamic type determination in the form of "safe casts" It provides accessors to access OATH objects. For each OATH type there is a corresponding accessor class (an accessor lies between a C++ pointer and a C++ refer- ence). The accessors can be initialized and assigned OATH objects to access. However, any other operation on an acces- sor is applied directly to the abstract object it accesses. 3.1.3. Hierarchy _ _ _ _________ The class hierarchy provided by OATH is the following: + obj + pos * pdPos + listPos * dlPos + stringPos * minStringPos + bag + set * hashSet + finiteSet # characterSet + queue + seq + lifoQueue * pdlQueue + fifoQueue + deq + list * dlList + string * minString + table # stringTable + token # character # localToken # stringToken + complex + real + rational + integer * bigInteger where the classes preceded by '+' are abstract types, the classes preceded by '*' are implementation types, and the classes preceded by '#' are "abstract implementation types". (A visually more readable version of this hierarchy can be found in [1], Figure 1 <see bibliography>.) 3.1.4. Evaluation _ _ _ __________ + Documentation: The documentation is very concise (probably too much) and lacks examples. Due to its conciseness sometimes it is not easy to understand and somehow it is cryptic. + Usability: OATH provides a wide set of classes. It does not seem easy to use the class services provided, especially for a beginner. Services that you would expect to find at a given level of the hierarchy sometimes are not there and you have to go upwards through the tree to find them, sometimes with names not directly related to what you are using. The services provided are not many, but their interface is simple to use. + Extensibility: This feature was not evaluated directly. However, a brief discussion on the way to extend the existing class library is present in the OATH Reference Manual [2] (OATH(30), section Developing New OATH Types). + Sensibleness: The available classes are perhaps too abstract. I would have preferred less abstract and more "practical" classes, but probably this would have been against the basic assumptions their designers of OATH made. Among the, there are classes for integers, rational, real, complex. + Miscellaneous: The provided hierarchy is that of a tree, where only single inheritance is supported. No templates (parameterized types) are provided, and no exception handling as well. Garbage collection is supported and appears to be even sophisticated in terms of the kinds of GC available. 3.1.5. Bibliography _ _ _ ____________ 1. Brian M.Kennedy, The Features of the Object-oriented Abstract Type Hierarchy, Computer Systems Laboratory, Computer Science Center, Texas Instrument, 26 August 1991 2. OATH Reference Manual (OATH 0.8), 26 August 1991 3.1.6. NetComments _ _ _ ___________ 3.2. COOL - C++ Object Oriented Library _ _ ____ _ ______ ________ _______ + It is available from csc.ti.com (192.94.94.1) in file /pub/COOL.tar.Z. + COOL can be used with the AT&T C++ translator (cfront) version 2.0. + COOL is a collection of classes, templates, and macros for use by C++ programmers writing complex applica- tions. It raises the level of abstraction for the pro- grammer to concentrate on the problem domain, not on implementing base data structures, macros, and classes. + Information provided by Marco Pace (MPACE@ESOC.BITNET) 3.2.1. Introduction _ _ _ ____________ COOL is a collection of classes, templates, and macros for use by C++ programmers writing complex applications. It raises the level of abstraction for the programmer to con- centrate on the problem domain, not on implementing base data structures, macros, and classes. In addition, COOL also provides a system independent software platform on top of which applications are built, since COOL encapsulates such system specific functionality as date/time and exception handling. For a more detailed description of COOL and its features, including a thorough discussion on the rationale for the design and implementa- tion choices see [5]. 3.2.2. Features _ _ _ ________ The class library hierarchy is basically forest, but it implements a rather flat inheritance tree. All complex classes are derived from the Generic class due to space efficiency concerns. COOL does not seem to provide multiple inheritance. COOL's exception handling provides a reise, handle, and proceed mechanism. Exception and exception handling classes are provided for this purpose. COOL provides parameterized templates. The peculiarity of COOL is that to allow this it extends the standard C++ preprocessor to recognize the notation intro- duced to specify templates. In other words, the programs written using COOL are not com- piled using the standard CC, but using CCC (COOL C++ Control Program), which is an extension of the CC compiler. It does not seem to include garbage collection. 3.2.3. Subclasses _ _ _ __________ The classes provided by the library are several, and they are listed here: Pair <T1,T2> Range Range <Type> Rational Complex Generic String Gen_String Regexp Vector Vector <Type> Association <Pair<T1,T2>> List_Node List_Node <Type> List List <Type> Date_Time Timer Bit_Set Exception Warning Error System_Error Fatal System_Signal Verify_Error Excp_Handler Jump_Handler Hash_Table Set Hash_Table <Key,Value> Package Matrix Matrix <Type> Queue Queue <Type> Random Stack Stack <Type> Symbol Binary_Node Binary_Node <Type> Binary_Tree Binary_Tree <Type> AVL_Tree <Type> N_Node <Type> D_Node <Type> N_Tree <Type,Node,Child> 3.2.4. Evaluation _ _ _ __________ Easy to use, the services provided are really a lot. The extendibility has not been tested, although this seems to be one of the feature of the library, which issue is dealt with in part of section 14 of the User Manual (See Bibliography). Performance not evaluated It does not seem to be supported by the developers. The installation of COOL was a tragedy: several problems were found, ranging from files not found to compile errors to link errors, etc. After a couple of days of trials the installation was aban- doned, although a post was made to the net to see if some- body could help on that. I got some answers after some time and I found out that other people had similar installation problems. They sug- gested some solutions which I haven't tried yet. It is interesting to note that the authors of COOL have written a paper on which they analyse the lessons learned from the usage of the library, what they would keep of it and what they would change in its design, and so on (See Bibliogra- phy). 3.2.5. Bibliography _ _ _ ____________ M.Fontana et al., COOL - C++ Object-Oriented Library, Texas Instrument. COOL User Manual, March 1990, Texas Instruments Inc. M.Fontana & M.Neath, Checked Out and Long Overdue: Experi- ences in the Design of a C++ Class Library, Texas Instrument Inc. 3.2.6. NetComments _ _ _ ___________ From: bergquis@gdc.com (Brett Bergquist) Did you get the paper about COOL "Checked Out and Long Over- due: Experiences in the Design of a C++ Class Library". In this paper, the authors discuss the strengths and weaknesses of the design of COOL. A couple of points that they men- tioned that they would do differently would be to simplify the dependencies between classes by using MI. Also they would factor out the use of the symbolic and package mechan- ism. Performance is not mentioned as an issue. 3.3. LEDA - Library of Efficient Data types and Algorithms _ _ ____ _______ __ _________ ____ _____ ___ __________ + Writen by: Stefan Naeher (stefan@mpi-sb.mpg.de) Anonymous ftp from host ftp.cs.uni-sb.de (134.96.252.31) in directory pub/LEDA. + - LEDA can be used with all cfront and GNU C++ com- pilers - it is provided as source code - there is no fee for non-commercial use + It consists of a sizeable collection of data types and algorithm: this includes stacks, queues, lists, sets, dictionaries, ordered sequences, partitions, priority queues, directed, undirected, and planar graphs, lines, points, planes and basic algorithms in graph and net- work theory and computational geometry + Information provided by Stefan Naeher(stefan@mpi- sb.mpg.de) and MARCO PACE (MPACE@ESOC.BITNET) 3.3.1. Introduction _ _ _ ____________ 3.3.2. Features _ _ _ ________ LEDA is a library of efficient data types and algo- rithms. Its main features are: a sizable collection of data types and algorithms: this includes stacks, queues, lists, sets, dictionaries, ordered sequences, partitions, priority queues, directed, undirected, and planar graphs, lines, points, planes and basic algorithms in graph and network theory and computa- tional geometry; the precise and readable specification of data types and algorithms; the inclusion of many of the most recent and efficient implementations; a comfortable data type graph; its extendibility; its ease of use. The library employs a strict separation between abstract data types and the con- crete data structures used to implement them, parameterized data types, and object oriented programming. 3.3.3. Classes _ _ _ _______ The classes provided by the library are several, and they are listed here: Simple Data Types Boolean (bool) Real Numbers (real) Strings (string) Real-valued vectors (vector) Real-valued matrices (matrix) Basic Data Types One Dimensional Arrays (array) Two Dimensional Arrays (array2) Stacks (stack) Queues (queue) Bounded Stacks (b_stack) Bounded Queues (b_queue) Lists (list) Sets (set) Integer Sets (int_set) Partitions (partition) Dynamic collections of trees (tree_collection) Priority Queues and Dictionaries Priority Queues (priority_queue) Bounded Priority Queues (b_priority_queue) Dictionaries (dictionary) Dictionary Arrays (d_array) Hashing Arrays (h_array) Sorted Sequences (sortseq) Persistent Dictionaries (p_dictionary) Graphs and Related Data Types Graphs (graph) Undirected Graphs (ugraph) Planar Maps (planar_map) Parametrized Graphs (GRAPH) Parametrized Undirected Graphs (UGRAPH) Parametrized Planar Maps (PLANAR_MAP) Node and Edge Arrays (node_array, edge_array) Two Dimensional Node Arrays (node_matrix) Node and Edge Sets (node_set, edge_set) Node Partitions (node_partition) Node Priority Queues (node_pq) Two-Dimensional Geometry Two-Dimensional Dictionaries (d2_dictionary) Sets of Points (point_set) Sets of Intervals (interval_set) Sets of Parallel Segments (segment_set) Planar Subdivision (subdivision) Graphic Windows (window) 3.3.4. Evaluation _ _ _ __________ The class library hierarchy is a forest, and it does not seem to provide multiple inheritance. Some exception handling is provided, but it seems to be quite raw, in the sense that it usually ends with the program abortion. However, the user can write its own error handler, but its function prototype has to be void handler(int, char*) where the first parameter is an error number and the second is an error message. LEDA provides parameterized templates. It does not seem to include garbage collection. It is not clear whether it is supported in some way by the developers. The installation of LEDA was quite simple and took a couple of hours. One problem only was found dur- ing the execution of the makefile, namely some include files needed for the creation of the graphics library for Sunview (in which we were not interested). After this the test pro- grams were created without problems. The execution of the test programs was carried out, but no description of what they are supposed to do and/or what input they expected was found. A few of them run without problems, others issued error messages, others aborted after a core dump. The set of classes provided is quite large, the classes themselves are easy to use, the services provided sufficient (although sometimes the set is not "rich" enough), the interface simple when the user has gone through section 1 of the User Manual [4], which explains the basics. The extendibility has not been tested, although this seems to be one of the features of the library, on which issue a brief discussion appears in section IV of the manual (See Bibliography). After some time spent trying to format the documenta- tion (it is available only in TEX format), we managed to have it printed. The documentation appears to be linear, easy to read (as promised by the authors), concise. It does not contain, however, examples of the way the classes have to be used. 3.3.5. Bibliography _ _ _ ____________ S.Naeher, LEDA User Manual (Version 2.1), Max-Planck- Institut fuer Informatik, Saarbruecken 3.3.6. NetComments _ _ _ ___________ 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. 3.9. Zinc _ _ ____ + Platform: DOS + This was the most commonly mentioned library for DOS. It was generally praised. Several people noted the documentation could be more helpful but the tech sup- port phone people seemed to make up for that failing. One respondent noted his release didn't handle variable fonts but said that may be fixed in the current release. The only respondant to explicitly mention using Zinc in graphics mode found it "intolerably slow." + Information provided by bennett@math.ksu.edu 3.9.1. Netcomments _ _ _ ___________ From abw@dsbc.icl.co.uk (Andy Wardley) POINTS FOR.... The Zinc Interface Library "...gives a fast nice GUI, that somewhat reminds me of windows.", "the library is well-designed." and "you can get it to do most things and its Windows capabilities are at last getting into shape." "I will also add that I'm very impressed with the company. My friend who has it told me he got an update in the mail without even asking and he was offered a Windows version (beta?) from their BBS for free. Very impressive for a software company." "For DOS I've heard it's very good but their Windows version is buggy, but I think they're coming out with a much-improved version" "See a recent c.l.c++ summary of PC GUI libs -- it did well." "We are developing DOS applications using Zinc (with Borland BC++) and are reasonably well-satisfied with it. Our application is not pushing Zinc very hard, however. We are using it in graphics mode, although we are mostly putting text objects & menus on the screen." "They provide much sample code & studying it is essential." "Tech support is free & good; they have a BBS." "But as a UI library it is really great. They have just released version 2.01 with a lot of bug fixes this means it is pretty solid now." "The design tool saves a lot of time. The documentation is extensive and good. There is a lot of good example code too." POINTS AGAINST... "The Zinc designer has lots of bugs and quirks, but you can get around them" "Some things could have been better done, and is surely better implemented in the OS of the Macintosh." "For top-professional use there are some limitations. We even considered returning the package. But if you can live without a 100% product, but rather a late beta, then this is for you." "It took me a while to get into their approach, partly because their documentation goes into detail but seems to leave out overviews." "The library is somewhat lower level than I would like. For example, check boxes and dialog boxes are not built-in, but they provide examples to show you how to build them." "They do not currently support variable fonts, although their tech support told me it is planned for a future release." "Incidentally, applications seem to be pretty large with it." "The major problem I have with it is I wish it worked with a DOS extender under Zortech" OTHER POINTS... "If you can't find what you need in the docs, then look in the sources" "Rumours says that they are working on Macintosh, OS/2 and UNIX version too. Apple programmers has seen an early version of the mac version." REVIEWS IN... Dr. Dobb's (12/90), Computer Language (12/90) PC Week (12/26?/91). Byte (01/91) SUMMARY... It seems that generally, people are happy with it and think it's a good UI library. The older version (pre V2.01) was slightly buggy, particularly in the designer and the MS windows parts, but this has mostly been fixed in V2.01. Most of the bugs had work arounds. The library is fast and flexible, although radio buttons, check boxes etc, are not built in classes and have to be derived from existing classes - fairly easy for the more advanced programmer - maybe slightly difficult for others.. Documentation, was reasonable in the older versions and is now greatly improved in the new one, with over 1100 pages. Technical support from the company was generally regarded as VERY good. Thanks to people who contributed... pope@daimi.aau.dk (Povl H. Pedersen) jamshid@emx.utexas.edu (Jamish Afshar) ferdie@coyote.datalog.com (fred jarvis) borkoles@dcs.qmw.ac.uk ajb@ee.wpi.edu (Arthur J Butler) 3.10. Starview C++ Graphical User Interface Library _ __ ________ _ _________ ____ _________ _______ + Designed to be independent of OS and Hardware vendors + Author: Andreas Meyer, STAR DIVISION Contact: STAR DIVISION GmbH Andreas Junge Zum Elfenbruch 5-11 D-2120 Lueneburg Phone: ++49 4131 700943 Fax: ++49 4131 700921 Email: ...!unido!starlab!aj + The development of large applications for Graphical User Interfaces (GUI's) like MS-WINDOWS, MS Presenta- tion Manager or OSF/Motif is a very time consuming job. In addition, the application programming interfaces (API's) of the different GUI's are totally incompatible making a direct port of source code to another GUI platform impossible, almost all code driving the user's interface must be re-written by the programmer. Two years ago, STAR DIVISION decided to develop a set of new applications for GUI's which should fulfill the requirements of modern software standards this entails: - Portability between the operating systems MS-DOS, OS/2, Macintosh and different UNIX flavours - At least portable between the GUI's MS-WINDOWS, MS-Presentation Manager, MacApp and OSF/Motif - Fulfillment of the requirements of the different GUI Style Guide's - Data exchange and direct communication between the applications in homogeneous and heterogeneous net- works (groupware approach) Because of the indifferent "political" situation (i.e. MS-DOS or OS/2 or UNIX or everything, WINDOWS or PM or X.11 or everything) we decided to develop a set of tools which helps us to be mostly independent from the decisions of the OS and hardware vendors. In addition tools help to improve productivity and are the base for a successful software project. C++ is the programming language of our choice because we could use our large experiences in C programming and C++ provides all major advantages of Object Oriented Programming (OOP) that is - from our point of view - the best available paradigm for complex software development today. + Information provided by Dave Riches (dsr@bnr.co.uk) 3.11. TEGL Library _ __ ____ _______ + Supported on Borland C++ + Address not known + Price around $99 + One respondant faulted it for "ignoring CUA" while another praised it as having the look and feel of presentation manager. The source code apparently is not highly polished and it does recommend using more than one mouse button. + Information provided by Andrew G. Bennett (bennett@math.ksu.edu) 3.12. Linpack Math Library _ __ _______ ____ _______ + MSDOS, UNIX, and many other platforms including a vec- torised version of CRAY + Commercial software from: Rogue Wave Software Inc. 1325 NW 9th Street, Corvallis, OR, 97330, (503) 754-2311. + No information on the compatability with the proposed ANSI/ISO standard + The classes are available now. Prices range from $199 to $995 for Matrix.h++ and $299 to $1195 for Linpack.h++. + Linpack.h++ is an object-oriented C++ version of the widely used Fortran library. Linpack.h++ includes 100% of the functionality of the Fortran version, plus much more. Because Linpack.h++ is written in C++ it has capabilities that far exceed the Fortran version. Both Matrix.h++ and Linpack.h++ are completely compati- ble with Rogue Wave's other C++ class libraries, Tools.h++ and Math.h++, which are accepted standards in the industry. Matrix.h++ includes all the funtionality of Math.h++. For example: general matrices, vectors, statistics, complex numbers, Fast Forier Transformation (FFT's), etc. Matrix.h++ adds specialized matrix classes such as banded, symmetric, positive-definite, Hermitian, tridiagonal, etc. Because Matrix.h++ includes Math.h++, it can take advantage of Math.h++'s highly optimized low-level assembly routines, making it fast as well as graceful. + Information provided by Dave Riches (dsr@bnr.co.uk) 3.13. Objectkit\C++ 1.0 _ __ ___________ _ _ + Commercial software available from: ParcPlace Systems, Inc. 999 E. Arques Ave. Sunnyvale, CA 94086 Tel: (408)481-9090 Sales: 1-800-759-7272 email: info@parcplace.com + Features the AT&T Standard Library Extensions: - variable length bit strings - adjustable 1-d vectors of parameterized type (implemented via macros) - classes for date, time-of-day, timezone and time- duration arithmetic - finite state machine classes - simple exception handling using Objection classes - parameterized linked lists (parameterization via macros) - associative arrays (i.e., keys/value associations) - fast memory allocation class: Pool - program execution time measurement class: Stopwatch - String class and specializations of iostream and streambuf for String As a convenience for purchasers, Objectkit\C++ 1.0 also includes the NIHCL and InterViews class libraries as *unsupported* free software. Objectkit\C++ OI - based on technology licensed from Solbourne, OI is a C++ class library for rapid develop- ment of graphical user-interfaces that allow runtime selection of OSF/Motif or OPENlOOK look-and-feel. + Information provided by Mike Khaw (khaw@parcplace.com) 3.14. MFC (Microsoft Foundation Class Library) _ __ ___ _________ __________ _____ _______ + Included with the MS C7 compiler. Please refer to the Microsoft Compiler section. + Includes complete source. Supports all standard memory models. Supports DLLs [dynamic link libaries aka shared Libraries]. Also sometimes referred to as AFX "Application FrameworX", and/or "The C++ API for Microsoft Windows" + Information provided by: jimad@microsoft.com 3.14.1. Introduction _ __ _ ____________ MFC's primary design goals are to provide an efficient, compact, fast, easy-to-use, typesafe, and portable version of the Windows API for the C++ programmer. A secondary goal is to provide Collection classes, diagnostic memory manage- ment, etc, for DOS and Windows programmers. MFC is imple- mented without the use of language-extensions, allowing the library to be ported to other C++ conformant compilers [although right now MFC is only shipping with the C7 com- piler.] MFC closely follows the naming conventions and use of the "C" Windows API so that programmers experienced in Windows programming find it easy to switch from C to the C++ APIs. However the "lower level" aspects of Windows program- ming are improved upon by MFC. For example wparam, lparam packing/unpacking is handled automatically and in a type safe manner. Also the main message loop is handled automat- ically. Switch statements are replaced with the use of vir- tual functions and/or cached message dispatch that avoid slow message searches. Finally, the C++ Windows classes are implemented in such a manner as to remain compatible with the C implementations, such that Windows programmers can still use the C APIs where desired, and/or can mix old implementations of Windows classes implemented in "C" with new Windows classes written in C++. Namespace collisions with other libraries are avoided by using an uppercase "C" prefix on the MFC Windows classes. MFC includes support for OLE, DDE, Multimedia, and Windows for Pen Computing. Appli- cations written using MFC are automatically pen aware. 3.14.2. Window Application Classes _ __ _ ______ ___________ _______ CWinApp Main windows application class Window Classes CWnd Base class for all windows CFrameWnd Main window base class for the SDI (Single Document Interface) desktop window CMDIFrameWnd Base class for the MDI (Multiple Document Interface) desktop window CMDIChildWnd Base class for MDI child windows CDialog Base class for modeless dialog windows CModalDialog Base class for modal dialog windows CButton Button control windows CComboBox Combo box control windows CEdit Edit control windows CListBox List box control windows CScrollBar Scroll bar control windows CStatic Static control windows GDI (Graphical Device Interface) Classes CDC Base class for display contexts CClientDC Display contexts for client areas of windows CMetaFileDC Metafile device contexts CPaintDC Display contexts used in <OnPaint> member functions CWindowDC Display contexts for entire windows CGdiObject Base class for GDI drawing tools CBitmap GDI physical bitmaps CBrush GDI physical brushes CFont GDI physical fonts CPalette GDI physical palettes CPen GDI physical pens CRgn GDI physical regions Other Windows Classes CMenu Menu structures CPoint (X, Y) points in a device context CSize Relative positions or coordinate pairs CRect Rectangular regions in a device context OLE (Object Linking and Embedding) Classes OLE Classes Object Linking and Embedding Classes Run-Time Object Model Class CObject Root class in the Foundation class hierarchy File Classes CFile Binary disk files CMemFile In-memory files CStdioFile Buffered stream disk files, usually text mode Object Input/Output CArchive Persistent storage for objects CDumpContext Destinations for diagnostic output Exceptions CException Abstract base class for exceptions CArchiveException Archive-specific exceptions CFileException File-specific exceptions CMemoryException Out of memory exceptions CNotSupportedException Function not supported exceptions CResourceException Windows resource not found exceptions Collections CByteArray Arrays of bytes CDWordArray Arrays of 32-bit double-words CObArray Arrays of CObject pointers CPtrArray Arrays of void pointers CStringArray Arrays of strings CWordArray Arrays of 16-bit words <template array class> CObList Lists of CObject pointers CPtrList Lists of void pointers CStringList List of strings <template list class> CMapPtrToWord Mappings of void pointers to 16-bit words CMapPtrToPtr Mappings of void pointers to void pointers CMapStringToOb Mappings of strings to CObject pointers CMapStringToPtr Mappings of void pointers to CObject pointers CMapStringToString Mappings of strings to strings CMapWordToOb Mappings of 16-bit words to CObject pointers CMapWordToPtr Mappings of 16-bit words to void pointers <template map class> Miscellaneous Support Classes CString Character strings CTime Absolute time and date values CTimeSpan Relative time and date values Global Functionality Diagnostic Services Global memory diagnostic functions and macros (Debug only) Exception Processing Global exception throwing and catching functions and macros Message-Map Reference CWnd message map entries with message-handler function prototypes 3.15. NetClasses _ __ __________ + Commercial software available from: PostModern Computing Technologies, Inc. 1032 Elwell Court, Suite 240 Palo Alto, California 94303 Telephone: (415) 967-6169 Facsimile: (415) 967-6212 Email: plambeck@cs.stanford.edu + No information on compatability of the future ANSI/ISO standard. + NetClasses is a set of C++ class libraries for distri- buted object-oriented communications that will begin beta testing June 15 and is scheduled for production release in the 3rd quarter of 1992. + Information provided by Thane E. Plambeck <plambeck@cs.stanford.edu> 3.15.1. Introduction _ __ _ ____________ One of the major stumbling blocks of developing and fielding complex distributed applications is the difficulty in implementing and debugging using existing communication tools. The focus of the NetClasses architecture has been to provide the tools necessary for programmers to develop com- plex distributed applications without having to deal with the esoteric details of low-level communications. NetClasses is a set of C++ class libraries that is organized as a software toolkit. The typical user of the NetClasses libraries will be a distributed systems application developer who requires an object-oriented framework for dis- tributed, message-passing based programming. By linking the appropriate NetClasses libraries, application programmers are then able to: + Transport objects over a network. Currently, there are three object varieties that NetC- lasses can transport: 1. Arbitrary C++ objects---once derived from PostModern's TransObject class 2. arbitrary NIH-derived objects; and provide an object-oriented data transport in which the struc- ture and organization of network transportable objects is specified externally in configurable files using a simple, programming language independent abstract syntax notation, the NetC- lasses Abstract Syntax Notation (NASN). + Perform remote method invocations (RMI) Using RMI, an application on machine B can invoke a method on machine A. RMI insulates distributed applica- tions from the complexity inherent in traditional, RPC-based distributed systems development tools such as protocol compilers, TCP/IP code writing, and detailed socket handling. RMI makes fault tolerance and connec- tion management transparent to the application program- mer. The RMI layer is built on top of the distributed services package that is described below. + Build complex information distribution systems on top of Distributed Services, PostModern Computing's object-oriented approach to client-server connection management and fault tolerance. + Use the NetClasses application programmer interface in order to create, manipulate, and destroy typed objects given NetClasses Typed Object data type definitions. (NIH-derived and native C++ objects are created, mani- pulated and destroyed from C++ itself). + Read and write all three varieties of NetClasses- transportable objects on streams using machine- independent external representations. All three varieties of objects can be stored to and read from files. 3.15.2. Objects as transportable data _ __ _ _______ __ _____________ ____ One of the most common needs in distributed applica- tions development is the ability to ship objects over a net- work. Currently, when data has to move from one machine to another this is usually done using hard-coded structures over a low-level communications interface such as Berkeley sockets or the System V Transport Layer Interface. Moving data in this way has several disadvantages: + If the format of the data changes, e.g. a new field must be added to a structure, all programs using that structure must be recompiled, whether or not they actu- ally make use of this new field. + Developing programs using low-level interfaces require programmers to concentrate on details such as sockaddr structs, byte ordering routines such as htonl, port numbers, and so on. These are details that are irrelevant to most applications and simply stand in the way of efficient distributed application programming. + Because of the low-level nature of the interfaces, the resulting distributed programs are generally not very scalable. In order for distributed programs to scale up to large size implementations it is necessary to provide an infrastructure whereby data and processes can be managed efficiently as the number of machines on the network grows. This has proven to be very diffi- cult using low-level interface tools. Engineers developing distributed systems using object- oriented methodologies place great emphasis on data encapsu- lation and clean interfaces. One of the goals of NetClasses has been to preserve these properties in the communication interfaces. Therefore, instead of shipping byte buffers over the net- work, NetClasses allows applications to ship objects. In an object-oriented program virtually all information is stored in objects, making objects the most natural form in which to transfer information over a network. 3.15.3. Varieties of object transport _ __ _ _________ __ ______ _________ PostModern Computing's NetClasses package provides a set of flexible C++ tools for object transport. The NetClasses NIH-based and Typed Object-based transports are built on top of the National Institutes Health (NIH) class library. However, the NetClasses Typed Object appli- cation programmer interface is not NIH-dependent. In par- ticular, the Typed Object interface does not in any way con- strain C++ developers who prefer not to use the NIH library themselves. The TransObject transport offers C++ programmers a third facility for object transport that is entirely NIH indepen- dent. The TransObject class library offers end-user appli- cation programmers a way to migrate existing C++ class definitions to a network-transportable framework. The Tran- sObject facility is independent of both the NetClassses Typed Object transport and the NIH-based object transport described above. 3.15.4. Distributed Services _ __ _ ___________ ________ In addition to transporting objects over a network, another common need in distributed application development is the management of object dissemination and connections between clients and servers. PostModern Computing's Distributed Service paradigm is a connection and service management mechanism that is organ- ized around the idea that network service providers should not have to set up explicit port numbers and RPC connections but rather should simply ``advertise'' themselves on the network. ``Agents'' are active processes on the network that monitor network service advertisements and manage con- nections between information producers and consumers. The Distributed Service package is organized as a combination of C++ class libraries and configurable ``dsagent'' execut- ables. The Distributed Services paradigm is a powerful and flexible package that provides an object oriented framework for integrating and connecting applications on a network. Distributed Services provides the following features: + Fault Tolerance + Load Balancing + Multicasting 3.15.5. Remote Method Invocation (RMI) _ __ _ ______ ______ __________ ___ The distributed services paradigm enables methods to be invoked on objects from remote machines. The RMI facility is a higher level communications facility that again shields the developer from port number and host name considerations. The focus of RMI is on ease of use. An RMI invocation requires no stub or skeleton files, protocol compilers, or RPC mechanisms. To enable object X of class C to have its method M invoked from a remote machine, a programmer uses the RMI::advertise method to advertise method X.M. If an application wants to invoke the M method on object X from a remote machine, it uses the RMI::invoke("X.M") method. Parameter passing in RMI can be based on any of the three NetClasses object transports (generic C++, NIH-object, or TypedObject). Synchronous and asynchronous RMI versions exist. Multiple agents can advertise method X.M. The one that is actually invoked is transparent to the client. RMI thus provides an easy mechanism for developing scalable distri- buted applications. 3.15.6. Transport mechanisms _ __ _ _________ __________ In the first developer's release, NetClasses includes TCP- and UDP-based object transport mechanisms. PostModern's Reliable Broadcast Protocol (now under alpha testing) is a UDP-based layer for reliable object transport in nonconnection-oriented environments. The TCP, UDP, and Reliable Broadcast Protocol facilities are all organized as C++ class libraries. 4. Comments _ ________ From: jcc@gna.axis-design.fr (Jean-Christophe Collet) Anyway, I did a lot of work with InterViews and I had a look to NihLib. I Highly recommend InterViews 3.0 but found NihLib rather unusable (it's a very big tree while we need more often a lot of small trees). One very, VERY, important criteria of a class library is its documentation. A very good library without a proper docu- mentation is very hard to use (if not useless). There is no need for the documentation to be thick and verbose but it should gives all the info you need to use the class. Then, there is reuse... (ako "how easy is it to derive a class ?") InterViews is a VERY good example of a good library with appropriate doc. From: fig.citib.com!kpt@fig.citib.com (Kevin P. Tyson) I am in the process of reviewing/selecting C++ class libraries for our shop. We have reviewed two todate. The Booch Components and Tools.h++. We started out by deciding, loosely, what our requirements are. They major ones boil down to: (1) High quality commercial support is very impor- tant to us. (2) Support for multi-threaded programming is only slightly less important. (3) Sophsiticated and exten- sible memory management support is our third requirement. We are a DCE/ENCINA shop and this is what has driven our requirements. We do distributed transaction processing based applications. Someone who does scientific programming will have different requirements and someone working on parallel processors will have their own requirements. The next libraries we intend to examine are COOL and the USL C++ Components library. So far Booch meet the three requirements listed above but was much too low level and lacked good documentation. Tools.h++ could be extended to meet our thread safe and memory management requirements, but that would have made support difficult as it would require modifying their source code. From: eyckmans%imec.be@zimec.be In article <p4fieINN7si@agate.berkeley.edu>, you write: |> Now, has anyone actually used COOL and would you have any idea why the |> authors expressed reservations about it's quality? How does it compare |> with other public domain libraries? Are there any good ones out there |> that you would like to boast about? I have not used COOL (yet). As a matter of fact, I have not yet actively used any of the libaries mentioned below, but here goes anyway... COOL ==== advantages ---------- - uses templates - uses exceptions disadvantages ------------- - COOL templates are not 100% ARM conformant - no garbage collection support at all - common root class (Smalltalk) - COOL uses an exception implementation which is not even close to the ARM remarks ------- - I have not yet tried to compile it with DEC C++ v1.0. - I think that the main objection the COOL authors have against it, is that they feel that their class hierarchy is not optimal. (Almost) all COOL classes either directly or indirectly inherit from a common root class called Generic. In their documentation, the authors state that if they were to redo it, they would rather go for a forest of base classes. NIH === advantages ---------- - used in many applications, and therefor thoroughly tested disadvantages ------------- - no garbage collection support at all - no templates - no exceptions - common root class (Smalltalk) remarks ------- - I have not yet tried to compile it with DEC C++ v1.0. LEDA ==== advantages ---------- - well designed set of data types - looks as if it should be very efficient - uses some template-like construct disadvantages ------------- - no exceptions - LEDA `templates' are not even close to the ARM - use is restricted to "research and education" - use is not for free (but it's cheap) - I cannot possibly get it to compile with DEC C++ v1.0 OATH ==== advantages ---------- - garbage collection comes "for free" - focuses on a how to implement classes, instead of on yet another set of classes a set of classes disadvantages ------------- - common root class (Smalltalk) - no templates - no exceptions - garbage collection comes "for free" - nobody can possibly get it to compile with DEC C++ v1.0 without major modifications From: eyckmans%imec.be@imec.be Hello, First of all, let me start by giving you a bit of background information on what my organisation is (and intends to be) doing. This will allow you to read my answers to your ques- tions in the correct context. + IMEC is a research institute focusing on the (automa- tion of the) design of VLSI chips. Part of the support we offer to the people who are doing research into the area of high level synthesis, currently consists of a C++ libary, written on top of NIH. At the moment, this libary is being redesigned from scratch (for various reasons), and this is where I (as a software expert) enter the picture. I should also add that we have to be able to distribute source code which ideally should run on different types of hardware. As you can see, using commercial class libraries is somewhat out of the ques- tion (although that may change). + So, one of the many things I am doing now, is to inves- tigate what C++ libaries are available to build upon, and whether they at least partially fit our needs. My problem is that, although I do have some experience with OO, I have never used C++ for "real applications", so my current knowledge of C++ is limited (but growing rapidly). Having said all that, here is what you are really after : > How is it the various libraries won't with with DEC's C++? Are they non > standard C++ or do they just not comply with C++ 3.0? How do you know > that they do not work with DEC C++? To my knowledge, DEC C++ v1.0 is *very* ARM compliant, while most other C++ compilers are not. This is one of the reasons why we are switching to the DEC compiler. Here is a list of what we have tried to compile with it until now : - InterViews - LEDA - OATH - SPOOK (don't ask) - some of our own tools Basically, in all cases we have discovered things which are not allowed by the ARM, but somehow did compile on previous compilers (g++ as well as various derivatives of cfront 2.0 and 2.1). Some of these were easy to fix, but some weren't. As a matter of fact, the SPOOK tool set is the only thing in the above list which, after modification, did make it all the way to executable code. > Are these notes impressions that you've gotten from people who have used > these various libraries? That depends on what libary we are talking about, so let's make a list : NIH : As I have said, this has been used in the previous version of our Synthesis Backbone. In addition, I picked up some info on comp.lang.c++. COOL : This has not been used at our site, but I have received some info from other people (isn't usenet great?). I also looked at the manual. LEDA : I have looked at the manual, and have actually tried to compile it with DEC C++ v1.0. OATH : I have looked at the manual, and have actually tried to compile it with DEC C++ v1.0. > Do you intend to get involved with one of these pack- ages in the future? I guess I've already answered this in my introduction. > Does this mean that you've tried to get it to work with cxx but it > won't compile? Or do you just know that it won't work becuase it uses > non standard C++? This question was about LEDA, so here are the gory details of what happened : 1. When compiling LEDA in its pure form, the compiler threw lots of warning and error messages at me. 2. I was able to solve most (but not yet all) of these, but now each compilation ends with the following mes- sage (provided that it does not report syntax errors) : 11, fatal: A bugcheck occurred in the compiler. This is true even for the smallest of files, so I suspect there must be some very ugly stuff in the header files, but I have no idea what this might be. Because of this, I just gave up. So I can't tell you whether the remaining syntax errors are solvable or not. While I'm at it, allow me to elaborate a little bit on my statement about compiling OATH with DEC C++ v1.0. The first time round, the compiler flagged lots of errors. I was able to solve this, but than I ran into an illegal downcast upon which, unfortunately, a large part of the OATH library depends. This is why I said that major changes to the code would be needed. However, after sending my mail, I realized that there is a small possibility that this second problem (although present in the code from the beginning) was actu- ally activated by the changes I made. So it looks like I will have to try again.