mirror of
git://gcc.gnu.org/git/gcc.git
synced 2025-03-06 09:17:02 +08:00
howto.html: Fix typo.
2001-07-18 Phil Edwards <pme@sources.redhat.com> * docs/html/27_io/howto.html: Fix typo. * docs/html/faq/index.html: Minor updates for 3.0 all around. * docs/html/faq/index.txt: Regenerated. From-SVN: r44135
This commit is contained in:
parent
d989f648fa
commit
4b92a3bf21
@ -1,3 +1,9 @@
|
||||
2001-07-18 Phil Edwards <pme@sources.redhat.com>
|
||||
|
||||
* docs/html/27_io/howto.html: Fix typo.
|
||||
* docs/html/faq/index.html: Minor updates for 3.0 all around.
|
||||
* docs/html/faq/index.txt: Regenerated.
|
||||
|
||||
2001-07-18 Stephen M. Webb <stephen@bregmasoft..com>
|
||||
Roman Sulzhyk <roman_sulzhyk@yahoo.com>
|
||||
|
||||
|
@ -8,7 +8,7 @@
|
||||
<META NAME="GENERATOR" CONTENT="vi and eight fingers">
|
||||
<TITLE>libstdc++-v3 HOWTO: Chapter 27</TITLE>
|
||||
<LINK REL=StyleSheet HREF="../lib3styles.css">
|
||||
<!-- $Id: howto.html,v 1.6 2001/07/09 19:37:01 pme Exp $ -->
|
||||
<!-- $Id: howto.html,v 1.7 2001/07/09 21:47:36 pme Exp $ -->
|
||||
</HEAD>
|
||||
<BODY>
|
||||
|
||||
@ -438,7 +438,7 @@
|
||||
<PRE>
|
||||
#include <EM>any of the I/O headers such as ios, iostream, etc</EM>
|
||||
|
||||
std::sync_with_stdio(false);
|
||||
std::ios::sync_with_stdio(false);
|
||||
</PRE>
|
||||
</P>
|
||||
<P>You must do this before performing any I/O via the C++ stream objects.
|
||||
@ -460,7 +460,7 @@
|
||||
<P CLASS="fineprint"><EM>
|
||||
Comments and suggestions are welcome, and may be sent to
|
||||
<A HREF="mailto:libstdc++@gcc.gnu.org">the mailing list</A>.
|
||||
<BR> $Id: howto.html,v 1.6 2001/07/09 19:37:01 pme Exp $
|
||||
<BR> $Id: howto.html,v 1.7 2001/07/09 21:47:36 pme Exp $
|
||||
</EM></P>
|
||||
|
||||
|
||||
|
@ -9,7 +9,7 @@
|
||||
** Locations of "the most recent snapshot is the Nth" text are
|
||||
** answers 1_1, 1_4, 4_1, 5_6.
|
||||
-->
|
||||
<!-- $Id: index.html,v 1.8 2001/05/10 18:42:11 pme Exp $ -->
|
||||
<!-- $Id: index.html,v 1.9 2001/05/30 21:55:04 pme Exp $ -->
|
||||
</HEAD>
|
||||
<BODY>
|
||||
|
||||
@ -241,7 +241,7 @@ which is no longer available, thanks deja...-->
|
||||
</P>
|
||||
<P>If you have a question that you think should be included here,
|
||||
or if you have a question <EM>about</EM> a question/answer here,
|
||||
contact <A HREF="mailto:pme@sources.redhat.com">Phil Edwards</A>
|
||||
contact <A HREF="mailto:pme@gcc.gnu.org">Phil Edwards</A>
|
||||
or <A HREF="mailto:gdr@gcc.gnu.org">Gabriel Dos Reis</A>.
|
||||
</P>
|
||||
|
||||
@ -257,7 +257,7 @@ which is no longer available, thanks deja...-->
|
||||
easier and more automated than building the GCC 2.[78]
|
||||
series was. If you are using GCC 2.95, you can still
|
||||
build earlier snapshots of libstdc++.
|
||||
<LI> GNU Make is the only make that supports these makefiles.
|
||||
<LI> GNU Make is recommended, but should not be required.
|
||||
<LI> The GNU Autotools are needed if you are messing with
|
||||
the configury or makefiles.
|
||||
</UL>
|
||||
@ -304,13 +304,13 @@ which is no longer available, thanks deja...-->
|
||||
<HR>
|
||||
<H2><A NAME="2_4">2.4 How do I know if it works?</A></H2>
|
||||
<P>libstdc++-v3 comes with its own testsuite. You do not need
|
||||
to actually install the library ("<TT>gmake
|
||||
to actually install the library ("<TT>make
|
||||
install</TT>") to run the testsuite.
|
||||
</P>
|
||||
<P>To run the testsuite on the library after building it, use
|
||||
"gmake check" while in your build directory. To run
|
||||
"make check" while in your build directory. To run
|
||||
the testsuite on the library after building and installing it,
|
||||
use "gmake check-install" instead.
|
||||
use "make check-install" instead.
|
||||
</P>
|
||||
<P>If you find bugs in the testsuite programs themselves, or if
|
||||
you think of a new test program that should be added to the
|
||||
@ -551,15 +551,22 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
|
||||
than a typedef for <TT>T*</TT> outweighs nearly all opposing
|
||||
arguments.
|
||||
</P>
|
||||
<P>Code which does assume that a vector iterator <code> i </code>
|
||||
is a pointer can often be fixed by changing <code> i </code> in
|
||||
certain expressions to <code> &*i </code>. Future revisions
|
||||
of the Standard are expected to bless this usage for
|
||||
vector<> (but not for basic_string<>).
|
||||
</P>
|
||||
|
||||
<HR>
|
||||
<H2><A NAME="5_2">5.2 What's next after libstdc++-v3?</A></H2>
|
||||
<P>Hopefully, not much. The goal of libstdc++-v3 is to produce
|
||||
a fully-compliant, fully-portable Standard Library. After that,
|
||||
we're mostly done: there won't <EM>be</EM> any more compliance
|
||||
work to do.
|
||||
work to do. However:
|
||||
</P>
|
||||
<P>The ISO Committee will meet periodically to review Defect Reports
|
||||
<OL>
|
||||
<LI><P>The ISO Committee will meet periodically to review Defect Reports
|
||||
in the C++ Standard. Undoubtedly some of these will result in
|
||||
changes to the Standard, which will be reflected in patches to
|
||||
libstdc++. Some of that is already happening, see 4.2. Some of
|
||||
@ -567,7 +574,16 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
|
||||
we add code to the library based on what the current proposed
|
||||
resolution specifies.
|
||||
</P>
|
||||
<P>The current libstdc++ contains extensions to the Library which
|
||||
<LI><P>Performance tuning. Lots of performance tuning. This too is
|
||||
already underway for post-3.0 releases, starting with memory
|
||||
expansion in container classes and buffer usage in synchronized
|
||||
stream objects.
|
||||
</P>
|
||||
<LI><P>An ABI for libstdc++ will eventually be developed, so that
|
||||
multiple binary-incompatible copies of the library can be replaced
|
||||
with a single backwards-compatible library, like libgcc_s.so is.
|
||||
</P>
|
||||
<LI><P>The current libstdc++ contains extensions to the Library which
|
||||
must be explicitly requested by client code (for example, the
|
||||
hash tables from SGI). Other extensions may be added to
|
||||
libstdc++-v3 if they seem to be "standard" enough.
|
||||
@ -575,6 +591,7 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
|
||||
Bugfixes and rewrites (to improve or fix thread safety, for
|
||||
instance) will of course be a continuing task.
|
||||
</P>
|
||||
</OL>
|
||||
<P><A
|
||||
HREF="http://gcc.gnu.org/ml/libstdc++/1999/msg00080.html">This
|
||||
question</A> about the next libstdc++ prompted some brief but
|
||||
@ -584,10 +601,11 @@ HREF="http://gcc.gnu.org/ml/libstdc++/1999/msg00084.html">speculation</A>.
|
||||
|
||||
<HR>
|
||||
<H2><A NAME="5_3">5.3 What about the STL from SGI?</A></H2>
|
||||
<P>The <A HREF="http://www.sgi.com/Technology/STL/">STL from SGI</A>
|
||||
is merged into libstdc++-v3 with changes as necessary.
|
||||
Currently release 3.3 is being used as an initial codebase, plus
|
||||
changes, fixes, and extensions.
|
||||
<P>The <A HREF="http://www.sgi.com/Technology/STL/">STL from SGI</A>,
|
||||
version 3.3, was the most recent merge of the STL codebase. The
|
||||
code in libstdc++ contains many fixes and changes, and it is
|
||||
very likely that the SGI code is no longer under active
|
||||
development. We expect that no future merges will take place.
|
||||
</P>
|
||||
<P>In particular, <TT>string</TT> is not from SGI and makes no
|
||||
use of their "rope" class (which is included as an
|
||||
@ -660,7 +678,7 @@ HREF="http://gcc.gnu.org/ml/libstdc++/1999/msg00084.html">speculation</A>.
|
||||
<P CLASS="fineprint"><EM>
|
||||
Comments and suggestions are welcome, and may be sent to
|
||||
<A HREF="mailto:libstdc++@gcc.gnu.org">the mailing list</A>.
|
||||
<BR> $Id: index.html,v 1.8 2001/05/10 18:42:11 pme Exp $
|
||||
<BR> $Id: index.html,v 1.9 2001/05/30 21:55:04 pme Exp $
|
||||
</EM></P>
|
||||
|
||||
|
||||
|
@ -187,7 +187,7 @@
|
||||
more automated than building the GCC 2.[78] series was. If you are
|
||||
using GCC 2.95, you can still build earlier snapshots of
|
||||
libstdc++.
|
||||
* GNU Make is the only make that supports these makefiles.
|
||||
* GNU Make is recommended, but should not be required.
|
||||
* The GNU Autotools are needed if you are messing with the configury
|
||||
or makefiles.
|
||||
|
||||
@ -228,11 +228,11 @@
|
||||
2.4 How do I know if it works?
|
||||
|
||||
libstdc++-v3 comes with its own testsuite. You do not need to actually
|
||||
install the library ("gmake install") to run the testsuite.
|
||||
install the library ("make install") to run the testsuite.
|
||||
|
||||
To run the testsuite on the library after building it, use "gmake
|
||||
To run the testsuite on the library after building it, use "make
|
||||
check" while in your build directory. To run the testsuite on the
|
||||
library after building and installing it, use "gmake check-install"
|
||||
library after building and installing it, use "make check-install"
|
||||
instead.
|
||||
|
||||
If you find bugs in the testsuite programs themselves, or if you think
|
||||
@ -430,27 +430,38 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
|
||||
were never guaranteed by the Standard anyway. The type-safety achieved
|
||||
by making iterators a real class rather than a typedef for T*
|
||||
outweighs nearly all opposing arguments.
|
||||
|
||||
Code which does assume that a vector iterator i is a pointer can often
|
||||
be fixed by changing i in certain expressions to &*i . Future
|
||||
revisions of the Standard are expected to bless this usage for
|
||||
vector<> (but not for basic_string<>).
|
||||
_________________________________________________________________
|
||||
|
||||
5.2 What's next after libstdc++-v3?
|
||||
|
||||
Hopefully, not much. The goal of libstdc++-v3 is to produce a
|
||||
fully-compliant, fully-portable Standard Library. After that, we're
|
||||
mostly done: there won't be any more compliance work to do.
|
||||
|
||||
The ISO Committee will meet periodically to review Defect Reports in
|
||||
the C++ Standard. Undoubtedly some of these will result in changes to
|
||||
the Standard, which will be reflected in patches to libstdc++. Some of
|
||||
that is already happening, see 4.2. Some of those changes are being
|
||||
predicted by the library maintainers, and we add code to the library
|
||||
based on what the current proposed resolution specifies.
|
||||
|
||||
The current libstdc++ contains extensions to the Library which must be
|
||||
explicitly requested by client code (for example, the hash tables from
|
||||
SGI). Other extensions may be added to libstdc++-v3 if they seem to be
|
||||
"standard" enough. (For example, the "long long" type from C99.)
|
||||
Bugfixes and rewrites (to improve or fix thread safety, for instance)
|
||||
will of course be a continuing task.
|
||||
mostly done: there won't be any more compliance work to do. However:
|
||||
1. The ISO Committee will meet periodically to review Defect Reports
|
||||
in the C++ Standard. Undoubtedly some of these will result in
|
||||
changes to the Standard, which will be reflected in patches to
|
||||
libstdc++. Some of that is already happening, see 4.2. Some of
|
||||
those changes are being predicted by the library maintainers, and
|
||||
we add code to the library based on what the current proposed
|
||||
resolution specifies.
|
||||
2. Performance tuning. Lots of performance tuning. This too is
|
||||
already underway for post-3.0 releases, starting with memory
|
||||
expansion in container classes and buffer usage in synchronized
|
||||
stream objects.
|
||||
3. An ABI for libstdc++ will eventually be developed, so that
|
||||
multiple binary-incompatible copies of the library can be replaced
|
||||
with a single backwards-compatible library, like libgcc_s.so is.
|
||||
4. The current libstdc++ contains extensions to the Library which
|
||||
must be explicitly requested by client code (for example, the hash
|
||||
tables from SGI). Other extensions may be added to libstdc++-v3 if
|
||||
they seem to be "standard" enough. (For example, the "long long"
|
||||
type from C99.) Bugfixes and rewrites (to improve or fix thread
|
||||
safety, for instance) will of course be a continuing task.
|
||||
|
||||
[69]This question about the next libstdc++ prompted some brief but
|
||||
interesting [70]speculation.
|
||||
@ -458,9 +469,10 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
|
||||
|
||||
5.3 What about the STL from SGI?
|
||||
|
||||
The [71]STL from SGI is merged into libstdc++-v3 with changes as
|
||||
necessary. Currently release 3.3 is being used as an initial codebase,
|
||||
plus changes, fixes, and extensions.
|
||||
The [71]STL from SGI, version 3.3, was the most recent merge of the
|
||||
STL codebase. The code in libstdc++ contains many fixes and changes,
|
||||
and it is very likely that the SGI code is no longer under active
|
||||
development. We expect that no future merges will take place.
|
||||
|
||||
In particular, string is not from SGI and makes no use of their "rope"
|
||||
class (which is included as an optional extension), nor is valarray
|
||||
@ -517,7 +529,7 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
|
||||
|
||||
Comments and suggestions are welcome, and may be sent to [78]the
|
||||
mailing list.
|
||||
$Id: index.html,v 1.8 2001/05/10 18:42:11 pme Exp $
|
||||
$Id: index.html,v 1.9 2001/05/30 21:55:04 pme Exp $
|
||||
|
||||
References
|
||||
|
||||
@ -571,7 +583,7 @@ References
|
||||
48. http://www.boost.org/
|
||||
49. http://gcc.gnu.org/fom_serv/cache/33.html
|
||||
50. mailto:libstdc++@gcc.gnu.org
|
||||
51. mailto:pme@sources.redhat.com
|
||||
51. mailto:pme@gcc.gnu.org
|
||||
52. mailto:gdr@gcc.gnu.org
|
||||
53. ../documentation.html
|
||||
54. ../17_intro/RELEASE-NOTES
|
||||
|
Loading…
Reference in New Issue
Block a user