documentation.html: First pass at unified table of contents.

2007-11-13  Benjamin Kosnik  <bkoz@redhat.com>

	* docs/html/documentation.html: First pass at unified table of contents.
	* docs/html/abi.html: Move...
	* docs/html/17_intro/abi.html: ...here.
	* docs/html/17_intro/porting-howto.html: Update, edit, put
	resulting pieces into...
	* docs/html/17_intro/api.html: New.
	* docs/html/17_intro/c++0x_status.html: New.
	* docs/html/17_intro/CHECKLIST: Move to...
	* docs/html/17_intro/c++1998_status.html: ...here.
	* docs/html/ext/tr1.html: Move ...
	* docs/html/17_intro/tr1_status.html: ...here.
	* docs/html/debug_mode.html: Move...
	* docs/html/ext/debug_mode.html: ...here.
	* docs/html/parallel_mode.html: Move...
	* docs/html/ext/parallel_mode.html: ...here
	* docs/html/17_intro/BUGS: Remove.
	* docs/html/17_intro/concept_check.diff: Remove.
	* docs/html/17_intro/HEADER_POLICY: Remove.
	* docs/html/17_intro/headers_cc.txt: Remove.
	* docs/html/17_intro/PROBLEMS: Remove.
	* docs/html/17_intro/RELEASE-NOTES: Remove.
	* docs/html/explanations.html: Remove.
	* docs/html/makedoc.awk: Remove.
	* docs/html/faq/index.txt: Remove. HTML only.
	* /docs/html/Makefile: Remove.
	
	* docs/html/17_intro/configury.html: Editing, updating,
	consistency check with doxygen conventions. Change libstdc++-v3 to
	libstdc++.	
	* docs/html/17_intro/howto.html: Same.
	* docs/html/17_intro/license.html: Same.
	* docs/html/17_intro/porting.html: Same.
	* docs/html/18_support/howto.html: Same.
	* docs/html/19_diagnostics/howto.html: Same.
	* docs/html/20_util/allocator.html: Same.
	* docs/html/20_util/howto.html: Same.
	* docs/html/21_strings/howto.html: Same.
	* docs/html/22_locale/codecvt.html: Same.
	* docs/html/22_locale/ctype.html: Same.
	* docs/html/22_locale/howto.html: Same.
	* docs/html/22_locale/messages.html: Same.
	* docs/html/23_containers/howto.html: Same.
	* docs/html/24_iterators/howto.html: Same.
	* docs/html/25_algorithms/howto.html: Same.
	* docs/html/26_numerics/howto.html: Same.
	* docs/html/27_io/howto.html: Same.
	* docs/html/configopts.html: Same.
	* docs/html/debug.html: Same.
	* docs/html/ext/ballocator_doc.html: Same.
	* docs/html/ext/howto.html: Same.
	* docs/html/ext/mt_allocator.html: Same.
	* docs/html/ext/sgiexts.html: Same.
	* docs/html/faq/index.html: Same.
	* docs/html/install.html: Same.
	* docs/html/test.html: Same.
	
	* include/bits/c++config: Change _GLIBCXX_DEPRECATED to
	_GLIBCXX_DEPRECATED_ATTR, _GLIBCXX_VISIBILITY to
	_GLIBCXX_VISIBILITY_ATTR.	
	* include/backward/auto_ptr.h: Same.
	* include/backward/binders.h: Same.
	* include/bits/stl_function.h: Same.
	* include/std/memory: Same.
	* include/std/streambuf: Same.
	* include/tr1_impl/boost_shared_ptr.h: Same.
	* src/globals_io.cc: Same.
	* src/ios_init.cc: Same.

From-SVN: r130150
This commit is contained in:
Benjamin Kosnik 2007-11-13 17:43:57 +00:00 committed by Benjamin Kosnik
parent d770555138
commit 4dd9d9db1d
56 changed files with 3571 additions and 3248 deletions

View File

@ -1,3 +1,73 @@
2007-11-13 Benjamin Kosnik <bkoz@redhat.com>
* docs/html/documentation.html: First pass at unified table of contents.
* docs/html/abi.html: Move...
* docs/html/17_intro/abi.html: ...here.
* docs/html/17_intro/porting-howto.html: Update, edit, put
resulting pieces into...
* docs/html/17_intro/api.html: New.
* docs/html/17_intro/c++0x_status.html: New.
* docs/html/17_intro/CHECKLIST: Move to...
* docs/html/17_intro/c++1998_status.html: ...here.
* docs/html/ext/tr1.html: Move ...
* docs/html/17_intro/tr1_status.html: ...here.
* docs/html/debug_mode.html: Move...
* docs/html/ext/debug_mode.html: ...here.
* docs/html/parallel_mode.html: Move...
* docs/html/ext/parallel_mode.html: ...here
* docs/html/17_intro/BUGS: Remove.
* docs/html/17_intro/concept_check.diff: Remove.
* docs/html/17_intro/HEADER_POLICY: Remove.
* docs/html/17_intro/headers_cc.txt: Remove.
* docs/html/17_intro/PROBLEMS: Remove.
* docs/html/17_intro/RELEASE-NOTES: Remove.
* docs/html/explanations.html: Remove.
* docs/html/makedoc.awk: Remove.
* docs/html/faq/index.txt: Remove. HTML only.
* /docs/html/Makefile: Remove.
* docs/html/17_intro/configury.html: Editing, updating,
consistency check with doxygen conventions. Change libstdc++-v3 to
libstdc++.
* docs/html/17_intro/howto.html: Same.
* docs/html/17_intro/license.html: Same.
* docs/html/17_intro/porting.html: Same.
* docs/html/18_support/howto.html: Same.
* docs/html/19_diagnostics/howto.html: Same.
* docs/html/20_util/allocator.html: Same.
* docs/html/20_util/howto.html: Same.
* docs/html/21_strings/howto.html: Same.
* docs/html/22_locale/codecvt.html: Same.
* docs/html/22_locale/ctype.html: Same.
* docs/html/22_locale/howto.html: Same.
* docs/html/22_locale/messages.html: Same.
* docs/html/23_containers/howto.html: Same.
* docs/html/24_iterators/howto.html: Same.
* docs/html/25_algorithms/howto.html: Same.
* docs/html/26_numerics/howto.html: Same.
* docs/html/27_io/howto.html: Same.
* docs/html/configopts.html: Same.
* docs/html/debug.html: Same.
* docs/html/ext/ballocator_doc.html: Same.
* docs/html/ext/howto.html: Same.
* docs/html/ext/mt_allocator.html: Same.
* docs/html/ext/sgiexts.html: Same.
* docs/html/faq/index.html: Same.
* docs/html/install.html: Same.
* docs/html/test.html: Same.
* include/bits/c++config: Change _GLIBCXX_DEPRECATED to
_GLIBCXX_DEPRECATED_ATTR, _GLIBCXX_VISIBILITY to
_GLIBCXX_VISIBILITY_ATTR.
* include/backward/auto_ptr.h: Same.
* include/backward/binders.h: Same.
* include/bits/stl_function.h: Same.
* include/std/memory: Same.
* include/std/streambuf: Same.
* include/tr1_impl/boost_shared_ptr.h: Same.
* src/globals_io.cc: Same.
* src/ios_init.cc: Same.
2007-11-13 Paolo Carlini <pcarlini@suse.de>
* include/bits/deque.tcc (deque<>::_M_push_back_aux,

View File

@ -1,28 +0,0 @@
2003-04-26
- _GLIBCPP_HAS_BUILTIN_SINF: We should still hold out for a cleaner solution the is currenly the case in bits/std_cmath.h.
- there may be one set of remaining string bugs, dependent on final
clarification of the string::find technicalities when finding in an
empty string or using an empty string for an argument. At the very
least, v-3 has interpreted the standard in a way that is in opposition
to other libraries on other platforms.
- trigraphs and keywords a la the iso646 header are not correctly
implemented. It looks like the compiler recognizes them as keywords
but then doesn't translate into the correct bit ops. It is a mystery.
- wide strings have not been tested, and may therefore be unusable.
- Chapter 27 io functionality is not finished. As such, there are
known bugs in: filebuf::putbackfail
- Many facet implementations are stubs. (22)
- Almost no optimizations for small-footprint/low-overhead. (22,27)
- There has been some work to wrap the C headers in namespace std::, but
it may not be complete yet, and C macros are not shadowed. Please consult
the mailing list archives for more information.

View File

@ -1,164 +0,0 @@
Header Policy
-------------
The C++ Standard specifies many mutual dependencies among the
headers it defines. It offers no advice on how to arrange headers
to avoid problems. The worst such problem is circular references.
Most simply this is "A includes B, B includes A":
// file <A> // file <B>
#ifndef A #ifndef B
#define A 1 #define B 1
#include <B> #include <A>
typedef int A_type; typedef int B_type;
extern B_type g(A_type); extern A_type f(B_type);
#endif /* A */ #endif /* B */
// file C.cc
#include <A>
The typical effect of such an "include loop" may be seen by tracing
the preprocessor activity:
C // file C.cc
C #include <A>
A // file <A>
A #ifndef A
A #define A 1
A #include <B>
B // file <B>
B #ifndef B
B #define B 1
B #include <A>
A // file <A>
A #ifndef A <-- oops, cpp symbol A defined already
A ... <-- skip <A> contents
A #endif
B typedef int B_type;
B extern A_type f(B_type); <-- error, A_type not defined yet.
B #endif /* B */
A typedef int A_type;
A extern B_type g(A_type);
A #endif /* A */
The main symptom of #include loops is that definitions from file <A>
are not available after the #include <A> for certain include orders.
The number of standard headers makes testing all permutations of
include order impractical, so a policy is needed to prevent chaos.
In any case, for some standard headers (as for the above) no ordering
can eliminate the loop.
Other factors influence the policy. Typical implementations of
Make (unfortunately including GNU make) have bugs relating to file
names with no suffix, that lead to such problems as failure to track
dependencies on such files and an inclination to _delete_ them.
Therefore, headers used in building the library are always of the
form <bits/yyy.h> generally, or specifically <bits/std_xxx.h> for
an equivalent to the standard header <xxx>.
Standard headers <xxx> are all placed under directory std/, and
are ignored except during installation. These headers simply
#include the corresponding header <bits/std_xxx.h>.
Standard substitute headers <bits/std_xxx.h> that have any complexity
may sub-include other headers. When they sub-include non-standard
headers, they first include all the headers required for that
non-standard header.
Mutual dependencies are handled by splitting up the declarations
intended for standard headers among two or more files, and then
interleaving them as needed. For example, we replace <A> and <B>
above, as follows:
// file <bits/std_A.h>
#ifndef _CPP_A
#define _CPP_A
# include <bits/A_types.h>
# include <bits/B_types.h>
# include <bits/A_funs.h>
#endif
// file <bits/std_B.h>
#ifndef _CPP_B
#define _CPP_B
# include <bits/A_types.h>
# include <bits/B_types.h>
# include <bits/B_funs.h>
#endif
// file <bits/A_types.h>
#ifndef _CPP_BITS_A_TYPES_H
#define _CPP_BITS_A_TYPES_H
typedef int A_type;
#endif
// file <bits/B_types.h>
#ifndef _CPP_BITS_B_TYPES_H
#define _CPP_BITS_B_TYPES_H
typedef int B_type;
#endif
// file <bits/A_funs.h>
#ifndef _CPP_BITS_A_FUNS_H
#define _CPP_BITS_A_FUNS_H
extern B_type g(A_type);
#endif
// file <bits/B_funs.h>
#ifndef _CPP_BITS_B_FUNS_H
#define _CPP_BITS_B_FUNS_H
extern A_type f(B_type);
#endif
Of course we have the standard headers under their mandated names:
// file <std/A>
#ifndef _CPP_A
#define _CPP_A
# include <bits/std_A.h>
#endif
// file <std/B>
#ifndef _CPP_B
#define _CPP_B
# include <bits/std_B.h>
#endif
Notice that the include guards are named uniformly except that
the guard for standard header <bits/std_A.h> is just _CPP_A,
identically as the header <A> in std/.
At installation the files std/* can be replaced by symbolic links,
or simply copied into place as is. The result is:
include/
include/A -> bits/std_A.h
include/B -> bits/std_A.h
include/bits/
include/bits/std_A.h
include/bits/std_B.h
include/bits/A_types.h
include/bits/B_types.h
include/bits/A_funs.h
include/bits/B_funs.h
Of course splitting up standard headers this way creates
complexity, so it is not done routinely, but only in response
to discovered needs.
Another reason to split up headers is for support of separate
compilation of templates. This interacts with the foregoing
because template definitions typically have many more dependencies
on other headers than do pure declarations. Non-inline template
definitions are placed in a separate ".tcc" file that is included
by the standard header, and any other standard header that
requires definitions from it for its implementation.
The key to preventing chaos, given the above structure, is:
Only standard headers <bits/std_xxxx.h> should sub-include
other headers.

View File

@ -1,8 +0,0 @@
Irix 6.2:
- math.h: defines extern long double hypotl( long double ); i.e., only
one argument. They've fixed this in 6.3.
DES OSF 3.2 & 4.0:
- libm define sincos, sincosf, and sincosl but there are no prototypes and
especially the return type is nowhere defined. The functions are
documented in the man pages, though.

View File

@ -1,83 +0,0 @@
2002-05-02
Release Notes
-------------
The Standard C++ Library, or libstdc++-v3, is an ongoing project
to fully implement the ISO 14882 Standard C++ library as described in
chapters 17 through 27 and annex D.
This is the fifteenth snapshot of the libstdc++ rewrite. It still
has some incomplet and incorrekt parts, but it's a lot less incomplete
and incorrect than some of the earlier snapshots, and quite usable.
The Standard C++ Library, follows an open development model,
attempting to be fully buzzword, bazaar, and GNU compliant. Full
details on participating, including contributor guidelines, mailing
list subscription, mailing list archives, up-to-date documentation,
and various and sundry other details can be found at the following
URL:
http://gcc.gnu.org/libstdc++/
New:
---
- more doxygen documentation
- more named locale fixups
- stdio_filebuf that takes fd, FILE
- io performance tuning
- allocation tuning, valgrind fixups
- __cxa_demangle now supported
Bugs fixed:
-----------
6533, 6513, 6501, 6511, 5820, 6414, 4150, 6360, 4164, 1072, 6124,
5180, 3457, 3139, 5268, 3983, 5542, 3129, 5207, 3719, 5734
+ others.
What doesn't:
-------------
- see BUGS.
Build and Install
-----------------
Up to date build and install directions can be found at:
http://gcc.gnu.org/libstdc++/install.html
Contact:
--------
Places have changed from previous snapshots. The web page, which has
information about joining the mailing list and searching its archives,
CVS access, and contribution information is now at:
http://gcc.gnu.org/libstdc++/
Please note that the mailing list has moved, and is now hosted on
gcc.gnu.org. (The web site above has the most up-to-date info.)
Obtain the library snapshot via ftp (including these release notes) from
ftp://gcc.gnu.org/pub/libstdc++/
The library is maintained by Benjamin Kosnik, Gabriel
Dos Reis, Phil Edwards, Ulrich Drepper, Loren James Rittle,
and Paolo Carlini.
Development tools:
------------------
You will need a current version of gcc to compile this snapshot of
libstdc++. The use of the latest stable gcc-3.0.x release (3.0.4), CVS
gcc, or gcc-3_1-branch is strongly recommended, which may also
introduce additional dependencies for up-to-date binutils. In
particular, current binutils (2.12) is recommended so that symbol
versioning for the library is on by default. In addition, you may need
up-to-date tools for modifying Makefiles and regenerating configure
scripts: automake (version 1.4), autoconf (version 2.13 and higher),
and libtool.

View File

@ -26,7 +26,7 @@
</em></p>
<p><em>
To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++-v3 homepage</a>.
To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++ homepage</a>.
</em></p>
<!-- ####################################################### -->
@ -240,7 +240,7 @@ on ELF systems).</p>
<li>Symbol versioning on the libstdc++.so binary.
<p>mapfile: libstdc++-v3/config/linker-map.gnu</p>
<p>mapfile: libstdc++/config/linker-map.gnu</p>
<p>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
@ -340,7 +340,7 @@ on ELF systems).</p>
<p>
This macro is defined in the file "c++config" in the
"libstdc++-v3/include/bits" directory. (Up to gcc-4.1.0, it was
"libstdc++/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.)
</p>
@ -393,7 +393,7 @@ on ELF systems).</p>
<p>
This macro is defined in the file "c++config" in the
"libstdc++-v3/include/bits" directory and is generated
"libstdc++/include/bits" directory and is generated
automatically by autoconf as part of the configure-time generation
of config.h.
</p>
@ -435,7 +435,7 @@ on ELF systems).</p>
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++-v3/acinclude.m4," and more details can be found in that
"libstdc++/acinclude.m4," and more details can be found in that
file's macro GLIBCXX_CONFIGURE (GLIBCPP_CONFIGURE before gcc-3.4.0).
</p>
<p>
@ -493,7 +493,7 @@ on ELF systems).</p>
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 with
g++, and shared libraries (libgcc_s, libstdc++-v3) compiled by a
g++, and shared libraries (libgcc_s, libstdc++) compiled by a
compiler (g++) with a compatible ABI. Phew.
</p>
@ -529,7 +529,7 @@ on ELF systems).</p>
</p>
<p>
In particular, libstdc++-v3/acinclude.m4 has a macro called
In particular, libstdc++/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 versioning are in
@ -542,7 +542,7 @@ on ELF systems).</p>
</h5>
<p>
When the GNU C++ library is being built with symbol versioning on,
you should see the following at configure time for libstdc++-v3:
you should see the following at configure time for libstdc++:
</p>
@ -776,7 +776,7 @@ http://gcc.gnu.org/ml/gcc/2002-08/msg00142.html
<p>
Two.
Use the 'make check-abi' rule in the libstdc++-v3 Makefile.
Use the 'make check-abi' rule in the libstdc++ Makefile.
</p>
<p>

View File

@ -0,0 +1,596 @@
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta name="AUTHOR" content="bkoz@gcc.gnu.org (Benjamin Kosnik), Felix Natter" />
<meta name="KEYWORDS" content="C++, libstdc++, API, deprecate backward" />
<meta name="DESCRIPTION" content="API evolution and deprecation history" />
<meta name="GENERATOR" content="emacs and ten fingers" />
<title>API Evolution and Deprecation History</title>
<link rel="StyleSheet" href="lib3styles.css" type="text/css" />
<link rel="Start" href="documentation.html" type="text/html"
title="GNU C++ Standard Library" />
<link rel="Copyright" href="17_intro/license.html" type="text/html" />
</head>
<body>
<h1 class="centered"><a name="top">API Evolution and Deprecation History</a></h1>
<p class="fineprint"><em>
The latest version of this document is always available at
<a href="http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/api.html">
http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/abi.html</a>.
</em></p>
<p><em>
To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++ homepage</a>.
</em></p>
<!-- ####################################################### -->
<hr />
<h3 class="left">
<a name="C++ API v1">First.</a>
</h3>
<p>2.72</p>
<p> The first generation GNU C++ library was called libg++. It had a
working relationship with at least two kinds of dinosaur. Sadly, the
details were not pried away from the estate.
</p>
<p>
</p>
<p>Known Issues include many of the limitations of its immediate ancestor.</p>
<h5>No <code>ios_base</code></h5>
<p> At least some older implementations don't have <code>std::ios_base</code>, so you should use <code>std::ios::badbit</code>, <code>std::ios::failbit</code> and <code>std::ios::eofbit</code> and <code>std::ios::goodbit</code>.
</p>
<h5>No <code>cout</code> in <code>ostream.h</code>, no <code>cin</code> in <code>istream.h</code</h5>
<p>
In earlier versions of the standard,
<tt>&lt;fstream.h&gt;</tt>,
<tt>&lt;ostream.h&gt;</tt>
and <tt>&lt;istream.h&gt;</tt>
used to define
<code>cout</code>, <code>cin</code> and so on. ISO C++ specifies that one needs to include
<tt>&lt;iostream&gt;</tt>
explicitly to get the required definitions.
</p>
<p> Some include adjustment may be required.</p>
<p>This project is no longer maintained or supported, and the sources
archived. The code is considered replaced and rewritten.
</p>
<hr />
<h3 class="left">
<a name="C++ API v1">Second.</a>
</h3>
<p> The second generation GNU C++ library was called libstdc++, or
libstdc++-v2. It was a separate GNU project, although reliably paired
with GCC. It spans the time between libg++ and pre-ISO C++.
</p>
<p>egcs 1.x</p>
<p>2.95</p>
<p>2.96</p>
<p>Portability Notes</p>
<p>Implementation Limitations</p>
<h5>Namespace <code>std::</code> not supported.</h5>
<p>
Some care is required to support C++ compiler and or library
implementation that do not have the standard library in
<code>namespace std</code>.
</p>
<p>
The following sections list some possible solutions to support compilers
that cannot ignore <code>std::</code>-qualified names.
</p>
<p> First, see if the compiler has a flag for this. Namespace
back-portability-issues are generally not a problem for g++
compilers that do not have libstdc++ in <code>std::</code>, as
the compilers use <code>-fno-honor-std</code> (ignore
<code>std::</code>, <code>:: = std::</code>) by default. That
is, the responsibility for enabling or disabling
<code>std::</code> is on the user; the maintainer does not have
to care about it. This probably applies to some other compilers
as well.
</p>
<p>Second, experiment with a variety of pre-processor tricks.</p>
<p> By defining <code>std</code> as a macro, fully-qualified namespace calls become global. Volia.
<pre class="programlisting">
#ifdef WICKEDLY_OLD_COMPILER
# define std
#endif
</pre>
(thanks to Juergen Heinzl who posted this solution on gnu.gcc.help)
<p>Define a macro <code>NAMESPACE_STD</code>, which is defined to
either &quot;&quot; or &quot;std&quot; based on a compile-type
test. On GNU systems, this can be done with autotools by means of an
autoconf test (see below) for <code>HAVE_NAMESPACE_STD</code>, then
using that to set a value for the <code>NAMESPACE_STD</code> macro.
At that point, one is able to use <code>NAMESPACE_STD::string</code>,
which will evaluate to <code>std::string</code> or
<code>::string</code> (ie, in the global namespace on systems that do
not put <code>string</code> in <code>std::</code>). </p>
<p>
<pre>
dnl @synopsis AC_CXX_HAVE_STD_NAMESPACE
dnl
dnl If the compiler supports the std namespace, define
dnl HAVE_STD_NAMESPACE.
dnl
dnl @category Cxx
dnl @author Todd Veldhuizen
dnl @author Luc Maisonobe <luc@spaceroots.org>
dnl @version 2004-02-04
dnl @license AllPermissive
AC_DEFUN([AC_CXX_HAVE_STD_NAMESPACE],
[AC_CACHE_CHECK(whether the compiler supports the std namespace,
ac_cv_cxx_have_std_namespace,
[AC_LANG_SAVE
AC_LANG_CPLUSPLUS
AC_TRY_COMPILE([#include <iostream>
std::istream& is = std::cin;
],[return 0;],
ac_cv_cxx_have_std_namespace=yes, ac_cv_cxx_have_std_namespace=no)
AC_LANG_RESTORE
])
if test "$ac_cv_cxx_have_std_namespace" = yes; then
AC_DEFINE(HAVE_STD_NAMESPACE,,[define if the compiler supports the std namespace])
fi
])
</pre>
<h5>Illegal iterator usage.</h5>
<p>
The following illustrate implementation-allowed illegal iterator
use, and then correct use. <div class="itemizedlist"><ul
type="disc"> <li><p>you cannot do
<code>ostream::operator&lt;&lt;(iterator)</code> to print the
address of the iterator =&gt; use <code>operator&lt;&lt;
&amp;*iterator</code> instead ?
</p></li>
<li><p>you cannot clear an iterator's reference
(<code>iterator = 0</code>) =&gt; use
<code>iterator = iterator_type();</code> ?
</p></li>
<li><p>
<code>if (iterator)</code> won't work any
more =&gt; use <code>if (iterator != iterator_type())</code>
?</p></li>
</ul>
<h5><code>isspace</code> from <tt>&lt;cctype&gt;</tt> is a macro
</h5>
<p> Glibc 2.0.x and 2.1.x define <tt>&lt;ctype.h&gt;</tt>
functionality as macros (isspace, isalpha etc.).
</p>
<p>
This implementations of libstdc++, however, keep these functions as
macros, and so it is not back-portable to use fully qualified
names. For example:
</p>
<pre>
#include &lt;cctype&gt;
int main() { std::isspace('X'); }
</pre>
<p>Results in something like this:
</p>
<pre>
std:: (__ctype_b[(int) ( ( 'X' ) )] &amp; (unsigned short int) _ISspace ) ;
</pre>
<p> A solution is to modify a header-file so that the compiler tells
<tt>&lt;ctype.h&gt;</tt> to define functions instead of macros:
</p>
<pre>
// This keeps isalnum, et al from being propagated as macros.
#if __linux__
# define __NO_CTYPE 1
#endif
</pre>
<p>Then, include &lt;ctype.h&gt;
</p>
<p>
Another problem arises if you put a <code>using namespace std;</code>
declaration at the top, and include <tt>&lt;ctype.h&gt;</tt>. This
will result in ambiguities between the definitions in the global
namespace (<tt>&lt;ctype.h&gt;</tt>) and the definitions in namespace
<code>std::</code> (<code>&lt;cctype&gt;</code>).
</p>
<h5>No <code>vector::at</code>, <code>deque::at</code>, <code>string::at</code></h5>
<p>
One solution is to add an autoconf-test for this:
</p>
<pre>
AC_MSG_CHECKING(for container::at)
AC_TRY_COMPILE(
[
#include &lt;vector&gt;
#include &lt;deque&gt;
#include &lt;string&gt;
using namespace std;
],
[
deque&lt;int&gt; test_deque(3);
test_deque.at(2);
vector&lt;int&gt; test_vector(2);
test_vector.at(1);
string test_string(&quot;test_string&quot;);
test_string.at(3);
],
[AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_CONTAINER_AT)],
[AC_MSG_RESULT(no)])
</pre>
<p>
If you are using other (non-GNU) compilers it might be a good idea
to check for <code>string::at</code> separately.
</p>
<h5>No <code>std::char_traits&lt;char&gt;::eof</code></h5>
<p>
Use some kind of autoconf test, plus this:
</p>
<pre>
#ifdef HAVE_CHAR_TRAITS
#define CPP_EOF std::char_traits&lt;char&gt;::eof()
#else
#define CPP_EOF EOF
#endif
</pre>
<h5>No <code>string::clear</code></h5>
<p>
There are two functions for deleting the contents of a string:
<code>clear</code> and <code>erase</code> (the latter
returns the string).
<pre class="programlisting">
void
clear() { _M_mutate(0, this-&gt;size(), 0); }
</pre>
<pre class="programlisting">
basic_string&amp;
erase(size_type __pos = 0, size_type __n = npos)
{
return this-&gt;replace(_M_check(__pos), _M_fold(__pos, __n),
_M_data(), _M_data());
}
</pre>
Unfortunately, ut <code>clear</code> is not
implemented in this version, so you should use
<code>erase</code> (which is probably faster than
<code>operator=(charT*)</code>).
</p>
<h5>Removal of <code>ostream::form</code> and
<code>istream::scan</code> extensions.</h5>
<p> These are no longer supported. Please use
<a href="#sec-stringstream" title="Using stringstreams">
stringstreams</a> instead.
</p>
<h5>No <code>basic_stringbuf</code>, <code>basic_stringstream<code></h5>
<p>
Libstdc++ provides the new
<code>i/ostringstream</code>-classes, (<tt>&lt;sstream&gt;</tt>), but for compatibility
with older implementations you still have to use
<code>i/ostrstream</code> (<tt>&lt;strstream&gt;</tt>):
<pre >
#ifdef HAVE_SSTREAM
#include &lt;sstream&gt;
#else
#include &lt;strstream&gt;
#endif
</pre>
<div class="itemizedlist"><ul type="disc">
<li><p> <code>strstream</code> is considered to be
deprecated
</p></li>
<li><p> <code>strstream</code> is limited to
<code>char</code>
</p></li>
<li><p> with <code>ostringstream</code> you don't
have to take care of terminating the string or freeing its
memory
</p></li>
<li><p> <code>istringstream</code> can be re-filled
(clear(); str(input);)
</p></li>
</ul></div>
<p>
You can then use output-stringstreams like this:
<pre >
#ifdef HAVE_SSTREAM
std::ostringstream oss;
#else
std::ostrstream oss;
#endif
oss &lt;&lt; &quot;Name=&quot; &lt;&lt; m_name &lt;&lt; &quot;, number=&quot; &lt;&lt; m_number &lt;&lt; std::endl;
...
#ifndef HAVE_SSTREAM
oss &lt;&lt; std::ends; // terminate the char*-string
#endif
// str() returns char* for ostrstream and a string for ostringstream
// this also causes ostrstream to think that the buffer's memory
// is yours
m_label.set_text(oss.str());
#ifndef HAVE_SSTREAM
// let the ostrstream take care of freeing the memory
oss.freeze(false);
#endif
</pre>
<p>
Input-stringstreams can be used similarly:
</p>
<pre>
std::string input;
...
#ifdef HAVE_SSTREAM
std::istringstream iss(input);
#else
std::istrstream iss(input.c_str());
#endif
int i;
iss &gt;&gt; i;
</pre>
<p> One (the only?) restriction is that an istrstream cannot be re-filled:
</p>
<pre >
std::istringstream iss(numerator);
iss &gt;&gt; m_num;
// this is not possible with istrstream
iss.clear();
iss.str(denominator);
iss &gt;&gt; m_den;
</pre>
<p>
If you don't care about speed, you can put these conversions in
a template-function:
</p>
<pre >
template &lt;class X&gt;
void fromString(const string&amp; input, X&amp; any)
{
#ifdef HAVE_SSTREAM
std::istringstream iss(input);
#else
std::istrstream iss(input.c_str());
#endif
X temp;
iss &gt;&gt; temp;
if (iss.fail())
throw runtime_error(..)
any = temp;
}
</pre>
<p> Another example of using stringstreams is in <a href="../21_strings/howto.html" target="_top">this howto</a>.
</p>
<p> There is additional information in the libstdc++-v2 info files, in
particular &quot;info iostream&quot;.
</p>
<h5>Little or no wide character support</h5>
<h5>No templatized iostreams</h5>
<h5>Thread safety issues.</h5>
<p>This project is no longer maintained or supported, and the sources
archived. The code is considered replaced and rewritten.
</p>
<hr />
<h3 class="left">
<a name="C++ API v1">Third.</a>
</h3>
<p> The third generation GNU C++ library is called libstdc++, or
libstdc++-v3.
</p>
<p>The subset commonly known as the Standard Template Library
(chapters 23 through 25, mostly) is adapted from the final release
of the SGI STL, with extensive changes.
</p>
<p>A more formal description of the V3 goals can be found in the
official <a href="../17_intro/DESIGN">design document</a>.
</p>
<p>Portability Notes</p>
<h5>Pre-ISO headers moved to backwards</h5>
<p> The pre-ISO C++ headers (iostream.h etc.) are available, but inclusion
generates a warning that you are using deprecated headers.
</p>
<p>This compatibility layer is constructed by including the
standard C++ headers, and injecting any items in
<code>std::</code> into the global namespace.
</p>
<p>For those of you new to ISO C++ (welcome, time travelers!), no,
that isn't a typo. Yes, the headers really have new names.
Marshall Cline's C++ FAQ Lite has a good explanation in <a
href="http://www.parashift.com/c++-faq-lite/coding-standards.html#faq-27.4">item
[27.4]</a>.
</p>
<p> Some include adjustment may be required.</p>
<h5>Extension headers hash_map, hash_set moved to ext</h5>
<p> Header files <code>hash_map</code> and <code>hash_set</code>
moved to <code>ext/hash_map</code> and <code>ext/hash_set</code>,
respectively. At the same time, all types in these files are enclosed
in <code>namespace __gnu_cxx</code>.
</p>
<h5>
No <code>ios::nocreate/ios::noreplace</code>.
</h5>
<p> The existence of <code>ios::nocreate</code> being used for
input-streams has been confirmed, most probably because the author
thought it would be more correct to specify nocreate explicitly. So
it can be left out for input-streams.
</p>
<p>For output streams, &quot;nocreate&quot; is probably the default,
unless you specify <code>std::ios::trunc</code> ? 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. To my knowledge,
even older implementations support <code>app</code>, <code>ate</code>
and <code>trunc</code> (except for <code>app</code> ?).
</p>
<h5>
No <code>stream::attach(int fd)</code>.
</h5>
<p>
Phil Edwards writes: It was considered and rejected for the ISO
standard. Not all environments use file descriptors. Of those
that do, not all of them use integers to represent them.
</p>
<p>
For a portable solution (among systems which use
filedescriptors), you need to implement a subclass of
<code>std::streambuf</code> (or
<code>std::basic_streambuf&lt;..&gt;</code>) which opens a file
given a descriptor, and then pass an instance of this to the
stream-constructor.
</p>
<p>
An extension is available that implements this.
<code>&lt;ext/stdio_filebuf.h&gt;</code> contains a derived class called
<a href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/class____gnu__cxx_1_1stdio__filebuf.html"><code>__gnu_cxx::stdio_filebuf</code></a>.
This class can be constructed from a C <code>FILE*</code> or a file
descriptor, and provides the <code>fd()</code> function.
</p>
<p>
For another example of this, refer to
<a href="http://www.josuttis.com/cppcode/fdstream.html" target="_top">fdstream example</a>
by Nicolai Josuttis.
</p>
<p><a href="http://gcc.gnu.org/bugzilla/buglist.cgi?cmdtype=runnamed&namedcmd=libstdc%2B%2B">Known Issues</a></p>
<h5>
container iterator types are not necessarily container value_type*
</h5>
<p>API History, User Visible Changes</p>
<p>3.0.0</p>
<p>3.1.0</p>
<p>3.2.0</p>
<p>3.3.0</p>
<p>3.4.0</p>
Macro guard for libstdc++ changed, from _GLIBCPP_ to _GLIBCXX_, to
accomodate a request from the C Pre Processor maintainer.
<p>4.0.0</p>
<p>4.1.0</p>
<cassert> how has to be explicitly included for <code>std::assert</code> calls.
<p>4.2.0</p>
<p>4.3.0</p>
Header streamlining.
Backward include edit.
PCH files built but not installed.
Namespace pb_ds moved to __gnu_pb_ds.
C++OX features appear.
<hr />
<h3 class="left">
<a name="C++ API v1">Fourth, and future</a>
</h3>
<hr />
<h3 class="left">
<a name="Deprecation">Deprecation and Backwards Compatibility</a>
</h3>
<hr />
<h3 class="left">
<a name="Links">Links</a>
</h3>
<p>
<a href="http://www.kegel.com/gcc/gcc4.html">Migrating to gcc-4.1</a>, by Dan Kegel.
</p>
<p>
<a href="http://lists.debian.org/debian-gcc/2006/03/msg00405.html">Building the whole Debian archive with GCC 4.1: a summary</a>, by Martin Michlmayr
</p>
<p>
<a href="http://annwm.lbl.gov/~leggett/Atlas/gcc-3.2.html">Migration guide for GCC-3.2</a>
</p>
</body>
</html>

File diff suppressed because it is too large Load Diff

View File

@ -1,3 +1,4 @@
<pre>
Completion Checklist for the Standard C++ Library
Updated: 2003-04-25
@ -6000,3 +6001,4 @@ M int pcount() const;
M char* str();
};
</pre>

View File

@ -1,382 +0,0 @@
Changes made while bringing boost/concept_check.hpp to v3's concept_check.h:
1) File format changed from DOS to Unix.
2) Boost config.hpp and other workaround files dropped (unneeded in g++ v3).
3) Conditionally-compiled code depending on those "breakage" macros was
removed, or not, depending on the macro, so that the macros themselves
are gone. Since the same code would always be compiled, let's make it
easier on the reader and a few milliseconds faster for cpplib.
4) Tests for NDEBUG were removed; if NDEBUG is defined, none of the checking
code will even be included.
5) BOOST_CLASS_REQUIRES* changed to accept a namespace parameter.
6) SameTypeConcept added (simple wrapper around existing code).
7) An unused variable in OutputIteratorConcept was removed.
At checkin, this was the exact diff, modulo the end-of-line character changes:
--- concept_check.hpp.orig Sun Apr 1 08:59:46 2001
+++ boost_concept_check.h Mon Apr 2 18:56:41 2001
@@ -5,20 +5,15 @@
// "as is" without express or implied warranty, and with no claim as
// to its suitability for any purpose.
//
+
+// GCC Note: based on version 1.12.0 of the Boost library.
#ifndef BOOST_CONCEPT_CHECKS_HPP
#define BOOST_CONCEPT_CHECKS_HPP
-#include <boost/config.hpp>
-#include <boost/iterator.hpp>
-#include <boost/iterator.hpp>
-#include <utility>
-#include <boost/pending/limits.hpp>
-
-#if (__GNUC__) || defined(__KCC) || defined(__ghs) || defined(__MWERKS__)
-#define BOOST_FPTR &
-#else
-#define BOOST_FPTR
-#endif
+#pragma GCC system_header
+#include <bits/stl_iterator_base_types.h> // for traits and tags
+#include <utility> // for pair<>
+
namespace boost {
@@ -27,80 +22,64 @@
template <class Concept>
void function_requires()
{
-#if !defined(NDEBUG)
- void (Concept::*x)() = BOOST_FPTR Concept::constraints;
+ void (Concept::*x)() = &Concept::constraints;
ignore_unused_variable_warning(x);
-#endif
}
-// The BOOST_CLASS_REQUIRES macros use function pointers as
-// template parameters, which VC++ does not support.
-
-#if defined(BOOST_NO_FUNCTION_PTR_TEMPLATE_PARAMETERS)
-
-#define BOOST_CLASS_REQUIRES(type_var, concept)
-#define BOOST_CLASS_REQUIRES2(type_var1, type_var2, concept)
-#define BOOST_CLASS_REQUIRES3(type_var1, type_var2, type_var3, concept)
-#define BOOST_CLASS_REQUIRES4(type_var1, type_var2, type_var3, type_var4, concept)
-#else
-
-#define BOOST_CLASS_REQUIRES(type_var, concept) \
- typedef void (concept <type_var>::* func##type_var##concept)(); \
+#define BOOST_CLASS_REQUIRES(type_var, ns, concept) \
+ typedef void (ns::concept <type_var>::* func##type_var##concept)(); \
template <func##type_var##concept _Tp1> \
struct concept_checking_##type_var##concept { }; \
typedef concept_checking_##type_var##concept< \
- BOOST_FPTR concept <type_var>::constraints> \
+ &ns::concept <type_var>::constraints> \
concept_checking_typedef_##type_var##concept
-#define BOOST_CLASS_REQUIRES2(type_var1, type_var2, concept) \
- typedef void (concept <type_var1,type_var2>::* func##type_var1##type_var2##concept)(); \
+#define BOOST_CLASS_REQUIRES2(type_var1, type_var2, ns, concept) \
+ typedef void (ns::concept <type_var1,type_var2>::* func##type_var1##type_var2##concept)(); \
template <func##type_var1##type_var2##concept _Tp1> \
struct concept_checking_##type_var1##type_var2##concept { }; \
typedef concept_checking_##type_var1##type_var2##concept< \
- BOOST_FPTR concept <type_var1,type_var2>::constraints> \
+ &ns::concept <type_var1,type_var2>::constraints> \
concept_checking_typedef_##type_var1##type_var2##concept
-#define BOOST_CLASS_REQUIRES3(type_var1, type_var2, type_var3, concept) \
- typedef void (concept <type_var1,type_var2,type_var3>::* func##type_var1##type_var2##type_var3##concept)(); \
+#define BOOST_CLASS_REQUIRES3(type_var1, type_var2, type_var3, ns, concept) \
+ typedef void (ns::concept <type_var1,type_var2,type_var3>::* func##type_var1##type_var2##type_var3##concept)(); \
template <func##type_var1##type_var2##type_var3##concept _Tp1> \
struct concept_checking_##type_var1##type_var2##type_var3##concept { }; \
typedef concept_checking_##type_var1##type_var2##type_var3##concept< \
- BOOST_FPTR concept <type_var1,type_var2,type_var3>::constraints> \
+ &ns::concept <type_var1,type_var2,type_var3>::constraints> \
concept_checking_typedef_##type_var1##type_var2##type_var3##concept
-#define BOOST_CLASS_REQUIRES4(type_var1, type_var2, type_var3, type_var4, concept) \
- typedef void (concept <type_var1,type_var2,type_var3,type_var4>::* func##type_var1##type_var2##type_var3##type_var4##concept)(); \
+#define BOOST_CLASS_REQUIRES4(type_var1, type_var2, type_var3, type_var4, ns, concept) \
+ typedef void (ns::concept <type_var1,type_var2,type_var3,type_var4>::* func##type_var1##type_var2##type_var3##type_var4##concept)(); \
template <func##type_var1##type_var2##type_var3##type_var4##concept _Tp1> \
struct concept_checking_##type_var1##type_var2##type_var3##type_var4##concept { }; \
typedef concept_checking_##type_var1##type_var2##type_var3##type_var4##concept< \
- BOOST_FPTR concept <type_var1,type_var2,type_var3,type_var4>::constraints> \
+ &ns::concept <type_var1,type_var2,type_var3,type_var4>::constraints> \
concept_checking_typedef_##type_var1##type_var2##type_var3##type_var4##concept
-#endif
-
-#if !defined BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
template <class T, class U>
struct require_same { };
template <class T>
struct require_same<T,T> { typedef T type; };
-#else
-// This version does not perform checking, but will not do any harm.
-template <class T, class U>
-struct require_same { typedef T type; };
-#endif
+
+ template <class T, class U>
+ struct SameTypeConcept
+ {
+ void constraints() {
+ typedef typename require_same<T, U>::type req;
+ }
+ };
template <class T>
struct IntegerConcept {
void constraints() {
-#if !defined BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
errortype_must_be_an_integer_type();
-#endif
}
};
-#if !defined BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
template <> struct IntegerConcept<short> { void constraints() {} };
template <> struct IntegerConcept<unsigned short> { void constraints() {} };
template <> struct IntegerConcept<int> { void constraints() {} };
@@ -108,32 +87,24 @@
template <> struct IntegerConcept<long> { void constraints() {} };
template <> struct IntegerConcept<unsigned long> { void constraints() {} };
// etc.
-#endif
template <class T>
struct SignedIntegerConcept {
void constraints() {
-#if !defined BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
errortype_must_be_a_signed_integer_type();
-#endif
}
};
-#if !defined BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
template <> struct SignedIntegerConcept<short> { void constraints() {} };
template <> struct SignedIntegerConcept<int> { void constraints() {} };
template <> struct SignedIntegerConcept<long> { void constraints() {} };
// etc.
-#endif
template <class T>
struct UnsignedIntegerConcept {
void constraints() {
-#if !defined BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
errortype_must_be_an_unsigned_integer_type();
-#endif
}
};
-#if !defined BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
template <> struct UnsignedIntegerConcept<unsigned short>
{ void constraints() {} };
template <> struct UnsignedIntegerConcept<unsigned int>
@@ -141,7 +112,6 @@
template <> struct UnsignedIntegerConcept<unsigned long>
{ void constraints() {} };
// etc.
-#endif
//===========================================================================
// Basic Concepts
@@ -159,15 +129,11 @@
struct AssignableConcept
{
void constraints() {
-#if !defined(_ITERATOR_) // back_insert_iterator broken for VC++ STL
a = a; // require assignment operator
-#endif
const_constraints(a);
}
void const_constraints(const TT& b) {
-#if !defined(_ITERATOR_) // back_insert_iterator broken for VC++ STL
a = b; // const required for argument to assignment
-#endif
}
TT a;
};
@@ -196,17 +162,13 @@
{
void constraints() {
TT b(a);
-#if !defined(_ITERATOR_) // back_insert_iterator broken for VC++ STL
a = a; // require assignment operator
-#endif
const_constraints(a);
ignore_unused_variable_warning(b);
}
void const_constraints(const TT& b) {
TT c(b);
-#if !defined(_ITERATOR_) // back_insert_iterator broken for VC++ STL
a = b; // const required for argument to assignment
-#endif
ignore_unused_variable_warning(c);
}
TT a;
@@ -304,6 +266,9 @@
BOOST_DEFINE_BINARY_OPERATOR_CONSTRAINT(-, SubtractOpConcept);
BOOST_DEFINE_BINARY_OPERATOR_CONSTRAINT(%, ModOpConcept);
+#undef BOOST_DEFINE_BINARY_PREDICATE_OP_CONSTRAINT
+#undef BOOST_DEFINE_BINARY_OPERATOR_CONSTRAINT
+
//===========================================================================
// Function Object Concepts
@@ -318,7 +283,6 @@
};
-#if !defined BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
template <class Func>
struct GeneratorConcept<Func,void>
{
@@ -327,7 +291,6 @@
}
Func f;
};
-#endif
template <class Func, class Return, class Arg>
struct UnaryFunctionConcept
@@ -340,7 +303,6 @@
Return r;
};
-#if !defined BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
template <class Func, class Arg>
struct UnaryFunctionConcept<Func, void, Arg> {
void constraints() {
@@ -348,7 +310,6 @@
}
Func f;
};
-#endif
template <class Func, class Return, class First, class Second>
struct BinaryFunctionConcept
@@ -362,7 +323,6 @@
Return r;
};
-#if !defined BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
template <class Func, class First, class Second>
struct BinaryFunctionConcept<Func, void, First, Second>
{
@@ -373,7 +333,6 @@
First first;
Second second;
};
-#endif
template <class Func, class Arg>
struct UnaryPredicateConcept
@@ -422,9 +381,7 @@
function_requires< AssignableConcept<TT> >();
function_requires< DefaultConstructibleConcept<TT> >();
function_requires< EqualityComparableConcept<TT> >();
-#ifndef BOOST_NO_STD_ITERATOR_TRAITS
typedef typename std::iterator_traits<TT>::value_type V;
-#endif
(void)*i; // require dereference operator
}
TT i;
@@ -446,7 +403,6 @@
void constraints() {
function_requires< TrivialIteratorConcept<TT> >();
// require iterator_traits typedef's
-#ifndef BOOST_NO_STD_ITERATOR_TRAITS
typedef typename std::iterator_traits<TT>::difference_type D;
function_requires< SignedIntegerConcept<D> >();
typedef typename std::iterator_traits<TT>::reference R;
@@ -455,7 +411,6 @@
function_requires< ConvertibleConcept<
typename std::iterator_traits<TT>::iterator_category,
std::input_iterator_tag> >();
-#endif
++i; // require preincrement operator
i++; // require postincrement operator
}
@@ -471,7 +426,7 @@
i++; // require postincrement operator
*i++ = t; // require postincrement and assignment
}
- TT i, j;
+ TT i;
ValueT t;
};
@@ -480,14 +435,12 @@
{
void constraints() {
function_requires< InputIteratorConcept<TT> >();
-#ifndef BOOST_NO_STD_ITERATOR_TRAITS
function_requires< ConvertibleConcept<
typename std::iterator_traits<TT>::iterator_category,
std::forward_iterator_tag> >();
typedef typename std::iterator_traits<TT>::reference reference;
reference r = *i;
ignore_unused_variable_warning(r);
-#endif
}
TT i;
};
@@ -507,11 +460,9 @@
{
void constraints() {
function_requires< ForwardIteratorConcept<TT> >();
-#ifndef BOOST_NO_STD_ITERATOR_TRAITS
function_requires< ConvertibleConcept<
typename std::iterator_traits<TT>::iterator_category,
std::bidirectional_iterator_tag> >();
-#endif
--i; // require predecrement operator
i--; // require postdecrement operator
}
@@ -536,12 +487,10 @@
void constraints() {
function_requires< BidirectionalIteratorConcept<TT> >();
function_requires< ComparableConcept<TT> >();
-#ifndef BOOST_NO_STD_ITERATOR_TRAITS
function_requires< ConvertibleConcept<
typename std::iterator_traits<TT>::iterator_category,
std::random_access_iterator_tag> >();
typedef typename std::iterator_traits<TT>::reference R;
-#endif
i += n; // require assignment addition operator
i = i + n; i = n + i; // require addition with difference type
@@ -552,11 +501,7 @@
}
TT a, b;
TT i, j;
-#ifndef BOOST_NO_STD_ITERATOR_TRAITS
typename std::iterator_traits<TT>::difference_type n;
-#else
- std::ptrdiff_t n;
-#endif
};
template <class TT>
@@ -568,11 +513,7 @@
i[n] = *i; // require element access and assignment
}
TT i;
-#ifndef BOOST_NO_STD_ITERATOR_TRAITS
typename std::iterator_traits<TT>::difference_type n;
-#else
- std::ptrdiff_t n;
-#endif
};
//===========================================================================

View File

@ -9,7 +9,7 @@
<meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
<meta name="DESCRIPTION" content="configury for libstdc++" />
<meta name="GENERATOR" content="vi and eight fingers" />
<title>libstdc++-v3 configury</title>
<title>libstdc++ configury</title>
<link rel="StyleSheet" href="../lib3styles.css" type='text/css' />
<link rel="Start" href="../documentation.html" type="text/html"
title="GNU C++ Standard Library" />
@ -26,7 +26,7 @@ Canadian cross build.</code></p>
<hr />
<h2>Notes on libstdc++-v3 configury</h2>
<h2>Notes on libstdc++ configury</h2>
<blockquote>
No problem is insoluble in all conceivable circumstances.<br />
-- The Cosmic AC,

View File

@ -1,83 +0,0 @@
// 1999-05-12 bkoz
// Copyright (C) 1999 Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library. This library is free
// software; you can redistribute it and/or modify it under the
// terms of the GNU General Public License as published by the
// Free Software Foundation; either version 2, or (at your option)
// any later version.
// This library is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
// You should have received a copy of the GNU General Public License along
// with this library; see the file COPYING. If not, write to the Free
// Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
// USA.
// 17.4.1.2 Headers
// "C++" headers
#include <algorithm>
#include <bitset>
#include <complex>
#include <deque>
#include <exception>
#include <fstream>
#include <functional>
#include <iomanip>
#include <ios>
#include <iosfwd>
#include <iostream>
#include <istream>
#include <iterator>
#include <limits>
#include <list>
#include <locale>
#include <map>
#include <memory>
#include <new>
#include <numeric>
#include <ostream>
#include <queue>
#include <set>
#include <sstream>
#include <stack>
#include <stdexcept>
#include <streambuf>
#include <string>
#include <typeinfo>
#include <utility>
#include <valarray>
#include <vector>
// "C" headers
#include <cassert>
#include <cctype>
#include <cerrno>
#include <cfloat>
#include <ciso646>
#include <climits>
#include <clocale>
#include <cmath>
#include <csetjmp>
#include <csignal>
#include <cstdarg>
#include <cstddef>
#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <ctime>
// "C" headers that might not work if wchar_t support is disabled.
#include <bits/c++config.h>
#if _GLIBCXX_USE_WCHAR_T
#include <cwchar>
#include <cwctype>
#endif
int main() { return 0; }

View File

@ -6,11 +6,11 @@
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
<meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards), Benjamin Kosnik, Felix Natter" />
<meta name="KEYWORDS" content="HOWTO, libstdc++, gcc, g++, libg++, STL" />
<meta name="DESCRIPTION" content="HOWTO for libstdc++ chapter 17." />
<meta name="GENERATOR" content="vi and eight fingers" />
<title>libstdc++-v3 HOWTO: Chapter 17: Library Introduction</title>
<title>libstdc++ HOWTO: Chapter 17: Library Introduction</title>
<link rel="StyleSheet" href="../lib3styles.css" type="text/css" />
<link rel="Start" href="../documentation.html" type="text/html"
title="GNU C++ Standard Library" />
@ -34,33 +34,175 @@
<hr />
<h1>Contents</h1>
<ul>
<li><a href="#2">The Standard C++ header files</a></li>
<li><a href="#3">The Standard C++ library and multithreading</a></li>
<li><a href="#4"><code>&lt;foo&gt;</code> vs <code>&lt;foo.h&gt;</code></a></li>
<li><a href="porting-howto.html">Porting HOWTO</a></li>
<li><a href="#5">Behavior specific to libstdc++-v3</a></li>
<li><a href="#6">Preprocessor macros controlling the library</a></li>
<li><a href="#2.1">Header Files</a></li>
<li><a href="#5">Implementation specific behavior</a></li>
<li><a href="#6">Macros</a></li>
<li><a href="#3">Multithreading</a></li>
</ul>
<hr />
<!-- ####################################################### -->
<h2><a name="2">The Standard C++ header files</a></h2>
<p>The Standard C++ Library specifies 50 header files that must be
<h2><a name="2.1">Header Files</a></h2>
<p>The C++ standard specifies 50 header files that must be
available to all hosted implementations. Actually, the word
&quot;files&quot; is a misnomer, since the contents of the headers
don't necessarily have to be in any kind of external file. The
only rule is that when you <code>#include</code> a certain header, the
only rule is that when one <code>#include</code>'s a certain header, the
contents of that header, as defined by the Standard, become
available to you, no matter how.
</p>
<p>The names of the headers can be easily seen in
<a href="headers_cc.txt"><code>testsuite/17_intro/headers.cc</code></a>,
which is a small testbed we use to make certain that the headers
all compile and run.
available, no matter how.
</p>
<p>C++98/03 include files:
</p>
<pre>
C++ Library Headers
algorithm ios new stack
bitset iosfwd numeric stdexcept
complex iostream ostream streambuf
istream queue string
deque iterator
exception limits typeinfo
fstream list set
functional locale map
iomanip memory sstream
C++ Headers for C Library Facilities
cassert cfloat cmath cstddef
ccomplex csetjmp cstdio ctime
cctype ciso646 csignal
cerrno climits cstdarg cstdlib cwchar
clocale cstring cwctype
</pre>
<p>C++0x include files:
</p>
<pre>
C++ Library Headers
algorithm ios new stack
array iosfwd numeric stdexcept
bitset iostream ostream streambuf
complex istream queue string
deque iterator random system_error
exception limits regex tuple
fstream list set type_traits
functional locale map typeinfo
iomanip memory sstream
C++ Headers for C Library Facilities
cassert cfloat cmath cstddef ctgmath
ccomplex cinttypes csetjmp cstdio ctime
cctype ciso646 csignal cstdint cuchar
cerrno climits cstdarg cstdlib cwchar
cfenv clocale cstdbool cstring cwctype
</pre>
<p>In addition, TR1 includes as:
</p>
<pre>
C++ Library Headers
tr1/array, tr1/complex, tr1/functional, tr1/memory, tr1/random,
tr1/regex, tr1/tuple, tr1/type_traits, tr1/unordered_map,
tr1/unordered_set, tr1/utility
C++ Headers for C Library Facilities
tr1/cmath, tr1/ccomplex, tr1/cfenv, tr1/cfloat, tr1/cinttypes,
tr1/climits, tr1/cstdarg, tr1/cstdbool, tr1/cstdint, tr1/cstdio,
tr1/cstdlib, tr1/ctgmath, tr1/ctime, tr1/cwchar, tr1/cwctype
C++ Compatibility Headers for C Library Facilities
tr1/complex.h, tr1/ctype.h, tr1/float.h, tr1/limits.h, tr1/math.h,
tr1/stdarg.h, tr1/stdbool.h, tr1/stdint.h, tr1/stdio.h, tr1/stdlib.h,
tr1/tgmath.h, tr1/wchar.h, tr1/wctype.h
</pre>
<hr />
<h2><a name="2.2">Headers and <code>namespace std::</code></a></h2>
<p>
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,
omitting the extension (.h). For example, instead of using
<tt>&lt;math.h&gt;</tt>, you
should use <tt>&lt;cmath&gt;</tt>. In some cases this has
the advantage that the C++-header is more standardized than
the C-header (i.e. <tt>&lt;ctime&gt;</tt> (almost)
corresponds to either <tt>&lt;time.h&gt;</tt> or <tt>&lt;sys/time.h&gt;</tt>).
The standard specifies that if you include the C-style header
(<tt>&lt;math.h&gt;</tt> in
this case), the symbols will be available both in the global
namespace and in namespace <code>std::</code> (but
libstdc++ does not yet have fully compliant headers) On the
other hand, if you include only the new header (i.e. <tt>&lt;cmath&gt;</tt>), the symbols
will only be defined in namespace <code>std::</code>
(and macros will be converted to inline-functions).
</p>
<p>FIXME: this is no longer accurate.</p>
<p>
For more information on this, and for information on how the
GNU C++ implementation might reuse (&quot;shadow&quot;) the C
library-functions, have a look at <a href="http://www.cantrip.org/cheaders.html" target="_top">
www.cantrip.org</a>.
</p>
<hr />
<h2><a name="2.5">Namespace <code>std::</code></a></h2>
<p>
One standard requirement is that the library components are defined
in <code>namespace std::</code>. Thus, in order to use these types or
functions, one must do one of two things:
</p>
<div class="itemizedlist"><ul type="disc"> <li><p>put a kind of
<span class="emphasis"><i>using-declaration</i></span> in your source
(either <code>using namespace std;</code> or i.e. <code>using
std::string;</code>) This approach works well for individual source files, but
should not be used in a global context, like header files.
</p></li> <li><p>use a <span class="emphasis"><i>fully
qualified name</i></span> for each library symbol
(i.e. <code>std::string</code>, <code>std::cout</code>) Always can be
used, and usually enhanced, by strategic use of typedefs. (In the
cases where the qualified verbage becomes unweidly.)
</p></li>
</ul>
<hr />
<h2><a name="2.6">Using namespace composition</code></a></h2>
<p>
<a href="http://gtkmm.sourceforge.net" target="_top">Gtk--</a> defines
most of its classes in namespace Gtk::. Thus, it was possible to
adapt Gtk-- to namespace std:: by using a C++-feature called
<span class="emphasis"><i>namespace composition</i></span>. This is what happens if
you put a <span class="emphasis"><i>using</i></span>-declaration into a
namespace-definition: the imported symbol(s) gets imported into the
currently active namespace(s). For example:
<pre class="programlisting">
namespace Gtk {
using std::string;
class Window { ... }
}
</pre>
In this example, <code>std::string</code> gets imported into
namespace Gtk::. The result is that you don't have to use
<code>std::string</code> in this header, but still
<code>std::string</code> does not get imported into
the global namespace (::) unless the user does
<code>using namespace Gtk;</code> (which is not recommended
practice for Gtk--, so it is not a problem). Additionally, the
<code>using</code>-declarations are wrapped in macros that
are set based on autoconf-tests to either &quot;&quot; or i.e. <code>using
std::string;</code> (depending on whether the system has
libstdc++ in <code>std::</code> or not). (ideas from
<tt>&lt;<a href="mailto:llewelly@dbritsch.dsl.xmission.com">llewelly@dbritsch.dsl.xmission.com</a>&gt;</tt>, Karl Nelson
<tt>&lt;<a href="mailto:kenelson@ece.ucdavis.edu">kenelson@ece.ucdavis.edu</a>&gt;</tt>)
</p>
<hr />
<h2><a name="3">The Standard C++ library and multithreading</a></h2>
<p>This section discusses issues surrounding the proper compilation
@ -119,7 +261,7 @@
href="../23_containers/howto.html#3">23</a> (containers), and <a
href="../27_io/howto.html#9">27</a> (I/O) for more information.
</p>
<p>The libstdc++-v3 library (unlike libstdc++-v2, all of it, not
<p>The libstdc++ library (unlike libstdc++-v2, all of it, not
just the STL) has been designed so that multithreaded
applications using it may be written. The first problem is
finding a <em>fast</em> method of implementation portable to all
@ -162,21 +304,7 @@
</p>
<hr />
<h2><a name="4"><code>&lt;foo&gt;</code> vs <code>&lt;foo.h&gt;</code></a></h2>
<p>The new-style headers are fully supported in libstdc++-v3. The compiler
itself fully supports namespaces, including <code>std::</code>.
</p>
<p>For those of you new to ISO C++98, no, that isn't a typo, the headers
really have new names. Marshall Cline's C++ FAQ Lite has a good
explanation in
<a href="http://www.parashift.com/c++-faq-lite/coding-standards.html#faq-27.4">item [27.4]</a>.
</p>
<p>Return <a href="#top">to top of page</a> or
<a href="../faq/index.html">to the FAQ</a>.
</p>
<hr />
<h2><a name="5">Behavior specific to libstdc++-v3</a></h2>
<h2><a name="5">Behavior specific to libstdc++</a></h2>
<p>The ISO standard defines the following phrase:
</p>
<blockquote><dl>
@ -209,7 +337,7 @@
<a href="../18_support/howto.html#1">here</a>.
</p>
<p><strong>[18.3]/8</strong> Even though it's listed in the library
sections, libstdc++-v3 has zero control over what the cleanup code hands
sections, libstdc++ has zero control over what the cleanup code hands
back to the runtime loader. Talk to the compiler people. :-)
</p>
<p><strong>[18.4.2.1]/5</strong> (bad_alloc),<br />
@ -289,74 +417,100 @@
</p>
<hr />
<h2><a name="6">Preprocessor macros controlling the library</a></h2>
<p>Some of the semantics of the libstdc++-v3 implementation are
controlled by preprocessor macros, both during build/installation and
during compilation of user code. Many of these choices are made when
the library is built and installed (actually, during
<a href="../configopts.html">the configuration step</a>, with the
various --enable/--disable choices being translated to #define/#undef).
<h2><a name="6">Macros for libstdc++</a></h2>
<p>All pre-processor switches and configurations are all gathered
in the file <code>c++config.h</code>, which is generated during
the libstdc++ configuration and build process, and included by
files part of the public libstdc++ API. Most of these macros
should not be used by consumers of libstdc++, and are reserved
for internal implementation use. <strong>These macros cannot be
redefined</strong>. However, a select handful of these macro
control libstdc++ extensions and extra features, or provide
versioning information for the API, and are able to be used.
</p>
<p>All library macros begin with <code>_GLIBCPP_</code> in earlier
versions, and <code>_GLIBCXX_</code> in later versions. The fact that
these symbols start with a leading underscore should give you a clue
that (by default) they aren't meant to be changed by the user. :-)
</p>
<p>These macros are all gathered in the file <code>c++config.h</code>,
which is generated during installation. <strong>You must assume that
these macros cannot be redefined by your own code</strong>, unless we
document otherwise here. Some of the choices control code which has
already been compiled (i.e., libstdc++.a/.so). If you explicitly
#define or #undef these macros, the <em>headers</em> may see different
code paths, but the <em>libraries</em> which you link against will not.
If you want to experiment with different values, you must change the
config headers before building/installing the library.
</p>
<p>Below are macros which, for 3.1 and later, you may change yourself,
in your own code with #define/#undef or with -D/-U compiler flags.
The default state of the symbol is listed. &quot;Configurable&quot;
(or &quot;Not configurable&quot;) means that the symbol is initially
chosen (or not) based on --enable/--disable options at configure time.
For 3.1 through 3.3, the prefixes are <code>_GLIBCPP_</code>.
<p>All library macros begin with <code>_GLIBCXX_</code> (except for
versions 3.1.x to 3.3.x, which use <code>_GLIBCPP_</code>).
</p>
<p>Below is the macro which users may check for library version
information. </p>
<dl>
<dt><code>__GLIBCXX__</code></dt> <dd>The current version of
libstdc++ in compressed ISO date format, form of an unsigned
long. For details on the value of this particular macro for a
particular release, please consult this <a href="abi.html">
document</a>.</dd> </dl>
<p>Below are the macros which users may change with #define/#undef or
with -D/-U compiler flags. The default state of the symbol is
listed.</p>
<p>&quot;Configurable&quot; (or &quot;Not configurable&quot;) means
that the symbol is initially chosen (or not) based on
--enable/--disable options at library build and configure time
(documented <a href="../configopts.html">here</a>), with the
various --enable/--disable choices being translated to
#define/#undef).
</p>
<p> &quot;ABI&quot; means that changing from the default value may
mean changing the ABI of compiled code. In other words, these
choices control code which has already been compiled (i.e., in a
binary such as libstdc++.a/.so). If you explicitly #define or
#undef these macros, the <em>headers</em> may see different code
paths, but the <em>libraries</em> which you link against will not.
Experimenting with different values with the expectation of
consistent linkage requires changing the config headers before
building/installing the library.
</p>
<dl>
<dt><code>_GLIBCXX_DEPRECATED</code></dt>
<dd>Undefined by default. Not configurable. Turning this on enables
older ARM-style iostreams code, and other anachronisms. This may be
useful in updating old C++ programs which no longer meet the
requirements of the language.
</dd>
<!--
Can this actually be turned off and still produce a working lib? Must
check. -pme
No, it can't. Hmmm. -pme
<dt><code>_GLIBCPP_RESOLVE_LIB_DEFECTS</code></dt>
<dd>Defined by default. Not configurable. The library follows
corrections and updates from the ISO committee, see
<a href="../faq/index.html#5_2">here</a> and
<a href="../ext/howto.html#5">here</a> for more on this feature.
If you have code which depends on the first version of the standard,
you might try undefining this macro.
</dd>
-->
<dt><code>_GLIBCXX_CONCEPT_CHECKS</code></dt>
<dd>Undefined by default. Configurable. When defined, performs
compile-time checking on certain template instantiations to detect
violations of the requirements of the standard. This is described
in more detail <a href="../19_diagnostics/howto.html#3">here</a>.
<dd>Defined by default. Not configurable. ABI-changing. Turning this off
removes older ARM-style iostreams code, and other anachronisms
from the API. This macro is dependent on the version of the
standard being tracked, and as a result may give different results for
<code>-std=c++98</code> and <code>-std=c++0x</code>. This may
be useful in updating old C++ code which no longer meet the
requirements of the language, or for checking current code
against new language standards. </dd>
<dt><code>_GLIBCXX_FORCE_NEW</code></dt> <dd>Undefined by
default. When defined, memory allocation and allocators controlled
by libstdc++ call operator new/delete without caching and
pooling. Configurable via
<code>--enable-libstdcxx-allocator</code>. ABI-changing.</a>
</dd>
<dt><code>_GLIBCXX_CONCEPT_CHECKS</code></dt> <dd>Undefined by
default. Configurable via <code>--enable-concept-checks</code>.
When defined, performs compile-time checking on certain template
instantiations to detect violations of the requirements of the
standard. This is described in more detail <a
href="../19_diagnostics/howto.html#3">here</a>.</dd>
<dt><code>_GLIBCXX_DEBUG</code></dt>
<dd>Undefined by default. Configurable. When defined, compiles
user code using the <a href="../debug.html#safe">libstdc++ debug
<dd>Undefined by default. When defined, compiles
user code using the <a href="../ext/debug.html#safe">libstdc++ debug
mode</a>.
</dd>
<dt><code>_GLIBCXX_DEBUG_PEDANTIC</code></dt>
<dd>Undefined by default. Configurable. When defined while
compiling with the <a href="../debug.html#safe">libstdc++ debug
<dd>Undefined by default. When defined while
compiling with the <a href="../ext/debug.html#safe">libstdc++ debug
mode</a>, makes the debug mode extremely picky by making the use
of libstdc++ extensions and libstdc++-specific behavior into
errors.
</dd>
<dt><code>_GLIBCXX_PARALLEL</code></dt>
<dd>Undefined by default. When defined, compiles
user code using the <a href="../ext/parallel_mode.html">libstdc++ parallel
mode</a>.
</dd>
<!--
<dt><code></code></dt>
<dd>

View File

@ -32,7 +32,7 @@
<h2>The Code: Runtime GPL</h2>
<p>The source code of libstdc++ is distributed under version 2 of the
<a href="COPYING">GNU General Public License</a>, with the so-called
<a href="COPYING" type="text/plain">GNU General Public License</a>, with the so-called
&quot;runtime exception,&quot; as follows (or see any header or
implementation file):
</p>
@ -85,7 +85,7 @@
<p>The documentation shipped with the library and made available over the
web, excluding the pages generated from source comments, are copyrighted
by the Free Software Foundation, and placed under
the <a href="COPYING.DOC">GNU Free Documentation License version 1.1</a>.
the <a href="COPYING.DOC" type="text/plain">GNU Free Documentation License version 1.1</a>.
There are no Front-Cover Texts, no Back-Cover Texts, and
<!-- as far as I know -->
no Invariant Sections.

View File

@ -1,744 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<title>Libstdc++-porting-howto</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.48">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="article">
<div class="titlepage">
<div><h1 class="title">
<a name="libstdc++-porting-howto"></a>Libstdc++-porting-howto</h1></div>
<div><h3 class="author">Felix Natter</h3></div>
<div><div class="legalnotice">
<p class="legalnotice-title"><b>Legal Notice</b></p>
<p>
This document can be distributed under the FDL
(<a href="http://www.gnu.org" target="_top">www.gnu.org</a>)
</p>
</div></div>
<div><p class="pubdate">Tue Jun 5 20:07:49 2001</p></div>
<div><div class="revhistory"><table border="1" width="100%" summary="Revision history">
<tr><th align="left" valign="top" colspan="3"><b>Revision History</b></th></tr>
<tr>
<td align="left">Revision 0.5</td>
<td align="left">Thu Jun 1 13:06:50 2000</td>
<td align="left">fnatter</td>
</tr>
<tr><td align="left" colspan="3">First docbook-version.</td></tr>
<tr>
<td align="left">Revision 0.8</td>
<td align="left">Sun Jul 30 20:28:40 2000</td>
<td align="left">fnatter</td>
</tr>
<tr><td align="left" colspan="3">First released version using docbook-xml
+ second upload to libstdc++-page.
</td></tr>
<tr>
<td align="left">Revision 0.9</td>
<td align="left">Wed Sep 6 02:59:32 2000</td>
<td align="left">fnatter</td>
</tr>
<tr><td align="left" colspan="3">5 new sections.</td></tr>
<tr>
<td align="left">Revision 0.9.1</td>
<td align="left">Sat Sep 23 14:20:15 2000</td>
<td align="left">fnatter</td>
</tr>
<tr><td align="left" colspan="3">added information about why file-descriptors are not in the
standard</td></tr>
<tr>
<td align="left">Revision 0.9.2</td>
<td align="left">Tue Jun 5 20:07:49 2001</td>
<td align="left">fnatter</td>
</tr>
<tr><td align="left" colspan="3">
a fix, added hint on increased portability of C-shadow-headers,
added autoconf-test HAVE_CONTAINER_AT
</td></tr>
<tr>
<td align="left">Revision 0.9.3</td>
<td align="left">Fri Jun 29 16:15:56 2001</td>
<td align="left">fnatter</td>
</tr>
<tr><td align="left" colspan="3">
changed signature of nonstandard filebuf-constructor and
update the section on filebuf::attach to point to ../ext/howto.html,
added link to ../21/strings/howto.html
in sec-stringstream, changed &lt;link&gt;-tags to have content
(so that these links work),
replace &quot;user-space&quot; by &quot;global namespace&quot;
add note about gcc 3.0 and shadow-headers
add section about ostream::form and istream::scan
sec-vector-at: remove hint to modify headers
fix spelling error in sec-stringstream
</td></tr>
<tr>
<td align="left">Revision 0.9.4</td>
<td align="left">Mon Nov 5 17:01:04 2001</td>
<td align="left">fnatter</td>
</tr>
<tr><td align="left" colspan="3">
rewrite section 1.1.3 because of gnu.gcc.help-post by
Juergen Heinzl
</td></tr>
</table></div></div>
<div><div class="abstract">
<p><b>Abstract</b></p>
<p>
Some notes on porting applications from libstdc++-2.90 (or earlier
versions) to libstdc++-v3. Not speaking in terms of the GNU libstdc++
implementations, this means porting from earlier versions of the
C++-Standard to ISO 14882.
</p>
</div></div>
<hr>
</div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl>
<dt>1. <a href="#sec-nsstd">Namespace std::</a>
</dt>
<dd><dl>
<dt>1.1.1. <a href="#sec-gtkmm-hack">Using namespace
composition if the project uses a separate
namespace</a>
</dt>
<dt>1.1.2. <a href="#sec-emptyns">Defining an empty namespace std</a>
</dt>
<dt>1.1.3. <a href="#sec-avoidfqn">Avoid to use fully qualified names
(i.e. std::string)</a>
</dt>
<dt>1.1.4. <a href="#sec-osprojects">How some open-source-projects deal
with this</a>
</dt>
</dl></dd>
<dt>2. <a href="#sec-nocreate">There is no ios::nocreate/ios::noreplace
in ISO 14882</a>
</dt>
<dt>3. <a href="#sec-stream::attach">stream::attach(int
fd) is not in the standard any more</a>
</dt>
<dt>4. <a href="#sec-headers">The new headers</a>
</dt>
<dd><dl>
<dt>4.4.1. <a href="#sec-cheaders">New headers replacing C-headers</a>
</dt>
<dt>4.4.2. <a href="#sec-fstream-header">
&lt;fstream&gt; does
not define std::cout,
std::cin etc.</a>
</dt>
</dl></dd>
<dt>5. <a href="#sec-iterators">Iterators</a>
</dt>
<dt>6. <a href="#sec-macros">
Libc-macros (i.e. isspace from
&lt;cctype&gt;)</a>
</dt>
<dt>7. <a href="#sec-stream-state">State of streams</a>
</dt>
<dt>8. <a href="#sec-vector-at">vector::at is missing (i.e. gcc 2.95.x)</a>
</dt>
<dt>9. <a href="#sec-eof">Using std::char_traits&lt;char&gt;::eof()</a>
</dt>
<dt>10. <a href="#sec-string-clear">Using string::clear()/string::erase()</a>
</dt>
<dt>11. <a href="#sec-scan-form">GNU Extensions ostream::form and istream::scan</a>
</dt>
<dt>12. <a href="#sec-stringstream">Using stringstreams</a>
</dt>
<dt>13. <a href="#sec-about">About...</a>
</dt>
</dl>
</div>
<p>
In the following, when I say portable, I will refer to &quot;portable among ISO
14882-implementations&quot;. On the other hand, if I say &quot;backportable&quot; or
&quot;conservative&quot;, I am talking about &quot;compiles with older
libstdc++-implementations&quot;.
</p>
<div class="section">
<div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="sec-nsstd"></a>Namespace std::</h2></div></div>
<p>
The latest C++-standard (ISO-14882) requires that the standard
C++-library is defined in namespace std::. Thus, in order to use
classes from the standard C++-library, you can do one of three
things:
<div class="itemizedlist"><ul type="disc">
<li><p>wrap your code in <b>namespace std {
... }</b> =&gt; This is not an option because only symbols
from the standard c++-library are defined in namespace std::.
</p></li>
<li><p>put a kind of
<span class="emphasis"><i>using-declaration</i></span> in your source (either
<b>using namespace std;</b> or i.e. <b>using
std::string;</b>) =&gt; works well for source-files, but
cannot be used in header-files.
</p></li>
<li><p>use a <span class="emphasis"><i>fully qualified name</i></span> for
each libstdc++-symbol (i.e. <b>std::string</b>,
<b>std::cout</b>) =&gt; can always be used
</p></li>
</ul></div>
<p>
Because there are many compilers which still use an implementation
that does not have the standard C++-library in namespace
<b>std::</b>, some care is required to support these as
well.
</p>
<p>
Namespace back-portability-issues are generally not a problem with
g++, because versions of g++ that do not have libstdc++ in
<b>std::</b> use <b>-fno-honor-std</b>
(ignore <b>std::</b>, <b>:: = std::</b>) by
default. That is, the responsibility for enabling or disabling
<b>std::</b> is on the user; the maintainer does not have
to care about it. This probably applies to some other compilers as
well.
</p>
<p>
The following sections list some possible solutions to support compilers
that cannot ignore std::.
</p>
<div class="section">
<div class="titlepage"><div><h3 class="title">
<a name="sec-gtkmm-hack"></a>Using <span class="emphasis"><i>namespace
composition</i></span> if the project uses a separate
namespace</h3></div></div>
<p>
<a href="http://gtkmm.sourceforge.net" target="_top">Gtk--</a> defines
most of its classes in namespace Gtk::. Thus, it was possible to
adapt Gtk-- to namespace std:: by using a C++-feature called
<span class="emphasis"><i>namespace composition</i></span>. This is what happens if
you put a <span class="emphasis"><i>using</i></span>-declaration into a
namespace-definition: the imported symbol(s) gets imported into the
currently active namespace(s). For example:
<pre class="programlisting">
namespace Gtk {
using std::string;
class Window { ... }
}
</pre>
In this example, <b>std::string</b> gets imported into
namespace Gtk::. The result is that you don't have to use
<b>std::string</b> in this header, but still
<b>std::string</b> does not get imported into
the global namespace (::) unless the user does
<b>using namespace Gtk;</b> (which is not recommended
practice for Gtk--, so it is not a problem). Additionally, the
<b>using</b>-declarations are wrapped in macros that
are set based on autoconf-tests to either &quot;&quot; or i.e. <b>using
std::string;</b> (depending on whether the system has
libstdc++ in <b>std::</b> or not). (ideas from
<tt>&lt;<a href="mailto:llewelly@dbritsch.dsl.xmission.com">llewelly@dbritsch.dsl.xmission.com</a>&gt;</tt>, Karl Nelson
<tt>&lt;<a href="mailto:kenelson@ece.ucdavis.edu">kenelson@ece.ucdavis.edu</a>&gt;</tt>)
</div>
<div class="section">
<div class="titlepage"><div><h3 class="title">
<a name="sec-emptyns"></a>Defining an empty namespace std</h3></div></div>
<p>
By defining an (empty) namespace <b>std::</b> before
using it, you avoid getting errors on systems where no part of the
library is in namespace std:
<pre class="programlisting">
namespace std { }
using namespace std;
</pre>
</div>
<div class="section">
<div class="titlepage"><div><h3 class="title">
<a name="sec-avoidfqn"></a>Avoid to use fully qualified names
(i.e. std::string)</h3></div></div>
<p>
If some compilers complain about <b>using
std::string;</b>, and if the &quot;hack&quot; for gtk-- mentioned above
does not work, then I see two solutions:
<div class="itemizedlist"><ul type="disc">
<li><p>
Define <b>std::</b> as a macro if the compiler
doesn't know about <b>std::</b>.
<pre class="programlisting">
#ifdef OLD_COMPILER
#define std
#endif
</pre>
(thanks to Juergen Heinzl who posted this solution on
gnu.gcc.help)
</li>
<li><p>
Define a macro NS_STD, which is defined to
either &quot;&quot; or &quot;std&quot;
based on an autoconf-test. Then you should be able to use
<b>NS_STD::string</b>, which will evaluate to
<b>::string</b> (&quot;string in the global namespace&quot;) on
systems that do not put string in std::. (This is untested)
</p></li>
</ul></div>
</div>
<div class="section">
<div class="titlepage"><div><h3 class="title">
<a name="sec-osprojects"></a>How some open-source-projects deal
with this</h3></div></div>
<p>
This information was gathered around May 2000. It may not be correct
by the time you read this.
</p>
<div class="table">
<p><b>Table 1. Namespace std:: in Open-Source programs</b></p>
<table summary="Namespace std:: in Open-Source programs" border="1">
<colgroup>
<col>
<col>
</colgroup>
<tbody>
<tr>
<td><a href="http://www.clanlib.org" target="_top">clanlib</a></td>
<td>usual</td>
</tr>
<tr>
<td><a href="http://pingus.seul.org" target="_top">pingus</a></td>
<td>usual</td>
</tr>
<tr>
<td><a href="http://www.mozilla.org" target="_top">mozilla</a></td>
<td>usual</td>
</tr>
<tr>
<td><a href="http://libsigc.sourceforge.net" target="_top">
libsigc++</a></td>
<td>conservative-impl</td>
</tr>
</tbody>
</table>
</div>
<div class="table">
<p><b>Table 2. Notations for categories</b></p>
<table summary="Notations for categories" border="1">
<colgroup>
<col>
<col>
</colgroup>
<tbody>
<tr>
<td>usual</td>
<td>mostly fully qualified names and some
using-declarations (but not in headers)</td>
</tr>
<tr>
<td>none</td>
<td>no namespace std at all</td>
</tr>
<tr>
<td>conservative-impl</td>
<td>wrap all
namespace-handling in macros to support compilers without
namespace-support (no libstdc++ used in headers)</td>
</tr>
</tbody>
</table>
</div>
<p>
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 Gtk--: see the <a href="#sec-gtkmm-hack" title="Using namespace
composition if the project uses a separate
namespace">section on the gtkmm-hack</a>).
</p>
</div>
</div>
<div class="section">
<div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="sec-nocreate"></a>There is no ios::nocreate/ios::noreplace
in ISO 14882</h2></div></div>
<p>
I have seen <b>ios::nocreate</b> being used for
input-streams, most probably because the author thought it would be
more correct to specify nocreate &quot;explicitly&quot;. So you can simply
leave it out for input-streams.
</p>
<p>
For output streams, &quot;nocreate&quot; is probably the default, unless you
specify <b>std::ios::trunc</b> ? 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. To my knowledge, even
older implementations support <b>app</b>,
<b>ate</b> and <b>trunc</b> (except for
<b>app</b> ?).
</p>
</div>
<div class="section">
<div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="sec-stream::attach"></a><b>stream::attach(int
fd)</b> is not in the standard any more</h2></div></div>
<p>
Phil Edwards <tt>&lt;<a href="mailto:pedwards@disaster.jaj.com">pedwards@disaster.jaj.com</a>&gt;</tt> writes:
It was considered and rejected. Not all environments use file
descriptors. Of those that do, not all of them use integers to represent
them.
</p>
<p>
For a portable solution (among systems which use
filedescriptors), you need to implement a subclass of
<b>std::streambuf</b> (or
<b>std::basic_streambuf&lt;..&gt;</b>) which opens a file
given a descriptor, and then pass an instance of this to the
stream-constructor. For an example of this, refer to
<a href="http://www.josuttis.com/cppcode/fdstream.html" target="_top">fdstream example</a>
by Nicolai Josuttis.
</p>
<p>
An extension is also available:
<code>&lt;ext/stdio_filebuf.h&gt;</code> contains a derived class called
<a href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/class____gnu__cxx_1_1stdio__filebuf.html"><code>__gnu_cxx::stdio_filebuf</code></a>.
This class can be constructed from a C <code>FILE*</code> or a file
descriptor, and provides the <code>fd()</code> function.
</p>
</div>
<div class="section">
<div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="sec-headers"></a>The new headers</h2></div></div>
<p>
All new headers can be seen in this <a href="headers_cc.txt" target="_top">
source-code</a>.
</p>
<p>
The old C++-headers (iostream.h etc.) are available, but gcc generates
a warning that you are using deprecated headers.
</p>
<div class="section">
<div class="titlepage"><div><h3 class="title">
<a name="sec-cheaders"></a>New headers replacing C-headers</h3></div></div>
<p>
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,
omitting the extension (.h). For example, instead of using
<tt>&lt;math.h&gt;</tt>, you
should use <tt>&lt;cmath&gt;</tt>. In some cases this has
the advantage that the C++-header is more standardized than
the C-header (i.e. <tt>&lt;ctime&gt;</tt> (almost)
corresponds to either <tt>&lt;time.h&gt;</tt> or <tt>&lt;sys/time.h&gt;</tt>).
The standard specifies that if you include the C-style header
(<tt>&lt;math.h&gt;</tt> in
this case), the symbols will be available both in the global
namespace and in namespace <b>std::</b> (but
libstdc++ does not yet have fully compliant headers) On the
other hand, if you include only the new header (i.e. <tt>&lt;cmath&gt;</tt>), the symbols
will only be defined in namespace <b>std::</b>
(and macros will be converted to inline-functions).
</p>
<p>
For more information on this, and for information on how the
GNU C++ implementation might reuse (&quot;shadow&quot;) the C
library-functions, have a look at <a href="http://www.cantrip.org/cheaders.html" target="_top">
www.cantrip.org</a>.
</p>
</div>
<div class="section">
<div class="titlepage"><div><h3 class="title">
<a name="sec-fstream-header"></a>
<tt>&lt;fstream&gt;</tt> does
not define <b>std::cout</b>,
<b>std::cin</b> etc.</h3></div></div>
<p>
In earlier versions of the standard,
<tt>&lt;fstream.h&gt;</tt>,
<tt>&lt;ostream.h&gt;</tt>
and <tt>&lt;istream.h&gt;</tt>
used to define
<b>cout</b>, <b>cin</b> and so on. Because
of the templatized iostreams in libstdc++-v3, you need to include
<tt>&lt;iostream&gt;</tt>
explicitly to define these.
</p>
</div>
</div>
<div class="section">
<div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="sec-iterators"></a>Iterators</h2></div></div>
<p>
The following are not proper uses of iterators, but may be working
fixes for existing uses of iterators.
<div class="itemizedlist"><ul type="disc">
<li><p>you cannot do
<b>ostream::operator&lt;&lt;(iterator)</b> to
print the address of the iterator =&gt; use
<b>operator&lt;&lt; &amp;*iterator</b> instead ?
</p></li>
<li><p>you cannot clear an iterator's reference
(<b>iterator = 0</b>) =&gt; use
<b>iterator = iterator_type();</b> ?
</p></li>
<li><p>
<b>if (iterator)</b> won't work any
more =&gt; use <b>if (iterator != iterator_type())</b>
?</p></li>
</ul></div>
</div>
<div class="section">
<div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="sec-macros"></a>
Libc-macros (i.e. <b>isspace</b> from
<tt>&lt;cctype&gt;</tt>)</h2></div></div>
<p>
Glibc 2.0.x and 2.1.x define the
<tt>&lt;ctype.h&gt;</tt>
-functionality as macros (isspace, isalpha etc.). Libstdc++-v3
&quot;shadows&quot; these macros as described in the <a href="#sec-cheaders" title="New headers replacing C-headers">section about
c-headers</a>.
</p>
<p>
Older implementations of libstdc++ (g++-2 for egcs 1.x and g++-3
for gcc 2.95.x), however, keep these functions as macros, and so it
is not back-portable to use fully qualified names. For example:
<pre class="programlisting">
#include &lt;cctype&gt;
int main() { std::isspace('X'); }
</pre>
will result in something like this (unless using g++-v3):
<pre class="programlisting">
std:: (__ctype_b[(int) ( ( 'X' ) )] &amp; (unsigned short int)
_ISspace ) ;
</pre>
<p>
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 &quot;wrapper&quot; macro as well ?).
</p>
<p>
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.x) define a
macro which tells <tt>&lt;ctype.h&gt;</tt> to define functions
instead of macros:
<pre class="programlisting">
// This keeps isalnum, et al from being propagated as macros.
#if __linux__
#define __NO_CTYPE 1
#endif
[ now include &lt;ctype.h&gt; ]
</pre>
<p>
Another problem arises if you put a <b>using namespace
std;</b> declaration at the top, and include <tt>&lt;ctype.h&gt;</tt>. This will result in
ambiguities between the definitions in the global namespace
(<tt>&lt;ctype.h&gt;</tt>) and the
definitions in namespace <b>std::</b>
(<b>&lt;cctype&gt;</b>).
</p>
<p>
The solution to this problem was posted to the libstdc++-v3
mailing-list:
Benjamin Kosnik <tt>&lt;<a href="mailto:bkoz@redhat.com">bkoz@redhat.com</a>&gt;</tt> writes:
&#x2018;
--enable-cshadow-headers is currently broken. As a result, shadow
headers are not being searched....
&#x2019;
This is now outdated, but gcc 3.0 still does not have fully
compliant &quot;shadow headers&quot;.
</p>
</div>
<div class="section">
<div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="sec-stream-state"></a>State of streams</h2></div></div>
<p>
At least some older implementations don't have
<b>std::ios_base</b>, so you should use
<b>std::ios::badbit</b>, <b>std::ios::failbit</b>
and <b>std::ios::eofbit</b> and
<b>std::ios::goodbit</b>.
</p>
</div>
<div class="section">
<div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="sec-vector-at"></a>vector::at is missing (i.e. gcc 2.95.x)</h2></div></div>
<p>
One solution is to add an autoconf-test for this:
<pre class="programlisting">
AC_MSG_CHECKING(for container::at)
AC_TRY_COMPILE(
[
#include &lt;vector&gt;
#include &lt;deque&gt;
#include &lt;string&gt;
using namespace std;
],
[
deque&lt;int&gt; test_deque(3);
test_deque.at(2);
vector&lt;int&gt; test_vector(2);
test_vector.at(1);
string test_string(&quot;test_string&quot;);
test_string.at(3);
],
[AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_CONTAINER_AT)],
[AC_MSG_RESULT(no)])
</pre>
If you are using other (non-GNU) compilers it might be a good idea
to check for <b>string::at</b> separately.
</div>
<div class="section">
<div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="sec-eof"></a>Using std::char_traits&lt;char&gt;::eof()</h2></div></div>
<p>
<pre class="programlisting">
#ifdef HAVE_CHAR_TRAITS
#define CPP_EOF std::char_traits&lt;char&gt;::eof()
#else
#define CPP_EOF EOF
#endif
</pre>
</div>
<div class="section">
<div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="sec-string-clear"></a>Using string::clear()/string::erase()</h2></div></div>
<p>
There are two functions for deleting the contents of a string:
<b>clear</b> and <b>erase</b> (the latter
returns the string).
<pre class="programlisting">
void
clear() { _M_mutate(0, this-&gt;size(), 0); }
</pre>
<pre class="programlisting">
basic_string&amp;
erase(size_type __pos = 0, size_type __n = npos)
{
return this-&gt;replace(_M_check(__pos), _M_fold(__pos, __n),
_M_data(), _M_data());
}
</pre>
The implementation of <b>erase</b> seems to be more
complicated (from libstdc++-v3), but <b>clear</b> is not
implemented in gcc 2.95.x's libstdc++, so you should use
<b>erase</b> (which is probably faster than
<b>operator=(charT*)</b>).
</div>
<div class="section">
<div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="sec-scan-form"></a>GNU Extensions ostream::form and istream::scan</h2></div></div>
<p>
These are not supported any more - use
<a href="#sec-stringstream" title="Using stringstreams">
stringstreams</a> instead.
</p>
</div>
<div class="section">
<div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="sec-stringstream"></a>Using stringstreams</h2></div></div>
<p>
Libstdc++-v3 provides the new
<b>i/ostringstream</b>-classes, (<tt>&lt;sstream&gt;</tt>), but for compatibility
with older implementations you still have to use
<b>i/ostrstream</b> (<tt>&lt;strstream&gt;</tt>):
<pre class="programlisting">
#ifdef HAVE_SSTREAM
#include &lt;sstream&gt;
#else
#include &lt;strstream&gt;
#endif
</pre>
<div class="itemizedlist"><ul type="disc">
<li><p> <b>strstream</b> is considered to be
deprecated
</p></li>
<li><p> <b>strstream</b> is limited to
<b>char</b>
</p></li>
<li><p> with <b>ostringstream</b> you don't
have to take care of terminating the string or freeing its
memory
</p></li>
<li><p> <b>istringstream</b> can be re-filled
(clear(); str(input);)
</p></li>
</ul></div>
<p>
You can then use output-stringstreams like this:
<pre class="programlisting">
#ifdef HAVE_SSTREAM
std::ostringstream oss;
#else
std::ostrstream oss;
#endif
oss &lt;&lt; &quot;Name=&quot; &lt;&lt; m_name &lt;&lt; &quot;, number=&quot; &lt;&lt; m_number &lt;&lt; std::endl;
...
#ifndef HAVE_SSTREAM
oss &lt;&lt; std::ends; // terminate the char*-string
#endif
// str() returns char* for ostrstream and a string for ostringstream
// this also causes ostrstream to think that the buffer's memory
// is yours
m_label.set_text(oss.str());
#ifndef HAVE_SSTREAM
// let the ostrstream take care of freeing the memory
oss.freeze(false);
#endif
</pre>
<p>
Input-stringstreams can be used similarly:
<pre class="programlisting">
std::string input;
...
#ifdef HAVE_SSTREAM
std::istringstream iss(input);
#else
std::istrstream iss(input.c_str());
#endif
int i;
iss &gt;&gt; i;
</pre>
One (the only?) restriction is that an istrstream cannot be re-filled:
<pre class="programlisting">
std::istringstream iss(numerator);
iss &gt;&gt; m_num;
// this is not possible with istrstream
iss.clear();
iss.str(denominator);
iss &gt;&gt; m_den;
</pre>
If you don't care about speed, you can put these conversions in
a template-function:
<pre class="programlisting">
template &lt;class X&gt;
void fromString(const string&amp; input, X&amp; any)
{
#ifdef HAVE_SSTREAM
std::istringstream iss(input);
#else
std::istrstream iss(input.c_str());
#endif
X temp;
iss &gt;&gt; temp;
if (iss.fail())
throw runtime_error(..)
any = temp;
}
</pre>
Another example of using stringstreams is in <a href="../21_strings/howto.html" target="_top">this howto</a>.
<p>
I have read the Josuttis book on Standard C++, so some information
comes from there. Additionally, there is information in
&quot;info iostream&quot;, which covers the old implementation that gcc 2.95.x
uses.
</p>
</div>
<div class="section">
<div class="titlepage"><div><h2 class="title" style="clear: both">
<a name="sec-about"></a>About...</h2></div></div>
<p>
Please send any experience, additions, corrections or questions to
<a href="mailto:fnatter@gmx.net" target="_top">fnatter@gmx.net</a> or for
discussion to the libstdc++-v3-mailing-list.
</p>
</div>
</div></body>
</html>

View File

@ -1,8 +1,8 @@
<html lang="en">
<head>
<title>Porting libstdc++-v3</title>
<title>Porting libstdc++</title>
<meta http-equiv="Content-Type" content="text/html">
<meta name="description" content="Porting libstdc++-v3">
<meta name="description" content="Porting libstdc++">
<meta name="generator" content="makeinfo 4.6">
<!--
Copyright &copy; 2000, 2001, 2002, 2003, 2005 Free Software Foundation, Inc.
@ -35,7 +35,7 @@ texts being (a) (see below), and with the Back-Cover Texts being (b)
--></style>
</head>
<body>
<h1 class="settitle">Porting libstdc++-v3</h1>
<h1 class="settitle">Porting libstdc++</h1>
<div class="node">
<p><hr>
Node:&nbsp;<a name="Top">Top</a>,
@ -44,14 +44,14 @@ Up:&nbsp;<a rel="up" accesskey="u" href="#dir">(dir)</a>
<br>
</div>
<h2 class="unnumbered">Porting libstdc++-v3</h2>
<h2 class="unnumbered">Porting libstdc++</h2>
<p>This document explains how to port libstdc++-v3 (the GNU C++ library) to
<p>This document explains how to port libstdc++ (the GNU C++ library) to
a new target.
<p>In order to make the GNU C++ library (libstdc++-v3) work with a new
<p>In order to make the GNU C++ library (libstdc++) work with a new
target, you must edit some configuration files and provide some new
header files. Unless this is done, libstdc++-v3 will use generic
header files. Unless this is done, libstdc++ will use generic
settings which may not be correct for your target; even if they are
correct, they will likely be inefficient.
@ -115,7 +115,7 @@ OS portion of the triplet (the default), then nothing needs to be changed.
<code>os_defines.h</code>. This file contains basic macro definitions
that are required to allow the C++ library to work with your C library.
<p>Several libstdc++-v3 source files unconditionally define the macro
<p>Several libstdc++ source files unconditionally define the macro
<code>_POSIX_SOURCE</code>. On many systems, defining this macro causes
large portions of the C library header files to be eliminated
at preprocessing time. Therefore, you may have to <code>#undef</code> this
@ -130,7 +130,7 @@ need to define. You will need to add them to the
target. It will not work to simply define these macros in
<code>os_defines.h</code>.
<p>At this time, there are a few libstdc++-v3-specific macros which may be
<p>At this time, there are a few libstdc++-specific macros which may be
defined:
<p><code>_GLIBCXX_USE_C99_CHECK</code> may be defined to 1 to check C99
@ -233,7 +233,7 @@ character classification, analogous to that provided by the C libraries
certainly need some modification.
<p>The first file to write is <code>ctype_base.h</code>. This file provides
some very basic information about character classification. The libstdc++-v3
some very basic information about character classification. The libstdc++
library assumes that your C library implements <code>&lt;ctype.h&gt;</code> by using
a table (indexed by character code) containing integers, where each of
these integers is a bit-mask indicating whether the character is
@ -530,7 +530,7 @@ Explaining the full workings of libtool is beyond the scope of this
document, but there are a few, particular bits that are necessary for
porting.
<p>Some parts of the libstdc++-v3 library are compiled with the libtool
<p>Some parts of the libstdc++ library are compiled with the libtool
<code>--tags CXX</code> option (the C++ definitions for libtool). Therefore,
<code>ltcf-cxx.sh</code> in the top-level directory needs to have the correct
logic to compile and archive objects equivalent to the C version of libtool,
@ -542,7 +542,7 @@ run as the library is loaded. Often, that requires linking in special
object files when the C++ library is built as a shared library, or
taking other system-specific actions.
<p>The libstdc++-v3 library is linked with the C version of libtool, even
<p>The libstdc++ library is linked with the C version of libtool, even
though it is a C++ library. Therefore, the C version of libtool needs to
ensure that the run-time library initializers are run. The usual way to
do this is to build the library using <code>gcc -shared</code>.
@ -974,7 +974,7 @@ to permit their use in free software.
<div class="contents">
<h2>Table of Contents</h2>
<ul>
<li><a name="toc_Top" href="#Top">Porting libstdc++-v3</a>
<li><a name="toc_Top" href="#Top">Porting libstdc++</a>
<li><a name="toc_Operating%20system" href="#Operating%20system">Operating system</a>
<li><a name="toc_CPU" href="#CPU">CPU</a>
<li><a name="toc_Character%20types" href="#Character%20types">Character types</a>

View File

@ -2102,7 +2102,7 @@ release.
<td>done</td>
<td></td>
<td></td>
<td>C library responsability</td>
<td>C library responsibility</td>
</tr>
<tr>
<td>8.24.4</td>
@ -2182,7 +2182,7 @@ release.
<td>done</td>
<td></td>
<td></td>
<td>C library responsability</td>
<td>C library responsibility</td>
</tr>
<tr>
<td>8.30</td>
@ -2214,7 +2214,7 @@ release.
<td>done</td>
<td></td>
<td></td>
<td>C library responsability</td>
<td>C library responsibility</td>
</tr>
<tr>
<td>8.31</td>

View File

@ -10,7 +10,7 @@
<meta name="KEYWORDS" content="HOWTO, libstdc++, GCC, g++, libg++, STL" />
<meta name="DESCRIPTION" content="HOWTO for the libstdc++ chapter 18." />
<meta name="GENERATOR" content="vi and eight fingers" />
<title>libstdc++-v3 HOWTO: Chapter 18: Library Support</title>
<title>libstdc++ HOWTO: Chapter 18: Library Support</title>
<link rel="StyleSheet" href="../lib3styles.css" type="text/css" />
<link rel="Start" href="../documentation.html" type="text/html"
title="GNU C++ Standard Library" />

View File

@ -10,7 +10,7 @@
<meta name="KEYWORDS" content="HOWTO, libstdc++, GCC, g++, libg++, STL" />
<meta name="DESCRIPTION" content="HOWTO for the libstdc++ chapter 19." />
<meta name="GENERATOR" content="vi and eight fingers" />
<title>libstdc++-v3 HOWTO: Chapter 19: Diagnostics</title>
<title>libstdc++ HOWTO: Chapter 19: Diagnostics</title>
<link rel="StyleSheet" href="../lib3styles.css" type="text/css" />
<link rel="Start" href="../documentation.html" type="text/html"
title="GNU C++ Standard Library" />
@ -36,7 +36,6 @@
<h1>Contents</h1>
<ul>
<li><a href="#1">Adding data to exceptions</a></li>
<li><a href="#2">Exception class hierarchy diagram</a></li>
<li><a href="#3">Concept checkers -- <strong>new and improved!</strong></a></li>
</ul>
@ -67,22 +66,6 @@
<a href="../faq/index.html">to the FAQ</a>.
</p>
<hr />
<h2><a name="2">Exception class hierarchy diagram</a></h2>
<p>At one point we were going to make up a PDF of the exceptions
hierarchy, akin to the one done for the I/O class hierarchy.
Time was our enemy. Since then we've moved to Doxygen, which has
the useful property of not sucking. Specifically, when the source
code is changed, the diagrams are automatically brought up to date.
For the old way, we had to update the diagrams separately.
</p>
<p>There are several links to the Doxygen-generated pages from
<a href="../documentation.html">here</a>.
</p>
<p>Return <a href="#top">to top of page</a> or
<a href="../faq/index.html">to the FAQ</a>.
</p>
<hr />
<h2><a name="3">Concept checkers -- <strong>new and improved!</strong></a></h2>
<p>Better taste! Less fat! Literally!</p>
@ -119,6 +102,13 @@
(or with <code>#define _GLIBCPP_CONCEPT_CHECKS</code> for versions
3.1, 3.2 and 3.3).
</p>
<p>Please note that the upcoming C++ standard has first-class
support for template parameter constraints based on concepts in the core
language. This will obviate the need for the library-simulated concept
checking described above.
</p>
<p>Return <a href="#top">to top of page</a> or
<a href="../faq/index.html">to the FAQ</a>.
</p>

View File

@ -28,14 +28,16 @@
</em></p>
<p><em>
To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++-v3 homepage</a>.
To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++ homepage</a>.
</em></p>
<!-- ####################################################### -->
<hr />
<p> The C++ Standard encapsulates memory management characteristics
for strings, container classes, and parts of iostreams in a
template class called <code>std::allocator</code>.
template class called <code>std::allocator</code>. This class, and
base classes of it, are the superset of available free store
(&quot;heap&quot;) management classes.
</p>
<h3 class="left">
@ -100,7 +102,7 @@
<p>What about threads? No problem: in a threadsafe environment, the
memory pool is manipulated atomically, so you can grow a container in
one thread and shrink it in another, etc. <strong>BUT</strong> what
if threads in libstdc++-v3 aren't set up properly?
if threads in libstdc++ aren't set up properly?
<a href="../faq/index.html#5_6">That's been answered already</a>.
</p>
<p><strong>BUT</strong> what if you want to use your own allocator? What

View File

@ -10,7 +10,7 @@
<meta name="KEYWORDS" content="HOWTO, libstdc++, GCC, g++, libg++, STL" />
<meta name="DESCRIPTION" content="HOWTO for the libstdc++ chapter 20." />
<meta name="GENERATOR" content="vi and eight fingers" />
<title>libstdc++-v3 HOWTO: Chapter 20: General Utilities</title>
<title>libstdc++ HOWTO: Chapter 20: General Utilities</title>
<link rel="StyleSheet" href="../lib3styles.css" type="text/css" />
<link rel="Start" href="../documentation.html" type="text/html"
title="GNU C++ Standard Library" />
@ -214,15 +214,7 @@
<pre>
pair&lt;int,MyClass&gt; p = make_pair(4,myobject);
</pre>
<p>Return <a href="#top">to top of page</a> or
<a href="../faq/index.html">to the FAQ</a>.
</p>
<hr />
<h2><a name="5">Memory allocators</a></h2>
<p>The available free store (&quot;heap&quot;) management classes are
described <a href="allocator.html">here</a>.
</p>
<p>Return <a href="#top">to top of page</a> or
<a href="../faq/index.html">to the FAQ</a>.
</p>

View File

@ -10,7 +10,7 @@
<meta name="KEYWORDS" content="HOWTO, libstdc++, GCC, g++, libg++, STL" />
<meta name="DESCRIPTION" content="HOWTO for the libstdc++ chapter 21." />
<meta name="GENERATOR" content="vi and eight fingers" />
<title>libstdc++-v3 HOWTO: Chapter 21: Strings</title>
<title>libstdc++ HOWTO: Chapter 21: Strings</title>
<link rel="StyleSheet" href="../lib3styles.css" type="text/css" />
<link rel="Start" href="../documentation.html" type="text/html"
title="GNU C++ Standard Library" />
@ -141,10 +141,10 @@
<em>if the implementors do it correctly</em>. The libstdc++
implementors did it correctly. Other vendors might not.
</li>
<li>While parts of the SGI STL are used in libstdc++-v3, their
<li>While parts of the SGI STL are used in libstdc++, their
string class is not. The SGI <code>string</code> is essentially
<code>vector&lt;char&gt;</code> and does not do any reference
counting like libstdc++-v3's does. (It is O(n), though.)
counting like libstdc++'s does. (It is O(n), though.)
So if you're thinking about SGI's string or rope classes,
you're now looking at four possibilities: CString, the
libstdc++ string, the SGI string, and the SGI rope, and this

View File

@ -37,7 +37,7 @@ attempts to detail conversions between the implementation-defined wide
characters (hereafter referred to as wchar_t) and the standard type
char that is so beloved in classic &quot;C&quot; (which can now be referred to
as narrow characters.) This document attempts to describe how the GNU
libstdc++-v3 implementation deals with the conversion between wide and
libstdc++ implementation deals with the conversion between wide and
narrow characters, and also presents a framework for dealing with the
huge number of other encodings that iconv can convert, including
Unicode and UTF8. Design issues and requirements are addressed, and
@ -274,7 +274,7 @@ multiple locales is fundamental. In practice, most users may not run
into this limitation. However, as a quality of implementation issue,
the GNU C++ library would like to offer a solution that allows
multiple locales and or simultaneous usage with computationally
correct results. In short, libstdc++-v3 is trying to offer, as an
correct results. In short, libstdc++ is trying to offer, as an
option, a high-quality implementation, damn the additional complexity!
</p>
@ -314,7 +314,7 @@ to wchar_t and wcsrtombs for conversions between wchar_t and char.
<p>
Neither of these two required specializations deals with Unicode
characters. As such, libstdc++-v3 implements a partial specialization
characters. As such, libstdc++ implements a partial specialization
of the codecvt class with and iconv wrapper class, encoding_state as the
third template parameter.
</p>

View File

@ -76,7 +76,7 @@ to wchar_t and wcsrtombs for conversions between wchar_t and char.
<p>
Neither of these two required specializations deals with Unicode
characters. As such, libstdc++-v3 implements
characters. As such, libstdc++ implements
</p>
<h2>

View File

@ -10,7 +10,7 @@
<meta name="KEYWORDS" content="HOWTO, libstdc++, GCC, g++, libg++, STL" />
<meta name="DESCRIPTION" content="HOWTO for the libstdc++ chapter 22." />
<meta name="GENERATOR" content="vi and eight fingers" />
<title>libstdc++-v3 HOWTO: Chapter 22: Localization</title>
<title>libstdc++ HOWTO: Chapter 22: Localization</title>
<link rel="StyleSheet" href="../lib3styles.css" type="text/css" />
<link rel="Start" href="../documentation.html" type="text/html"
title="GNU C++ Standard Library" />
@ -75,7 +75,7 @@
wide characters (hereafter referred to as wchar_t) and the standard
type char that is so beloved in classic &quot;C&quot; (which can
now be referred to as narrow characters.) This document attempts
to describe how the GNU libstdc++-v3 implementation deals with the
to describe how the GNU libstdc++ implementation deals with the
conversion between wide and narrow characters, and also presents a
framework for dealing with the huge number of other encodings that
iconv can convert, including Unicode and UTF8. Design issues and

View File

@ -267,10 +267,10 @@ documentation. Here's an idea of what is required:
<li> Copy the binary files into the correct directory structure.
<p>
<code>cp fr_FR.mo (dir)/fr_FR/LC_MESSAGES/libstdc++-v3.mo</code>
<code>cp fr_FR.mo (dir)/fr_FR/LC_MESSAGES/libstdc++.mo</code>
</p>
<p>
<code>cp de_DE.mo (dir)/de_DE/LC_MESSAGES/libstdc++-v3.mo</code>
<code>cp de_DE.mo (dir)/de_DE/LC_MESSAGES/libstdc++.mo</code>
</p>
</li>
@ -302,7 +302,7 @@ void test01()
{
typedef messages&lt;char&gt;::catalog catalog;
const char* dir =
"/mnt/egcs/build/i686-pc-linux-gnu/libstdc++-v3/po/share/locale";
"/mnt/egcs/build/i686-pc-linux-gnu/libstdc++/po/share/locale";
const locale loc_de("de_DE");
const messages&lt;char&gt;&amp; mssg_de = use_facet&lt;messages&lt;char&gt; &gt;(loc_de);

View File

@ -10,7 +10,7 @@
<meta name="KEYWORDS" content="HOWTO, libstdc++, GCC, g++, libg++, STL" />
<meta name="DESCRIPTION" content="HOWTO for the libstdc++ chapter 23." />
<meta name="GENERATOR" content="vi and eight fingers" />
<title>libstdc++-v3 HOWTO: Chapter 23: Containers</title>
<title>libstdc++ HOWTO: Chapter 23: Containers</title>
<link rel="StyleSheet" href="../lib3styles.css" type="text/css" />
<link rel="Start" href="../documentation.html" type="text/html"
title="GNU C++ Standard Library" />
@ -200,7 +200,7 @@
along the lines of the third category, the author would love to hear
from you...
</p>
<p>Also note that the implementation of bitset used in libstdc++-v3 has
<p>Also note that the implementation of bitset used in libstdc++ has
<a href="../ext/sgiexts.html#ch23">some extensions</a>.
</p>
<p>Return <a href="#top">to top of page</a> or
@ -230,7 +230,7 @@
<p><em>However, please ignore all discussions about the user-level
configuration of the lock implementation inside the STL
container-memory allocator on those pages. For the sake of this
discussion, libstdc++-v3 configures the SGI STL implementation,
discussion, libstdc++ configures the SGI STL implementation,
not you. This is quite different from how gcc pre-3.0 worked.
In particular, past advice was for people using g++ to
explicitly define _PTHREADS or other macros or port-specific
@ -239,7 +239,7 @@
longer be done unless you really know what you are doing and
assume all responsibility.</em>
</p>
<p>Since the container implementation of libstdc++-v3 uses the SGI
<p>Since the container implementation of libstdc++ uses the SGI
code, we use the same definition of thread safety as SGI when
discussing design. A key point that beginners may miss is the
fourth major paragraph of the first page mentioned above
@ -248,7 +248,7 @@
client code (that'd be you, not us). There is a notable
exceptions to this rule. Allocators called while a container or
element is constructed uses an internal lock obtained and
released solely within libstdc++-v3 code (in fact, this is the
released solely within libstdc++ code (in fact, this is the
reason STL requires any knowledge of the thread configuration).
</p>
<p>For implementing a container which does its own locking, it is
@ -290,7 +290,7 @@
addresses this topic, but I will ignore it here because it is not yet
finalized.)
</p>
<p>Here we'll describe how the hinting works in the libstdc++-v3
<p>Here we'll describe how the hinting works in the libstdc++
implementation, and what you need to do in order to take advantage of
it. (Insertions can change from logarithmic complexity to amortized
constant time, if the hint is properly used.) Also, since the current

View File

@ -10,7 +10,7 @@
<meta name="KEYWORDS" content="HOWTO, libstdc++, GCC, g++, libg++, STL" />
<meta name="DESCRIPTION" content="HOWTO for the libstdc++ chapter 24." />
<meta name="GENERATOR" content="vi and eight fingers" />
<title>libstdc++-v3 HOWTO: Chapter 24: Iterators</title>
<title>libstdc++ HOWTO: Chapter 24: Iterators</title>
<link rel="StyleSheet" href="../lib3styles.css" type="text/css" />
<link rel="Start" href="../documentation.html" type="text/html"
title="GNU C++ Standard Library" />
@ -45,7 +45,7 @@
<h2><a name="1">They ain't pointers!</a></h2>
<p><a href="../faq/index.html#5_1">FAQ 5.1</a> points out that iterators
are not implemented as pointers. They are a generalization of
pointers, but they are implemented in libstdc++-v3 as separate classes.
pointers, but they are implemented in libstdc++ as separate classes.
</p>
<p>Keeping that simple fact in mind as you design your code will
prevent a whole lot of difficult-to-understand bugs.

View File

@ -10,7 +10,7 @@
<meta name="KEYWORDS" content="HOWTO, libstdc++, GCC, g++, libg++, STL" />
<meta name="DESCRIPTION" content="HOWTO for the libstdc++ chapter 25." />
<meta name="GENERATOR" content="vi and eight fingers" />
<title>libstdc++-v3 HOWTO: Chapter 25: Algorithms</title>
<title>libstdc++ HOWTO: Chapter 25: Algorithms</title>
<link rel="StyleSheet" href="../lib3styles.css" type="text/css" />
<link rel="Start" href="../documentation.html" type="text/html"
title="GNU C++ Standard Library" />

View File

@ -10,7 +10,7 @@
<meta name="KEYWORDS" content="HOWTO, libstdc++, GCC, g++, libg++, STL" />
<meta name="DESCRIPTION" content="HOWTO for the libstdc++ chapter 26." />
<meta name="GENERATOR" content="vi and eight fingers" />
<title>libstdc++-v3 HOWTO: Chapter 26: Numerics</title>
<title>libstdc++ HOWTO: Chapter 26: Numerics</title>
<link rel="StyleSheet" href="../lib3styles.css" type="text/css" />
<link rel="Start" href="../documentation.html" type="text/html"
title="GNU C++ Standard Library" />
@ -144,7 +144,7 @@
<hr />
<h2><a name="4">C99</a></h2>
<p>In addition to the other topics on this page, we'll note here some
of the C99 features that appear in libstdc++-v3.
of the C99 features that appear in libstdc++.
</p>
<p>The C99 features depend on the <code>--enable-c99</code> configure flag.
This flag is already on by default, but it can be disabled by the

View File

@ -10,7 +10,7 @@
<meta name="KEYWORDS" content="HOWTO, libstdc++, GCC, g++, libg++, STL" />
<meta name="DESCRIPTION" content="HOWTO for the libstdc++ chapter 27." />
<meta name="GENERATOR" content="vi and eight fingers" />
<title>libstdc++-v3 HOWTO: Chapter 27: Input/Output</title>
<title>libstdc++ HOWTO: Chapter 27: Input/Output</title>
<link rel="StyleSheet" href="../lib3styles.css" type="text/css" />
<link rel="Start" href="../documentation.html" type="text/html"
title="GNU C++ Standard Library" />
@ -458,7 +458,7 @@
<p>The special steps taken by libstdc++, at least for version 3.0,
involve doing very little buffering for the standard streams, leaving
most of the buffering to the underlying C library. (This kind of
thing is <a href="../explanations.html#cstdio">tricky to get right</a>.)
thing is tricky to get right.)
The upside is that correctness is ensured. The downside is that
writing through <code>cout</code> can quite easily lead to awful
performance when the C++ I/O library is layered on top of the C I/O
@ -501,7 +501,7 @@
<p>This gets a bit tricky. Please read carefully, and bear with me.
</p>
<h3>Structure</h3>
<p>As described <a href="../explanations.html#cstdio">here</a>, a wrapper
<p>A wrapper
type called <code>__basic_file</code> provides our abstraction layer
for the <code>std::filebuf</code> classes. Nearly all decisions dealing
with actual input and output must be made in <code>__basic_file</code>.
@ -539,8 +539,8 @@
like any other critical shared resource.
</p>
<h3>The future</h3>
<p>As already mentioned <a href="../explanations.html#cstdio">here</a>, a
second choice is available for I/O implementations: libio. This is
<p> A
second choice may be available for I/O implementations: libio. This is
disabled by default, and in fact will not currently work due to other
issues. It will be revisited, however.
</p>
@ -713,7 +713,7 @@
<p>The v2 library included non-standard extensions to construct
<code>std::filebuf</code>s from C stdio types such as
<code>FILE*</code>s and POSIX file descriptors.
Today the recommended way to use stdio types with libstdc++-v3
Today the recommended way to use stdio types with libstdc++
IOStreams is via the <code>stdio_filebuf</code> class (see below),
but earlier releases provided slightly different mechanisms.
</p>

View File

@ -1,37 +0,0 @@
PWD_COMMAND=$${PWDCMD-pwd}
MAKEINFO=makeinfo
INC=../../../gcc/doc/include
all: documentation.html \
faq/index.txt \
17_intro/confdeps.png \
17_intro/porting.html \
17_intro/porting-howto.html
# chock full of GNUism, probably
documentation.html: $(wildcard */howto.html)
sed -n '1,/beginlist/p' $@ > tmp.top
sed -n '/endlist/,$$p' $@ > tmp.bottom
echo ' <ul>' > tmp.middle
for i in [0-9]*/howto.html; do \
title=`grep 'h1 ' $$i |\
sed 's=.*\(Chapter [[:digit:]]*\):[[:space:]]*\(.*\)</a>.*=\2 (\1)='` ;\
awk -v file=$$i -v "title=$$title" -f makedoc.awk $$i >> tmp.middle ;\
done
awk -v file=ext/howto.html -v "title=Extensions to the Standard Library"\
-f makedoc.awk ext/howto.html >> tmp.middle ;\
echo ' </ul>' >> tmp.middle
cat tmp.top tmp.middle tmp.bottom > $@
rm tmp.top tmp.middle tmp.bottom
faq/index.txt: faq/index.html
lynx -dump $< | sed "s%file://localhost`${PWD_COMMAND}`%..%" > $@
17_intro/porting.html: 17_intro/porting.texi
${MAKEINFO} -I ${INC} --html --no-split $< -o $@
17_intro/confdeps.png: 17_intro/confdeps.dot
dot -Tpng -o $@ $<
# vim:noet ts=4

