FreeChainXenon/gcc
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

footer.html: Update to see if it takes effect.

Browse source 
2000-05-03  Phil Edwards  <pme@sourceware.cygnus.com>
            Felix Natter <fnatter@gmx.net>

	* docs/footer.html:  Update to see if it takes effect.
	* docs/thanks.html:  More people.
	* docs/17_intro/headers_cc.txt:  Copy from testsuite, since that can't
	  be seen from the web pages.  Rename for browser-friendliness...
	* docs/17_intro/howto.html:  ...and update here.
	* docs/17_intro/porting-howto.html:  Changes from Felix.
	* docs/gccrebuild.html:  Mention v3->egcs move.
	* docs/faq/index.html:  Ditto.  Also misc tweaks and URL updates.
	* docs/faq/index.txt:  Regenerate.

Co-Authored-By: Felix Natter <fnatter@gmx.net>

From-SVN: r33631
This commit is contained in:
Phil Edwards 2000-05-03 16:11:03 +00:00 • committed by Phil Edwards
parent 1920de4701
commit 754ac8f7b2
9 changed files with 342 additions and 160 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
libstdc++-v3/ChangeLog
View file

@ -1,3 +1,16 @@
2000-05-03 Phil Edwards <pme@sourceware.cygnus.com>
Felix Natter <fnatter@gmx.net>
* docs/footer.html: Update to see if it takes effect.
* docs/thanks.html: More people.
* docs/17_intro/headers_cc.txt: Copy from testsuite, since that can't
be seen from the web pages. Rename for browser-friendliness...
* docs/17_intro/howto.html: ...and update here.
* docs/17_intro/porting-howto.html: Changes from Felix.
* docs/gccrebuild.html: Mention v3->egcs move.
* docs/faq/index.html: Ditto. Also misc tweaks and URL updates.
* docs/faq/index.txt: Regenerate.
2000-05-01 Benjamin Kosnik <bkoz@redhat.com> 2000-05-01 Benjamin Kosnik <bkoz@redhat.com>
* config/cpu/powerpc/bits/atomicity.h (__exchange_and_add): More * config/cpu/powerpc/bits/atomicity.h (__exchange_and_add): More

83
libstdc++-v3/docs/17_intro/headers_cc.txt Normal file
View file

@ -0,0 +1,83 @@
// 1999-05-12 bkoz
// Copyright (C) 1999 Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library. This library is free
// software; you can redistribute it and/or modify it under the
// terms of the GNU General Public License as published by the
// Free Software Foundation; either version 2, or (at your option)
// any later version.
// This library is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
// You should have received a copy of the GNU General Public License along
// with this library; see the file COPYING. If not, write to the Free
// Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307,
// USA.
// 17.4.1.2 Headers
// "C++" headers
#include <algorithm>
#include <bitset>
#include <complex>
#include <deque>
#include <exception>
#include <fstream>
#include <functional>
#include <iomanip>
#include <ios>
#include <iosfwd>
#include <iostream>
#include <istream>
#include <iterator>
#include <limits>
#include <list>
#include <locale>
#include <map>
#include <memory>
#include <new>
#include <numeric>
#include <ostream>
#include <queue>
#include <set>
#include <sstream>
#include <stack>
#include <stdexcept>
#include <streambuf>
#include <string>
#include <typeinfo>
#include <utility>
#include <valarray>
#include <vector>
// "C" headers
#include <cassert>
#include <cctype>
#include <cerrno>
#include <cfloat>
#include <ciso646>
#include <climits>
#include <clocale>
#include <cmath>
#include <csetjmp>
#include <csignal>
#include <cstdarg>
#include <cstddef>
#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <ctime>
// "C" headers that might not work if wchar_t support is disabled.
#include <bits/c++config.h>
#if _GLIBCPP_USE_WCHAR_T
#include <cwchar>
#include <cwctype>
#endif
int main() { }

6
libstdc++-v3/docs/17_intro/howto.html
View file

@ -9,7 +9,7 @@
<TITLE>libstdc++-v3 HOWTO: Chapter 17</TITLE> <TITLE>libstdc++-v3 HOWTO: Chapter 17</TITLE>
<LINK REL="home" HREF="http://sourceware.cygnus.com/libstdc++/docs/18_support/"> <LINK REL="home" HREF="http://sourceware.cygnus.com/libstdc++/docs/18_support/">
<LINK REL=StyleSheet HREF="../lib3styles.css"> <LINK REL=StyleSheet HREF="../lib3styles.css">
<!-- $Id: howto.html,v 1.1 2000/04/21 20:33:31 bkoz Exp $ --> <!-- $Id: howto.html,v 1.2 2000/04/25 06:39:48 bkoz Exp $ -->
</HEAD> </HEAD>
<BODY> <BODY>
@ -46,7 +46,7 @@
available to you, no matter how. available to you, no matter how.
</P> </P>
<P>The names of the headers can be easily seen in <P>The names of the headers can be easily seen in
<A HREF="../testsuite/17_intro/headers.cc">this source code</A>, <A HREF="headers_cc.txt"><TT>testsuite/17_intro/headers.cc</TT></A>,
which is a small testbed we use to make certain that the headers which is a small testbed we use to make certain that the headers
all compile and run. all compile and run.
</P> </P>
@ -147,7 +147,7 @@
Comments and suggestions are welcome, and may be sent to Comments and suggestions are welcome, and may be sent to
<A HREF="mailto:pme@sourceware.cygnus.com">Phil Edwards</A> or <A HREF="mailto:pme@sourceware.cygnus.com">Phil Edwards</A> or
<A HREF="mailto:gdr@egcs.cygnus.com">Gabriel Dos Reis</A>. <A HREF="mailto:gdr@egcs.cygnus.com">Gabriel Dos Reis</A>.
<BR> $Id: howto.html,v 1.1 2000/04/21 20:33:31 bkoz Exp $ <BR> $Id: howto.html,v 1.2 2000/04/25 06:39:48 bkoz Exp $
</EM></P> </EM></P>

200
libstdc++-v3/docs/17_intro/porting-howto.html
View file

@ -15,9 +15,18 @@
<li><a href = "#nocreate">File-flags: <tt>ios::nocreate</tt> and <li><a href = "#nocreate">File-flags: <tt>ios::nocreate</tt> and
<tt>ios::noreplace</tt></a> <tt>ios::noreplace</tt></a>
<li><a href = "#headers">The new headers</a> <li><a href = "#headers">The new headers</a>
<li><a href = "#iterators">Iterator-changes</a>
<li><a href = "#macros">Libc-macros</a>
<li><a href = "#about">Comments, suggestions, corrections, questions...</a> <li><a href = "#about">Comments, suggestions, corrections, questions...</a>
</center> </center>
<p>
In the following, when I say portable, I will refer to "portable among ISO
14882-implementations". On the other hand, if I say "backportable" or
"conservative", I am talking about "compiles with older
libstdc++-implementations".
</p>
<a name = "std"> <a name = "std">
<h2>Namespace std::</h2> <h2>Namespace std::</h2>
</a> </a>
@ -25,29 +34,40 @@
The latest C++-standard (ISO-14882) requires that the standard C++-library The latest C++-standard (ISO-14882) requires that the standard C++-library
is defined in namespace std::. Thus, to use classes from the standard c++ is defined in namespace std::. Thus, to use classes from the standard c++
library, you can do one of three things: library, you can do one of three things:
<ul> <ul>
<li>wrap your code in <tt>namespace std { ... }</tt> <li>wrap your code in <tt>namespace std { ... }</tt> => This is not an
=> This is not an option because only symbols from the standard c++-library are option because only symbols from the standard c++-library are defined in
defined in namespace std::. namespace std::.
<li>put a kind of <dfn>using-declaration</dfn> in your source
(either <tt>using namespace std;</tt> or i.e. <tt>using std::string;</tt>) <li>put a kind of <dfn>using-declaration</dfn> in your source (either
=> works well for source-files, but cannot be used in header-files <tt>using namespace std;</tt> or i.e. <tt>using std::string;</tt>)
<li>use a <dfn>fully qualified name</dfn> for each libstdc++-symbol => works well for source-files, but cannot be used in header-files
(i.e. <tt>std::string</tt>, <tt>std::cout</tt>)
=> can always be used <li>use a <dfn>fully qualified name</dfn> for each libstdc++-symbol
</ul> (i.e. <tt>std::string</tt>, <tt>std::cout</tt>) => can always be used
</ul>
</p>
<p>
Because there are many compilers which still use an implementation that
does not have the standard C++-library in namespace <tt>std::</tt>, some
care is required to support these as well.
</p>
<p>
Namespace back-portability-issues are generally not a problem with g++,
because versions of g++ that do not have libstdc++ in <tt>std::</tt> use
<tt>-fno-honor-std</tt> (ignore <tt>std::</tt>, <tt>:: = std::</tt>) by
default. That is, the responsibility for enabling or disabling
<tt>std::</tt> is on the user; the maintainer does not have to care about it.
This probably applies to some other compilers as well.
</p> </p>
<p> <p>
Namespace portability-issues are not a problem with g++, because versions
of g++ that do not have libstdc++ in std:: use <tt>-fno-honor-std</tt>
(ignore <tt>std::</tt>, <tt>:: = std::</tt>) by default. This probably
applies to some other compilers as well.
The following sections list some possible solutions to support compilers The following sections list some possible solutions to support compilers
that cannot ignore std::. that cannot ignore std::.
</p> </p>
<a name = "gtkmm">
<h3>Using <dfn>namespace composition</dfn> if the project uses a separate <h3>Using <dfn>namespace composition</dfn> if the project uses a separate
namespace</h3> namespace</h3>
</a>
<p> <p>
<a href = "http://gtkmm.sourcforge.net">Gtk--</a> defines most of its <a href = "http://gtkmm.sourcforge.net">Gtk--</a> defines most of its
@ -55,8 +75,7 @@ classes in namespace Gtk::. Thus, it was possible to adapt Gtk-- to
namespace std:: by using a C++-feature called <dfn>namespace namespace std:: by using a C++-feature called <dfn>namespace
composition</dfn>. This is what happens if you put a composition</dfn>. This is what happens if you put a
<dfn>using</dfn>-declaration into a namespace-definition: the imported <dfn>using</dfn>-declaration into a namespace-definition: the imported
symbol(s) gets imported into the currently active namespace(s). This is symbol(s) gets imported into the currently active namespace(s). For example:
what it looks like in Gtk--:
<pre> <pre>
namespace Gtk { namespace Gtk {
using std::string; using std::string;
@ -64,16 +83,23 @@ namespace Gtk {
} }
</pre> </pre>
In this example, <tt>std::string</tt> gets imported into namespace Gtk::. In this example, <tt>std::string</tt> gets imported into namespace Gtk::.
The result is that you don't have to use <tt>std::string</tt> in this header, The result is that you don't have to use <tt>std::string</tt> in this
but still <tt>std::string</tt> does not get imported into user-space (the header, but still <tt>std::string</tt> does not get imported into
global namespace ::) unless the user does <tt>using namespace Gtk;</tt> user-space (the global namespace ::) unless the user does <tt>using
(which is not recommended practice for Gtk--, so it is not a problem). namespace Gtk;</tt> (which is not recommended practice for Gtk--, so it is
not a problem). Additionally, the <tt>using</tt>-declarations are wrapped
in macros that are set based on autoconf-tests to either "" or
i.e. <tt>using std::string;</tt> (depending on whether the system has
libstdc++ in <tt>std::</tt> or not).
(ideas from llewelly@dbritsch.dsl.xmission.com,
Karl Nelson <kenelson@ece.ucdavis.edu>)
</p> </p>
<h3>Defining an empty namespace std for backwards-compatibility</h3> <h3>Defining an empty namespace std</h3>
<p> <p>
By defining an (empty) namespace std:: before using it, you can avoid By defining an (empty) namespace <tt>std::</tt> before using it, you can
getting errors on systems where no part of the library is in std: avoid getting errors on systems where no part of the library is in
namespace std:
<pre> <pre>
namespace std { } namespace std { }
using namespace std; using namespace std;
@ -82,12 +108,12 @@ using namespace std;
<h3>Avoid to use fully qualified names (i.e. std::string)</h3> <h3>Avoid to use fully qualified names (i.e. std::string)</h3>
<p> <p>
If some compilers complain about <tt>using std::string;</tt>, and if the If some compilers complain about <tt>using std::string;</tt>, and if the
hack for gtk-- mentioned above does not work, then it might be a good idea "hack" for gtk-- mentioned above does not work, then it might be a good idea
to define a macro <tt>NS_STD</tt>, which is defined to either "" or "std" to define a macro <tt>NS_STD</tt>, which is defined to either "" or "std"
based on an autoconf-test. Then you should be able to use based on an autoconf-test. Then you should be able to use
<tt>NS_STD::string</tt>, which will evaluate to <tt>::string</tt> ("string <tt>NS_STD::string</tt>, which will evaluate to <tt>::string</tt> ("string
in the global namespace") on systems that do not put string in std::. in the global namespace") on systems that do not put string in std::.
(This is untested and might not even be necessary) (This is untested)
</p> </p>
<h3>How some open-source-projects deal with this</h3> <h3>How some open-source-projects deal with this</h3>
@ -103,7 +129,7 @@ in the global namespace") on systems that do not put string in std::.
<tr><td><a href = "http://www.mnemonic.org">mnemonic</a></td> <td>none</td> <tr><td><a href = "http://www.mnemonic.org">mnemonic</a></td> <td>none</td>
</tr> </tr>
<tr><td><a href = "http://libsigc.sourceforge.net">libsigc++</a></td> <tr><td><a href = "http://libsigc.sourceforge.net">libsigc++</a></td>
<td>portable-impl</td> <td>conservative-impl</td>
</tr> </tr>
</table> </table>
@ -117,11 +143,14 @@ in the global namespace") on systems that do not put string in std::.
<td>none</td> <td>no namespace std at all</td> <td>none</td> <td>no namespace std at all</td>
</tr> </tr>
<tr> <tr>
<td>portable-impl</td> <td>wrap all namespace-handling in macros to support <td>conservative-impl</td> <td>wrap all namespace-handling in macros to
compilers without namespace-support (no libstdc++ used in headers)</td> support compilers without namespace-support (no libstdc++ used in
headers)</td>
</tr> </tr>
</table> </table>
As you can see, this currently lacks an example of a project which uses
libstdc++-symbols in headers in a back-portable way
(except for the <a href = "#gtkmm">Gtk-- "hack"</a>).
</p> </p>
<a name = "nocreate"> <a name = "nocreate">
<h2>there is no ios::nocreate/ios::noreplace in ISO 14882</h2> <h2>there is no ios::nocreate/ios::noreplace in ISO 14882</h2>
@ -136,7 +165,8 @@ input-streams.
For output streams, "nocreate" is probably the default, unless you specify For output streams, "nocreate" is probably the default, unless you specify
<tt>std::ios::trunc</tt> ? To be safe, you can open the file for <tt>std::ios::trunc</tt> ? To be safe, you can open the file for
reading, check if it has been opened, and then decide whether you want to reading, check if it has been opened, and then decide whether you want to
create/replace or not. create/replace or not. To my knowledge, even older implementations support
<tt>app</tt>, <tt>ate</tt> and <tt>trunc</tt> (except for <tt>app</tt> ?).
</p> </p>
<a name = "attach"> <a name = "attach">
<h2><tt>stream::attach(int fd)</tt> is not in the standard any more</h2> <h2><tt>stream::attach(int fd)</tt> is not in the standard any more</h2>
@ -166,32 +196,108 @@ headers and tell users of old compilers that they should create links
(which is what they will have to do sometime anyway). (which is what they will have to do sometime anyway).
</p> </p>
<h3><tt>&lt;ctype.h&gt;</tt> introduces ambiguity when used with <a name = "cheaders">
<tt>&lt;cctype&gt;</tt></h3> <h3>New headers replacing C-headers</h3>
<p> </a>
The best solution I came up with so far is to include <tt>cctype</tt> <p>
instead of <tt>ctype.h</tt> wherever possible, and then use fully You should not use the C-headers (except for system-level headers) from C++
qualified names to refer to the libstdc++-versions: std::islower, programs. Instead, you should use a set of headers that are named by
std::isalnum etc. (you will need to as soon as any header includes prepending 'c' and, as usual, ommiting the extension (.h). For example,
<tt>&lt;ctype.h&gt;</tt>, because then there will be an ambiguity with the instead of using <tt>&lt;math.h&gt;</tt>, you should use
C-versions in the global namespace defined in <tt>&lt;ctype.h&gt;</tt>) <tt>&lt;cmath&gt;</tt>. The standard specifies that if you include the
C-style header (<tt>&lt;math.h&gt;</tt> in this case), the symbols will be
available both in the global namespace and in namespace <tt>std::</tt>
(libstdc++-v3, version 2.90.8 currently puts them in <tt>std::</tt> only)
On the other hand, if you include only the new header
(i.e. <tt>&lt;cmath&gt;</tt>), the symbols will only be defined in
namespace <tt>std::</tt> (and macros will be converted to
inline-functions).
</p> </p>
<p>
For more information on this, and for information on how the GNU C++
implementation reuses ("shadows") the C library-functions, have
a look at <a href = "http://www.cantrip.org/cheaders.html">www.cantrip.org</a>.
</p>
<h3><tt>&lt;fstream&gt;</tt> does not define <tt>std::cout</tt>, <h3><tt>&lt;fstream&gt;</tt> does not define <tt>std::cout</tt>,
<tt>std::cin</tt> etc.</h3> <tt>std::cin</tt> etc.</h3>
<p> <p>
In previous versions of the standard, <tt>&lt;fstream.h&gt;</tt>, In previous versions of the standard, <tt>&lt;fstream.h&gt;</tt>,
<tt>&lt;ostream.h&gt;</tt> and <tt>&lt;istream.h&gt;</tt> used to define <tt>&lt;ostream.h&gt;</tt> and <tt>&lt;istream.h&gt;</tt> used to define
<tt>cout</tt>, <tt>cin</tt> and so on. With libstdc++-v3, you need <tt>cout</tt>, <tt>cin</tt> and so on. Because of the templatized iostreams
to include <tt>&lt;iostream&gt;</tt> to define these. in libstdc++-v3, you need to include <tt>&lt;iostream&gt;</tt> explicitly
to define these.
</p> </p>
<a name = "iterators">
<h2>Iterators</h2>
</a>
<p>
The following are not proper uses of iterators, but may be working fixes
for existing uses of iterators.
<ul>
<li>you cannot do <tt>ostream::operator<<(iterator)</tt> to print the
address of the iterator => use <tt><< &*iterator</tt> instead ?
<li>you cannot clear an iterator's reference (<tt>iterator = 0</tt>)
=> use <tt>iterator = iterator_type();</tt> ?
<li><tt>if (iterator)</tt> won't work any more
=> use <tt>if (iterator != iterator_type())</tt> ?
</ul>
</p>
<a name = "macros">
<h2>Libc-macros (i.e. <tt>isspace</tt> from <tt>&lt;cctype&gt;</tt>)</h2>
</a>
<p>
Glibc 2.0.x and 2.1.x define the <tt>&lt;ctype.h&gt;</tt>-functionality
as macros (isspace, isalpha etc.). Libstdc++-v3 "shadows" these macros
as described in the <a href = "#cheaders">section on C-headers</a>.
</p>
<p>
Older implementations of libstdc++ (g++-2 for egcs 1.x and g++-3 for
gcc 2.95.2), however, keep these functions as macros, and so it is not
back-portable to use fully qualified names. For example:
<pre>
#include &lt;cctype&gt;
int main() { std::isspace('X'); }
</pre>
will result in something like this (unless using g++-v3):
<pre>
std:: (__ctype_b[(int) ( ( 'X' ) )] & (unsigned short int) _ISspace ) ;
</pre>
Another problem arises if you put a <tt>using namespace std;</tt>
declaration at the top, and include <tt>&lt;ctype.h&gt;</tt>. This will
result in ambiguities between the definitions in the global namespace
(<tt>&lt;ctype.h&gt;</tt>) and the definitions in namespace <tt>std::</tt>
(<tt>&lt;cctype&gt;</tt>).
</p>
<p>
One solution I can think of is to test for -v3 using autoconf-macros, and
define macros for each of the C-functions (maybe that is possible with one
"wrapper" macro as well ?).
</p>
<p>
Another solution which would fix g++ is to tell the user to modify
a header-file so that g++-2 (egcs 1.x) and g++-3 (gcc 2.95.2)
enable a macro which tells &lt;ctype.h&gt; to define functions instead of
macros:
<pre>
// This keeps isanum, et al from being propagated as macros.
#if __linux__
#define __NO_CTYPE 1
#endif
[ now include &lt;ctype.h&gt; ]
</pre>
</p>
<a name = "about"> <a name = "about">
<h2>About...</h2> <h2>About...</h2>
</a> </a>
<p> <p>
Please send any experience, additions, corrections or questions to <a href = Please send any experience, additions, corrections or questions to <a href
"mailto:fnatter@gmx.net">fnatter@gmx.net</a> or for discussion to = "mailto:fnatter@gmx.net">fnatter@gmx.net</a> or for discussion to the
the libstdc++-v3-mailing-list. libstdc++-v3-mailing-list.
</p> </p>
</body> </body>

45
libstdc++-v3/docs/faq/index.html
View file

@ -13,7 +13,7 @@
** Locations of "the most recent snapshot is the Nth" text are ** Locations of "the most recent snapshot is the Nth" text are
** answers 1_1, 1_4, 4_1, 5_6. ** answers 1_1, 1_4, 4_1, 5_6.
--> -->
<!-- $Id: index.html,v 1.21 2000/03/26 03:44:35 pme Exp $ --> <!-- $Id: index.html,v 1.1 2000/04/21 20:33:32 bkoz Exp $ -->
</HEAD> </HEAD>
<BODY> <BODY>
@ -106,7 +106,7 @@ HREF="ftp://sourceware.cygnus.com/pub/libstdc++/libstdc++-2.90.8.tar.gz">the
<HR> <HR>
<H2><A NAME="1_2">1.2 Why should I use libstdc++?</A></H2> <H2><A NAME="1_2">1.2 Why should I use libstdc++?</A></H2>
<P>The recent completion of the ISO C++ standardization gave the <P>The completion of the ISO C++ standardization gave the
C++ community a powerful set of reuseable tools in the form C++ community a powerful set of reuseable tools in the form
of the C++ Standard Library. However, all existing C++ of the C++ Standard Library. However, all existing C++
implementations are (as the Draft Standard used to say) implementations are (as the Draft Standard used to say)
@ -117,10 +117,10 @@ HREF="ftp://sourceware.cygnus.com/pub/libstdc++/libstdc++-2.90.8.tar.gz">the
(<TT>gcc</TT>, <TT>g++</TT>, etc) is widely considered to be (<TT>gcc</TT>, <TT>g++</TT>, etc) is widely considered to be
one of the leading compilers in the world. Its development one of the leading compilers in the world. Its development
has recently been taken over by the has recently been taken over by the
<A HREF="http://egcs.cygnus.com/">GCC team</A>. All of <A HREF="http://gcc.gnu.org/">GCC team</A>. All of
the rapid development and near-legendary the rapid development and near-legendary
<A <A
HREF="http://egcs.cygnus.com/gcc-2.95/buildstat.html">portability</A> HREF="http://gcc.gnu.org/gcc-2.95/buildstat.html">portability</A>
that are the hallmarks of an open-source project are being that are the hallmarks of an open-source project are being
applied to libstdc++. applied to libstdc++.
</P> </P>
@ -214,7 +214,7 @@ HREF="ftp://sourceware.cygnus.com/pub/libstdc++/libstdc++-2.90.8.tar.gz">
stuff&quot; classes will probably migrate there.) stuff&quot; classes will probably migrate there.)
</P> </P>
<P>For the bold and/or desperate, the <P>For the bold and/or desperate, the
<A HREF="http://egcs.cygnus.com/faq.html#libg++">GCC FAQ</A> <A HREF="http://gcc.gnu.org/faq.html#libg++">GCC FAQ</A>
describes where to find the last libg++ source. describes where to find the last libg++ source.
</P> </P>
@ -271,32 +271,13 @@ HREF="http://sourceware.cygnus.com/automake/">automake</A>.
<P>Yes, as of 2.90.8, it is intended as such.</P> <P>Yes, as of 2.90.8, it is intended as such.</P>
<P>The installation instructions cover this in more detail, but <P>The installation instructions cover this in more detail, but
replacing the older library requires rebuilding some of the replacing the older library requires rebuilding some of the
code that comes with g++. If you do not want to do that, code that comes with g++. You will need sources for the 2.95.2
then you'll be missing out on a lot of functionality, but it compiler in order to build this snapshot. Building the library
can still be done. on its own and then using -I/-L will no longer work.
</P> </P>
<P>In that case, you can use the same procedure that used to be <P>After the 2.90.8 snapshot, the library sources were integrated
required: into the compiler sources. Future releases of the compiler will
<OL> ship with libstdc++-v3.
<LI> Build GCC as usual.
<LI> Build libstdc++-v3 as described in the installation
document, under the section &quot;without GCC
sources.&quot; Be aware that you will lose the std::
namespace encapsulation.
<LI> Build your code using -I and -L options so that GCC
finds the libstdc++-v3 headers and library before the
older headers in the GCC include tree.
</OL>
</P>
<P>If you configured libstdc++-v3 to install under a directory
called <B>/lib3</B>, for example, the command line would look
something like
<!-- Careful, the leading spaces in PRE show up directly. -->
<PRE>
g++ -Wall -I/lib3/include/g++-v3 -L/lib3/lib foo.cc -o foo
</PRE>
More information (such as using SGI or GNU extensions, and
setting the runtime library path) can be found in the RELEASE-NOTES.
</P> </P>
<HR> <HR>
@ -511,7 +492,7 @@ to the list</A>, Nathan Myers announced that he has started a list of
<H2><A NAME="4_5">4.5 Aw, that's easy to fix!</A></H2> <H2><A NAME="4_5">4.5 Aw, that's easy to fix!</A></H2>
<P>If you have found a bug in the library and you think you have <P>If you have found a bug in the library and you think you have
a working fix, then send it in! The main GCC site has a page a working fix, then send it in! The main GCC site has a page
on <A HREF="http://egcs.cygnus.com/contribute.html">submitting on <A HREF="http://gcc.gnu.org/contribute.html">submitting
patches</A> that covers the procedure, but for libstdc++ you patches</A> that covers the procedure, but for libstdc++ you
should of course send the patch to our mailing list, not the should of course send the patch to our mailing list, not the
GCC mailing list. The libstdc++ GCC mailing list. The libstdc++
@ -664,7 +645,7 @@ HREF="http://sourceware.cygnus.com/ml/libstdc++/1999/msg00084.html">speculation<
Comments and suggestions are welcome, and may be sent to Comments and suggestions are welcome, and may be sent to
<A HREF="mailto:pme@sourceware.cygnus.com">Phil Edwards</A> or <A HREF="mailto:pme@sourceware.cygnus.com">Phil Edwards</A> or
<A HREF="mailto:gdr@egcs.cygnus.com">Gabriel Dos Reis</A>. <A HREF="mailto:gdr@egcs.cygnus.com">Gabriel Dos Reis</A>.
<BR> $Id: index.html,v 1.21 2000/03/26 03:44:35 pme Exp $ <BR> $Id: index.html,v 1.1 2000/04/21 20:33:32 bkoz Exp $
</EM></P> </EM></P>

