libstdc++-v3 HOWTO: Chapter 27

From 4b92a3bf21f0f5c27628a4b1a74da2fd2572f732 Mon Sep 17 00:00:00 2001 From: Phil Edwards Date: Wed, 18 Jul 2001 21:37:06 +0000 Subject: [PATCH] howto.html: Fix typo. 2001-07-18 Phil Edwards * 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 --- libstdc++-v3/ChangeLog | 6 +++ libstdc++-v3/docs/html/27_io/howto.html | 6 +-- libstdc++-v3/docs/html/faq/index.html | 46 +++++++++++++------ libstdc++-v3/docs/html/faq/index.txt | 60 +++++++++++++++---------- 4 files changed, 77 insertions(+), 41 deletions(-) diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog index dda8697c157..e47ceb8c0b2 100644 --- a/libstdc++-v3/ChangeLog +++ b/libstdc++-v3/ChangeLog @@ -1,3 +1,9 @@ +2001-07-18 Phil Edwards + + * 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 Roman Sulzhyk diff --git a/libstdc++-v3/docs/html/27_io/howto.html b/libstdc++-v3/docs/html/27_io/howto.html index 2d7184f13bb..3241e6e0fb0 100644 --- a/libstdc++-v3/docs/html/27_io/howto.html +++ b/libstdc++-v3/docs/html/27_io/howto.html @@ -8,7 +8,7 @@ libstdc++-v3 HOWTO: Chapter 27 - + @@ -438,7 +438,7 @@

      #include any of the I/O headers such as ios, iostream, etc
 
-     std::sync_with_stdio(false);
+     std::ios::sync_with_stdio(false);

You must do this before performing any I/O via the C++ stream objects. @@ -460,7 +460,7 @@

Comments and suggestions are welcome, and may be sent to the mailing list. -
$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 $

diff --git a/libstdc++-v3/docs/html/faq/index.html b/libstdc++-v3/docs/html/faq/index.html index e202e54f555..128ecb4dde7 100644 --- 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. --> - + @@ -241,7 +241,7 @@ which is no longer available, thanks deja...-->

If you have a question that you think should be included here, or if you have a question about a question/answer here, - contact Phil Edwards + contact Phil Edwards or Gabriel Dos Reis.

@@ -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++. -

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. @@ -304,13 +304,13 @@ which is no longer available, thanks deja...-->

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 + to actually install the library ("make install") to run the testsuite.

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. 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 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. + work to do. However: - The ISO Committee will meet periodically to review Defect Reports + + 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. - The current libstdc++ contains extensions to the Library which + 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. + + 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. + + 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. + This question about the next libstdc++ prompted some brief but @@ -584,10 +601,11 @@ HREF="http://gcc.gnu.org/ml/libstdc++/1999/msg00084.html">speculation. 5.3 What about the STL from SGI? - The 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 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 @@ -660,7 +678,7 @@ HREF="http://gcc.gnu.org/ml/libstdc++/1999/msg00084.html">speculation. Comments and suggestions are welcome, and may be sent to 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 $ diff --git a/libstdc++-v3/docs/html/faq/index.txt b/libstdc++-v3/docs/html/faq/index.txt index 37f8e7ed9b6..88c1b4be339 100644 --- 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. - - 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 -- 2.30.2