From 604b91240e4f3a1b5c97681b575389addf3dd638 Mon Sep 17 00:00:00 2001
From: Jonathan Wakely
diff --git a/libstdc++-v3/doc/html/faq.html b/libstdc++-v3/doc/html/faq.html index 76f318c969d..6166c3e1f05 100644 --- a/libstdc++-v3/doc/html/faq.html +++ b/libstdc++-v3/doc/html/faq.html @@ -4,7 +4,7 @@ 2008 FSF -
- C++ applications often dependent on specific language support + C++ applications often depend on specific language support routines, say for throwing exceptions, or catching exceptions, and - perhaps also dependent on features in the C++ Standard Library. + perhaps also depend on features in the C++ Standard Library.
The C++ Standard Library has many include files, types defined in those include files, specific named functions, and other @@ -65,7 +65,7 @@ as to give distinct versions to the C++ interface. releases of library binaries the ability to add new symbols and add functionality, all the while retaining compatibility with the previous releases in the series. Thus, program binaries linked with the initial -release of a library binary will still link correctly if the library +release of a library binary will still run correctly if the library binary is replaced by carefully-managed subsequent library binaries. This is called forward compatibility.
@@ -99,7 +99,7 @@ compatible. is not listed, it has the same version labels as the preceding release.
This corresponds to the mapfile: gcc/libgcc-std.ver
gcc-3.0.0: GCC_3.0
gcc-3.3.0: GCC_3.3
gcc-3.3.1: GCC_3.3.1
gcc-3.3.2: GCC_3.3.2
gcc-3.3.4: GCC_3.3.4
gcc-3.4.0: GCC_3.4
gcc-3.4.2: GCC_3.4.2
gcc-3.4.4: GCC_3.4.4
gcc-4.0.0: GCC_4.0.0
gcc-4.1.0: GCC_4.1.0
gcc-4.2.0: GCC_4.2.0
gcc-4.3.0: GCC_4.3.0
gcc-4.4.0: GCC_4.4.0
Release versioning on the libstdc++.so binary, implemented in
- the same was as the libgcc_s.so binary above. Listed is the
+ the same way as the libgcc_s.so binary above. Listed is the
filename: DT_SONAME
can be deduced from
the filename by removing the last two period-delimited numbers. For
example, filename libstdc++.so.5.0.4
@@ -117,9 +117,9 @@ compatible.
Note 3: This release (but not previous or subsequent) has one
known incompatibility, see 33678
in the GCC bug database.
-
Symbol versioning on the libstdc++.so binary.
mapfile: libstdc++/config/linker-map.gnu
It is versioned with the following labels and version +
Symbol versioning on the libstdc++.so binary.
mapfile: libstdc++-v3/config/abi/pre/gnu.ver
It is versioned with the following labels and version definitions, where the version definition is the maximum for a - particular release. Note, only symbol which are newly introduced + particular release. Note, only symbols which are newly introduced will use the maximum version definition. Thus, for release series with the same label, but incremented version definitions, the later release has both versions. (An example of this would be the @@ -151,7 +151,7 @@ compatible. was released, in compressed ISO date format, as an unsigned long.
This macro is defined in the file "c++config" in the - "libstdc++/include/bits" directory. (Up to gcc-4.1.0, it was + "libstdc++-v3/include/bits" directory. (Up to gcc-4.1.0, it was changed every night by an automated script. Since gcc-4.1.0, it is the same value as gcc/DATESTAMP.)
@@ -164,7 +164,7 @@ compatible. is called _GLIBCXX_VERSION).
This macro is defined in the file "c++config" in the - "libstdc++/include/bits" directory and is generated + "libstdc++-v3/include/bits" directory and is generated automatically by autoconf as part of the configure-time generation of config.h.
@@ -177,7 +177,7 @@ compatible. All C++ includes are installed in include/c++, then nest in a directory hierarchy corresponding to the C++ compiler's released version. This version corresponds to the variable "gcc_version" in - "libstdc++/acinclude.m4," and more details can be found in that + "libstdc++-v3/acinclude.m4," and more details can be found in that file's macro GLIBCXX_CONFIGURE (GLIBCPP_CONFIGURE before gcc-3.4.0).
C++ includes are versioned as follows: @@ -190,7 +190,8 @@ compatible.
Minimum environment that supports a versioned ABI: A supported dynamic linker, a GNU linker of sufficient vintage to understand - demangled C++ name globbing (ld), a shared executable compiled + demangled C++ name globbing (ld) or the Sun linker, a shared + executable compiled with g++, and shared libraries (libgcc_s, libstdc++) compiled by a compiler (g++) with a compatible ABI. Phew.
@@ -200,7 +201,7 @@ compatible.
Most modern Linux and BSD versions, particularly ones using gcc-3.1.x tools and more recent vintages, will meet the - requirements above. + requirements above, as does Solaris 2.5 and up.
It turns out that most of the configure options that change default behavior will impact the mangled names of exported @@ -208,12 +209,12 @@ compatible.
For more information on configure options, including ABI impacts, see: - http://gcc.gnu.org/onlinedocs/libstdc++/configopts.html + here
There is one flag that explicitly deals with symbol versioning: --enable-symvers.
- In particular, libstdc++/acinclude.m4 has a macro called + In particular, libstdc++-v3/acinclude.m4 has a macro called GLIBCXX_ENABLE_SYMVERS that defaults to yes (or the argument passed in via --enable-symvers=foo). At that point, the macro attempts to make sure that all the requirement for symbol @@ -228,6 +229,7 @@ compatible. checking versioning on shared library symbols... gnu
+ or another of the supported styles. If you don't see this line in the configure output, or if this line appears but the last word is 'no', then you are out of luck.
@@ -255,6 +257,17 @@ If you see symbols in the resulting output with "GLIBCXX_3" as part of the name, then the executable is versioned. Here's an example:
U _ZNSt8ios_base4InitC1Ev@@GLIBCXX_3.4
+
+On Solaris 2, you can use pvs -r
instead:
+
+%g++ hello.cc -o hello.out + +%pvs -r hello.out + libstdc++.so.6 (GLIBCXX_3.4, GLIBCXX_3.4.12); + libgcc_s.so.1 (GCC_3.0); + libc.so.1 (SUNWprivate_1.1, SYSVABI_1.3); +
+ldd -v
works too, but is very verbose.
The following will cause the library minor version number to increase, say from "libstdc++.so.3.0.4" to "libstdc++.so.3.0.5". @@ -274,7 +287,7 @@ number to increase, say from "libstdc++.so.3.0.4" to
Adding an explicit copy constructor or destructor to a class that would otherwise have implicit versions. This will change the way the compiler deals with this class in by-value return -statements or parameters: instead of being passing instances of this +statements or parameters: instead of passing instances of this class in registers, the compiler will be forced to use memory. See this part of the C++ ABI documentation for further details.
@@ -358,7 +371,7 @@ http://gcc.gnu.org/ml/gcc/2002-08/msg00142.html Two. Use the 'make check-abi' rule in the libstdc++ Makefile.
-This is a proactive check the library ABI. Currently, exported symbol +This is a proactive check of the library ABI. Currently, exported symbol names that are either weak or defined are checked against a last known good baseline. Currently, this baseline is keyed off of 3.4.0 binaries, as this was the last time the .so number was incremented. In @@ -387,13 +400,13 @@ Another approach might be to use the -fdump-class-hierarchy flag to get information. However, currently this approach gives insufficient data for use in library testing, as class data members, their offsets, and other detailed data is not displayed with this flag. -(See g++/7470 on how this was used to find bugs.) +(See PR g++/7470 on how this was used to find bugs.)
Perhaps there are other C++ ABI checkers. If so, please notify us. We'd like to know about them!
A "C" application, dynamically linked to two shared libraries, liba, -libb. The dependent library liba is C++ shared library compiled with +libb. The dependent library liba is a C++ shared library compiled with gcc-3.3.x, and uses io, exceptions, locale, etc. The dependent library libb is a C++ shared library compiled with gcc-3.4.x, and also uses io, exceptions, locale, etc. @@ -467,49 +480,49 @@ gcc test.c -g -O2 -L. -lone -ltwo /usr/lib/libstdc++.so.5 /usr/lib/libstdc++.so. 24660: versioning weak symbols in libstdc++
19664: libstdc++ headers should have pop/push of the visibility around the declarations -
- + .
- + .
Dynamic Shared Objects: Survey and Issues @@ -517,7 +530,7 @@ gcc test.c -g -O2 -L. -lone -ltwo /usr/lib/libstdc++.so.5 /usr/lib/libstdc++.so. . ISO C++ J16/06-0046 - .
Versioning With Namespaces @@ -525,7 +538,7 @@ gcc test.c -g -O2 -L. -lone -ltwo /usr/lib/libstdc++.so.5 /usr/lib/libstdc++.so. . ISO C++ J16/06-0083 - .
Binary Compatibility of Shared Libraries Implemented in C++
diff --git a/libstdc++-v3/doc/html/manual/algorithms.html b/libstdc++-v3/doc/html/manual/algorithms.html
index 0ef261f85c9..17d09b6bd5f 100644
--- a/libstdc++-v3/doc/html/manual/algorithms.html
+++ b/libstdc++-v3/doc/html/manual/algorithms.html
@@ -7,7 +7,7 @@
Standard Contents
Next
The neatest accomplishment of the algorithms sect1 is that all the work is done via iterators, not containers directly. This means two diff --git a/libstdc++-v3/doc/html/manual/api.html b/libstdc++-v3/doc/html/manual/api.html index 45b2b378b24..efd9a39f19c 100644 --- a/libstdc++-v3/doc/html/manual/api.html +++ b/libstdc++-v3/doc/html/manual/api.html @@ -75,11 +75,11 @@ _Alloc_traits have been removed. __alloc to select an underlying allocator that satisfied memory allocation requests. The selection of this underlying allocator was not user-configurable. -
Table B.1. Extension Allocators
Allocator (3.4) | Header (3.4) | Allocator (3.[0-3]) | Header (3.[0-3]) |
---|---|---|---|
__gnu_cxx::new_allocator<T> | ext/new_allocator.h | std::__new_alloc | memory |
__gnu_cxx::malloc_allocator<T> | ext/malloc_allocator.h | std::__malloc_alloc_template<int> | memory |
__gnu_cxx::debug_allocator<T> | ext/debug_allocator.h | std::debug_alloc<T> | memory |
__gnu_cxx::__pool_alloc<T> | ext/pool_allocator.h | std::__default_alloc_template<bool,int> | memory |
__gnu_cxx::__mt_alloc<T> | ext/mt_allocator.h | ||
__gnu_cxx::bitmap_allocator<T> | ext/bitmap_allocator.h |
Releases after gcc-3.4 have continued to add to the collection +
Table B.1. Extension Allocators
Allocator (3.4) | Header (3.4) | Allocator (3.[0-3]) | Header (3.[0-3]) |
---|---|---|---|
__gnu_cxx::new_allocator<T> | ext/new_allocator.h | std::__new_alloc | memory |
__gnu_cxx::malloc_allocator<T> | ext/malloc_allocator.h | std::__malloc_alloc_template<int> | memory |
__gnu_cxx::debug_allocator<T> | ext/debug_allocator.h | std::debug_alloc<T> | memory |
__gnu_cxx::__pool_alloc<T> | ext/pool_allocator.h | std::__default_alloc_template<bool,int> | memory |
__gnu_cxx::__mt_alloc<T> | ext/mt_allocator.h | ||
__gnu_cxx::bitmap_allocator<T> | ext/bitmap_allocator.h |
Releases after gcc-3.4 have continued to add to the collection of available allocators. All of these new allocators are standard-style. The following table includes details, along with the first released version of GCC that included the extension allocator. -
Table B.2. Extension Allocators Continued
Allocator | Include | Version |
---|---|---|
__gnu_cxx::array_allocator<T> | ext/array_allocator.h | 4.0.0 |
__gnu_cxx::throw_allocator<T> | ext/throw_allocator.h | 4.2.0 |
+
Table B.2. Extension Allocators Continued
Allocator | Include | Version |
---|---|---|
__gnu_cxx::array_allocator<T> | ext/array_allocator.h | 4.0.0 |
__gnu_cxx::throw_allocator<T> | ext/throw_allocator.h | 4.2.0 |
Debug mode first appears.
Precompiled header support PCH support. diff --git a/libstdc++-v3/doc/html/manual/appendix_contributing.html b/libstdc++-v3/doc/html/manual/appendix_contributing.html index 1864b97d84c..655f40c584b 100644 --- a/libstdc++-v3/doc/html/manual/appendix_contributing.html +++ b/libstdc++-v3/doc/html/manual/appendix_contributing.html @@ -7,7 +7,7 @@ Appendices
Table of Contents
The GNU C++ Library follows an open development model. Active contributors are assigned maintainer-ship responsibility, and given diff --git a/libstdc++-v3/doc/html/manual/appendix_free.html b/libstdc++-v3/doc/html/manual/appendix_free.html index 15db4da3b0d..8e3dbbed847 100644 --- a/libstdc++-v3/doc/html/manual/appendix_free.html +++ b/libstdc++-v3/doc/html/manual/appendix_free.html @@ -7,7 +7,7 @@ Appendices
The biggest deficiency in free operating systems is not in the software--it is the lack of good free manuals that we can include in diff --git a/libstdc++-v3/doc/html/manual/appendix_gpl.html b/libstdc++-v3/doc/html/manual/appendix_gpl.html index e2258ccf2d3..a9a81dfea27 100644 --- a/libstdc++-v3/doc/html/manual/appendix_gpl.html +++ b/libstdc++-v3/doc/html/manual/appendix_gpl.html @@ -78,7 +78,7 @@
The precise terms and conditions for copying, distribution and modification follow. -
Table of Contents
As noted previously, certain other tools are necessary for hacking on files that diff --git a/libstdc++-v3/doc/html/manual/atomics.html b/libstdc++-v3/doc/html/manual/atomics.html index 317d66fce72..12f7406f01c 100644 --- a/libstdc++-v3/doc/html/manual/atomics.html +++ b/libstdc++-v3/doc/html/manual/atomics.html @@ -7,7 +7,7 @@ Standard Contents
Table of Contents
Facilities for atomic operations.
diff --git a/libstdc++-v3/doc/html/manual/backwards.html b/libstdc++-v3/doc/html/manual/backwards.html index 02517c6cd94..851461bab9a 100644 --- a/libstdc++-v3/doc/html/manual/backwards.html +++ b/libstdc++-v3/doc/html/manual/backwards.html @@ -17,8 +17,8 @@ ISO Standard (e.g., statistical analysis). While there are a lot of really useful things that are used by a lot of people, the Standards Committee couldn't include everything, and so a lot of those “obvious” classes didn't get included. -
Known Issues include many of the limitations of its immediate ancestor.
Portability notes and known implementation limitations are as follows.
At least some older implementations don't have std::ios_base
, so you should use std::ios::badbit
, std::ios::failbit
and std::ios::eofbit
and std::ios::goodbit
.
-
+
Known Issues include many of the limitations of its immediate ancestor.
Portability notes and known implementation limitations are as follows.
At least some older implementations don't have std::ios_base
, so you should use std::ios::badbit
, std::ios::failbit
and std::ios::eofbit
and std::ios::goodbit
.
+
In earlier versions of the standard,
fstream.h
,
ostream.h
@@ -44,7 +44,7 @@ considered replaced and rewritten.
archived. The code is considered replaced and rewritten.
Portability notes and known implementation limitations are as follows. -
+
Some care is required to support C++ compiler and or library
implementation that do not have the standard library in
namespace std
.
@@ -108,7 +108,7 @@ AC_DEFUN([AC_CXX_NAMESPACE_STD], [
AC_DEFINE(HAVE_NAMESPACE_STD,,[Define if g++ supports namespace std. ])
fi
])
-
The following illustrate implementation-allowed illegal iterator use, and then correct use.
@@ -121,7 +121,7 @@ AC_DEFUN([AC_CXX_NAMESPACE_STD], [
if (iterator)
won't work any more => use
if (iterator != iterator_type())
-
Glibc 2.0.x and 2.1.x define ctype.h
functionality as macros
(isspace, isalpha etc.).
@@ -154,7 +154,7 @@ std:: (__ctype_b[(int) ( ( 'X' ) )] & (unsigned short int) _ISspace ) ;
(ctype.h
) and the
definitions in namespace std::
(<cctype>
).
-
One solution is to add an autoconf-test for this:
AC_MSG_CHECKING(for container::at) @@ -180,7 +180,7 @@ AC_DEFINE(HAVE_CONTAINER_AT)],
If you are using other (non-GNU) compilers it might be a good idea
to check for string::at
separately.
-
Use some kind of autoconf test, plus this:
#ifdef HAVE_CHAR_TRAITS @@ -188,7 +188,7 @@ AC_DEFINE(HAVE_CONTAINER_AT)], #else #define CPP_EOF EOF #endif -
There are two functions for deleting the contents of a string:
clear
and erase
(the latter returns the
string).
@@ -206,12 +206,12 @@ erase(size_type __pos = 0, size_type __n = npos)
Unfortunately, clear
is not implemented in this
version, so you should use erase
(which is probably
faster than operator=(charT*)
).
-
These are no longer supported. Please use stringstreams instead. -
Although the ISO standard i/ostringstream
-classes are
provided, (sstream
), for
compatibility with older implementations the pre-ISO
@@ -299,14 +299,14 @@ any = temp;
Another example of using stringstreams is in this howto.
There is additional information in the libstdc++-v2 info files, in particular “info iostream”. -
Earlier GCC releases had a somewhat different approach to threading configuration and proper compilation. Before GCC 3.0, configuration of the threading model was dictated by compiler @@ -364,7 +364,7 @@ libstdc++-v3. of the SGI STL (version 3.3), with extensive changes.
A more formal description of the V3 goals can be found in the official design document. -
Portability notes and known implementation limitations are as follows.
The pre-ISO C++ headers +
Portability notes and known implementation limitations are as follows.
The pre-ISO C++ headers
(iostream.h
, defalloc.h
etc.) are
available, unlike previous libstdc++ versions, but inclusion
generates a warning that you are using deprecated headers.
@@ -436,7 +436,7 @@ like vector.h
can be replaced with using namespace std;
can be put at the global
scope. This should be enough to get this code compiling, assuming the
other usage is correct.
-
At this time most of the features of the SGI STL extension have been +
At this time most of the features of the SGI STL extension have been replaced by standardized libraries. In particular, the unordered_map and unordered_set containers of TR1 are suitable replacement for the non-standard hash_map and hash_set @@ -508,7 +508,7 @@ AC_DEFUN([AC_HEADER_EXT_HASH_SET], [ AC_DEFINE(HAVE_EXT_HASH_SET,,[Define if ext/hash_set is present. ]) fi ]) -
The existence of ios::nocreate
being used for
input-streams has been confirmed, most probably because the author
thought it would be more correct to specify nocreate explicitly. So
@@ -519,7 +519,7 @@ open the file for reading, check if it has been opened, and then
decide whether you want to create/replace or not. To my knowledge,
even older implementations support app
, ate
and trunc
(except for app
?).
-
Phil Edwards writes: It was considered and rejected for the ISO
@@ -542,7 +542,7 @@ No stream::attach(int fd)
For another example of this, refer to
fdstream example
by Nicolai Josuttis.
-
Check for complete library coverage of the C++1998/2003 standard.
@@ -610,7 +610,7 @@ AC_DEFUN([AC_HEADER_STDCXX_98], [ AC_DEFINE(STDCXX_98_HEADERS,,[Define if ISO C++ 1998 header files are present. ]) fi ]) -
Check for library coverage of the TR1 standard.
@@ -687,7 +687,7 @@ AC_DEFUN([AC_HEADER_TR1_UNORDERED_SET], [ AC_DEFINE(HAVE_TR1_UNORDERED_SET,,[Define if tr1/unordered_set is present. ]) fi ]) -
Check for baseline language coverage in the compiler for the C++0xstandard.
@@ -899,25 +899,25 @@ AC_DEFUN([AC_HEADER_UNORDERED_SET], [ AC_DEFINE(HAVE_UNORDERED_SET,,[Define if unordered_set is present. ]) fi ]) -
Consider a block of size 64 ints. In memory, it would look like this: (assume a 32-bit system where, size_t is a 32-bit entity). -
+
The first Column(268) represents the size of the Block in bytes as seen by the Bitmap Allocator. Internally, a global free list is used to keep track of the free blocks used and given back by the diff --git a/libstdc++-v3/doc/html/manual/bk01pt03ch17s03.html b/libstdc++-v3/doc/html/manual/bk01pt03ch17s03.html index c7a65a08a7a..c927b3a3f87 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt03ch17s03.html +++ b/libstdc++-v3/doc/html/manual/bk01pt03ch17s03.html @@ -19,6 +19,6 @@ mode or with debug mode. The following table provides the names and headers of the debugging containers: -
Table 17.1. Debugging Containers
Container | Header | Debug container | Debug header |
---|---|---|---|
std::bitset | bitset | __gnu_debug::bitset | <debug/bitset> |
std::deque | deque | __gnu_debug::deque | <debug/deque> |
std::list | list | __gnu_debug::list | <debug/list> |
std::map | map | __gnu_debug::map | <debug/map> |
std::multimap | map | __gnu_debug::multimap | <debug/map> |
std::multiset | set | __gnu_debug::multiset | <debug/set> |
std::set | set | __gnu_debug::set | <debug/set> |
std::string | string | __gnu_debug::string | <debug/string> |
std::wstring | string | __gnu_debug::wstring | <debug/string> |
std::basic_string | string | __gnu_debug::basic_string | <debug/string> |
std::vector | vector | __gnu_debug::vector | <debug/vector> |
In addition, when compiling in C++0x mode, these additional +
Table 17.1. Debugging Containers
Container | Header | Debug container | Debug header |
---|---|---|---|
std::bitset | bitset | __gnu_debug::bitset | <debug/bitset> |
std::deque | deque | __gnu_debug::deque | <debug/deque> |
std::list | list | __gnu_debug::list | <debug/list> |
std::map | map | __gnu_debug::map | <debug/map> |
std::multimap | map | __gnu_debug::multimap | <debug/map> |
std::multiset | set | __gnu_debug::multiset | <debug/set> |
std::set | set | __gnu_debug::set | <debug/set> |
std::string | string | __gnu_debug::string | <debug/string> |
std::wstring | string | __gnu_debug::wstring | <debug/string> |
std::basic_string | string | __gnu_debug::basic_string | <debug/string> |
std::vector | vector | __gnu_debug::vector | <debug/vector> |
In addition, when compiling in C++0x mode, these additional containers have additional debug capability. -
Table 17.2. Debugging Containers C++0x
Container | Header | Debug container | Debug header |
---|---|---|---|
std::unordered_map | unordered_map | __gnu_debug::unordered_map | <debug/unordered_map> |
std::unordered_multimap | unordered_map | __gnu_debug::unordered_multimap | <debug/unordered_map> |
std::unordered_set | unordered_set | __gnu_debug::unordered_set | <debug/unordered_set> |
std::unordered_multiset | unordered_set | __gnu_debug::unordered_multiset | <debug/unordered_set> |