124
libstdc++-v3/docs/faq/index.txt
View file

@ -65,11 +65,11 @@
1.2 Why should I use libstdc++? 1.2 Why should I use libstdc++?
The recent completion of the ISO C++ standardization gave the C++ The completion of the ISO C++ standardization gave the C++ community a
community a powerful set of reuseable tools in the form of the C++ powerful set of reuseable tools in the form of the C++ Standard
Standard Library. However, all existing C++ implementations are (as Library. However, all existing C++ implementations are (as the Draft
the Draft Standard used to say) "incomplet and incorrekt," and many Standard used to say) "incomplet and incorrekt," and many suffer from
suffer from limitations of the compilers that use them. limitations of the compilers that use them.
The GNU C/C++/FORTRAN/<pick-a-language> compiler (gcc, g++, etc) is The GNU C/C++/FORTRAN/<pick-a-language> compiler (gcc, g++, etc) is
widely considered to be one of the leading compilers in the world. Its widely considered to be one of the leading compilers in the world. Its
@ -206,25 +206,13 @@
The installation instructions cover this in more detail, but replacing The installation instructions cover this in more detail, but replacing
the older library requires rebuilding some of the code that comes with the older library requires rebuilding some of the code that comes with
g++. If you do not want to do that, then you'll be missing out on a g++. You will need sources for the 2.95.2 compiler in order to build
lot of functionality, but it can still be done. this snapshot. Building the library on its own and then using -I/-L
will no longer work.
In that case, you can use the same procedure that used to be required: After the 2.90.8 snapshot, the library sources were integrated into
1. Build GCC as usual. the compiler sources. Future releases of the compiler will ship with
2. Build libstdc++-v3 as described in the installation document, libstdc++-v3.
under the section "without GCC sources." Be aware that you will
lose the std:: namespace encapsulation.
3. Build your code using -I and -L options so that GCC finds the
libstdc++-v3 headers and library before the older headers in the
GCC include tree.
If you configured libstdc++-v3 to install under a directory called
/lib3, for example, the command line would look something like
g++ -Wall -I/lib3/include/g++-v3 -L/lib3/lib foo.cc -o foo
More information (such as using SGI or GNU extensions, and setting the
runtime library path) can be found in the RELEASE-NOTES.
_________________________________________________________________ _________________________________________________________________
2.3 What is this CVS thing that you keep mentioning? 2.3 What is this CVS thing that you keep mentioning?
@ -533,71 +521,71 @@ count(struct __rb_tree_node_base *, struct __rb_tree_node_base *)'
Comments and suggestions are welcome, and may be sent to [71]Phil Comments and suggestions are welcome, and may be sent to [71]Phil
Edwards or [72]Gabriel Dos Reis. Edwards or [72]Gabriel Dos Reis.
$Id: index.txt,v 1.17 2000/03/26 03:44:35 pme Exp $ $Id: index.html,v 1.1 2000/04/21 20:33:32 bkoz Exp $
References References
1. http://sourceware.cygnus.com/libstdc++/ 1. http://sourceware.cygnus.com/libstdc++/
2. http://sourceware.cygnus.com/libstdc++/faq/index.html 2. http://sourceware.cygnus.com/libstdc++/faq/index.html
3. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/index.html 3. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/index.html
4. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#1_0 4. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#1_0
5. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#1_1 5. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#1_1
6. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#1_2 6. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#1_2
7. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#1_3 7. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#1_3
8. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#1_4 8. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#1_4
9. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#1_5 9. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#1_5
10. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#1_6 10. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#1_6
11. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#1_7 11. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#1_7
12. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#1_8 12. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#1_8
13. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#2_0 13. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#2_0
14. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#2_1 14. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#2_1
15. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#2_2 15. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#2_2
16. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#2_3 16. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#2_3
17. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#2_4 17. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#2_4
18. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#3_0 18. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#3_0
19. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#3_1 19. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#3_1
20. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#3_2 20. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#3_2
21. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#4_0 21. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#4_0
22. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#4_1 22. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#4_1
23. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#4_2 23. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#4_2
24. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#4_3 24. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#4_3
25. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#4_4 25. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#4_4
26. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#4_5 26. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#4_5
27. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#5_0 27. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#5_0
28. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#5_1 28. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#5_1
29. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#5_2 29. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#5_2
30. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#5_3 30. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#5_3
31. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#5_4 31. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#5_4
32. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#5_5 32. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#5_5
33. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#5_6 33. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#5_6
34. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#5_7 34. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#5_7
35. ftp://sourceware.cygnus.com/pub/libstdc++/libstdc++-2.90.8.tar.gz 35. ftp://sourceware.cygnus.com/pub/libstdc++/libstdc++-2.90.8.tar.gz
36. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/17_intro/DESIGN 36. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/17_intro/DESIGN
37. http://egcs.cygnus.com/ 37. http://gcc.gnu.org/
38. http://egcs.cygnus.com/gcc-2.95/buildstat.html 38. http://gcc.gnu.org/gcc-2.95/buildstat.html
39. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/index.html 39. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/index.html
40. ftp://sourceware.cygnus.com/pub/libstdc++/libstdc++-2.90.8.tar.gz 40. ftp://sourceware.cygnus.com/pub/libstdc++/libstdc++-2.90.8.tar.gz
41. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/index.html 41. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/index.html
42. http://www.deja.com/getdoc.xp?AN=469581698&fmt=text 42. http://www.deja.com/getdoc.xp?AN=469581698&fmt=text
43. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/17_intro/contribute.html 43. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/17_intro/contribute.html
44. http://www.boost.org/ 44. http://www.boost.org/
45. http://egcs.cygnus.com/faq.html#libg++ 45. http://gcc.gnu.org/faq.html#libg++
46. mailto:libstdc++@sourceware.cygnus.com 46. mailto:libstdc++@sourceware.cygnus.com
47. mailto:pme@sourceware.cygnus.com 47. mailto:pme@sourceware.cygnus.com
48. mailto:gdr@egcs.cygnus.com 48. mailto:gdr@egcs.cygnus.com
49. http://sourceware.cygnus.com/autoconf/ 49. http://sourceware.cygnus.com/autoconf/
50. http://sourceware.cygnus.com/automake/ 50. http://sourceware.cygnus.com/automake/
51. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/documentation.html 51. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/documentation.html
52. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/17_intro/RELEASE-NOTES 52. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/17_intro/RELEASE-NOTES
53. http://www.gnu.org/software/cvs/cvs.html 53. http://www.gnu.org/software/cvs/cvs.html
54. http://www.cyclic.com/ 54. http://www.cyclic.com/
55. http://www.xraylith.wisc.edu/~khan/software/gnu-win32/libstdc++-v3.html 55. http://www.xraylith.wisc.edu/~khan/software/gnu-win32/libstdc++-v3.html
56. file://localhost/ml/libstdc++/1998/msg00006.html 56. file://localhost/ml/libstdc++/1998/msg00006.html
57. http://www.cantrip.org/draft-bugs.txt 57. http://www.cantrip.org/draft-bugs.txt
58. http://anubis.dkuug.dk/jtc1/sc22/wg21/ 58. http://anubis.dkuug.dk/jtc1/sc22/wg21/
59. http://egcs.cygnus.com/contribute.html 59. http://gcc.gnu.org/contribute.html
60. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/17_intro/contribute.html 60. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/17_intro/contribute.html
61. file://localhost/home0/pedwards/EGCS/gcc-2.95.2/libstdc++-v3/docs/faq/index.html#2_4 61. file://localhost/home0/pedwards/src/egcsworking/libstdc++-v3/docs/faq/index.html#2_4
62. http://sourceware.cygnus.com/ml/libstdc++/1999/msg00080.html 62. http://sourceware.cygnus.com/ml/libstdc++/1999/msg00080.html
63. http://sourceware.cygnus.com/ml/libstdc++/1999/msg00084.html 63. http://sourceware.cygnus.com/ml/libstdc++/1999/msg00084.html
64. http://www.sgi.com/Technology/STL/ 64. http://www.sgi.com/Technology/STL/

