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

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
4b92a3bf · Phil Edwards · d989f648 · 4b92a3bf · 4b92a3bf · 4b92a3bf
Commit 4b92a3bf authored Jul 18, 2001 by Phil Edwards
Hide whitespace changes
Inline Side-by-side

Showing with 77 additions and 41 deletions

libstdc++-v3/ChangeLog
+6 -0

libstdc++-v3/docs/html/27_io/howto.html
+3 -3

libstdc++-v3/docs/html/faq/index.html
+32 -14

libstdc++-v3/docs/html/faq/index.txt
+36 -24

No files found.
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
+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>

--- a/libstdc++-v3/docs/html/27_io/howto.html
+++ b/libstdc++-v3/docs/html/27_io/howto.html
@@ -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>

--- a/libstdc++-v3/docs/html/faq/index.html
+++ b/libstdc++-v3/docs/html/faq/index.html
@@ -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 (&quot;<TT>gmake
+         to actually install the library (&quot;<TT>make
         install</TT>&quot;) to run the testsuite.
      </P>
      <P>To run the testsuite on the library after building it, use
-         &quot;gmake check&quot; while in your build directory.  To run
+         &quot;make check&quot; while in your build directory.  To run
         the testsuite on the library after building and installing it,
-         use &quot;gmake check-install&quot; instead.
+         use &quot;make check-install&quot; 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> &amp;*i </code>.  Future revisions
+         of the Standard are expected to bless this usage for
+         vector&lt;&gt; (but not for basic_string&lt;&gt;).
+      </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 &quot;standard&quot; 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>
+      <P>The <A HREF="http://www.sgi.com/Technology/STL/">STL from SGI</A>,
-         is merged into libstdc++-v3 with changes as necessary.  
+         version 3.3, was the most recent merge of the STL codebase.  The
-         Currently release 3.3 is being used as an initial codebase, plus
+         code in libstdc++ contains many fixes and changes, and it is
-         changes, fixes, and extensions.
+         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 &quot;rope&quot; 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>

--- a/libstdc++-v3/docs/html/faq/index.txt
+++ b/libstdc++-v3/docs/html/faq/index.txt
@@ -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.
+   mostly done: there won't be any more compliance work to do. However:
+    1. The ISO Committee will meet periodically to review Defect Reports
-   The ISO Committee will meet periodically to review Defect Reports in
+       in the C++ Standard. Undoubtedly some of these will result in
-   the C++ Standard. Undoubtedly some of these will result in changes to
+       changes to the Standard, which will be reflected in patches to
-   the Standard, which will be reflected in patches to libstdc++. Some of
+       libstdc++. Some of that is already happening, see 4.2. Some of
-   that is already happening, see 4.2. Some of those changes are being
+       those changes are being predicted by the library maintainers, and
-   predicted by the library maintainers, and we add code to the library
+       we add code to the library based on what the current proposed
-   based on what the current proposed resolution specifies.
+       resolution specifies.
+    2. Performance tuning. Lots of performance tuning. This too is
-   The current libstdc++ contains extensions to the Library which must be
+       already underway for post-3.0 releases, starting with memory
-   explicitly requested by client code (for example, the hash tables from
+       expansion in container classes and buffer usage in synchronized
-   SGI). Other extensions may be added to libstdc++-v3 if they seem to be
+       stream objects.
-   "standard" enough. (For example, the "long long" type from C99.)
+    3. An ABI for libstdc++ will eventually be developed, so that
-   Bugfixes and rewrites (to improve or fix thread safety, for instance)
+       multiple binary-incompatible copies of the library can be replaced
-   will of course be a continuing task.
+       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
+   The [71]STL from SGI, version 3.3, was the most recent merge of the
-   necessary. Currently release 3.3 is being used as an initial codebase,
+   STL codebase. The code in libstdc++ contains many fixes and changes,
-   plus changes, fixes, and extensions.
+   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