View File

@ -6,10 +6,10 @@
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
<meta name="KEYWORDS" content="libstdc++, libstdc++-v3, GCC, g++" />
<meta name="DESCRIPTION" content="Configuration options for libstdc++-v3." />
<meta name="KEYWORDS" content="libstdc++, libstdc++, GCC, g++" />
<meta name="DESCRIPTION" content="Configuration options for libstdc++." />
<meta name="GENERATOR" content="vi and eight fingers" />
<title>libstdc++-v3 configure options</title>
<title>libstdc++ configure options</title>
<link rel="StyleSheet" href="lib3styles.css" type="text/css" />
<link rel="Copyright" href="17_intro/license.html" type="text/html" />
</head>
@ -25,7 +25,7 @@ options</a></h1>
</em></p>
<p><em>
To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++-v3 homepage</a>.
To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++ homepage</a>.
</em></p>
<!-- ####################################################### -->
@ -94,8 +94,7 @@ options</a></h1>
<dt><code>--enable-cstdio=OPTION </code></dt>
<dd><p>Select a target-specific I/O package. At the moment, the only
choice is to use 'stdio', a generic &quot;C&quot; abstraction.
The default is 'stdio'. A longer explanation is <a
href="explanations.html#cstdio">here</a>.
The default is 'stdio'.
</p>
</dd>

