From: skdutta@ucs.att.com (Saumen Dutta)
Subject: C++ Product List - Version 2.04 - Part 7/8
Organization: AT&T Universal Card Services, Jacksonville FL
Date: Wed, 18 Nov 1992 02:30:37 GMT

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.