mirror of
git://gcc.gnu.org/git/gcc.git
synced 2025-04-22 21:41:28 +08:00
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:
parent
d770555138
commit
4dd9d9db1d
@ -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,
|
||||
|
@ -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.
|
||||
|
||||
|
@ -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.
|
||||
|
||||
|
@ -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.
|
@ -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.
|
||||
|
@ -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>
|
596
libstdc++-v3/docs/html/17_intro/api.html
Normal file
596
libstdc++-v3/docs/html/17_intro/api.html
Normal 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><fstream.h></tt>,
|
||||
<tt><ostream.h></tt>
|
||||
and <tt><istream.h></tt>
|
||||
used to define
|
||||
<code>cout</code>, <code>cin</code> and so on. ISO C++ specifies that one needs to include
|
||||
<tt><iostream></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 "" or "std" 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<<(iterator)</code> to print the
|
||||
address of the iterator => use <code>operator<<
|
||||
&*iterator</code> instead ?
|
||||
</p></li>
|
||||
<li><p>you cannot clear an iterator's reference
|
||||
(<code>iterator = 0</code>) => use
|
||||
<code>iterator = iterator_type();</code> ?
|
||||
</p></li>
|
||||
<li><p>
|
||||
<code>if (iterator)</code> won't work any
|
||||
more => use <code>if (iterator != iterator_type())</code>
|
||||
?</p></li>
|
||||
</ul>
|
||||
|
||||
<h5><code>isspace</code> from <tt><cctype></tt> is a macro
|
||||
</h5>
|
||||
|
||||
<p> Glibc 2.0.x and 2.1.x define <tt><ctype.h></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 <cctype>
|
||||
int main() { std::isspace('X'); }
|
||||
</pre>
|
||||
|
||||
<p>Results in something like this:
|
||||
</p>
|
||||
|
||||
<pre>
|
||||
std:: (__ctype_b[(int) ( ( 'X' ) )] & (unsigned short int) _ISspace ) ;
|
||||
</pre>
|
||||
|
||||
|
||||
<p> A solution is to modify a header-file so that the compiler tells
|
||||
<tt><ctype.h></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 <ctype.h>
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Another problem arises if you put a <code>using namespace std;</code>
|
||||
declaration at the top, and include <tt><ctype.h></tt>. This
|
||||
will result in ambiguities between the definitions in the global
|
||||
namespace (<tt><ctype.h></tt>) and the definitions in namespace
|
||||
<code>std::</code> (<code><cctype></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 <vector>
|
||||
#include <deque>
|
||||
#include <string>
|
||||
|
||||
using namespace std;
|
||||
],
|
||||
[
|
||||
deque<int> test_deque(3);
|
||||
test_deque.at(2);
|
||||
vector<int> test_vector(2);
|
||||
test_vector.at(1);
|
||||
string test_string("test_string");
|
||||
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<char>::eof</code></h5>
|
||||
|
||||
<p>
|
||||
Use some kind of autoconf test, plus this:
|
||||
</p>
|
||||
<pre>
|
||||
#ifdef HAVE_CHAR_TRAITS
|
||||
#define CPP_EOF std::char_traits<char>::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->size(), 0); }
|
||||
</pre>
|
||||
<pre class="programlisting">
|
||||
basic_string&
|
||||
erase(size_type __pos = 0, size_type __n = npos)
|
||||
{
|
||||
return this->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><sstream></tt>), but for compatibility
|
||||
with older implementations you still have to use
|
||||
<code>i/ostrstream</code> (<tt><strstream></tt>):
|
||||
<pre >
|
||||
#ifdef HAVE_SSTREAM
|
||||
#include <sstream>
|
||||
#else
|
||||
#include <strstream>
|
||||
#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 << "Name=" << m_name << ", number=" << m_number << std::endl;
|
||||
...
|
||||
#ifndef HAVE_SSTREAM
|
||||
oss << 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 >> i;
|
||||
</pre>
|
||||
|
||||
<p> One (the only?) restriction is that an istrstream cannot be re-filled:
|
||||
</p>
|
||||
|
||||
<pre >
|
||||
std::istringstream iss(numerator);
|
||||
iss >> m_num;
|
||||
// this is not possible with istrstream
|
||||
iss.clear();
|
||||
iss.str(denominator);
|
||||
iss >> m_den;
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
If you don't care about speed, you can put these conversions in
|
||||
a template-function:
|
||||
</p>
|
||||
<pre >
|
||||
template <class X>
|
||||
void fromString(const string& input, X& any)
|
||||
{
|
||||
#ifdef HAVE_SSTREAM
|
||||
std::istringstream iss(input);
|
||||
#else
|
||||
std::istrstream iss(input.c_str());
|
||||
#endif
|
||||
X temp;
|
||||
iss >> 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 "info iostream".
|
||||
</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, "nocreate" 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<..></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><ext/stdio_filebuf.h></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>
|
||||
|
2280
libstdc++-v3/docs/html/17_intro/c++0x_status.html
Normal file
2280
libstdc++-v3/docs/html/17_intro/c++0x_status.html
Normal file
File diff suppressed because it is too large
Load Diff
@ -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>
|
@ -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
|
||||
};
|
||||
|
||||
//===========================================================================
|
||||
|
@ -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,
|
||||
|
@ -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; }
|
@ -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><foo></code> vs <code><foo.h></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
|
||||
"files" 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><math.h></tt>, you
|
||||
should use <tt><cmath></tt>. In some cases this has
|
||||
the advantage that the C++-header is more standardized than
|
||||
the C-header (i.e. <tt><ctime></tt> (almost)
|
||||
corresponds to either <tt><time.h></tt> or <tt><sys/time.h></tt>).
|
||||
|
||||
The standard specifies that if you include the C-style header
|
||||
(<tt><math.h></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><cmath></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 ("shadow") 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 "" or i.e. <code>using
|
||||
std::string;</code> (depending on whether the system has
|
||||
libstdc++ in <code>std::</code> or not). (ideas from
|
||||
<tt><<a href="mailto:llewelly@dbritsch.dsl.xmission.com">llewelly@dbritsch.dsl.xmission.com</a>></tt>, Karl Nelson
|
||||
<tt><<a href="mailto:kenelson@ece.ucdavis.edu">kenelson@ece.ucdavis.edu</a>></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><foo></code> vs <code><foo.h></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. "Configurable"
|
||||
(or "Not configurable") 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>"Configurable" (or "Not configurable") 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> "ABI" 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>
|
||||
|
@ -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
|
||||
"runtime exception," 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.
|
||||
|
@ -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 <link>-tags to have content
|
||||
(so that these links work),
|
||||
replace "user-space" by "global namespace"
|
||||
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">
|
||||
<fstream> 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
|
||||
<cctype>)</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<char>::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 "portable among ISO
|
||||
14882-implementations". On the other hand, if I say "backportable" or
|
||||
"conservative", I am talking about "compiles with older
|
||||
libstdc++-implementations".
|
||||
</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> => 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>) => 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>) => 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 "" or i.e. <b>using
|
||||
std::string;</b> (depending on whether the system has
|
||||
libstdc++ in <b>std::</b> or not). (ideas from
|
||||
<tt><<a href="mailto:llewelly@dbritsch.dsl.xmission.com">llewelly@dbritsch.dsl.xmission.com</a>></tt>, Karl Nelson
|
||||
<tt><<a href="mailto:kenelson@ece.ucdavis.edu">kenelson@ece.ucdavis.edu</a>></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 "hack" 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 "" or "std"
|
||||
based on an autoconf-test. Then you should be able to use
|
||||
<b>NS_STD::string</b>, which will evaluate to
|
||||
<b>::string</b> ("string in the global namespace") 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 "explicitly". So you can simply
|
||||
leave it out for input-streams.
|
||||
</p>
|
||||
<p>
|
||||
For output streams, "nocreate" 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><<a href="mailto:pedwards@disaster.jaj.com">pedwards@disaster.jaj.com</a>></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<..></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><ext/stdio_filebuf.h></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><math.h></tt>, you
|
||||
should use <tt><cmath></tt>. In some cases this has
|
||||
the advantage that the C++-header is more standardized than
|
||||
the C-header (i.e. <tt><ctime></tt> (almost)
|
||||
corresponds to either <tt><time.h></tt> or <tt><sys/time.h></tt>).
|
||||
|
||||
The standard specifies that if you include the C-style header
|
||||
(<tt><math.h></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><cmath></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 ("shadow") 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><fstream></tt> does
|
||||
not define <b>std::cout</b>,
|
||||
<b>std::cin</b> etc.</h3></div></div>
|
||||
<p>
|
||||
In earlier versions of the standard,
|
||||
<tt><fstream.h></tt>,
|
||||
<tt><ostream.h></tt>
|
||||
and <tt><istream.h></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><iostream></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<<(iterator)</b> to
|
||||
print the address of the iterator => use
|
||||
<b>operator<< &*iterator</b> instead ?
|
||||
</p></li>
|
||||
<li><p>you cannot clear an iterator's reference
|
||||
(<b>iterator = 0</b>) => use
|
||||
<b>iterator = iterator_type();</b> ?
|
||||
</p></li>
|
||||
<li><p>
|
||||
<b>if (iterator)</b> won't work any
|
||||
more => 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><cctype></tt>)</h2></div></div>
|
||||
<p>
|
||||
Glibc 2.0.x and 2.1.x define the
|
||||
<tt><ctype.h></tt>
|
||||
-functionality as macros (isspace, isalpha etc.). Libstdc++-v3
|
||||
"shadows" 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 <cctype>
|
||||
int main() { std::isspace('X'); }
|
||||
</pre>
|
||||
will result in something like this (unless using g++-v3):
|
||||
<pre class="programlisting">
|
||||
std:: (__ctype_b[(int) ( ( 'X' ) )] & (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 "wrapper" 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><ctype.h></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 <ctype.h> ]
|
||||
</pre>
|
||||
<p>
|
||||
Another problem arises if you put a <b>using namespace
|
||||
std;</b> declaration at the top, and include <tt><ctype.h></tt>. This will result in
|
||||
ambiguities between the definitions in the global namespace
|
||||
(<tt><ctype.h></tt>) and the
|
||||
definitions in namespace <b>std::</b>
|
||||
(<b><cctype></b>).
|
||||
</p>
|
||||
<p>
|
||||
The solution to this problem was posted to the libstdc++-v3
|
||||
mailing-list:
|
||||
Benjamin Kosnik <tt><<a href="mailto:bkoz@redhat.com">bkoz@redhat.com</a>></tt> writes:
|
||||
‘
|
||||
--enable-cshadow-headers is currently broken. As a result, shadow
|
||||
headers are not being searched....
|
||||
’
|
||||
This is now outdated, but gcc 3.0 still does not have fully
|
||||
compliant "shadow headers".
|
||||
</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 <vector>
|
||||
#include <deque>
|
||||
#include <string>
|
||||
|
||||
using namespace std;
|
||||
],
|
||||
[
|
||||
deque<int> test_deque(3);
|
||||
test_deque.at(2);
|
||||
vector<int> test_vector(2);
|
||||
test_vector.at(1);
|
||||
string test_string("test_string");
|
||||
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<char>::eof()</h2></div></div>
|
||||
<p>
|
||||
<pre class="programlisting">
|
||||
#ifdef HAVE_CHAR_TRAITS
|
||||
#define CPP_EOF std::char_traits<char>::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->size(), 0); }
|
||||
</pre>
|
||||
<pre class="programlisting">
|
||||
basic_string&
|
||||
erase(size_type __pos = 0, size_type __n = npos)
|
||||
{
|
||||
return this->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><sstream></tt>), but for compatibility
|
||||
with older implementations you still have to use
|
||||
<b>i/ostrstream</b> (<tt><strstream></tt>):
|
||||
<pre class="programlisting">
|
||||
#ifdef HAVE_SSTREAM
|
||||
#include <sstream>
|
||||
#else
|
||||
#include <strstream>
|
||||
#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 << "Name=" << m_name << ", number=" << m_number << std::endl;
|
||||
...
|
||||
#ifndef HAVE_SSTREAM
|
||||
oss << 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 >> i;
|
||||
</pre>
|
||||
One (the only?) restriction is that an istrstream cannot be re-filled:
|
||||
<pre class="programlisting">
|
||||
std::istringstream iss(numerator);
|
||||
iss >> m_num;
|
||||
// this is not possible with istrstream
|
||||
iss.clear();
|
||||
iss.str(denominator);
|
||||
iss >> m_den;
|
||||
</pre>
|
||||
If you don't care about speed, you can put these conversions in
|
||||
a template-function:
|
||||
<pre class="programlisting">
|
||||
template <class X>
|
||||
void fromString(const string& input, X& any)
|
||||
{
|
||||
#ifdef HAVE_SSTREAM
|
||||
std::istringstream iss(input);
|
||||
#else
|
||||
std::istrstream iss(input.c_str());
|
||||
#endif
|
||||
X temp;
|
||||
iss >> 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
|
||||
"info iostream", 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>
|
@ -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 © 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: <a name="Top">Top</a>,
|
||||
@ -44,14 +44,14 @@ Up: <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><ctype.h></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>
|
||||
|
@ -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>
|
@ -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" />
|
||||
|
@ -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>
|
||||
|
@ -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
|
||||
("heap") 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
|
||||
|
@ -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<int,MyClass> 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 ("heap") 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>
|
||||
|
@ -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<char></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
|
||||
|
@ -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 "C" (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>
|
||||
|
@ -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>
|
||||
|
@ -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 "C" (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
|
||||
|
@ -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<char>::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<char>& mssg_de = use_facet<messages<char> >(loc_de);
|
||||
|
||||
|
@ -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
|
||||
|
@ -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.
|
||||
|
@ -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" />
|
||||
|
@ -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
|
||||
|
@ -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>
|
||||
|
@ -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
|
@ -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 "C" abstraction.
|
||||
The default is 'stdio'. A longer explanation is <a
|
||||
href="explanations.html#cstdio">here</a>.
|
||||
The default is 'stdio'.
|
||||
</p>
|
||||
</dd>
|
||||
|
||||
|
@ -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>
|
||||
|
||||
<!-- ####################################################### -->
|
||||
|
@ -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">"the latest collection"</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><URL:ftp://gcc.gnu.org/pub/gcc/libstdc++/doxygen/></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><foo></code> vs <code><foo.h></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">"Hinting" 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 "Write after approval")</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 "Write after approval")</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">"the latest collection"</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><URL:ftp://gcc.gnu.org/pub/gcc/libstdc++/doxygen/></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.
|
||||
|
@ -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">"I/O packages", <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
|
||||
"FILE*") 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>
|
@ -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
|
||||
|
@ -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>
|
||||
|
||||
|
@ -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
|
||||
|
@ -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>
|
||||
|
||||
<!-- ####################################################### -->
|
||||
|
@ -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>
|
||||
|
||||
<!-- ####################################################### -->
|
@ -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>
|
||||
|
||||
|
||||
|
@ -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 <my
|
||||
<li><a href="#3_1">Can libstdc++ be used with <my
|
||||
favorite compiler>?</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<T>::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<T>::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
|
||||
".../docs/17_intro/" 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 ("<code>make
|
||||
install</code>") 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 <my
|
||||
<h2><a name="3_1">3.1 Can libstdc++ be used with <my
|
||||
favorite compiler>?</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 "bug" is an apparently missing
|
||||
"<code>../</code>" 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 "libstdc++". The BUGS file in the source
|
||||
tree also tracks known serious problems.
|
||||
category set to "libstdc++".
|
||||
</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 "standard" enough.
|
||||
libstdc++ if they seem to be "standard" enough.
|
||||
(For example, the "long long" type from C99.)
|
||||
Bugfixes and rewrites (to improve or fix thread safety, for
|
||||
instance) will of course be a continuing task.
|
||||
@ -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
@ -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>
|
||||
|
@ -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
|
@ -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
|
||||
|
@ -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
|
||||
|
||||
|
@ -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>
|
||||
|
@ -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
|
||||
|
||||
|
@ -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
|
||||
|
||||
|
@ -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)
|
||||
|
@ -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()
|
||||
{
|
||||
|
@ -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)
|
||||
|
@ -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;
|
||||
|
@ -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;
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user