View File

@ -24,7 +24,7 @@
</em></p>
<p><em>
To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++-v3 homepage</a>.
To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++ homepage</a>.
</em></p>
<!-- ####################################################### -->

View File

@ -6,100 +6,33 @@
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta name="KEYWORDS"
content="libstdc++, homepage, home, C++, library, c++, std, g++, ABI, STL" />
<title>GNU C++ Standard Library</title>
content="libstdc++, homepage, home, C++, library, c++, std, g++, STL" />
<title>The GNU C++ Library</title>
<link rel="StyleSheet" href="lib3styles.css" type="text/css" />
<link rel="Copyright" href="17_intro/license.html" type="text/html" />
<link rel="Help" href="faq/index.html" type="text/html" title="F.A.Q." />
</head>
<body>
<h1>The GNU C++ Library</h1>
<p><strong>All of these documents</strong> (in fact, this entire homepage set)
are bundled with the library source, under the <code>docs</code>
subdirectory, for releases and snapshots. The sole exception is the
automatically-generated source documentation, available separately.
<h2><a name="3">Table of Contents</a></h2>
<p>
The GNU Standard C++ Library is an ongoing <a
href="http://gcc.gnu.org/libstdc++">project</a> to implement the ISO
14882 Standard C++ library as described in chapters 17 through 27 and
annex D, extensions as described by TR1, and future C++ library
standards still in progress. For those who want to see exactly how far
the project has come, or just want the latest bleeding-edge code, the
up-to-date source is always publically available over anonymous SVN,
and can be browsed over the <a
href="http://gcc.gnu.org/svn.html">web</a>.
</p>
<hr />
<br />
<h2><a name="1">Introduction</a></h2>
<p>This is a short list of text files pertaining to this implementation of
ISO 14882. A brief description may follow the name of the file.
</p>
<ul>
<li><a href="17_intro/COPYING">License</a>
- GPL v2 license terms</li>
<li><a href="abi.html">ABI Policy and Guidelines</a></li>
<li><a href="17_intro/BUGS">BUGS</a></li>
<li><a href="17_intro/PROBLEMS">PROBLEMS</a>
- target-specific known issues</li>
<!-- Linking to "../README" doesn't work; we are at the top level
of the web pages. Punt. -->
<li>README - directory structure</li>
<li><a href="17_intro/RELEASE-NOTES">RELEASE-NOTES</a>
- latest version info, recent changes and news</li>
<li><a href="17_intro/TODO">TODO</a>
- tasks yet undone</li>
<li><a href="faq/index.html">FAQ (HTML)</a>,
<a href="faq/index.txt">FAQ (text)</a></li>
</ul>
<hr />
<br />
<h2><a name="2">Configuring, Building, Testing, Installing</a></h2>
<ul>
<li><a href="configopts.html">Configure options</a></li>
<li><a href="install.html">Getting started: configure, build, install</a>
</li>
<li><a href="test.html">Testing details</a></li>
<li><a href="debug.html">Debugging schemes and strategies</a>
</li>
</ul>
<hr />
<br />
<h2><a name="4">Source-Level Documentation</a></h2>
<p>The library sources have been specially formatted so that with the
proper invocation of another tool (Doxygen), a set of HTML pages
are generated from the sources files themselves. The resultant
documentation is referred to as Source-Level Documentation, and is
useful for examining the signatures of public member functions for
the library classes, finding out what is in a particular include
file, looking at inheritance diagrams, etc.
</p>
<p>The source-level documentation for the most recent releases can
be viewed online:
</p>
<ul>
<li><a href="libstdc++-html-USERS-3.4/index.html">for the 3.4 release</a></li>
<li><a href="latest-doxygen/index.html">&quot;the latest collection&quot;</a>
(for the main development tree; see the date on the first page)
</li>
</ul>
<p>This generated HTML collection, as above, is also available for download in
the libstdc++ snapshots directory at
<code>&lt;URL:ftp://gcc.gnu.org/pub/gcc/libstdc++/doxygen/&gt;</code>.
You will almost certainly need to use one of the
<a href="http://gcc.gnu.org/mirrors.html">mirror sites</a> to download
the tarball. After unpacking, simply load libstdc++-html-*/index.html
into a browser.
</p>
<p>Documentation for older releases is available for download only, not
online viewing.
</p>
<p>In addition, an initial set of man pages are also available in the
same place as the HTML collections. Start with C++Intro(3).
</p>
<hr />
<br />
<h2><a name="3">Chapter-Specific Documentation</a></h2>
<p>Information, extensions, notes and advice on specific implementation
capabilites and/or liabilities broken down into chapter names based on the
C++ standard.
<p>Stable versions of libstdc++ are included with releases of
<a href="http://gcc.gnu.org/releases.html">the GCC compilers</a>.
</p>
<!--
The list below is automatically generated. To make changes in the text,
@ -109,96 +42,153 @@
-->
<!-- beginlist -->
<ul>
<li>Library Introduction (Chapter 17)
<li>Introduction
<ul>
<li><a href="17_intro/howto.html#2">The Standard C++ header files</a></li>
<li><a href="17_intro/howto.html#3">The Standard C++ library and multithreading</a></li>
<li><a href="17_intro/howto.html#4"><code>&lt;foo&gt;</code> vs <code>&lt;foo.h&gt;</code></a></li>
<li><a href="17_intro/porting-howto.html">Porting HOWTO</a></li>
<li><a href="17_intro/howto.html#5">Behavior specific to libstdc++-v3</a></li>
<li><a href="17_intro/howto.html#6">Preprocessor macros controlling the library</a></li>
<li> Status
<ul>
<li>Implementation Status
<ul>
<li><a href="17_intro/c++1998_status.html">C++1998</a>,
including <a href="17_intro/howto.html#5">implementation-defined behavior</a> and <a href="ext/howto.html#5">LWG issues</a> </li>
<li><a href="17_intro/tr1_status.html">C++TR1</a></li>
<li><a href="17_intro/c++0x_status.html">C++0x</a></li>
<li>Extensions</li>
</ul>
</li>
<li><a href="17_intro/license.html">License</a></li>
<li><a href="http://gcc.gnu.org/bugzilla/buglist.cgi?cmdtype=runnamed&namedcmd=libstdc%2B%2B">Known Bugs</a></li>
</ul>
</li>
<li> Configuring, Building, Testing, Installing
<ul>
<li><a href="install.html">Getting started: configure, build, install</a>
</li>
<li><a href="configopts.html">Configure options</a></li>
<li><a href="test.html">Testing details</a></li>
</li>
</ul>
</li>
<li> Using the Library
<ul>
<li>Header Files</li>
<ul>
<li><a href="17_intro/howto.html#2.1">Available headers</a></li>
<li><a href="17_intro/howto.html#2.2">Headers and <code>namespace std</code></a></li>
<li>Pre-compiled headers</li>
</ul>
<li>Namespaces</li>
<ul>
<li><a href="17_intro/howto.html#2.5">Namespace <code>std::</code></a></li>
<li><a href="17_intro/howto.html#2.6">Using namespace composition</a></li>
</ul>
<li><a href="17_intro/howto.html#6">Macros</a></li>
<li>Concurrency</li>
<ul>
<li>Atomic Operations</li>
<li><a href="17_intro/howto.html#3">Thread safety overview</a></li>
<li><a href="faq/index.html#5_6">Is it thread safe?</li>
<li><a href="23_containers/howto.html#3">Containers</a></li>
<li><a href="27_io/howto.html#9">IO</a></li>
</ul>
<li>Exception safety</li>
<li><a href="debug.html">Debugging support</a>
</ul>
</li>
</ul>
</li>
<li>Library Support (Chapter 18)
<li>Support
<ul>
<li><a href="18_support/howto.html#1">Types</a></li>
<li><a href="18_support/howto.html#2">Implementation properties</a></li>
<li><a href="18_support/howto.html#2">Implementation properties of builtin types</a></li>
<li><a href="18_support/howto.html#3">Start and Termination</a></li>
<li><a href="18_support/howto.html#4">Verbose <code>terminate</code></a></li>
<li><a href="18_support/howto.html#5">Dynamic memory management</a></li>
<li><a href="18_support/howto.html#6">RTTI, the ABI, and demangling</a></li>
</ul>
</li>
<li>Diagnostics (Chapter 19)
<li>Diagnostics
<ul>
<li>Exception class hierarchy</li>
<li><a href="19_diagnostics/howto.html#1">Adding data to exceptions</a></li>
<li><a href="19_diagnostics/howto.html#2">Exception class hierarchy diagram</a></li>
<li><a href="19_diagnostics/howto.html#3">Concept checkers -- <strong>new and improved!</strong></a></li>
<li><a href="19_diagnostics/howto.html#3">Concept checking</a></li>
</ul>
</li>
<li>General Utilities (Chapter 20)
<li>General Utilities
<ul>
<li><a href="20_util/howto.html#1"><code>auto_ptr</code> is not omnipotent</a></li>
<li><a href="20_util/howto.html#2"><code>auto_ptr</code> inside container classes</a></li>
<li><a href="20_util/howto.html#3">Functors</a></li>
<li><a href="20_util/howto.html#4">Pairs</a></li>
<li><a href="20_util/howto.html#5">Memory allocators</a></li>
<li>Memory</li>
<ul>
<li><a href="20_util/allocator.html">allocator</a></li>
<li>auto_ptr</li>
<ul>
<li><a href="20_util/howto.html#1"><code>auto_ptr</code> is not omnipotent</a></li>
<li><a href="20_util/howto.html#2"><code>auto_ptr</code> inside container classes</a></li>
</ul>
</ul>
</ul>
</li>
<li>Strings (Chapter 21)
<li>Strings
<ul>
<li><a href="21_strings/howto.html#1">MFC's CString</a></li>
<li><a href="21_strings/howto.html#2">A case-insensitive string class</a></li>
<li><a href="21_strings/howto.html#3">Breaking a C++ string into tokens</a></li>
<li><a href="21_strings/howto.html#4">Simple transformations</a></li>
<li><a href="21_strings/howto.html#5">Making strings of arbitrary character types</a></li>
<li><a href="21_strings/howto.html#6">Shrink-to-fit strings</a></li>
<li><a href="21_strings/howto.html#1">MFC's CString</a></li>
</ul>
</li>
<li>Localization (Chapter 22)
<li>Localization
<ul>
<li><a href="22_locale/howto.html#1">class locale</a></li>
<li><a href="22_locale/howto.html#2">class codecvt</a></li>
<li><a href="22_locale/howto.html#3">class ctype</a></li>
<li><a href="22_locale/howto.html#4">class messages</a></li>
<li><a href="22_locale/howto.html#5">Bjarne Stroustrup on Locales</a></li>
<li><a href="22_locale/howto.html#6">Nathan Myers on Locales</a></li>
<li><a href="22_locale/howto.html#7">Correct Transformations</a></li>
<li><a href="22_locale/howto.html#4">class messages</a></li>
</ul>
</li>
<li>Containers (Chapter 23)
<li>Containers
<ul>
<li><a href="23_containers/howto.html#1">Making code unaware of the container/array difference</a></li>
<li><a href="23_containers/howto.html#2">Variable-sized bitmasks</a></li>
<li><a href="23_containers/howto.html#3">Containers and multithreading</a></li>
<li><a href="23_containers/howto.html#4">&quot;Hinting&quot; during insertion</a></li>
<li><a href="23_containers/howto.html#5">Bitmasks and string arguments</a></li>
<li><a href="23_containers/howto.html#6"><code>std::list::size()</code> is O(n)!</a></li>
<li><a href="23_containers/howto.html#7">Space overhead management for vectors</a></li>
<li><a href="23_containers/howto.html#2">Variable-sized bitmasks</a></li>
<li><a href="23_containers/howto.html#5">Bitmasks and string arguments</a></li>
</ul>
</li>
<li>Iterators (Chapter 24)
<li>Iterators
<ul>
<li><a href="24_iterators/howto.html#1">They ain't pointers!</a></li>
<li><a href="24_iterators/howto.html#2">It ends <em>where?</em></a></li>
</ul>
</li>
<li>Algorithms (Chapter 25)
<li>Algorithms
<ul>
<li><a href="25_algorithms/howto.html#1">Prerequisites</a></li>
<li><a href="25_algorithms/howto.html#2">Special <code>swap</code>s</a></li>
<li><a href="25_algorithms/howto.html#2">Specializations for <code>swap</code></a></li>
</ul>
</li>
<li>Numerics (Chapter 26)
<li>Numerics
<ul>
<li><a href="26_numerics/howto.html#1">Complex Number Processing</a></li>
<li><a href="26_numerics/howto.html#2">Array Processing</a></li>
@ -207,7 +197,7 @@
</ul>
</li>
<li>Input/Output (Chapter 27)
<li>Input/Output
<ul>
<li><a href="27_io/howto.html#1">Copying a file</a></li>
<li><a href="27_io/howto.html#2">The buffering is screwing up my program!</a></li>
@ -227,43 +217,117 @@
<li><a href="ext/howto.html#4">Compile-time checks</a></li>
<li><a href="debug_mode.html">Debug mode</a></li>
<li><a href="parallel_mode.html">Parallel mode</a></li>
<li><a href="ext/pb_ds/index.html">Policy Based Data Structures</a></li>
<li><a href="ext/howto.html#1">Ropes and trees and hashes, oh my!</a></li>
<li><a href="ext/howto.html#2">Added members and types</a></li>
<li> Allocators</li>
<ul>
<li><a href="ext/mt_allocator.html"><code>__mt_alloc</code> </a></li>
<li><a href="ext/howto.html#5">LWG Issues</a></li>
<li><a href="ext/ballocator_doc.html">Bitmap Allocator</a></li>
</ul>
<li> Containers </li>
<ul>
<li><a href="ext/pb_ds/index.html">Policy Based Data Structures</a></li>
<li><a href="ext/howto.html#1">Ropes and trees and hashes, oh my!</a></li>
</ul>
<li> Algorithms</li>
<ul>
<li><a href="ext/sgiexts.html">HP/SGI STL Extensions</a></li>
</ul>
<li> Input/Output</li>
<ul>
<li><a href="27_io/howto.html#11">Derived filebuf classes</a></li>
</ul>
<li><a href="ext/../18_support/howto.html#6">Demangling</a></li>
</ul>
</li>
<li>Appendix
<ul>
<li>A. <a name="5">Contributing and Maintenance</a></li>
<ul>
<li><a href="17_intro/contribute.html">Contributor checklist</a></li>
<li><a href="http://gcc.gnu.org/svnwrite.html">Getting write access
(look for &quot;Write after approval&quot;)</a></li>
<li><a href="17_intro/BADNAMES">BADNAMES</a>
- names to avoid because of potential collisions</li>
<li><a href="17_intro/C++STYLE">Coding style, by example</a></li>
<li> Doxygen markup style guide. In the source docs/doxygen directory, see guide.html. Here's the a link to the current <a href="http://gcc.gnu.org/viewcvs/*checkout*/trunk/libstdc%2B%2B-v3/docs/doxygen/guide.html?content-type=text%2Fplain">page</a>.
</li>
<li><a href="17_intro/DESIGN">DESIGN</a>
- overview of the implementation plan</li>
<li>Header policy, namespace map, API conventions</li>
</ul>
<li>B. Porting</li>
<ul>
<li><a href="17_intro/porting.html">Porting to new hardware or operating systems.</a></li>
<li><a href="17_intro/abi.html">ABI Policy and Guidelines</a></li>
<li><a href="17_intro/api.html">API Evolution and Deprecation History</a></li>
</ul>
<li>C. <a href="http://www.gnu.org/software/libc/manual/html_node/Free-Manuals.html#Free-Manuals">Free Software Needs Free Documentation </a>
</ul>
</li>
</ul>
<!-- endlist -->
<hr />
<br />
<h2><a name="5">Contributor-Specific Information</a></h2>
<h2><a name="4">Source-Level Documentation</a></h2>
<p>The library sources have been specially formatted so that with the
proper invocation of another tool (Doxygen), a set of HTML pages
are generated from the sources files themselves. The resultant
documentation is referred to as Source-Level Documentation, and is
useful for examining the signatures of public member functions for
the library classes, finding out what is in a particular include
file, looking at inheritance diagrams, etc.
</p>
<p>The source-level documentation for the most recent releases can
be viewed online:
</p>
<ul>
<li><a href="17_intro/contribute.html">Contributor checklist</a></li>
<li><a href="http://gcc.gnu.org/svnwrite.html">Getting SVN write access
(look for &quot;Write after approval&quot;)</a></li>
<li><a href="17_intro/BADNAMES">BADNAMES</a>
- names to avoid because of potential collisions</li>
<li><a href="17_intro/C++STYLE">C++STYLE</a>
- coding style by example</li>
<li> In the libstdc++-v3/docs/doxygen directory, see guide.html, a
doxygen markup style guide</li>
<li><a href="17_intro/CHECKLIST">CHECKLIST</a>
- a list of required features and their status.</li>
<li><a href="17_intro/DESIGN">DESIGN</a>
- overview of the implementation plan</li>
<li><a href="17_intro/HEADER_POLICY">HEADER_POLICY</a>
- header naming and sub-include structure</li>
<li><a href="libstdc++-html-USERS-3.4/index.html">for the 3.4 release</a></li>
<li><a href="libstdc++-html-USERS-4.1/index.html">for the 4.1 release</a></li>
<li><a href="libstdc++-html-USERS-4.2/index.html">for the 4.2 release</a></li>
<li><a href="latest-doxygen/index.html">&quot;the latest collection&quot;</a>
(for the main development tree; see the date on the first page)
</li>
</ul>
<p>This generated HTML collection, as above, is also available for download in
the libstdc++ snapshots directory at
<code>&lt;URL:ftp://gcc.gnu.org/pub/gcc/libstdc++/doxygen/&gt;</code>.
You will almost certainly need to use one of the
<a href="http://gcc.gnu.org/mirrors.html">mirror sites</a> to download
the tarball. After unpacking, simply load libstdc++-html-*/index.html
into a browser.
</p>
<p>Documentation for older releases is available for download only, not
online viewing.
</p>
<p>In addition, an initial set of man pages are also available in the
same place as the HTML collections. Start with C++Intro(3).
</p>
<hr />
<br />
<h2><a name="7"><a href="faq/index.html">Frequently Asked Questions</a></a></h2
<hr />
<br />
<p><strong>All of these documents</strong> (in fact, this entire homepage set)
are bundled with the library source, under the <code>docs</code>
subdirectory, for releases and snapshots. The sole exception is the
automatically-generated source documentation, available separately.
</p>
<!-- ####################################################### -->
<p>Return <a href="http://gcc.gnu.org/libstdc++/">to the libstdc++ homepage</a>.</p>
<hr />
<p class="fineprint"><em>
See <a href="17_intro/license.html">license.html</a> for copying conditions.