4
libstdc++-v3/docs/footer.html
View file

@ -9,8 +9,8 @@
These pages are stoically maintained by These pages are stoically maintained by
<A HREF="mailto:pme@sourceware.cygnus.com">Phil Edwards</a>, who might now <A HREF="mailto:pme@sourceware.cygnus.com">Phil Edwards</a>, who might now
actually be able to maintain them as the directory structure is slowly actually be able to maintain them as the directory structure is slowly
congealing into some kind of permanent structure, and was last modified on congealing into some kind of permanent structure, and were last modified on
2000-03-24. 2000-04-29.
</EM></P> </EM></P>
<!-- And this closes everything out. --> <!-- And this closes everything out. -->

9
libstdc++-v3/docs/gccrebuild.html
View file

@ -9,7 +9,7 @@
<TITLE>How to automatically rebuild libgcc.a.</TITLE> <TITLE>How to automatically rebuild libgcc.a.</TITLE>
<LINK REL="home" HREF="http://sourceware.cygnus.com/libstdc++/"> <LINK REL="home" HREF="http://sourceware.cygnus.com/libstdc++/">
<LINK REL=StyleSheet HREF="lib3styles.css"> <LINK REL=StyleSheet HREF="lib3styles.css">
<!-- $Id: gccrebuild.html,v 1.1 2000/01/14 20:03:09 pme Exp $ --> <!-- $Id: gccrebuild.html,v 1.1 2000/04/21 20:33:30 bkoz Exp $ -->
</HEAD> </HEAD>
<BODY> <BODY>
@ -39,7 +39,10 @@
as <EM>objdir</EM>; here it will be called <EM>GCCobjdir</EM>. as <EM>objdir</EM>; here it will be called <EM>GCCobjdir</EM>.
</P> </P>
<P>This is a kludge, and will go away eventually.</P> <P>This is a kludge, and will go away eventually. (In a sense, it has
already gone away, as the library sources have been merged into the
compiler sources.)
</P>
<HR> <HR>
@ -111,7 +114,7 @@
<HR> <HR>
<P CLASS="fineprint"><EM> <P CLASS="fineprint"><EM>
$Id: gccrebuild.html,v 1.1 2000/01/14 20:03:09 pme Exp $ $Id: gccrebuild.html,v 1.1 2000/04/21 20:33:30 bkoz Exp $
</EM></P> </EM></P>

