1 files changed, 0 insertions, 86 deletions
diff --git a/contrib/libg++/libstdc++/stl/README b/contrib/libg++/libstdc++/stl/README
deleted file mode 100644
index fad26dec0c0d..000000000000
--- a/contrib/libg++/libstdc++/stl/README
+++ /dev/null
@@ -1,86 +0,0 @@
-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