-<?xml version='1.0'?>
-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
- "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
-[ ]>
+<book xmlns="http://docbook.org/ns/docbook" version="5.0">
-<book>
-
-<article id="faq" xreflabel="Frequently Asked Questions">
+<article xml:id="faq" xreflabel="Frequently Asked Questions">
<?dbhtml filename="faq.html"?>
-<articleinfo>
- <title>Frequently Asked Questions</title>
+<info><title>Frequently Asked Questions</title>
+
<copyright>
<year>
- 2008
+ 2008, 2010
</year>
<holder>
- <ulink url="http://www.fsf.org">FSF</ulink>
+ <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.fsf.org">FSF</link>
</holder>
</copyright>
-</articleinfo>
+</info>
<!-- FAQ starts here -->
<qandaset>
<!-- General Information -->
-<qandadiv id="faq.info" xreflabel="General Information">
-<title>General Information</title>
+<qandadiv xml:id="faq.info" xreflabel="General Information">
+
-<qandaentry id="faq.what">
- <question id="faq.what.q">
+<qandaentry xml:id="faq.what">
+ <question xml:id="faq.what.q">
<para>
What is libstdc++?
</para>
</question>
- <answer id="faq.what.a">
+ <answer xml:id="faq.what.a">
<para>
The GNU Standard C++ Library v3 is an ongoing project to
implement the ISO 14882 Standard C++ library as described in
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 <ulink url="http://gcc.gnu.org/svn.html">web</ulink>.
+ the <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/svn.html">web</link>.
</para>
</answer>
</qandaentry>
-<qandaentry id="faq.why">
- <question id="q-why">
+<qandaentry xml:id="faq.why">
+ <question xml:id="q-why">
<para>
Why should I use libstdc++?
</para>
</question>
- <answer id="a-why">
+ <answer xml:id="a-why">
<para>
The completion of the ISO C++ standardization gave the C++
community a powerful set of reuseable tools in the form of the C++
(<command>gcc</command>, <command>g++</command>, etc) is widely
considered to be one of the leading compilers in the world. Its
development is overseen by the
- <ulink url="http://gcc.gnu.org/">GCC team</ulink>. All of
+ <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/">GCC team</link>. All of
the rapid development and near-legendary
- <ulink url="http://gcc.gnu.org/buildstat.html">portability</ulink>
+ <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/buildstat.html">portability</link>
that are the hallmarks of an open-source project are being
applied to libstdc++.
</para>
</answer>
</qandaentry>
-<qandaentry id="faq.who">
- <question id="q-who">
+<qandaentry xml:id="faq.who">
+ <question xml:id="q-who">
<para>
Who's in charge of it?
</para>
</question>
- <answer id="a-who">
+ <answer xml:id="a-who">
<para>
The libstdc++ project is contributed to by several developers
- all over the world, in the same way as GCC or Linux.
+ all over the world, in the same way as GCC or the Linux kernel.
Benjamin Kosnik, Gabriel Dos Reis, Phil Edwards, Ulrich Drepper,
Loren James Rittle, and Paolo Carlini are the lead maintainers of
the SVN archive.
Development and discussion is held on the libstdc++ mailing
list. Subscribing to the list, or searching the list
archives, is open to everyone. You can read instructions for
- doing so on the <ulink url="http://gcc.gnu.org/libstdc++/">homepage</ulink>.
+ doing so on the <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/libstdc++/">homepage</link>.
If you have questions, ideas, code, or are just curious, sign up!
</para>
</answer>
</qandaentry>
-<qandaentry id="faq.when">
- <question id="q-when">
+<qandaentry xml:id="faq.when">
+ <question xml:id="q-when">
<para>
When is libstdc++ going to be finished?
</para>
</question>
- <answer id="a-when">
+ <answer xml:id="a-when">
<para>
Nathan Myers gave the best of all possible answers, responding to
a Usenet article asking this question: <emphasis>Sooner, if you
</answer>
</qandaentry>
-<qandaentry id="faq.how">
- <question id="q-how">
+<qandaentry xml:id="faq.how">
+ <question xml:id="q-how">
<para>
How do I contribute to the effort?
</para>
</question>
- <answer id="a-how">
+ <answer xml:id="a-how">
<para>
Here is <link linkend="appendix.contrib">a page devoted to
this topic</link>. Subscribing to the mailing list (see above, or
</answer>
</qandaentry>
-<qandaentry id="faq.whereis_old">
- <question id="q-whereis_old">
+<qandaentry xml:id="faq.whereis_old">
+ <question xml:id="q-whereis_old">
<para>
What happened to the older libg++? I need that!
</para>
</question>
- <answer id="a-whereis_old">
+ <answer xml:id="a-whereis_old">
<para>
The most recent libg++ README states that libg++ is no longer
being actively maintained. It should not be used for new
</answer>
</qandaentry>
-<qandaentry id="faq.more_questions">
- <question id="q-more_questions">
+<qandaentry xml:id="faq.more_questions">
+ <question xml:id="q-more_questions">
<para>
What if I have more questions?
</para>
</question>
- <answer id="a-more_questions">
+ <answer xml:id="a-more_questions">
<para>
If you have read the README file, and your question remains
unanswered, then just ask the mailing list. At present, you do not
</qandadiv>
<!-- License -->
-<qandadiv id="faq.license" xreflabel="License QA">
-<title>License</title>
+<qandadiv xml:id="faq.license" xreflabel="License QA">
+
-<qandaentry id="faq.license.what">
- <question id="q-license.what">
+<qandaentry xml:id="faq.license.what">
+ <question xml:id="q-license.what">
<para>
What are the license terms for libstdc++?
</para>
</question>
- <answer id="a-license.what">
+ <answer xml:id="a-license.what">
<para>
See <link linkend="manual.intro.status.license">our license description</link>
for these and related questions.
</answer>
</qandaentry>
-<qandaentry id="faq.license.any_program">
- <question id="q-license.any_program">
+<qandaentry xml:id="faq.license.any_program">
+ <question xml:id="q-license.any_program">
<para>
So any program which uses libstdc++ falls under the GPL?
</para>
</question>
- <answer id="a-license.any_program">
+ <answer xml:id="a-license.any_program">
<para>
No. The special exception permits use of the library in
proprietary applications.
</qandaentry>
-<qandaentry id="faq.license.lgpl">
- <question id="q-license.lgpl">
+<qandaentry xml:id="faq.license.lgpl">
+ <question xml:id="q-license.lgpl">
<para>
How is that different from the GNU {Lesser,Library} GPL?
</para>
</question>
- <answer id="a-license.lgpl">
+ <answer xml:id="a-license.lgpl">
<para>
The LGPL requires that users be able to replace the LGPL code with a
modified version; this is trivial if the library in question is a C
</answer>
</qandaentry>
-<qandaentry id="faq.license.what_restrictions">
- <question id="q-license.what_restrictions">
+<qandaentry xml:id="faq.license.what_restrictions">
+ <question xml:id="q-license.what_restrictions">
<para>
I see. So, what restrictions are there on programs that use the library?
</para>
</question>
- <answer id="a-license.what_restrictions">
+ <answer xml:id="a-license.what_restrictions">
<para>
None. We encourage such programs to be released as open source,
but we won't punish you or sue you if you choose otherwise.
</qandadiv>
<!-- Installation -->
-<qandadiv id="faq.installation" xreflabel="Installation">
-<title>Installation</title>
+<qandadiv xml:id="faq.installation" xreflabel="Installation">
-<qandaentry id="faq.how_to_install">
- <question id="q-how_to_install">
+
+<qandaentry xml:id="faq.how_to_install">
+ <question xml:id="q-how_to_install">
<para>How do I install libstdc++?
</para>
</question>
- <answer id="a-how_to_install">
+ <answer xml:id="a-how_to_install">
<para>
Often libstdc++ comes pre-installed as an integral part of many
- existing Linux and Unix systems, as well as many embedded
+ existing GNU/Linux and Unix systems, as well as many embedded
development tools. It may be necessary to install extra
development packages to get the headers, or the documentation, or
the source: please consult your vendor for details.
</answer>
</qandaentry>
-<qandaentry id="faq.how_to_get_sources">
- <question id="q-how_to_get_sources">
+<qandaentry xml:id="faq.how_to_get_sources">
+ <question xml:id="q-how_to_get_sources">
<para>How does one get current libstdc++ sources?
</para>
</question>
- <answer id="a-how_to_get_sources">
+ <answer xml:id="a-how_to_get_sources">
<para>
Libstdc++ sources for all official releases can be obtained as
part of the GCC sources, available from various sites and
- mirrors. A full <ulink url="http://gcc.gnu.org/mirrors.html">list of
- download sites</ulink> is provided on the main GCC site.
+ mirrors. A full <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/mirrors.html">list of
+ download sites</link> is provided on the main GCC site.
</para>
<para>
Current libstdc++ sources can always be checked out of the main
<application>Subversion</application>, or <acronym>SVN</acronym>, is
one of several revision control packages. It was selected for GNU
projects because it's free (speech), free (beer), and very high
- quality. The <ulink url="http://subversion.tigris.org"> Subversion
- home page</ulink> has a better description.
+ quality. The <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://subversion.tigris.org"> Subversion
+ home page</link> has a better description.
</para>
<para>
The <quote>anonymous client checkout</quote> feature of SVN is
</para>
<para>
For more information
- see <
ulink url="http://gcc.gnu.org/svn.html"><acronym>SVN</acronym>
- details</ulink>.
+ see <
link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/svn.html"><acronym>SVN</acronym>
+ details</link>.
</para>
</answer>
</qandaentry>
-<qandaentry id="faq.how_to_test">
- <question id="q-how_to_test">
+<qandaentry xml:id="faq.how_to_test">
+ <question xml:id="q-how_to_test">
<para>How do I know if it works?
</para>
</question>
- <answer id="a-how_to_test">
+ <answer xml:id="a-how_to_test">
<para>
Libstdc++ comes with its own validation testsuite, which includes
conformance testing, regression testing, ABI testing, and
performance testing. Please consult the
- <ulink url="http://gcc.gnu.org/install/test.html">testing
- documentation</ulink> for more details.
+ <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/install/test.html">testing
+ documentation</link> for more details.
</para>
<para>
If you find bugs in the testsuite programs themselves, or if you
</answer>
</qandaentry>
-<qandaentry id="faq.how_to_set_paths">
- <question id="q-how_to_set_paths">
+<qandaentry xml:id="faq.how_to_set_paths">
+ <question xml:id="q-how_to_set_paths">
<para>How do I insure that the dynamically linked library will be found?
</para>
</question>
- <answer id="a-how_to_set_paths">
+ <answer xml:id="a-how_to_set_paths">
<para>
Depending on your platform and library version, the error message might
be similar to one of the following:
is usually called something such as <filename>ld.so/rtld/dld.so</filename>.
</para>
<para>
- Using LD_LIBRARY_PATH is not always the best solution, <link
- linkend="manual.intro.using.linkage.dynamic">Finding Dynamic or Shared
+ Using LD_LIBRARY_PATH is not always the best solution, <link linkend="manual.intro.using.linkage.dynamic">Finding Dynamic or Shared
Libraries</link> in the manual gives some alternatives.
</para>
</answer>
</qandaentry>
-<qandaentry id="faq.what_is_libsupcxx">
- <question id="q-what_is_libsupcxx">
+<qandaentry xml:id="faq.what_is_libsupcxx">
+ <question xml:id="q-what_is_libsupcxx">
<para>
What's libsupc++?
</para>
</question>
- <answer id="a-what_is_libsupcxx">
+ <answer xml:id="a-what_is_libsupcxx">
<para>
If the only functions from <filename>libstdc++.a</filename>
which you need are language support functions (those listed in
</answer>
</qandaentry>
-<qandaentry id="faq.size">
- <question id="q-size">
+<qandaentry xml:id="faq.size">
+ <question xml:id="q-size">
<para>
This library is HUGE!
</para>
</question>
- <answer id="a-size">
+ <answer xml:id="a-size">
<para>
Usually the size of libraries on disk isn't noticeable. When a
link editor (or simply <quote>linker</quote>) pulls things from a
<!-- Platform-Specific Issues -->
-<qandadiv id="faq.platform-specific" xreflabel="Platform-Specific Issues">
-<title>Platform-Specific Issues</title>
+<qandadiv xml:id="faq.platform-specific" xreflabel="Platform-Specific Issues">
+
-<qandaentry id="faq.other_compilers">
- <question id="q-other_compilers">
+<qandaentry xml:id="faq.other_compilers">
+ <question xml:id="q-other_compilers">
<para>
Can libstdc++ be used with non-GNU compilers?
</para>
</question>
- <answer id="a-other_compilers">
+ <answer xml:id="a-other_compilers">
<para>
Perhaps.
</para>
non-standard features of g++ that are not present in older
versions of proprietary compilers. It may take as much as a year or two
after an official release of GCC that contains these features for
- proprietary tools support these constructs.
+ proprietary tools to support these constructs.
</para>
<para>
In the near past, specific released versions of libstdc++ have
</answer>
</qandaentry>
-<qandaentry id="faq.solaris_long_long">
- <question id="q-solaris_long_long">
+<qandaentry xml:id="faq.solaris_long_long">
+ <question xml:id="q-solaris_long_long">
<para>
No 'long long' type on Solaris?
</para>
</question>
- <answer id="a-solaris_long_long">
+ <answer xml:id="a-solaris_long_long">
<para>
By default we try to support the C99 <type>long long</type> type.
This requires that certain functions from your C library be present.
</answer>
</qandaentry>
-<qandaentry id="faq.predefined">
- <question id="q-predefined">
+<qandaentry xml:id="faq.predefined">
+ <question xml:id="q-predefined">
<para>
<constant>_XOPEN_SOURCE</constant> and <constant>_GNU_SOURCE</constant> are always defined?
</para>
</question>
- <answer id="a-predefined">
+ <answer xml:id="a-predefined">
<para>On Solaris, g++ (but not gcc) always defines the preprocessor
macro <constant>_XOPEN_SOURCE</constant>. On GNU/Linux, the same happens
with <constant>_GNU_SOURCE</constant>. (This is not an exhaustive list;
<para>To see which symbols are defined, look for CPLUSPLUS_CPP_SPEC in
the gcc config headers for your target (and try changing them to
see what happens when building complicated code). You can also run
- <command>g++ -E -dM - < /dev/null"</command> to display
+ <command>g++ -E -dM - < /dev/null"</command> to display
a list of predefined macros for any particular installation.
</para>
<para>This has been discussed on the mailing lists
- <ulink url="http://gcc.gnu.org/cgi-bin/htsearch?method=and&format=builtin-long&sort=score&words=_XOPEN_SOURCE+Solaris">quite a bit</ulink>.
+ <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/cgi-bin/htsearch?method=and&format=builtin-long&sort=score&words=_XOPEN_SOURCE+Solaris">quite a bit</link>.
</para>
<para>This method is something of a wart. We'd like to find a cleaner
solution, but nobody yet has contributed the time.
</answer>
</qandaentry>
-<qandaentry id="faq.darwin_ctype">
- <question id="q-darwin_ctype">
+<qandaentry xml:id="faq.darwin_ctype">
+ <question xml:id="q-darwin_ctype">
<para>
Mac OS X <filename class="headerfile">ctype.h</filename> is broken! How can I fix it?
</para>
</question>
- <answer id="a-darwin_ctype">
+ <answer xml:id="a-darwin_ctype">
<para>This is a long-standing bug in the OS X support. Fortunately,
the patch is quite simple, and well-known.
- <ulink url="http://gcc.gnu.org/ml/gcc/2002-03/msg00817.html"> Here's a
- link to the solution</ulink>.
+ <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/ml/gcc/2002-03/msg00817.html"> Here's a
+ link to the solution</link>.
</para>
</answer>
</qandaentry>
-<qandaentry id="faq.threads_i386">
- <question id="q-threads_i386">
+<qandaentry xml:id="faq.threads_i386">
+ <question xml:id="q-threads_i386">
<para>
Threading is broken on i386?
</para>
</question>
- <answer id="a-threads_i386">
+ <answer xml:id="a-threads_i386">
<para>
</para>
<para>Support for atomic integer operations is/was broken on i386
</answer>
</qandaentry>
-<qandaentry id="faq.atomic_mips">
- <question id="q-atomic_mips">
+<qandaentry xml:id="faq.atomic_mips">
+ <question xml:id="q-atomic_mips">
<para>
MIPS atomic operations
</para>
</question>
- <answer id="a-atomic_mips">
+ <answer xml:id="a-atomic_mips">
<para>
The atomic locking routines for MIPS targets requires MIPS II
and later. A patch went in just after the 3.3 release to
</answer>
</qandaentry>
-<qandaentry id="faq.linux_glibc">
- <question id="q-linux_glibc">
+<qandaentry xml:id="faq.linux_glibc">
+ <question xml:id="q-linux_glibc">
<para>
Recent GNU/Linux glibc required?
</para>
</question>
- <answer id="a-linux_glibc">
+ <answer xml:id="a-linux_glibc">
<para>When running on GNU/Linux, libstdc++ 3.2.1 (shared library version
5.0.1) and later uses localization and formatting code from the system
C library (glibc) version 2.2.5 which contains necessary bugfixes.
Most GNU/Linux distros make more recent versions available now.
+ libstdc++ 4.6.0 and later require glibc 2.3 or later for this
+ localization and formatting code.
</para>
<para>The guideline is simple: the more recent the C++ library, the
more recent the C library. (This is also documented in the main
</answer>
</qandaentry>
-<qandaentry id="faq.freebsd_wchar">
- <question id="q-freebsd_wchar">
+<qandaentry xml:id="faq.freebsd_wchar">
+ <question xml:id="q-freebsd_wchar">
<para>
Can't use wchar_t/wstring on FreeBSD
</para>
</question>
- <answer id="a-freebsd_wchar">
+ <answer xml:id="a-freebsd_wchar">
<para>
Older versions of FreeBSD's C library do not have sufficient
support for wide character functions, and as a result the
<!-- Known Bugs -->
-<qandadiv id="faq.known_bugs" xreflabel="Known Bugs">
-<title>Known Bugs</title>
+<qandadiv xml:id="faq.known_bugs" xreflabel="Known Bugs">
-<qandaentry id="faq.what_works">
- <question id="q-what_works">
+
+<qandaentry xml:id="faq.what_works">
+ <question xml:id="q-what_works">
<para>
What works already?
</para>
</question>
- <answer id="a-what_works">
+ <answer xml:id="a-what_works">
<para>
Short answer: Pretty much everything <emphasis>works</emphasis>
except for some corner cases. Support for localization
Long answer: See the implementation status pages for
<link linkend="status.iso.1998">C++98</link>,
<link linkend="status.iso.tr1">TR1</link>, and
- <link linkend="status.iso.200x">C++0x</link>.
+ <link linkend="status.iso.2011">C++11</link>.
</para>
</answer>
</qandaentry>
-<qandaentry id="faq.standard_bugs">
- <question id="q-standard_bugs">
+<qandaentry xml:id="faq.standard_bugs">
+ <question xml:id="q-standard_bugs">
<para>
Bugs in the ISO C++ language or library specification
</para>
</question>
- <answer id="a-standard_bugs">
+ <answer xml:id="a-standard_bugs">
<para>
Unfortunately, there are some.
</para>
For those people who are not part of the ISO Library Group
(i.e., nearly all of us needing to read this page in the first
place), a public list of the library defects is occasionally
- published <ulink url="http://www.open-std.org/jtc1/sc22/wg21/">here</ulink>.
+ published on <link xmlns:xlink="http://www.w3.org/1999/xlink"
+ xlink:href="http://www.open-std.org/jtc1/sc22/wg21/">the WG21
+ website</link>.
Some of these issues have resulted in code changes in libstdc++.
</para>
<para>
If you think you've discovered a new bug that is not listed,
- please post a message describing your problem
- to <email>libstdc++@gcc.gnu.org</email> or the Usenet group
- comp.lang.c++.moderated.
+ please post a message describing your problem to the author of
+ the library issues list or the Usenet group comp.lang.c++.moderated.
</para>
</answer>
</qandaentry>
-<qandaentry id="faq.compiler_bugs">
- <question id="q-compiler_bugs">
+<qandaentry xml:id="faq.compiler_bugs">
+ <question xml:id="q-compiler_bugs">
<para>
Bugs in the compiler (gcc/g++) and not libstdc++
</para>
</question>
- <answer id="a-compiler_bugs">
+ <answer xml:id="a-compiler_bugs">
<para>
On occasion, the compiler is wrong. Please be advised that this
happens much less often than one would think, and avoid jumping to
</para>
<para>
Before reporting a bug, please examine the
- <ulink url="http://gcc.gnu.org/bugs.html">bugs database</ulink> with the
+ <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/bugs/">bugs database</link> with the
category set to <quote>g++</quote>.
</para>
</answer>
</qandadiv>
<!-- Known Non-Bugs -->
-<qandadiv id="faq.known_non-bugs" xreflabel="Known Non-Bugs">
-<title>Known Non-Bugs</title>
+<qandadiv xml:id="faq.known_non-bugs" xreflabel="Known Non-Bugs">
+
-<qandaentry id="faq.stream_reopening_fails">
- <question id="q-stream_reopening_fails">
+<qandaentry xml:id="faq.stream_reopening_fails">
+ <question xml:id="q-stream_reopening_fails">
<para>
Reopening a stream fails
</para>
</question>
- <answer id="a-stream_reopening_fails">
+ <answer xml:id="a-stream_reopening_fails">
<para>
One of the most-reported non-bug reports. Executing a sequence like:
</para>
- <literallayout>
+ <literallayout class="normal">
#include <fstream>
...
std::fstream fs(<quote>a_file</quote>);
</answer>
</qandaentry>
-<qandaentry id="faq.wefcxx_verbose">
- <question id="q-wefcxx_verbose">
+<qandaentry xml:id="faq.wefcxx_verbose">
+ <question xml:id="q-wefcxx_verbose">
<para>
-Weffc++ complains too much
</para>
</question>
- <answer id="a-wefcxx_verbose">
+ <answer xml:id="a-wefcxx_verbose">
<para>
Many warnings are emitted when <literal>-Weffc++</literal> is used. Making
libstdc++ <literal>-Weffc++</literal>-clean is not a goal of the project,
</answer>
</qandaentry>
-<qandaentry id="faq.ambiguous_overloads">
- <question id="q-ambiguous_overloads">
+<qandaentry xml:id="faq.ambiguous_overloads">
+ <question xml:id="q-ambiguous_overloads">
<para>
Ambiguous overloads after including an old-style header
</para>
</question>
- <answer id="a-ambiguous_overloads">
+ <answer xml:id="a-ambiguous_overloads">
<para>
Another problem is the <literal>rel_ops</literal> namespace and the template
comparison operator functions contained therein. If they become
(e.g., <quote>using</quote> them and the <iterator> header),
then you will suddenly be faced with huge numbers of ambiguity
errors. This was discussed on the -v3 list; Nathan Myers
- <ulink url="http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html">sums
- things up here</ulink>. The collisions with vector/string iterator
+ <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html">sums
+ things up here</link>. The collisions with vector/string iterator
types have been fixed for 3.1.
</para>
</answer>
</qandaentry>
-<qandaentry id="faq.v2_headers">
- <question id="q-v2_headers">
+<qandaentry xml:id="faq.v2_headers">
+ <question xml:id="q-v2_headers">
<para>
The g++-3 headers are <emphasis>not ours</emphasis>
</para>
</question>
- <answer id="a-v2_headers">
+ <answer xml:id="a-v2_headers">
<para>
- If you have found an extremely broken header file which is
- causing problems for you, look carefully before submitting a
- "high" priority bug report (which you probably
- shouldn't do anyhow; see the last paragraph of the page
- describing <ulink url="http://gcc.gnu.org/bugs.html">the GCC
- bug database</ulink>).
- </para>
- <para>
- If the headers are in <filename>${prefix}/include/g++-3</filename>, or
- if the installed library's name looks like
- <filename>libstdc++-2.10.a</filename> or
+ If you are using headers in
+ <filename>${prefix}/include/g++-3</filename>, or if the installed
+ library's name looks like <filename>libstdc++-2.10.a</filename> or
<filename>libstdc++-libc6-2.10.so</filename>, then you are using the
old libstdc++-v2 library, which is nonstandard and
unmaintained. Do not report problems with -v2 to the -v3
</answer>
</qandaentry>
-<qandaentry id="faq.boost_concept_checks">
- <question id="q-boost_concept_checks">
+<qandaentry xml:id="faq.boost_concept_checks">
+ <question xml:id="q-boost_concept_checks">
<para>
Errors about <emphasis>*Concept</emphasis> and
<emphasis>constraints</emphasis> in the STL
</para>
</question>
- <answer id="a-boost_concept_checks">
+ <answer xml:id="a-boost_concept_checks">
<para>
If you see compilation errors containing messages about
<errortext>foo Concept </errortext>and something to do with a
</answer>
</qandaentry>
-<qandaentry id="faq.dlopen_crash">
- <question id="q-dlopen_crash">
+<qandaentry xml:id="faq.dlopen_crash">
+ <question xml:id="q-dlopen_crash">
<para>
Program crashes when using library code in a
dynamically-loaded library
</para>
</question>
- <answer id="a-dlopen_crash">
+ <answer xml:id="a-dlopen_crash">
<para>
If you are using the C++ library across dynamically-loaded
objects, make certain that you are passing the correct options
when compiling and linking:
</para>
- <literallayout>
+ <literallayout class="normal">
// compile your library components
g++ -fPIC -c a.cc
g++ -fPIC -c b.cc
</answer>
</qandaentry>
-<qandaentry id="faq.memory_leaks">
- <question id="q-memory_leaks">
+<qandaentry xml:id="faq.memory_leaks">
+ <question xml:id="q-memory_leaks">
<para>
<quote>Memory leaks</quote> in containers
</para>
</question>
- <answer id="a-memory_leaks">
+ <answer xml:id="a-memory_leaks">
<para>
A few people have reported that the standard containers appear
to leak memory when tested with memory checkers such as
- <ulink url="http://valgrind.org/">valgrind</ulink>.
+ <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://valgrind.org/">valgrind</link>.
The library's default allocators keep free memory in a pool
for later reuse, rather than returning it to the OS. Although
this memory is always reachable by the library and is never
</answer>
</qandaentry>
-<qandaentry id="faq.list_size_on">
- <question id="q-list_size_on">
+<qandaentry xml:id="faq.list_size_on">
+ <question xml:id="q-list_size_on">
<para>
list::size() is O(n)!
</para>
</question>
- <answer id="a-list_size_on">
+ <answer xml:id="a-list_size_on">
<para>
See
the <link linkend="std.containers">Containers</link>
</answer>
</qandaentry>
-<qandaentry id="faq.easy_to_fix">
- <question id="q-easy_to_fix">
+<qandaentry xml:id="faq.easy_to_fix">
+ <question xml:id="q-easy_to_fix">
<para>
Aw, that's easy to fix!
</para>
</question>
- <answer id="a-easy_to_fix">
+ <answer xml:id="a-easy_to_fix">
<para>
If you have found a bug in the library and you think you have
a working fix, then send it in! The main GCC site has a page
- on <ulink url="http://gcc.gnu.org/contribute.html">submitting
- patches</ulink> that covers the procedure, but for libstdc++ you
+ on <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/contribute.html">submitting
+ patches</link> that covers the procedure, but for libstdc++ you
should also send the patch to our mailing list in addition to
the GCC patches mailing list. The libstdc++
<link linkend="appendix.contrib">contributors' page</link>
<para>
In addition to the description, the patch, and the ChangeLog
entry, it is a Good Thing if you can additionally create a small
- test program to test for the presence of the bug that your
- patch fixes. Bugs have a way of being reintroduced; if an old
- bug creeps back in, it will be caught immediately by the
- <ulink url="#2_4">testsuite</ulink> -- but only if such a test exists.
+ test program to test for the presence of the bug that your patch
+ fixes. Bugs have a way of being reintroduced; if an old bug
+ creeps back in, it will be caught immediately by the testsuite -
+ but only if such a test exists.
</para>
</answer>
</qandaentry>
<!-- Miscellaneous -->
-<qandadiv id="faq.misc" xreflabel="Miscellaneous">
-<title>Miscellaneous</title>
+<qandadiv xml:id="faq.misc" xreflabel="Miscellaneous">
+
-<qandaentry id="faq.iterator_as_pod">
- <question id="faq.iterator_as_pod_q">
+<qandaentry xml:id="faq.iterator_as_pod">
+ <question xml:id="faq.iterator_as_pod_q">
<para>
string::iterator is not char*; vector<T>::iterator is not T*
</para>
</question>
- <answer id="faq.iterator_as_pod_a">
+ <answer xml:id="faq.iterator_as_pod_a">
<para>
If you have code that depends on container<T> iterators
being implemented as pointer-to-T, your code is broken. It's
</answer>
</qandaentry>
-<qandaentry id="faq.what_is_next">
- <question id="q-what_is_next">
+<qandaentry xml:id="faq.what_is_next">
+ <question xml:id="q-what_is_next">
<para>
What's next after libstdc++?
</para>
</question>
- <answer id="a-what_is_next">
+ <answer xml:id="a-what_is_next">
<para>
Hopefully, not much. The goal of libstdc++ is to produce a
fully-compliant, fully-portable Standard Library. After that,
There is an effort underway to add significant extensions to
the standard library specification. The latest version of
this effort is described in
- <ulink url="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">
- The C++ Library Technical Report 1</ulink>.
+ <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">
+ The C++ Library Technical Report 1</link>.
</para>
</answer>
</qandaentry>
-<qandaentry id="faq.sgi_stl">
- <question id="q-sgi_stl">
+<qandaentry xml:id="faq.sgi_stl">
+ <question xml:id="q-sgi_stl">
<para>
What about the STL from SGI?
</para>
</question>
- <answer id="a-sgi_stl">
+ <answer xml:id="a-sgi_stl">
<para>
- The <ulink url="http://www.sgi.com/tech/stl/">STL from SGI</ulink>,
+ The <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.sgi.com/tech/stl/">STL from SGI</link>,
version 3.3, was the final merge of the STL codebase. The
code in libstdc++ contains many fixes and changes, and
the SGI code is no longer under active
</para>
<para>
In particular, <classname>string</classname> is not from SGI and makes no
- use of their "rope" class (which is included as an
+ use of their "rope" class (which is included as an
optional extension), nor is <classname>valarray</classname> and some others.
Classes like <classname>vector<></classname> are, but have been
extensively modified.
</answer>
</qandaentry>
-<qandaentry id="faq.extensions_and_backwards_compat">
- <question id="q-extensions_and_backwards_compat">
+<qandaentry xml:id="faq.extensions_and_backwards_compat">
+ <question xml:id="q-extensions_and_backwards_compat">
<para>
Extensions and Backward Compatibility
</para>
</question>
- <answer id="a-extensions_and_backwards_compat">
+ <answer xml:id="a-extensions_and_backwards_compat">
<para>
See the <link linkend="manual.appendix.porting.backwards">link</link> on backwards compatibility and <link linkend="appendix.porting.api">link</link> on evolution.
</para>
</answer>
</qandaentry>
-<qandaentry id="faq.tr1_support">
- <question id="q-tr1_support">
+<qandaentry xml:id="faq.tr1_support">
+ <question xml:id="q-tr1_support">
<para>
Does libstdc++ support TR1?
</para>
</question>
- <answer id="a-tr1_support">
+ <answer xml:id="a-tr1_support">
<para>
Yes.
</para>
<para>
The C++ Standard Library Technical Report adds many new features to
the library. The latest version of this effort is described in
- <ulink url=
- "http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">
- Technical Report 1</ulink>.
+ <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">
+ Technical Report 1</link>.
</para>
<para>
- The implementation status of TR1 in libstdc++ can be tracked <link
- linkend="status.iso.tr1">on the TR1 status
+ The implementation status of TR1 in libstdc++ can be tracked <link linkend="status.iso.tr1">on the TR1 status
page</link>.
</para>
</answer>
</qandaentry>
-<qandaentry id="faq.get_iso_cxx">
- <question id="q-get_iso_cxx">
+<qandaentry xml:id="faq.get_iso_cxx">
+ <question xml:id="q-get_iso_cxx">
<para>How do I get a copy of the ISO C++ Standard?
</para>
</question>
- <answer id="a-get_iso_cxx">
+ <answer xml:id="a-get_iso_cxx">
<para>
Copies of the full ISO 14882 standard are available on line via
the ISO mirror site for committee members. Non-members, or those
get a copy of the standard from their respective national
standards organization. In the USA, this national standards
organization is ANSI and their website is
- right <ulink url="http://www.ansi.org">here</ulink>. (And if
+ right <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.ansi.org">here</link>. (And if
you've already registered with them, clicking this link will take
you to directly to the place where you can
- <ulink url="http://webstore.ansi.org/RecordDetail.aspx?sku=ISO%2FIEC+14882:2003">buy the standard on-line</ulink>.
+ <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://webstore.ansi.org/RecordDetail.aspx?sku=ISO%2FIEC+14882:2003">buy the standard on-line</link>.
</para>
<para>
Who is your country's member body? Visit the
- <ulink url="http://www.iso.ch/">ISO homepage</ulink> and find out!
+ <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.iso.ch/">ISO homepage</link> and find out!
</para>
<para>
The 2003 version of the standard (the 1998 version plus TC1) is
</answer>
</qandaentry>
-<qandaentry id="faq.what_is_abi">
- <question id="q-what_is_abi">
+<qandaentry xml:id="faq.what_is_abi">
+ <question xml:id="q-what_is_abi">
<para>
What's an ABI and why is it so messy?
</para>
</question>
- <answer id="a-what_is_abi">
+ <answer xml:id="a-what_is_abi">
<para>
<acronym>ABI</acronym> stands for <quote>Application Binary
Interface</quote>. Conventionally, it refers to a great
</answer>
</qandaentry>
-<qandaentry id="faq.size_equals_capacity">
- <question id="q-size_equals_capacity">
+<qandaentry xml:id="faq.size_equals_capacity">
+ <question xml:id="q-size_equals_capacity">
<para>
How do I make std::vector<T>::capacity() == std::vector<T>::size?
</para>
</question>
- <answer id="a-size_equals_capacity">
+ <answer xml:id="a-size_equals_capacity">
<para>
The standard idiom for deallocating a <classname>vector<T></classname>'s
unused memory is to create a temporary copy of the vector and swap their
contents, e.g. for <classname>vector<T> v</classname>
</para>
- <literallayout>
+ <literallayout class="normal">
std::vector<T>(v).swap(v);
</literallayout>
<para>
OSDN Git Service
