From 754ac8f7b2d97cbb4adbb355865fd01e69c73a1e Mon Sep 17 00:00:00 2001
From: Phil Edwards
+#include
The names of the headers can be easily seen in - this source code, + testsuite/17_intro/headers.cc, which is a small testbed we use to make certain that the headers all compile and run.
@@ -147,7 +147,7 @@ Comments and suggestions are welcome, and may be sent to Phil Edwards or Gabriel Dos Reis. -+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". +
++Because there are many compilers which still use an implementation that +does not have the standard C++-library in namespace std::, some +care is required to support these as well. +
++Namespace back-portability-issues are generally not a problem with g++, +because versions of g++ that do not have libstdc++ in std:: use +-fno-honor-std (ignore std::, :: = std::) by +default. That is, the responsibility for enabling or disabling +std:: is on the user; the maintainer does not have to care about it. +This probably applies to some other compilers as well.
-Namespace portability-issues are not a problem with g++, because versions -of g++ that do not have libstdc++ in std:: use -fno-honor-std -(ignore std::, :: = std::) by default. This probably -applies to some other compilers as well. - The following sections list some possible solutions to support compilers that cannot ignore std::.
+Gtk-- 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 namespace composition. This is what happens if you put a using-declaration into a namespace-definition: the imported -symbol(s) gets imported into the currently active namespace(s). This is -what it looks like in Gtk--: +symbol(s) gets imported into the currently active namespace(s). For example:
namespace Gtk { using std::string; @@ -64,16 +83,23 @@ namespace Gtk { }In this example, std::string gets imported into namespace Gtk::. -The result is that you don't have to use std::string in this header, -but still std::string does not get imported into user-space (the -global namespace ::) unless the user does using namespace Gtk; -(which is not recommended practice for Gtk--, so it is not a problem). +The result is that you don't have to use std::string in this +header, but still std::string does not get imported into +user-space (the global namespace ::) unless the user does using +namespace Gtk; (which is not recommended practice for Gtk--, so it is +not a problem). Additionally, the using-declarations are wrapped +in macros that are set based on autoconf-tests to either "" or +i.e. using std::string; (depending on whether the system has +libstdc++ in std:: or not). +(ideas from llewelly@dbritsch.dsl.xmission.com, +Karl Nelson
-By defining an (empty) namespace std:: before using it, you can avoid -getting errors on systems where no part of the library is in std: +By defining an (empty) namespace std:: before using it, you can +avoid getting errors on systems where no part of the library is in +namespace std:
namespace std { } using namespace std; @@ -82,12 +108,12 @@ using namespace std;Avoid to use fully qualified names (i.e. std::string)
If some compilers complain about using std::string;, 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 NS_STD, which is defined to either "" or "std" based on an autoconf-test. Then you should be able to use NS_STD::string, which will evaluate to ::string ("string 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)
How some open-source-projects deal with this
@@ -103,7 +129,7 @@ in the global namespace") on systems that do not put string in std::.mnemonic none @@ -117,11 +143,14 @@ in the global namespace") on systems that do not put string in std::. libsigc++ -portable-impl +conservative-impl none no namespace std at all - - +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 Gtk-- "hack").portable-impl wrap all namespace-handling in macros to support - compilers without namespace-support (no libstdc++ used in headers) +conservative-impl wrap all namespace-handling in macros to + support compilers without namespace-support (no libstdc++ used in + headers) there is no ios::nocreate/ios::noreplace in ISO 14882
@@ -136,7 +165,8 @@ input-streams. For output streams, "nocreate" is probably the default, unless you specify std::ios::trunc ? To be safe, you can open the file for 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 +app, ate and trunc (except for app ?).stream::attach(int fd) is not in the standard any more
@@ -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). -<ctype.h> introduces ambiguity when used with - <cctype>
--The best solution I came up with so far is to include cctype -instead of ctype.h wherever possible, and then use fully -qualified names to refer to the libstdc++-versions: std::islower, -std::isalnum etc. (you will need to as soon as any header includes -<ctype.h>, because then there will be an ambiguity with the -C-versions in the global namespace defined in <ctype.h>) + +
New headers replacing C-headers
+ ++You should not use the C-headers (except for system-level headers) from C++ +programs. Instead, you should use a set of headers that are named by +prepending 'c' and, as usual, ommiting the extension (.h). For example, +instead of using <math.h>, you should use +<cmath>. The standard specifies that if you include the +C-style header (<math.h> in this case), the symbols will be +available both in the global namespace and in namespace std:: +(libstdc++-v3, version 2.90.8 currently puts them in std:: only) +On the other hand, if you include only the new header +(i.e. <cmath>), the symbols will only be defined in +namespace std:: (and macros will be converted to +inline-functions).
- ++For more information on this, and for information on how the GNU C++ +implementation reuses ("shadows") the C library-functions, have +a look at www.cantrip.org. +
+<fstream> does not define std::cout, std::cin etc.
In previous versions of the standard, <fstream.h>, <ostream.h> and <istream.h> used to define -cout, cin and so on. With libstdc++-v3, you need -to include <iostream> to define these. +cout, cin and so on. Because of the templatized iostreams +in libstdc++-v3, you need to include <iostream> explicitly +to define these. +
+ + +Iterators
+ ++The following are not proper uses of iterators, but may be working fixes +for existing uses of iterators. +
+Glibc 2.0.x and 2.1.x define the <ctype.h>-functionality +as macros (isspace, isalpha etc.). Libstdc++-v3 "shadows" these macros +as described in the section on C-headers. +
++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: +
+#include <cctype> +int main() { std::isspace('X'); } ++will result in something like this (unless using g++-v3): +
+std:: (__ctype_b[(int) ( ( 'X' ) )] & (unsigned short int) _ISspace ) ; ++Another problem arises if you put a using namespace std; +declaration at the top, and include <ctype.h>. This will +result in ambiguities between the definitions in the global namespace +(<ctype.h>) and the definitions in namespace std:: +(<cctype>). + +
+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 ?). +
++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 <ctype.h> to define functions instead of +macros: +
+// This keeps isanum, et al from being propagated as macros. +#if __linux__ +#define __NO_CTYPE 1 +#endif + +[ now include <ctype.h> ] ++ +
-Please send any experience, additions, corrections or questions to fnatter@gmx.net or for discussion to -the libstdc++-v3-mailing-list. +Please send any experience, additions, corrections or questions to fnatter@gmx.net or for discussion to the +libstdc++-v3-mailing-list.
diff --git a/libstdc++-v3/docs/faq/index.html b/libstdc++-v3/docs/faq/index.html index 12c7b3d..e516fe1 100644 --- a/libstdc++-v3/docs/faq/index.html +++ b/libstdc++-v3/docs/faq/index.html @@ -13,7 +13,7 @@ ** Locations of "the most recent snapshot is the Nth" text are ** answers 1_1, 1_4, 4_1, 5_6. --> - + @@ -106,7 +106,7 @@ HREF="ftp://sourceware.cygnus.com/pub/libstdc++/libstdc++-2.90.8.tar.gz">theThe recent completion of the ISO C++ standardization gave the +
The completion of the ISO C++ standardization gave the C++ community a powerful set of reuseable tools in the form of the C++ Standard Library. However, all existing C++ 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 (gcc, g++, etc) is widely considered to be one of the leading compilers in the world. Its development has recently been taken over by the - GCC team. All of + GCC team. All of the rapid development and near-legendary portability +HREF="http://gcc.gnu.org/gcc-2.95/buildstat.html">portability that are the hallmarks of an open-source project are being applied to libstdc++.
@@ -214,7 +214,7 @@ HREF="ftp://sourceware.cygnus.com/pub/libstdc++/libstdc++-2.90.8.tar.gz"> stuff" classes will probably migrate there.)For the bold and/or desperate, the - GCC FAQ + GCC FAQ describes where to find the last libg++ source.
@@ -271,32 +271,13 @@ HREF="http://sourceware.cygnus.com/automake/">automake.Yes, as of 2.90.8, it is intended as such.
The installation instructions cover this in more detail, but replacing 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 lot of functionality, but it - can still be done. -
-In that case, you can use the same procedure that used to be - required: -
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. + code that comes with g++. You will need sources for the 2.95.2 + compiler in order to build this snapshot. Building the library + on its own and then using -I/-L will no longer work. + +
After the 2.90.8 snapshot, the library sources were integrated + into the compiler sources. Future releases of the compiler will + ship with libstdc++-v3.
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
- on submitting
+ on submitting
patches that covers the procedure, but for libstdc++ you
should of course send the patch to our mailing list, not the
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
Phil Edwards or
Gabriel Dos Reis.
-
$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 $
This is a kludge, and will go away eventually.
+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.) +
-$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 $
diff --git a/libstdc++-v3/docs/thanks.html b/libstdc++-v3/docs/thanks.html index 791272c..02d989c 100644 --- a/libstdc++-v3/docs/thanks.html +++ b/libstdc++-v3/docs/thanks.html @@ -17,7 +17,7 @@ Please keep this list in alphabetical order.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: