This is version 1.36.3 of libg++, the GNU C++ class library.
Release date Tue Jan 16 05:52:19 1990  Doug Lea  (dl at g.oswego.edu)

* Please skim through this once BEFORE attempting to make and install libg++.

* Contents

    * g++ source files are in the ./src directory
    * Some simple tests and demo programs are in ./tests
    * Header files are in ./g++-include
    * documentation is in ./libg++.texinfo. You may convert this into
      an emacs Info file by editing the file and typing `texinfo-format-buffer'
    * Some miscellaneous files of possible interest are in ./etc
      (These files are not officially a part of the libg++ distribution,
      and are subject to arbitrary changes, deletions, etc. from release
      to release.)

* Pre-installation

    * Install a version of g++ with at least as high a version
      number as this version of libg++. You also need gcc installed.

    * If there is a version of the GNU as (gas) assembler that
      works on your machine, get it, and install it as gcc-as,
      in whatever lib directory holds gcc-cc1plus. Otherwise,
      you may have to remake g++ with -DFASCIST_ASSEMBLER in CFLAGS,
      and disable the -PIPE_AS flag in the libg++ Makefile.

    * If, for some reason, you are attempting to use libg++ with some
      other C++-2.0 compiler (like cfront), the only intentional
      deviation from the 2.0 standard used in libg++ is the use
      of named return values. If you would like to volunteer to
      correctly #ifdef around these, I will incorporate these
      changes into a future release. If you encounter any other problematic
      g++-specific idioms (outside of incremental linking, wrappers,
      and the like, tested only in the test files, but otherwise
      unused in the library), please report them.

* Installation (see libg++.texinfo more more details)

    * Except for how to set the `PWD' make variable (which you must
      manually change if you do not use GNU make), the Makefiles
      are reported to be compatible with all flavors of `make'.

    * Check the declared indicated pathnames, etc. in the top-level Makefile

        Be sure to use USG-oriented switches if you run SystemV unix.

        If you run into problems, check through system-dependent
        #defines in  g++-include/stdio.h,  g++-include/math.h
        and g++-include/values.h, especially, and report any
        incompatibilities or problems to bug-lib-g++@prep.ai.mit.edu.

    * Choose functionality flags.

        In the libg++ Makefile, `XTRAFLAGS' are selectable. By default,
        none of these are enabled:

        -DEFAULT_filebuf, if included in XTRAFLAGS, causes standard
         cin, cout, and cerr streams to bypass your libc stdio facilities.
         I know of no system for which this is absolutely required. However,
         if there are known bugs with your stdio implementation, or if
         you wish to give up some functionality in order to be conservative,
         then select this. If you use this, expect an innocuous difference
         between the expected and obtained results of tFile in how the
         final status of standard streams is printed.

        -DNO_GNULIB3 suppresses compilation of a dummy `main',
         which calls global constructors and destructors around a
         user main. Select this if you have made alternative arrangements
         for doing this.

        -DNO_LINE_BUFFER_STREAMBUF suppresses line-buffering (automatic
         flushing of output whenever a newline is encountered). Selecting
         this may result in slightly smaller code, but will require
         manual flushing when lines are expected to be printed right
         when they are written.

        -DNO_LIBGXX_MALLOC suppresses compilation of libg++ malloc
         routines, thus causing all malloc, free, realloc, operator
         new() and operator delete() calls to go through your libc
         version of malloc. Select this if your system requires a
         the system version of malloc (possibly necessary on some
         shared memory multiprocessors, since libg++ malloc does not
         contain any concurrency control), or, perhaps, if your applications
         are specially tuned for or otherwise work better with your
         system malloc.

        -DMALLOC_STATS compiles statistics counting into libg++ malloc
         (but also slows it down a little). Select this if you are
         interested in examining the performance of libg++ malloc.
         (I welcome this, and would be grateful to receive statistics
         (printed via `malloc_stats()') for programs with heavy
         dynamic allocation requirements.)

    * Other compilation flags are tunable, but the default versions
        should normally suffice.

    * type `make all', or, step-by-step:

       `make src'          -- to compile libg++.a
       `make tests'        -- to make some tests/demos of libg++.
                              This will first compile tests, then run them,
                              then diff the results against expected
                              results. 
       `make install'      -- to install libg++.a and include directories    
       `make etc'          -- (optional) to compile various other things 
       `make gperf'        -- (optional) to compile Doug Schmidt's
                               perfect hash function generator.  This
                               program illustrates many of the new
                               C++ 2.0 features available in G++,
                               including multiple inheritance and static
                               member functions.

* General compilation notes