View File

@ -1,86 +0,0 @@
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
<meta name="KEYWORDS" content="libstdc++, libstdc++-v3, GCC, g++" />
<meta name="DESCRIPTION" content="Explanatory notes about libstdc++-v3." />
<meta name="GENERATOR" content="vi and eight fingers" />
<title>Explanatory notes about libstdc++-v3 design</title>
<link rel="StyleSheet" href="lib3styles.css" type="text/css" />
<link rel="Copyright" href="17_intro/license.html" type="text/html" />
</head>
<body>
<h1 class="centered"><a name="top">Explanatory notes about libstdc++-v3
design</a></h1>
<p class="fineprint"><em>
The latest version of this document is always available at
<a href="http://gcc.gnu.org/onlinedocs/libstdc++/explanations.html">
http://gcc.gnu.org/onlinedocs/libstdc++/explanations.html</a>.
</em></p>
<p><em>
To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++-v3 homepage</a>.
</em></p>
<!-- ####################################################### -->
<hr />
<h3><a name="cstdio">&quot;I/O packages&quot;, <code>--enable-cstdio</code></a></h3>
<p>In addition to all the nifty things which C++ can do for I/O, its library
also includes all of the I/O capabilites of C. Making them work together
can be a challenge, not only
<a href="27_io/howto.html#8">for the programmer</a> but for the
implementors as well.
</p>
<p>There are two ways to do a C++ library: the cool way, and the easy way.
More specifically, the cool-but-easy-to-get-wrong way, and the
easy-to-guarantee-correct-behavior way. For 3.0, the easy way is used.
</p>
<p>Choosing 'stdio' is the easy way. It builds a C++ library which forwards
all operations to the C library. Many of the C++ I/O functions are
specified in the standard 'as if' they called a certain C function; the
easiest way to get it correct is to actually call that function. The
disadvantage is that the C++ code will run slower (fortunately, the layer
is thin).
</p>
<p>Other packages are possible. For a new package, a header must be
written to provide types like streamsize (usually just a typedef), as
well as some internal types like<code> __c_file_type </code> and
<code> __c_lock </code> (for the stdio case, these are FILE (as in
&quot;FILE*&quot;) and a simple POSIX mutex, respectively). An
interface class called <code> __basic_file </code> must also be filled in;
as an example, for the stdio case, these member functions are all
inline calles to fread, fwrite, etc.
</p>
<p>Return <a href="#top">to the top of the page</a> or
<a href="http://gcc.gnu.org/libstdc++/">to the homepage</a>.
</p>
<hr />
<h3><a name="alloc">Internal Allocators</a></h3>
<p>
</p>
<p>Return <a href="#top">to the top of the page</a> or
<a href="http://gcc.gnu.org/libstdc++/">to the homepage</a>.
</p>
<!-- ####################################################### -->
<hr />
<p class="fineprint"><em>
See <a href="17_intro/license.html">license.html</a> for copying conditions.
Comments and suggestions are welcome, and may be sent to
<a href="mailto:libstdc++@gcc.gnu.org">the libstdc++ mailing list</a>.
</em></p>
</body>
</html>

