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 / 16485 < prev next >

Wrap

Text File | 1992-11-17 | 19.7 KB | 546 lines

Newsgroups: comp.lang.c++ Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!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 7/8 Message-ID: <1992Nov18.023037.822@ucs.att.com> Organization: AT&T Universal Card Services, Jacksonville FL Date: Wed, 18 Nov 1992 02:30:37 GMT Lines: 536 3.16. USL C++ Standard Components _ __ ___ _ ________ __________ + Platform: SunOS and System V. Works with AT&T C++ Compiler 3.0. + Corporate Headquarters: UNIX System Laboratories, Inc. 190 River Road, Summit, NJ, 07901, USA Telephone: +1-800-828-UNIX Prompt #2 or +1-908-522-6000 European Headquarters: UNIX System Laboratories Europe Ltd. International House, Ealing Broadway London W5 5DB England Telephone: +11-44-81-587-7711 Asia Pacific Headquarters: UNIX System Laboratories Pacific Ltd., No1 Nan-oh Bldg., Nishi-Shimbashi, Ninato-ku Tokyo 105 Japan Telephone: +81-3-3431-3670 + A collection of Libraries and Tools for C++. Makes use of templates in the class library. + Information provided by Paul Fillinich (paulf@usl.com) 3.16.1. Introduction _ __ _ ____________ UNIX System Laboratories offers the C++ Standard Com- ponents, a collection of general purpose programming rou- tines and tools which promote greater efficiency and produc- tivity for the C++ programmer. This product includes com- ponents that can be used in virtually any application han- dling some low-level aspect of programming which in C or C++ tends to be tedious and error-prone. By taking care of the common, low-level aspects of computing, they give program- mers more time to focus on the application. In addition to the components, a variety of tools are offered which aid in the use of both the components as well as the C++ Language System. Included in this offering is a tool for utilizing the templates feature of the language and a tool which will aid in incorporating other programming environment tools into the C++ Language System. 3.16.2. Features _ __ _ ________ General Purpose - Reusable for applications and other library routines providing real cost savings in development and test time and maintenance costs. Designed for the efficiency which C++ programmers demand - Small standalone non-hierarchical components pro- vide for greater compile and run time efficiency. The smaller code size results in greater efficiency in computing resource usage. USL C++ Standard Components are designed for the AT&T standard for C++. This design criteria results in a high level of confidence that the product works well with the many derivative USL C++ Language System product which abound. Tested and reliable, in production for over 2 years - These components have been in use within Bell Laboratories within a wide range of applications. This maturity results in lowering the risk of the use in critical applications. Well documented - A thorough reference manual coupled with an extensive tutorial provide the end user with a jump start on productive use of the components without extensive training. For resellers, it is easier for producing quality documentation for a shrink wrapped product. Built to meet "Real World" needs - Production proven, applicable to any application, useful in every application, the C++ Standard Components provide a high return on the investment. 3.16.3. Components _ __ _ __________ The classes provided by the library are several, and they are listed here: Included in the C++ Standard Components are the follow- ing components: Args - a set of facilities providing more natural and convenient access to UNIX command line options and arguments than typical command line parsers. Bits - extends built-in support for bit manipulation to arbitrary-length bitstrings. It also allows easy access to individual bits and provides additional operations such as concatenation. Blocks - are like built-in arrays, except that their size can be adjusted dynamically. Using Blocks eliminates many of the errors programmers make when working with adjustable-size data structures. Block Algorithms - 90 highly efficient algorithms for operating on contiguously stored data (can be used with either arrays or Blocks) including algorithms for searching, sorting, inserting, partitioning, generation, copying, and removing. Fsm - offers a method of specifying program control flow that is useful in a wide variety of applications. Pro- grammers define "states" and "transitions" among states that are "fired" by specific "inputs." Graphs - three classes that can be used to maintain arbitrary relationships between arbitrary entities. Useful for semantic modeling and other "network" applications. Graph Algorithms - Several of the most fundamental algorithms for operating on Graphs, including breadth-first and depth-first searching, cycle and component detection. ipcstream - specializes the standard I/O architecture (iostream) to interprocess communication between clients and servers. Clients and servers communicate by writing to or reading from streams. Lists - are doubly-linked lists. Since pointer manipu- lation and node allocation are handled automatically, using Lists eliminates another major source of programming errors. Maps - are like arrays, except that the subscripts can be non-integral types such as character strings (similar to associative arrays in AWK). Objections - are a kind of "error object" that can be "raised" by one piece of code and "handled" by another (like UNIX "software signals"). Library components use Objections to inform clients of errors. Path - a set of facilities for manipulating UNIX path names and UNIX search paths. Facilities include automatic path canonicalization, path relativization, wildcard and tilde expansion, path completion, and searching in search paths. Pools - improve the runtime performance of programs which allocate and deallocate many objects of the same type (for example, Lists use Pools internally for obtaining nodes). Regex - a set of facilities providing a consistent and enhanced interface to the Section 3 regular expression com- pilation and matching routines (re(3), regcmp(3), regex(3), or regexp(3), depending on the version of UNIX running). Sets - three unordered homogeneous collection classes: Sets, Bags, and pointer sets. Provides the usual insertion, removal, membership, algebraic and relational operators and iterators. Stopwatch - can be used for timing critical sections of code during the "performance tuning" phase of development. Strings - are variable-length character strings. Strings offer an efficient alternative to null-terminated character arrays and their associated C library functions (strcpy, strcmp, etc). Strings have natural syntax and semantics; for example, to concatenate strings x and y, write x+y. Strstream - specialize the standard I/O architecture (iostream) to in-core formatting, where the source or target is a String. Symbol - unique identifiers based on character strings with efficient tests for equality and ordering. Time - consists of three related abstractions for deal- ing with time in computer programs: Time (absolute time), Duration (time difference) and Place (geographical loca- tion). 3.16.4. Tools _ __ _ _____ In addition to the above components, the following tools are also made available as part of this release: demangle - Demangle demangles all the various names strewn throughout each of the object files in the argument list. This enables the various C tools such as nm(1), dbx(1), gprof(1), and others to produce results with pleasant identifier names. freestore - Freestore is a C++ symbolic freestore manager which contains routines that let the programmer view the contents of the freestore symbolically during execution of a C++ program. They are normally called "by hand" by the programmer from within a debugger but since they are linked in as part of the application code, they can also be called from the program itself. G2++ - G2++ provides a method for structuring records for messages used for interprocess communication or records used for long-term data storage. I/O routines are available for reading and writing G2++ records from a C++ program: G2++ typed I/O routines. These routines are generated by the G2++ compiler. hier - Hier produces the inheritance hierarchy for the C++ source code contained in the given collection of files. The output language can be any of "ps" (postscript), "dag", "pic", "tex", or "dvi". publik - Publik prints the public portions of all class definitions contained, directly or indirectly, in the list of input files. 3.16.5. Documentation _ __ _ _____________ C++ Standard Components Programmer's Manual C++ Standard Components Programmer's Guide Getting Started 3.17. SockStream - A Library for using sockets _ __ __________ _ _______ ___ _____ _______ + Writen by: Mayan Moudgill (moudgill@cs.cornell.edu) Anonymous ftp from host ftp.cs.cornell.edu in directory pub/sockets. + The C++ Socket Stream Library was developed with two aims in mind -- to provide an iostream-based interface for sockets, and to facilitate using the event driven features provided by BSD-sockets (i.e. SIGURG and SIGIO). Both have been accomplished. Included are 3 demo sets. Also included are an efficient interface to fd_set and select. + Information provided by Mayan Moudgill(moudgill@cs.cornell.edu) 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.