+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>
<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>
<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.
<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>
** 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>
</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>
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>
<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
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
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.
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
<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
<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>
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.
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
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.
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
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
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
OSDN Git Service