View File

@ -15,7 +15,7 @@ at <a
href="http://gcc.gnu.org/onlinedocs/libstdc++/ext/ballocator_doc.html">
http://gcc.gnu.org/onlinedocs/libstdc++/ext/ballocator_doc.html</a>.</small></small></em><br>
<br>
<em> To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++-v3
<em> To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++
homepage</a>.</em><br>
<br>
<hr style="width: 100%; height: 2px;"><br>
@ -415,7 +415,7 @@ Thus, knowing these values, and based on the sizeof(value_type), we may
create a function that returns the Max_Wastage_Percentage for us to use.<br>
<br>
<hr style="width: 100%; height: 2px;"><small><small><em> See <a
href="file:///home/dhruv/projects/libstdc++-v3/gcc/libstdc++-v3/docs/html/17_intro/license.html">license.html</a>
href="file:///home/dhruv/projects/libstdc++/gcc/libstdc++/docs/html/17_intro/license.html">license.html</a>
for copying conditions. Comments and suggestions are welcome, and may
be
sent to <a href="mailto:libstdc++@gcc.gnu.org">the libstdc++ mailing

View File

@ -23,7 +23,7 @@
</em></p>
<p><em>
To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++-v3 homepage</a>.
To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++ homepage</a>.
</em></p>

