summaryrefslogtreecommitdiffstats
path: root/libg++/libstdc++/stl/README
diff options
context:
space:
mode:
Diffstat (limited to 'libg++/libstdc++/stl/README')
-rw-r--r--libg++/libstdc++/stl/README86
1 files changed, 86 insertions, 0 deletions
diff --git a/libg++/libstdc++/stl/README b/libg++/libstdc++/stl/README
new file mode 100644
index 0000000..fad26de
--- /dev/null
+++ b/libg++/libstdc++/stl/README
@@ -0,0 +1,86 @@
+This directory contains Hewlett-Packard's implementation of
+the C++ Standard Template Library.
+It is the October 31, 1995 version.
+It has been extensively modified so it can be compiled by g++.
+(Version 2.6.1 or newer is recommended.)
+Some of these hacks are pretty ugly, but are needed to work around
+bugs in g++ (which we are working on).
+Thanks to Carsten Bormann <cabo@informatik.uni-bremen.de> for
+coming up with many of these work-arounds. However, I have
+come up with alternate (possibly inferior!) work-arounds in some cases.
+
+Note that this is based on a pre-Draft Standard for C++.
+Things are likely to change. For example, the header file names
+are very likely to change. The Allocator interface will change. Etc, etc.
+CYGNUS MAKES NO COMMITTMENT (yet) TO SUPPORT BACKWARD COMPATIBILITY FOR STL.
+
+For examples if things that should work, look in the ../tests directory.
+
+DOCUMENTATION:
+See http://www.cs.rpi.edu/~musser/stl.html on the World-Wide Web,
+or anonymous ftp to butler.hpl.hp.com, directory stl, file sharfile.Z.
+
+ --Per Bothner
+Cygnus Support bothner@cygnus.com
+
+-----------
+Here is Carsten Bormann's notes on his changes:
+
+This is a set of seriously bletcherous hacks to HP's wonderful STL
+library. The objective is to hammer STL through GCC 2.6.1 (2.6.0
+seems to work, too, until you run into one of its bugs) so that us
+academic types can play with STL, not to make STL better in any way.
+
+Many of these changes make the library much less efficient. All
+changes (except vector<bool> -- see below) are due to bugs (or
+non-features) in GCC, not due to any problems in STL. Do not judge
+the performance of STL (code space, data space, compile time
+complexity, run time complexity) from these hacks -- they will be much
+better when GCC implements more of Standard C++. May the authors of
+STL forgive me.
+
+The class templates generally have been hacked in the following ways:
+
+1) Static data members have been eliminated, generally by making them
+non-static members or member functions (both of which generally
+seriously impairs performance -- e.g., each rb_tree iterator now
+carries a copy of NIL since there is no other place to put it). The
+template list<> has suffered most.
+
+Allocators are still static members, since I changed defalloc.h to
+have static members only. (This makes allocators less useful, but
+still useable.) (Note that a static member without data need not be
+initialized.)
+
+2) For member functions defined outside the class template, parameters
+of type tmpl<T>::something have been changed. In some cases, a class
+derived from the type has been used; in some cases the function simply
+has been made inline (again causing code bloat).
+
+3) A number of function templates in iterator.h have been declared
+again for derived classes defined by templates, usually by making them
+friend functions and using the name injection feature of GCC. I don't
+understand the relevant sections of the WP, so I don't know if this
+hack will cease to work in more conforming versions of GCC or become
+unneccessary or simply STL won't work with standard C++. Some of
+the necessary friends may still be missing...
+
+defalloc.h has lost much of its functionality: see above.
+
+bool.h has been made ineffective, since GCC supports bool.
+
+Finally, bit_vector has been changed into a proper specialization of
+vector<bool>.
+[Not in this libstdc++ release. -PB]
+
+demo.cc and Makefile build a small demo program for a number of
+features of STL. This is not a test suite, so I certainly have not
+found all my mistakes (could anyone in possession of such a test suite
+please run it over these hacks?). Send bug reports (that follow GNU
+bug reporting conventions) to
+
+ cabo@informatik.uni-bremen.de
+
+Note that I generally do not have time to answer questions about STL.
+
+Carsten Bormann
OpenPOWER on IntegriCloud