18
libstdc++-v3/docs/thanks.html
View file

@ -17,7 +17,7 @@
Please keep this list in alphabetical order. Please keep this list in alphabetical order.
<!-- <!--
Latest update 2000-03-09, more or less. Latest update 2000-04-29, more or less.
--> -->
<UL> <UL>
@ -56,7 +56,8 @@
<LI>Benjamin Kosnik for, well, everything. <LI>Benjamin Kosnik for, well, everything.
<LI>Martin v. Loewis for namespace patches and fixes. <LI>Martin v. Loewis for namespace patches and fixes, and tons of
assistance with the compiler merges.
<LI>Philip Martin for lots of string and vector iterator fixes and <LI>Philip Martin for lots of string and vector iterator fixes and
improvements, and string clean up and testsuites. improvements, and string clean up and testsuites.
@ -71,7 +72,10 @@
<LI>Nathan Myers for inflicting locales on the rest of us, working on <LI>Nathan Myers for inflicting locales on the rest of us, working on
iostream, string and string documentation (!), fixing that iostream, string and string documentation (!), fixing that
__black_count loop that so many people bugged us about, and creating __black_count loop that so many people bugged us about, and creating
the initial documentation (DESIGN, CHECKLIST, and so forth). the initial documentation (DESIGN, CHECKLIST, and so forth). Huge
chunks of the MT-safe code are also due to his work.
<LI>Felix Natter for documentation on porting.
<LI>Chip Salzenberg for patches and improvements to locales, traits, <LI>Chip Salzenberg for patches and improvements to locales, traits,
Makefiles, libio, libtool hackery, and &quot;long long&quot; support. Makefiles, libio, libtool hackery, and &quot;long long&quot; support.
@ -84,11 +88,15 @@
</UL></P> </UL></P>
<P>We'd also like to thank the folks who have contributed time and <P>We'd also like to thank the folks who have contributed time and
energy in testing libstdc++-v3: energy in testing libstdc++-v3, especially those sending in testsuite
evaluations:
<UL> <UL>
<LI>Folks for sending in testsuite evaluations. <LI>J&uuml;rgen Freyh
<LI>llewelly <!-- Honest, that's the only name in the messages. -->
<LI>Loren James Rittle
<LI>George Talbot
</UL></P> </UL></P>