View File

@ -10,7 +10,7 @@
<meta name="KEYWORDS" content="HOWTO, libstdc++, GCC, g++, libg++, STL" />
<meta name="DESCRIPTION" content="Notes for the libstdc++ extensions." />
<meta name="GENERATOR" content="vi and eight fingers" />
<title>libstdc++-v3 HOWTO: Extensions</title>
<title>libstdc++ HOWTO: Extensions</title>
<link rel="StyleSheet" href="../lib3styles.css" type="text/css" />
<link rel="Start" href="../documentation.html" type="text/html"
title="GNU C++ Standard Library" />
@ -37,7 +37,7 @@
existence, of these extensions may change with little or no
warning. (Ideally, the really good ones will appear in the next
revision of C++.) Also, other platforms, other compilers, other
versions of g++ or libstdc++-v3 may not recognize these names, or
versions of g++ or libstdc++ may not recognize these names, or
treat them differently, or... </li>
<li>You should know how to <a href="../faq/index.html#5_4">access
these headers properly</a>. </li>
@ -144,7 +144,7 @@
<hr />
<h2><a name="4">Compile-time checks</a></h2>
<p>Currently libstdc++-v3 uses the concept checkers from the Boost
<p>Currently libstdc++ uses the concept checkers from the Boost
library to perform <a href="../19_diagnostics/howto.html#3">optional
compile-time checking</a> of template instantiations of the standard
containers. They are described in the linked-to page.
@ -161,7 +161,7 @@
for making changes to the library. They periodically publish an
Issues List containing problems and possible solutions. As they reach
a consensus on proposed solutions, we often incorporate the solution
into libstdc++-v3.
into libstdc++.
</p>
<p>Here are the issues which have resulted in code changes to the library.
The links are to the specific defect reports from a <strong>partial

View File

@ -27,7 +27,7 @@
</em></p>
<p><em>
To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++-v3 homepage</a>.
To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++ homepage</a>.
</em></p>
<!-- ####################################################### -->

View File

@ -24,7 +24,7 @@
</em></p>
<p><em>
To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++-v3 homepage</a>.
To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++ homepage</a>.
</em></p>
<!-- ####################################################### -->

View File

@ -6,10 +6,10 @@
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
<meta name="KEYWORDS" content="libstdc++, libstdc++-v3, GCC, g++, STL, SGI" />
<meta name="DESCRIPTION" content="SGI extensions preserved in libstdc++-v3." />
<meta name="KEYWORDS" content="libstdc++, libstdc++, GCC, g++, STL, SGI" />
<meta name="DESCRIPTION" content="SGI extensions preserved in libstdc++." />
<meta name="GENERATOR" content="vi and eight fingers" />
<title>SGI extensions to the library in libstdc++-v3</title>
<title>SGI extensions to the library in libstdc++</title>
<link rel="StyleSheet" href="../lib3styles.css" type="text/css" />
<link rel="Start" href="../documentation.html" type="text/html"
title="GNU C++ Standard Library" />
@ -20,7 +20,7 @@
<body>
<h1 class="centered"><a name="top">SGI extensions to the library in
libstdc++-v3</a></h1>
libstdc++</a></h1>
<p>This page describes the extensions that SGI made to their version of the
STL subset of the Standard C++ Library. For a time we
@ -44,7 +44,7 @@ libstdc++-v3</a></h1>
documentation, buy a copy of Matt Austern's book. *grin*
</p>
<p>Back to the <a href="howto.html">libstdc++-v3 extensions</a>.
<p>Back to the <a href="howto.html">libstdc++ extensions</a>.
</p>

View File

@ -6,9 +6,9 @@
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<meta name="KEYWORDS" content="libstdc++, libstdc++-v3, GCC, g++, libg++, STL" />
<meta name="KEYWORDS" content="libstdc++, libstdc++, GCC, g++, libg++, STL" />
<meta name="DESCRIPTION" content="FAQ for the GNU libstdc++ effort." />
<title>libstdc++-v3 FAQ</title>
<title>libstdc++ FAQ</title>
<link rel="StyleSheet" href="../lib3styles.css" />
<link rel="Start" rev="Help" href="../documentation.html" type="text/html"
title="GNU C++ Standard Library" />
@ -28,7 +28,7 @@
</em></p>
<p><em>
To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++-v3 homepage</a>.
To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++ homepage</a>.
</em></p>
<!-- ####################################################### -->
@ -38,21 +38,21 @@
<li><a href="#1_0">General Information</a>
<!-- I suspect these will mostly be links to/into existing documents. -->
<ol>
<li><a href="#1_1">What is libstdc++-v3?</a> </li>
<li><a href="#1_1">What is libstdc++?</a> </li>
<li><a href="#1_2">Why should I use libstdc++?</a> </li>
<li><a href="#1_3">Who's in charge of it?</a> </li>
<li><a href="#1_4">How do I get libstdc++?</a> </li>
<li><a href="#1_4">[removed]</a> </li>
<li><a href="#1_5">When is libstdc++ going to be finished?</a> </li>
<li><a href="#1_6">How do I contribute to the effort?</a> </li>
<li><a href="#1_7">What happened to libg++? I need that!</a> </li>
<li><a href="#1_8">What if I have more questions?</a> </li>
<li><a href="#1_9">What are the license terms for libstdc++-v3?</a> </li>
<li><a href="#1_9">What are the license terms for libstdc++?</a> </li>
</ol>
</li>
<li><a href="#2_0">Installation</a>
<ol>
<li><a href="#2_1">How do I install libstdc++-v3?</a> </li>
<li><a href="#2_1">How do I install libstdc++?</a> </li>
<li><a href="#2_2">[removed]</a> </li>
<li><a href="#2_3">What is this SVN thing that you keep
mentioning?</a> </li>
@ -66,7 +66,7 @@
<li><a href="#3_0">Platform-Specific Issues</a>
<ol>
<li><a href="#3_1">Can libstdc++-v3 be used with &lt;my
<li><a href="#3_1">Can libstdc++ be used with &lt;my
favorite compiler&gt;?</a> </li>
<li><a href="#3_2">[removed]</a> </li>
<li><a href="#3_3">[removed]</a> </li>
@ -85,7 +85,7 @@
<li><a href="#4_0">Known Bugs and Non-Bugs</a>
<ol>
<li><a href="#4_1">What works already?</a> </li>
<li><a href="#4_2">Bugs in gcc/g++ (not libstdc++-v3)</a> </li>
<li><a href="#4_2">Bugs in gcc/g++ (not libstdc++)</a> </li>
<li><a href="#4_3">Bugs in the C++ language/lib specification</a> </li>
<li><a href="#4_4">Things in libstdc++ that only look like bugs</a><ul>
<li><a href="#4_4_iostreamclear">reopening a stream fails</a> </li>
@ -110,11 +110,11 @@
<ol>
<li><a href="#5_1">string::iterator is not char*;
vector&lt;T&gt;::iterator is not T*</a> </li>
<li><a href="#5_2">What's next after libstdc++-v3?</a> </li>
<li><a href="#5_2">What's next after libstdc++?</a> </li>
<li><a href="#5_3">What about the STL from SGI?</a> </li>
<li><a href="#5_4">Extensions and Backward Compatibility</a> </li>
<li><a href="#5_5">Does libstdc++ support TR1?</a> </li>
<li><a href="#5_6">Is libstdc++-v3 thread-safe?</a> </li>
<li><a href="#5_6">Is libstdc++ thread-safe?</a> </li>
<li><a href="#5_7">How do I get a copy of the ISO C++ Standard?</a> </li>
<li><a href="#5_8">What's an ABI and why is it so messy?</a> </li>
<li><a href="#5_9">How do I make std::vector&lt;T&gt;::capacity()
@ -130,23 +130,15 @@
<h1><a name="1_0">1.0 General Information</a></h1>
<!-- I suspect these will mostly be links to/into existing documents. -->
<h2><a name="1_1">1.1 What is libstdc++-v3?</a></h2>
<h2><a name="1_1">1.1 What is libstdc++?</a></h2>
<p>The GNU Standard C++ Library v3 is an
ongoing project to implement the ISO 14882 Standard C++ library
as described in chapters 17 through 27 and annex D.
For those who want to see exactly how
far the project has come, or just want the latest
bleeding-edge code, the up-to-date source is available over
anonymous SVN, and can even be browsed over the Web (see
<a href="#1_4">1.4</a> below).
</p>
<p>The older libstdc++-v2 project is no longer maintained; the code
has been completely replaced and rewritten.
<a href="#4_4_interface">If you are using V2</a>, then you need to
report bugs to your system vendor, not to the V3 list.
</p>
<p>A more formal description of the V3 goals can be found in the
official <a href="../17_intro/DESIGN">design document</a>.
anonymous SVN, and can even be browsed over the
<a href="http://gcc.gnu.org/svn.html">web</a>.
</p>
<hr />
@ -164,7 +156,7 @@
is overseen by the
<a href="http://gcc.gnu.org/">GCC team</a>. All of
the rapid development and near-legendary
<a href="http://gcc.gnu.org/gcc-3.3/buildstat.html">portability</a>
<a href="http://gcc.gnu.org/buildstat.html">portability</a>
that are the hallmarks of an open-source project are being
applied to libstdc++.
</p>
@ -192,17 +184,10 @@
<hr />
<h2><a name="1_4">1.4 How do I get libstdc++?</a></h2>
<p>The <a href="http://gcc.gnu.org/libstdc++/">homepage</a>
has instructions for retrieving the latest SVN sources, and for
browsing the SVN sources over the web.
</p>
<p>Stable versions of libstdc++-v3 are included with releases of
<a href="http://gcc.gnu.org/releases.html">the GCC compilers</a>.
</p>
<p>The subset commonly known as the Standard Template Library
(chapters 23 through 25, mostly) is adapted from the final release
of the SGI STL, with extensive changes.
</p>
<hr />
<h2><a name="1_5">1.5 When is libstdc++ going to be finished?</a></h2>
@ -266,7 +251,7 @@ which is no longer available, thanks deja...-->
<hr />
<h2><a name="1_8">1.8 What if I have more questions?</a></h2>
<p>If you have read the README and RELEASE-NOTES files, and your
<p>If you have read the README file, and your
question remains unanswered, then just ask the mailing list.
At present, you do not need to be subscribed to the list to
send a message to it. More information is available on the
@ -281,14 +266,14 @@ which is no longer available, thanks deja...-->
</p>
<hr />
<h2><a name="1_9">1.9 What are the license terms for libstdc++-v3?</a></h2>
<h2><a name="1_9">1.9 What are the license terms for libstdc++?</a></h2>
<p>See <a href="../17_intro/license.html">our license description</a>
for these and related questions.
</p>
<hr />
<h1><a name="2_0">2.0 Installation</a></h1>
<h2><a name="2_1">2.1 How do I install libstdc++-v3?</a></h2>
<h2><a name="2_1">2.1 How do I install libstdc++?</a></h2>
<p>Complete instructions are not given here (this is a FAQ, not
an installation document), but the tools required are few:
</p>
@ -310,12 +295,10 @@ which is no longer available, thanks deja...-->
with new flags such as --enable-threads are there also, as well as
patches and instructions for working with GCC 2.95.
</p>
<p>The top-level install.html and
<a href="../17_intro/RELEASE-NOTES">RELEASE-NOTES</a> files contain
<p>The top-level install.html file contains
the exact build and installation instructions. You may wish to
browse those files over ViewVC ahead of time to get a feel for
what's required. RELEASE-NOTES is located in the
&quot;.../docs/17_intro/&quot; directory of the distribution.
what's required.
</p>
<hr />
@ -343,7 +326,7 @@ 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
<p>libstdc++ comes with its own testsuite. You do not need
to actually install the library (&quot;<code>make
install</code>&quot;) to run the testsuite, but you do need
DejaGNU, as described
@ -367,7 +350,7 @@ which is no longer available, thanks deja...-->
into your executable, not the entire library. Unfortunately, even
if you only need a single function or variable from an object file,
the entire object file is extracted. (There's nothing unique to C++
or libstdc++-v3 about this; it's just common behavior, given here
or libstdc++ about this; it's just common behavior, given here
for background reasons.)
</p>
<p>Some of the object files which make up libstdc++.a are rather large.
@ -376,7 +359,7 @@ which is no longer available, thanks deja...-->
of your executable. Historically the best way around this was to
only place a very few functions (often only a single one) in each
source/object file; then extracting a single function is the same
as extracting a single .o file. For libstdc++-v3 this is only
as extracting a single .o file. For libstdc++ this is only
possible to a certain extent; the object files in question contain
template classes and template functions, pre-instantiated, and
splitting those up causes severe maintenance headaches.
@ -449,7 +432,7 @@ which is no longer available, thanks deja...-->
<hr />
<h1><a name="3_0">3.0 Platform-Specific Issues</a></h1>
<h2><a name="3_1">3.1 Can libstdc++-v3 be used with &lt;my
<h2><a name="3_1">3.1 Can libstdc++ be used with &lt;my
favorite compiler&gt;?</a></h2>
<p>Probably not. Yet.</p>
<p>Because GCC advances so rapidly, development and testing of
@ -594,8 +577,7 @@ which is no longer available, thanks deja...-->
<h1><a name="4_0">4.0 Known Bugs and Non-Bugs</a></h1>
<em>Note that this section can get rapidly outdated -- such is the
nature of an open-source project. For the latest information, join
the mailing list or look through recent archives. The RELEASE-
NOTES and BUGS files are generally kept up-to-date.</em>
the mailing list or look through GCC bugzilla.</em>
<p>For 3.0.1, the most common &quot;bug&quot; is an apparently missing
&quot;<code>../</code>&quot; in include/Makefile, resulting in files
@ -631,13 +613,12 @@ which is no longer available, thanks deja...-->
corner cases. Also, localization is incomplete. For whether it works
well, or as you expect it to work, see 5.2.
</p>
<p>Long answer: See the docs/html/17_intro/CHECKLIST file, which is
badly outdated... Also see the RELEASE-NOTES file, which is kept
more up to date.
<p>Long answer: See the implementation status pages for C++98,
TR1, and C++0x.
</p>
<hr />
<h2><a name="4_2">4.2 Bugs in gcc/g++ (not libstdc++-v3)</a></h2>
<h2><a name="4_2">4.2 Bugs in gcc/g++ (not libstdc++)</a></h2>
<p>This is by no means meant to be complete nor exhaustive, but
mentions some problems that users may encounter when building
or using libstdc++. If you are experiencing one of these
@ -646,8 +627,7 @@ which is no longer available, thanks deja...-->
</p>
<p>Before reporting a bug, examine the
<a href="http://gcc.gnu.org/bugs.html">bugs database</a> with the
category set to &quot;libstdc++&quot;. The BUGS file in the source
tree also tracks known serious problems.
category set to &quot;libstdc++&quot;.
</p>
<ul>
<li>Debugging is problematic, due to bugs in line-number generation
@ -746,7 +726,7 @@ which is no longer available, thanks deja...-->
libstdc++-v2 library, which is nonstandard and unmaintained. Do not
report problems with -v2 to the -v3 mailing list.
</p>
<p>For GCC versions 3.0 and 3.1 the libstdc++-v3 header files are
<p>For GCC versions 3.0 and 3.1 the libstdc++ header files are
installed in <code>${prefix}/include/g++-v3</code> (see the 'v'?).
Starting with version 3.2 the headers are installed in
<code>${prefix}/include/c++/${version}</code> as this prevents
@ -768,7 +748,7 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
<p>Note that 2.95.x shipped with the
<a href="#4_4_interface">old v2 library</a> which is no longer
maintained. Also note that gcc 2.95.3 fixes this problem, but
requires a separate patch for libstdc++-v3.
requires a separate patch for libstdc++.
</p>
<p><a name="4_4_checks"><strong>concept checks</strong></a>
If you see compilation errors containing messages about
@ -855,8 +835,8 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
</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
<h2><a name="5_2">5.2 What's next after libstdc++?</a></h2>
<p>Hopefully, not much. The goal of libstdc++ 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. However:
@ -883,7 +863,7 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
<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.
libstdc++ if they seem to be &quot;standard&quot; enough.
(For example, the &quot;long long&quot; type from C99.)
Bugfixes and rewrites (to improve or fix thread safety, for
instance) will of course be a continuing task.
@ -1061,8 +1041,8 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
</p>
<hr />
<h2><a name="5_6">5.6 Is libstdc++-v3 thread-safe?</a></h2>
<p>libstdc++-v3 strives to be thread-safe when all of the following
<h2><a name="5_6">5.6 Is libstdc++ thread-safe?</a></h2>
<p>libstdc++ strives to be thread-safe when all of the following
conditions are met:
</p>
<ul>

