This is version 1.20.0 of libg++, the g++ class library.


* Install by typing 'make' in the ./src directory

    * Please read through Makefile before installing.


* Contents

    * Header files are in ./incl

    * g++ source files and a few test programs are in ./src

    * All documentation is contained in the libg++.texinfo file.
       This file may be incorporated into g++/g++.texinfo by
        replacing the section labelled
            @chapter GNU C++ Header Files and Libraries
        with the contents of libg++.texinfo

* Changes from previous release:

  * All documentation previously in ./doc is in libg++.texinfo.

  * All reported errors from the previous release are fixed, and many
    suggested modifications have been performed. Thanks to all who
    have sent bug reports and comments, including those with mail
    addresses that I have not been able to reply to.

  * A few small changes have been made to achieve better compatibility
    between File-based classes and AT&T streams and to lessen and
    isolate dependencies on _iobuf fields.  Also, the File classes are
    somewhat more secure: no read/write operations will proceed if the
    File is in a _fail or _bad state. These changes necessitate a bit
    more overhead per operation.

  * void* operators have been added to istreams, ostreams, etc.

  * All library class error handling is now performed through
    resetable error handlers

  * Obstack now supports grow_fast

  * The default File() constructor now runs 'initialize()'. Elements
    of arrays of Files now never have "garbage" in their 
    member variables. (Arrays of any class with constructors should
    work correctly in g++ 1.20.0, so initialize is never needed)

  * Inlining is now performed separately from class declaration.
    Inline functions are processed only if the files are compiled
    with the -O switch, which automatically #defines __OPTIMIZE__.
    If the files are not compiled with -O, the function versions
    of all inlines, kept in libg++.a are used, providing
    fast-compile/slow-run performance. Otherwise inlines are used
    extensively to achieve slow-compile/fast-run performance.

  * Most PlotFile code is now non-inline in PlotFile.cc, since these
    operations are almost never time-critical.

  * 'make test0' in ./src contains the simple g++, ld++, etc., tests
    previously contained in the g++ distribution.  This is made
    before doing anything else in the Makefile.

  * The Makefile now puts .h files and libg++.a into their target 
    directories.


* New additions

  * A String class and a multiple-precision Integer class are available:

    * Please read the documentation.

    * These have not been exhaustively tested. I would much appreciate
      any bug reports, suggestions for improvement, or examples of
      applications that test these classes more completely.

    * There have been several changes made since the pre-release
      versions that were available.

    * The code contains a few things that may change with future g++ 
      releases. This includes, especially, dynamic allocation methods
      (which, as released, do not use realloc() in many places they
      could).
        

* A few words about libg++

    * libg++ is NOT intended to create a complete object oriented
      programming system from the ground up. People wishing to program
      using an established completely hierarchical (smalltalk-style)
      object system may be interested in obtaining Keith Gorlen's OOPS
      library.  Other public domain c++ library classes are available
      from other sources, including the forthcoming USENIX C++ tape,
      and the Interviews package, available from X-window
      distributions.

    * Most libg++ classes are designed to form useful base classes or
      members of more interesting applications classes and the like.
      Many classes are attempts to allow g++ programmers a consistent
      object-oriented view of facilties commonly found in C libraries.
      Much of the .cc file support code interfaces such facilities
      with c++ classes, and has very little to do with object-oriented

    * The design evolution of libg++ classes is an ongoing effort. All
      released classes are subject to change. Most changes will be
      improvements in the implementations, not the public functions,
      when possible. Comments and suggestions about class design and
      implementation are always very welcome. At this stage in the 
      development of g++ and libg++, feedback from active users is
      extremely valuable.

    * Sometime in the next several months, there may be several
      significant implementation changes to conform to the forthcoming
      GNU CC libc support libraries.

    * There are currently no container classes (vectors, associative
      arrays, etc.) in libg++.  c++ (g++) requires the use of
      tortuous macro devices in order to create truly generic classes.
      I will wait until g++ is extended to allow parameterized classes
      before writing any of these sorts of things.

    * I try to maintain a consistent naming strategy:

        * Class names always start with capitals, except for
          istream and ostream, for AT&T compatibility.

        * Structures and objects that must be publicly defined,
          but are not intended for public use have names beginning
          with an underscore. (for example, the _Srep struct, which
          is used only by the String and SubString classes.)

        * Long function names use the underscore convention to
          seperate parts, as in set_File_exception_handler()

        * When a function could be usefully defined either as a
          member or a friend, it is generally a member if it modifies
          and/or returns itself, else it is a friend. There are cases
          where naturalness of expression wins out over this rule.


    * I have attempted to format class declarations so that it is easy
      to quickly check them to determine function names, parameters,
      and so on. Because of the different kinds of things that may
      appear in class declarations, I don't know the perfect way to do
      this. I am open to suggestions on developing a common class
      declaration formatting style.


* I continue to solicit

    * bug reports.

    * suggestions

    * comments

    * questions about using libg++

    * other contributions to be incorporated into libg++.

    * sample programs using libg++.

Good luck.

Doug Lea, Computer Science Dept., SUNY Oswego, Oswego, NY, 13126 (315)341-2367
email: dl@rocky.oswego.edu        or dl%rocky.oswego.edu@devvax.tn.cornell.edu 
UUCP :...cornell!devvax!oswego!dl or ...rochester!rocksvax!oswego!dl
