diff options
Diffstat (limited to 'libg++/libstdc++/stl/README')
-rw-r--r-- | libg++/libstdc++/stl/README | 86 |
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 |