File diff suppressed because it is too large Load Diff

View File

@ -6,10 +6,10 @@
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
<meta name="KEYWORDS" content="libstdc++, libstdc++-v3, GCC, g++" />
<meta name="KEYWORDS" content="libstdc++, libstdc++, GCC, g++" />
<meta name="DESCRIPTION" content="README for the GNU libstdc++ effort." />
<meta name="GENERATOR" content="vi and eight fingers" />
<title>libstdc++-v3 Installation Instructions</title>
<title>libstdc++ Installation Instructions</title>
<link rel="StyleSheet" href="lib3styles.css" type="text/css" />
<link rel="Copyright" href="17_intro/license.html" type="text/html" />
</head>
@ -24,7 +24,7 @@
</em></p>
<p><em>
To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++-v3 homepage</a>.
To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++ homepage</a>.
</em></p>
@ -32,10 +32,10 @@
<hr />
<h2>Contents</h2>
<p>Because libstdc++-v3 is part of GCC, the primary source for
<p>Because libstdc++ is part of GCC, the primary source for
installation instructions is
<a href="http://gcc.gnu.org/install/">the GCC install page</a>.
Additional data is given here only where it applies to libstdc++-v3.
Additional data is given here only where it applies to libstdc++.
</p>
<ul>
@ -61,7 +61,7 @@
<code>-ffunction-sections -fdata-sections -Wl,--gc-sections</code>.
To obtain maximum benefit from this, binutils after this date should
also be used (bugs were fixed with C++ exception handling related
to this change in libstdc++-v3). The version of these tools should
to this change in libstdc++). The version of these tools should
be <code>2.10.90</code>, or later, and you can get snapshots (as
well as releases) of binutils
<a href="ftp://sources.redhat.com/pub/binutils">here</a>. The
@ -163,8 +163,8 @@ zh_TW BIG5
Instructions</a> first. Read <em>all of them</em>.
<strong>Twice.</strong>
</p>
<p>When building libstdc++-v3 you'll have to configure
the entire <em>gccsrcdir</em> directory. The full list of libstdc++-v3
<p>When building libstdc++ you'll have to configure
the entire <em>gccsrcdir</em> directory. The full list of libstdc++
specific configuration options, not dependent on the specific compiler
release being used, can be found <a href="configopts.html">here</a>.
</p>

View File

@ -1,69 +0,0 @@
# Take apart bits of HTML and puts them back together again in new and
# fascinating ways. Copyright (C) 2002 Free Software Foundation, Inc.
# Contributed by Phil Edwards <pme@gcc.gnu.org>. Simple two-state automaton
# inspired by Richard Henderson's gcc/mkmap-symver.awk.
# 'file' is the name of the file on stdin
# 'title' is the text to print at the start of the list
BEGIN {
state = "looking";
entries = 0;
printf (" <li>%s\n", title);
printf (" <ul>\n");
}
# Searching for the little table of contents at the top.
state == "looking" && /^<h1>Contents/ {
state = "entries";
next;
}
# Ignore everything else up to that point.
state == "looking" {
next;
}
# An entry in the table of contents. Pull that line apart.
state == "entries" && /<li>/ {
extract_info($0);
next;
}
# End of the list. Don't bother reading the rest of the file. (It could
# also contain more <li>'s, so that would be incorrect as well as wasteful.)
state == "entries" && /^<\/ul>/ {
exit;
}
END {
for (i = 0; i < entries; i++)
printf (" %s\n", entry[i]);
printf (" </ul>\n </li>\n\n");
}
function extract_info(line) {
# thistarget will be things like "#5" or "elsewhere.html"
match(line,"href=\".*\"");
thistarget = substr(line,RSTART+6,RLENGTH-7);
# take apart the filename
split(file,X,"/");
if (thistarget ~ /^#/) {
# local name, use directory and filename
target = file thistarget
} else {
# different file, only use directory
target = X[1] "/" thistarget
}
# visible text
gsub("</a></li>","",line);
start = index(line,"\">") + 2;
thistext = substr(line,start);
# Assemble and store the HTML for later output.
entry[entries++] = "<li><a href=\"" target "\">" thistext "</a></li>"
}
# vim:sw=2

View File

@ -9,7 +9,7 @@
<meta name="KEYWORDS" content="c++, libstdc++, test, regression, g++" />
<meta name="DESCRIPTION" content="README for the GNU libstdc++ effort." />
<meta name="GENERATOR" content="vi and eight fingers" />
<title>libstdc++-v3 Testing Instructions</title>
<title>libstdc++ Testing Instructions</title>
<link rel="StyleSheet" href="lib3styles.css" />
</head>
<body>
@ -23,7 +23,7 @@
</em></p>
<p><em>
To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++-v3 homepage</a>.
To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++ homepage</a>.
</em></p>
<!-- ####################################################### -->
@ -434,7 +434,7 @@ up in the normal.exp file.
</pre>
<p>
More examples can be found in the libstdc++-v3/testsuite/*/*.cc files.
More examples can be found in the libstdc++/testsuite/*/*.cc files.
</p>
<hr />
@ -452,7 +452,7 @@ up in the normal.exp file.
<pre> make check</pre>
<p>in the <em>libbuilddir</em> directory.</p>
<p>or</p>
<pre> make check-target-libstdc++-v3</pre>
<pre> make check-target-libstdc++</pre>
<p>in the <em>gccbuilddir</em> directory.</p>
<p>
@ -472,11 +472,11 @@ specific argument to the variable RUNTESTFLAGS, as below.
</p>
<pre>
make check-target-libstdc++-v3 RUNTESTFLAGS="-v"
make check-target-libstdc++ RUNTESTFLAGS="-v"
</pre>
or
<pre>
make check-target-libstdc++-v3 RUNTESTFLAGS="-v -v"
make check-target-libstdc++ RUNTESTFLAGS="-v -v"
</pre>
<p> To run a subset of the library tests, try using a command like the
@ -494,20 +494,20 @@ specially crafted site.exp, or pass down --target_board flags.
Example flags to pass down for various embedded builds are as follows:
<pre>
--target=powerpc-eabism (libgloss/sim)
make check-target-libstdc++-v3 RUNTESTFLAGS="--target_board=powerpc-sim"
make check-target-libstdc++ RUNTESTFLAGS="--target_board=powerpc-sim"
--target=calmrisc32 (libgloss/sid)
make check-target-libstdc++-v3 RUNTESTFLAGS="--target_board=calmrisc32-sid"
make check-target-libstdc++ RUNTESTFLAGS="--target_board=calmrisc32-sid"
--target=xscale-elf (newlib/sim)
make check-target-libstdc++-v3 RUNTESTFLAGS="--target_board=arm-sim"
make check-target-libstdc++ RUNTESTFLAGS="--target_board=arm-sim"
</pre>
<p> Also, here is an example of how to run the libstdc++ testsuite for a
multilibed build directory with different ABI settings:
</p>
<pre>
make check-target-libstdc++-v3 RUNTESTFLAGS='--target_board \"unix{-mabi=32,,-mabi=64}\"'
make check-target-libstdc++ RUNTESTFLAGS='--target_board \"unix{-mabi=32,,-mabi=64}\"'
</pre>
<p>
@ -519,7 +519,7 @@ of libstdc++ is in your <code>LD_LIBRARY_PATH</code>, or equivalent.
If your GCC source tree is at <code>/path/to/gcc</code>, then you can
run the tests as follows:
<pre>
runtest --tool libstdc++ --srcdir=/path/to/gcc/libstdc++-v3/testsuite
runtest --tool libstdc++ --srcdir=/path/to/gcc/libstdc++/testsuite
</pre>
The testsuite will create a number of files in the directory in which you
run this command,. Some of those files might use the same name as

View File

@ -54,7 +54,7 @@ _GLIBCXX_BEGIN_NAMESPACE(std)
explicit
auto_ptr_ref(_Tp1* __p): _M_ptr(__p) { }
} _GLIBCXX_DEPRECATED;
} _GLIBCXX_DEPRECATED_ATTR;
/**
@ -285,7 +285,7 @@ _GLIBCXX_BEGIN_NAMESPACE(std)
template<typename _Tp1>
operator auto_ptr<_Tp1>() throw()
{ return auto_ptr<_Tp1>(this->release()); }
} _GLIBCXX_DEPRECATED;
} _GLIBCXX_DEPRECATED_ATTR;
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// 541. shared_ptr template assignment and void
@ -294,7 +294,7 @@ _GLIBCXX_BEGIN_NAMESPACE(std)
{
public:
typedef void element_type;
} _GLIBCXX_DEPRECATED;
} _GLIBCXX_DEPRECATED_ATTR;
_GLIBCXX_END_NAMESPACE

View File

@ -119,7 +119,7 @@ _GLIBCXX_BEGIN_NAMESPACE(std)
typename _Operation::result_type
operator()(typename _Operation::second_argument_type& __x) const
{ return op(value, __x); }
} _GLIBCXX_DEPRECATED;
} _GLIBCXX_DEPRECATED_ATTR;
/// One of the @link s20_3_6_binder binder functors@endlink.
template<typename _Operation, typename _Tp>
@ -154,7 +154,7 @@ _GLIBCXX_BEGIN_NAMESPACE(std)
typename _Operation::result_type
operator()(typename _Operation::first_argument_type& __x) const
{ return op(__x, value); }
} _GLIBCXX_DEPRECATED;
} _GLIBCXX_DEPRECATED_ATTR;
/// One of the @link s20_3_6_binder binder functors@endlink.
template<typename _Operation, typename _Tp>

View File

@ -47,26 +47,26 @@
// Macros for visibility.
// _GLIBCXX_HAVE_ATTRIBUTE_VISIBILITY
// _GLIBCXX_VISIBILITY
// _GLIBCXX_VISIBILITY_ATTR
#define _GLIBCXX_HAVE_ATTRIBUTE_VISIBILITY
#if _GLIBCXX_HAVE_ATTRIBUTE_VISIBILITY
# define _GLIBCXX_VISIBILITY(V) __attribute__ ((__visibility__ (#V)))
# define _GLIBCXX_VISIBILITY_ATTR(V) __attribute__ ((__visibility__ (#V)))
#else
# define _GLIBCXX_VISIBILITY(V)
# define _GLIBCXX_VISIBILITY_ATTR(V)
#endif
// Macros for deprecated.
// _GLIBCXX_USE_DEPRECATED
// _GLIBCXX_DEPRECATED
#ifndef _GLIBCXX_USE_DEPRECATED
# define _GLIBCXX_USE_DEPRECATED 1
// _GLIBCXX_DEPRECATED_ATTR
#ifndef _GLIBCXX_DEPRECATED
# define _GLIBCXX_DEPRECATED 1
#endif
#if defined(__DEPRECATED) && defined(__GXX_EXPERIMENTAL_CXX0X__)
# define _GLIBCXX_DEPRECATED __attribute__ ((__deprecated__))
# define _GLIBCXX_DEPRECATED_ATTR __attribute__ ((__deprecated__))
#else
# define _GLIBCXX_DEPRECATED
# define _GLIBCXX_DEPRECATED_ATTR
#endif
// Macros for activating various namespace association modes.
@ -124,7 +124,7 @@
# define _GLIBCXX_STD std
# define _GLIBCXX_BEGIN_NESTED_NAMESPACE(X, Y) _GLIBCXX_BEGIN_NAMESPACE(X)
# define _GLIBCXX_END_NESTED_NAMESPACE _GLIBCXX_END_NAMESPACE
# define _GLIBCXX_BEGIN_NAMESPACE(X) namespace X _GLIBCXX_VISIBILITY(default) {
# define _GLIBCXX_BEGIN_NAMESPACE(X) namespace X _GLIBCXX_VISIBILITY_ATTR(default) {
# define _GLIBCXX_END_NAMESPACE }
#else
@ -141,7 +141,7 @@
# define _GLIBCXX_STD_D __norm
# define _GLIBCXX_STD_P _GLIBCXX_STD
# define _GLIBCXX_STD __cxx1998
# define _GLIBCXX_BEGIN_NAMESPACE(X) namespace X _GLIBCXX_VISIBILITY(default) {
# define _GLIBCXX_BEGIN_NAMESPACE(X) namespace X _GLIBCXX_VISIBILITY_ATTR(default) {
# define _GLIBCXX_END_NAMESPACE }
# define _GLIBCXX_EXTERN_TEMPLATE 0
# endif
@ -151,7 +151,7 @@
# define _GLIBCXX_STD_D _GLIBCXX_STD
# define _GLIBCXX_STD_P __norm
# define _GLIBCXX_STD __cxx1998
# define _GLIBCXX_BEGIN_NAMESPACE(X) namespace X _GLIBCXX_VISIBILITY(default) {
# define _GLIBCXX_BEGIN_NAMESPACE(X) namespace X _GLIBCXX_VISIBILITY_ATTR(default) {
# define _GLIBCXX_END_NAMESPACE }
# define _GLIBCXX_EXTERN_TEMPLATE 0
# endif
@ -161,7 +161,7 @@
# define _GLIBCXX_STD_D __norm
# define _GLIBCXX_STD_P __norm
# define _GLIBCXX_STD __cxx1998
# define _GLIBCXX_BEGIN_NAMESPACE(X) namespace X _GLIBCXX_VISIBILITY(default) {
# define _GLIBCXX_BEGIN_NAMESPACE(X) namespace X _GLIBCXX_VISIBILITY_ATTR(default) {
# define _GLIBCXX_END_NAMESPACE }
# define _GLIBCXX_EXTERN_TEMPLATE 0
# endif
@ -171,7 +171,7 @@
without inlining due to lack of weak symbols
# endif
# define _GLIBCXX_BEGIN_NESTED_NAMESPACE(X, Y) namespace X { namespace Y _GLIBCXX_VISIBILITY(default) {
# define _GLIBCXX_BEGIN_NESTED_NAMESPACE(X, Y) namespace X { namespace Y _GLIBCXX_VISIBILITY_ATTR(default) {
# define _GLIBCXX_END_NESTED_NAMESPACE } }
#endif

View File

@ -700,7 +700,7 @@ _GLIBCXX_BEGIN_NAMESPACE(std)
_GLIBCXX_END_NAMESPACE
#if !defined(__GXX_EXPERIMENTAL_CXX0X__) || _GLIBCXX_USE_DEPRECATED
#if !defined(__GXX_EXPERIMENTAL_CXX0X__) || _GLIBCXX_DEPRECATED
# include <backward/binders.h>
#endif

View File

@ -71,7 +71,7 @@
# include <bits/stl_function.h> // std::less
# include <debug/debug.h>
# include <type_traits>
# if _GLIBCXX_USE_DEPRECATED
# if _GLIBCXX_DEPRECATED
# include <backward/auto_ptr.h>
# endif
# if defined(_GLIBCXX_INCLUDE_AS_CXX0X)

View File

@ -763,7 +763,7 @@ _GLIBCXX_BEGIN_NAMESPACE(std)
overflow(int_type /* __c */ = traits_type::eof())
{ return traits_type::eof(); }
#if _GLIBCXX_USE_DEPRECATED
#if _GLIBCXX_DEPRECATED
// Annex D.6
public:
/**
@ -773,11 +773,7 @@ _GLIBCXX_BEGIN_NAMESPACE(std)
* been read.
*
* See http://gcc.gnu.org/ml/libstdc++/2002-05/msg00168.html
*
* @note This function has been deprecated by the standard. You
* must define @c _GLIBCXX_DEPRECATED to make this visible; see
* c++config.h.
*/
*/
void
stossc()
{

View File

@ -299,7 +299,7 @@ _GLIBCXX_BEGIN_NAMESPACE_TR1
}
}
#if !defined(__GXX_EXPERIMENTAL_CXX0X__) || _GLIBCXX_USE_DEPRECATED
#if !defined(__GXX_EXPERIMENTAL_CXX0X__) || _GLIBCXX_DEPRECATED
// Special case for auto_ptr<_Tp> to provide the strong guarantee.
template<typename _Tp>
explicit
@ -601,7 +601,7 @@ _GLIBCXX_BEGIN_NAMESPACE_TR1
/**
* @post use_count() == 1 and __r.get() == 0
*/
#if !defined(__GXX_EXPERIMENTAL_CXX0X__) || _GLIBCXX_USE_DEPRECATED
#if !defined(__GXX_EXPERIMENTAL_CXX0X__) || _GLIBCXX_DEPRECATED
template<typename _Tp1>
explicit
__shared_ptr(std::auto_ptr<_Tp1>& __r)
@ -645,7 +645,7 @@ _GLIBCXX_BEGIN_NAMESPACE_TR1
return *this;
}
#if !defined(__GXX_EXPERIMENTAL_CXX0X__) || _GLIBCXX_USE_DEPRECATED
#if !defined(__GXX_EXPERIMENTAL_CXX0X__) || _GLIBCXX_DEPRECATED
template<typename _Tp1>
__shared_ptr&
operator=(std::auto_ptr<_Tp1>& __r)
@ -1020,7 +1020,7 @@ _GLIBCXX_BEGIN_NAMESPACE_TR1
shared_ptr(const weak_ptr<_Tp1>& __r)
: __shared_ptr<_Tp>(__r) { }
#if !defined(__GXX_EXPERIMENTAL_CXX0X__) || _GLIBCXX_USE_DEPRECATED
#if !defined(__GXX_EXPERIMENTAL_CXX0X__) || _GLIBCXX_DEPRECATED
template<typename _Tp1>
explicit
shared_ptr(std::auto_ptr<_Tp1>& __r)
@ -1047,7 +1047,7 @@ _GLIBCXX_BEGIN_NAMESPACE_TR1
return *this;
}
#if !defined(__GXX_EXPERIMENTAL_CXX0X__) || _GLIBCXX_USE_DEPRECATED
#if !defined(__GXX_EXPERIMENTAL_CXX0X__) || _GLIBCXX_DEPRECATED
template<typename _Tp1>
shared_ptr&
operator=(std::auto_ptr<_Tp1>& __r)

View File

@ -75,7 +75,7 @@ _GLIBCXX_BEGIN_NAMESPACE(std)
_GLIBCXX_END_NAMESPACE
namespace __gnu_internal _GLIBCXX_VISIBILITY(hidden)
namespace __gnu_internal _GLIBCXX_VISIBILITY_ATTR(hidden)
{
using namespace std;
using namespace __gnu_cxx;

View File

@ -39,7 +39,7 @@
#include <ext/stdio_filebuf.h>
#include <ext/stdio_sync_filebuf.h>
namespace __gnu_internal _GLIBCXX_VISIBILITY(hidden)
namespace __gnu_internal _GLIBCXX_VISIBILITY_ATTR(hidden)
{
using namespace __gnu_cxx;