By default, everything is compiled with the g++/gcc -Wall flag
enabled. This causes g++ to produce numerous diagnostic warnings and
reminders. This is perfectly normal. Only true error messages, which
cause the `makes' to halt indicate real problems. If you do not like
to look at the warnings, disable the -Wall in the Makefile. -Wall is
enabled because, if there are true errors, warnings leading up to
them may prove helpful.

* Notes on compiling and running libg++/tests

test0 and tCurses are not automatically run through `checktests'.
You must run them manually:

test0 only tests the dynamic linking capabilities of g++, which are
not exploited in the rest of the library. The test is in libg++/tests
since it requires include files, etc., not otherwise present in the
g++ release. To run test0, you can type `test.shell' when asked for a
file name, and get a csh shell loaded, if dynamic linking is working.
If you exit from the shell, you should be back in test0, and you can
type `test.bye2' to cleanly exit.

With the current g++, tests/test0, and incremental linking in
general should work on most machines. If it does not, you may even
have trouble compiling it.  You can do `touch tests/test0', and
continue if this happens to you.

tCurses attempts to place one of each curses library primitive (boxes,
strings, numbers...) on your screen, and asks for some input, to test
curses input routines. Since there is no way to describe the output
in a system- and terminal- independent way, you will have to be the 
judge of whether it works acceptably.

tCurses (and the curses-based classes generally) may fail on the
Sequent and perhaps other systems with unusual or old curses library
implementations if you do not end input with a <linefeed> instead of
the normal <carriage-return>.

It is a very good idea to also cd to the test directory and run tests
manually, to see what they do. 

Compiling and running the tests consumes a fair amount of time and
disk space!

Some reported diffs may be perfectly reasonable, owing to things like
floating point precision differences: The expected.out file was created
on a Sun4/110.

    Some tRational and tFix results depend on floating point precision
    and may generate slightly different output on different machines.

    tRandom seeds some random-numbers in a way that also relies on
    floating-point representations -- Your output should be numerically
    similar, but probably not identical.

* changes from libg++-1.36.1

    * `Tmp' classes have been eliminated from Strings, Integers, etc.
       (Via some retuning of the main classes, Tmp classes were found
        to not significantly impact performance one way or the other,
        so they were removed.)

    * There is now a version of malloc, directly supporting operator
      new, etc. It may be faster and better suited to C++ applications
      than your libc malloc. You should be able to use it unless you need
      a special malloc for a distributed shared memory environment or
      the like. If you can't use it, edit the appropriate flag in
      the top-level Makefile. I would very much appreciate feedback
      about whether this malloc makes any difference in time or space
      efficiency than whatever you are now using.

    * By default, output is now line-buffered. Use the
      NO_LINE_BUFFER_STREAMBUF define in the Makefile to override

    * Otherwise, the stream classes remain C++-1.2 compatible.
      C++-2.0-compatible versions are still in the works.

    * various and sundry bug fixes, minor enhancements, and/or portability 
        improvements as described in the ChangeLog. 

* Known bugs and problems

    * Support for the DecStation3100 (pmax) is uncertain. There have
        been reports of several, mostly minor, problems with prereleases.
        It is not yet clear whether the fault lies in g++, gcc, libg++,
        and/or DecStation Ultrix.

    * Vax MINFLOAT and MAXFLOAT values may or may not be correct to
        the last bit, but agree with those expected by gcc and g++.

    * Some early prereleases of the gcc backend of the current g++ had problems
        that require turning off optimization switches to compile all
        .cc and .c files on some machines.

* Lots of other information is in the libg++.texinfo file. It really is
  very important to actually read the documentation before using 
  library classes. Examination of the demo files in the test directory
  may also be useful. (Note however, that the demo files are merely
  designed to test examples of each class capability,
  and are not especially good examples of client functions that might
  use these classes.)

* There is now a gnu libg++ mailing list (bug-lib-g++@prep.ai.mit.edu) and
    associated usenet gnu news group.

* You will be performing a valuable service if you use libg++
   classes and report back any comments, and suggestions, or bugs,
   preferably to the bug-lib-g++ list. Your feedback is extremely 
   helpful in efforts to make libg++ as useful and reliable as possible.

* See file `etc/release.log' for changes from previous versions

* If you are a systems administrator installing libg++ for others,
    please make the documentation (libg++.texinfo) and test files
    available to users!

* I continue to solicit

  * bug reports.
  * suggestions.
  * comments.
  * questions about installing and using libg++
  * other contributions to be incorporated into libg++.
  * sample programs using libg++.

  Often, the best place to send such things is bug-lib-g++@prep.ai.mit.edu,
  although direct mail to me is also welcome.

* Good luck!

Doug Lea, Computer Science Dept., SUNY Oswego, Oswego, NY, 13126 (315)341-2367
email: dl@oswego.edu              or dl%oswego.edu@nisc.nyser.net
UUCP :...cornell!devvax!oswego!dl or ...rutgers!sunybcs!oswego!dl
