mirror of
https://github.com/autc04/Retro68.git
synced 2024-12-22 19:30:36 +00:00
913 lines
67 KiB
HTML
913 lines
67 KiB
HTML
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||
<!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"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Frequently Asked Questions</title><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><meta name="keywords" content="ISO C++, runtime, library" /><link rel="home" href="index.html" title="The GNU C++ Library" /><link rel="up" href="bk03.html" title="" /><link rel="prev" href="bk03.html" title="" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Frequently Asked Questions</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk03.html">Prev</a> </td><th width="60%" align="center"></th><td width="20%" align="right"> </td></tr></table><hr /></div><div class="article"><div class="titlepage"><div><div><h1 class="title"><a id="faq"></a>Frequently Asked Questions</h1></div><div><p class="copyright">Copyright ©
|
||
2008-2018
|
||
|
||
<a class="link" href="https://www.fsf.org" target="_top">FSF</a>
|
||
</p></div></div><hr /></div><div class="qandaset"><a id="faq.faq"></a><dl><dt></dt><dd><dl><dt>1.1. <a href="faq.html#faq.what">
|
||
What is libstdc++?
|
||
</a></dt><dt>1.2. <a href="faq.html#faq.why">
|
||
Why should I use libstdc++?
|
||
</a></dt><dt>1.3. <a href="faq.html#faq.who">
|
||
Who's in charge of it?
|
||
</a></dt><dt>1.4. <a href="faq.html#faq.when">
|
||
When is libstdc++ going to be finished?
|
||
</a></dt><dt>1.5. <a href="faq.html#faq.how">
|
||
How do I contribute to the effort?
|
||
</a></dt><dt>1.6. <a href="faq.html#faq.whereis_old">
|
||
What happened to the older libg++? I need that!
|
||
</a></dt><dt>1.7. <a href="faq.html#faq.more_questions">
|
||
What if I have more questions?
|
||
</a></dt></dl></dd><dt></dt><dd><dl><dt>2.1. <a href="faq.html#faq.license.what">
|
||
What are the license terms for libstdc++?
|
||
</a></dt><dt>2.2. <a href="faq.html#faq.license.any_program">
|
||
So any program which uses libstdc++ falls under the GPL?
|
||
</a></dt><dt>2.3. <a href="faq.html#faq.license.lgpl">
|
||
How is that different from the GNU {Lesser,Library} GPL?
|
||
</a></dt><dt>2.4. <a href="faq.html#faq.license.what_restrictions">
|
||
I see. So, what restrictions are there on programs that use the library?
|
||
</a></dt></dl></dd><dt></dt><dd><dl><dt>3.1. <a href="faq.html#faq.how_to_install">How do I install libstdc++?
|
||
</a></dt><dt>3.2. <a href="faq.html#faq.how_to_get_sources">How does one get current libstdc++ sources?
|
||
</a></dt><dt>3.3. <a href="faq.html#faq.how_to_test">How do I know if it works?
|
||
</a></dt><dt>3.4. <a href="faq.html#faq.how_to_set_paths">How do I insure that the dynamically linked library will be found?
|
||
</a></dt><dt>3.5. <a href="faq.html#faq.what_is_libsupcxx">
|
||
What's libsupc++?
|
||
</a></dt><dt>3.6. <a href="faq.html#faq.size">
|
||
This library is HUGE!
|
||
</a></dt></dl></dd><dt></dt><dd><dl><dt>4.1. <a href="faq.html#faq.other_compilers">
|
||
Can libstdc++ be used with non-GNU compilers?
|
||
</a></dt><dt>4.2. <a href="faq.html#faq.solaris_long_long">
|
||
No 'long long' type on Solaris?
|
||
</a></dt><dt>4.3. <a href="faq.html#faq.predefined">
|
||
_XOPEN_SOURCE and _GNU_SOURCE are always defined?
|
||
</a></dt><dt>4.4. <a href="faq.html#faq.darwin_ctype">
|
||
Mac OS X ctype.h is broken! How can I fix it?
|
||
</a></dt><dt>4.5. <a href="faq.html#faq.threads_i386">
|
||
Threading is broken on i386?
|
||
</a></dt><dt>4.6. <a href="faq.html#faq.atomic_mips">
|
||
MIPS atomic operations
|
||
</a></dt><dt>4.7. <a href="faq.html#faq.linux_glibc">
|
||
Recent GNU/Linux glibc required?
|
||
</a></dt><dt>4.8. <a href="faq.html#faq.freebsd_wchar">
|
||
Can't use wchar_t/wstring on FreeBSD
|
||
</a></dt></dl></dd><dt></dt><dd><dl><dt>5.1. <a href="faq.html#faq.what_works">
|
||
What works already?
|
||
</a></dt><dt>5.2. <a href="faq.html#faq.standard_bugs">
|
||
Bugs in the ISO C++ language or library specification
|
||
</a></dt><dt>5.3. <a href="faq.html#faq.compiler_bugs">
|
||
Bugs in the compiler (gcc/g++) and not libstdc++
|
||
</a></dt></dl></dd><dt></dt><dd><dl><dt>6.1. <a href="faq.html#faq.stream_reopening_fails">
|
||
Reopening a stream fails
|
||
</a></dt><dt>6.2. <a href="faq.html#faq.wefcxx_verbose">
|
||
-Weffc++ complains too much
|
||
</a></dt><dt>6.3. <a href="faq.html#faq.ambiguous_overloads">
|
||
Ambiguous overloads after including an old-style header
|
||
</a></dt><dt>6.4. <a href="faq.html#faq.v2_headers">
|
||
The g++-3 headers are not ours
|
||
</a></dt><dt>6.5. <a href="faq.html#faq.boost_concept_checks">
|
||
Errors about *Concept and
|
||
constraints in the STL
|
||
</a></dt><dt>6.6. <a href="faq.html#faq.dlopen_crash">
|
||
Program crashes when using library code in a
|
||
dynamically-loaded library
|
||
</a></dt><dt>6.7. <a href="faq.html#faq.memory_leaks">
|
||
“Memory leaks” in libstdc++
|
||
</a></dt><dt>6.8. <a href="faq.html#faq.list_size_on">
|
||
list::size() is O(n)!
|
||
</a></dt><dt>6.9. <a href="faq.html#faq.easy_to_fix">
|
||
Aw, that's easy to fix!
|
||
</a></dt></dl></dd><dt></dt><dd><dl><dt>7.1. <a href="faq.html#faq.iterator_as_pod">
|
||
string::iterator is not char*;
|
||
vector<T>::iterator is not T*
|
||
</a></dt><dt>7.2. <a href="faq.html#faq.what_is_next">
|
||
What's next after libstdc++?
|
||
</a></dt><dt>7.3. <a href="faq.html#faq.sgi_stl">
|
||
What about the STL from SGI?
|
||
</a></dt><dt>7.4. <a href="faq.html#faq.extensions_and_backwards_compat">
|
||
Extensions and Backward Compatibility
|
||
</a></dt><dt>7.5. <a href="faq.html#faq.tr1_support">
|
||
Does libstdc++ support TR1?
|
||
</a></dt><dt>7.6. <a href="faq.html#faq.get_iso_cxx">How do I get a copy of the ISO C++ Standard?
|
||
</a></dt><dt>7.7. <a href="faq.html#faq.what_is_abi">
|
||
What's an ABI and why is it so messy?
|
||
</a></dt><dt>7.8. <a href="faq.html#faq.size_equals_capacity">
|
||
How do I make std::vector<T>::capacity() == std::vector<T>::size?
|
||
</a></dt></dl></dd></dl><table border="0" style="width: 100%;"><colgroup><col align="left" width="1%" /><col /></colgroup><tbody><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>1.1. <a href="faq.html#faq.what">
|
||
What is libstdc++?
|
||
</a></dt><dt>1.2. <a href="faq.html#faq.why">
|
||
Why should I use libstdc++?
|
||
</a></dt><dt>1.3. <a href="faq.html#faq.who">
|
||
Who's in charge of it?
|
||
</a></dt><dt>1.4. <a href="faq.html#faq.when">
|
||
When is libstdc++ going to be finished?
|
||
</a></dt><dt>1.5. <a href="faq.html#faq.how">
|
||
How do I contribute to the effort?
|
||
</a></dt><dt>1.6. <a href="faq.html#faq.whereis_old">
|
||
What happened to the older libg++? I need that!
|
||
</a></dt><dt>1.7. <a href="faq.html#faq.more_questions">
|
||
What if I have more questions?
|
||
</a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.what"></a><a id="faq.what.q"></a><p><strong>1.1.</strong></p></td><td align="left" valign="top"><p>
|
||
What is libstdc++?
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="faq.what.a"></a></td><td align="left" valign="top"><p>
|
||
The GNU Standard C++ Library v3 is an ongoing project to
|
||
implement the ISO 14882 C++ Standard Library as described in
|
||
clauses 20 through 33 and annex D (prior to the 2017 standard
|
||
the library clauses started with 17). 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 can be cloned via
|
||
<a class="link" href="https://gcc.gnu.org/git.html" target="_top">Git</a>.
|
||
</p><p>
|
||
N.B. The library is called libstdc++ <span class="emphasis"><em>not</em></span> stdlibc++.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.why"></a><a id="q-why"></a><p><strong>1.2.</strong></p></td><td align="left" valign="top"><p>
|
||
Why should I use libstdc++?
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-why"></a></td><td align="left" valign="top"><p>
|
||
The completion of the initial ISO C++ standardization effort gave the C++
|
||
community a powerful set of reuseable tools in the form of the C++
|
||
Standard Library. However, for several years C++ implementations were
|
||
(as the Draft Standard used to say) <span class="quote">“<span class="quote">incomplet and
|
||
incorrekt</span>”</span>, and many suffered from limitations of the compilers
|
||
that used them.
|
||
</p><p>
|
||
The GNU compiler collection
|
||
(<span class="command"><strong>gcc</strong></span>, <span class="command"><strong>g++</strong></span>, etc) is widely
|
||
considered to be one of the leading compilers in the world. Its
|
||
development is overseen by the
|
||
<a class="link" href="https://gcc.gnu.org/" target="_top">GCC team</a>. All of
|
||
the rapid development and near-legendary
|
||
<a class="link" href="https://gcc.gnu.org/buildstat.html" target="_top">portability</a>
|
||
that are the hallmarks of an open-source project are applied to libstdc++.
|
||
</p><p>
|
||
All of the standard classes and functions from C++98/C++03, C++11 and C++14
|
||
(such as <code class="classname">string</code>,
|
||
<code class="classname">vector<></code>, iostreams, algorithms etc.)
|
||
are freely available and attempt to be fully compliant.
|
||
Work is ongoing to complete support for the current revision of the
|
||
ISO C++ Standard.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.who"></a><a id="q-who"></a><p><strong>1.3.</strong></p></td><td align="left" valign="top"><p>
|
||
Who's in charge of it?
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-who"></a></td><td align="left" valign="top"><p>
|
||
The libstdc++ project is contributed to by several developers
|
||
all over the world, in the same way as GCC or the Linux kernel.
|
||
The current maintainers are listed in the
|
||
<a class="link" href="https://gcc.gnu.org/viewcvs/gcc/trunk/MAINTAINERS?view=co" target="_top"><code class="filename">MAINTAINERS</code></a>
|
||
file (look for "c++ runtime libs").
|
||
</p><p>
|
||
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 <a class="link" href="https://gcc.gnu.org/lists.html" target="_top">GCC mailing lists</a> page.
|
||
If you have questions, ideas, code, or are just curious, sign up!
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.when"></a><a id="q-when"></a><p><strong>1.4.</strong></p></td><td align="left" valign="top"><p>
|
||
When is libstdc++ going to be finished?
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-when"></a></td><td align="left" valign="top"><p>
|
||
Nathan Myers gave the best of all possible answers, responding to
|
||
a Usenet article asking this question: <span class="emphasis"><em>Sooner, if you
|
||
help.</em></span>
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.how"></a><a id="q-how"></a><p><strong>1.5.</strong></p></td><td align="left" valign="top"><p>
|
||
How do I contribute to the effort?
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how"></a></td><td align="left" valign="top"><p>
|
||
See the <a class="link" href="manual/appendix_contributing.html" title="Appendix A. Contributing">Contributing</a> section in
|
||
the manual. Subscribing to the mailing list (see above, or
|
||
the homepage) is a very good idea if you have something to
|
||
contribute, or if you have spare time and want to
|
||
help. Contributions don't have to be in the form of source code;
|
||
anybody who is willing to help write documentation, for example,
|
||
or has found a bug in code that we all thought was working and is
|
||
willing to provide details, is more than welcome!
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.whereis_old"></a><a id="q-whereis_old"></a><p><strong>1.6.</strong></p></td><td align="left" valign="top"><p>
|
||
What happened to the older libg++? I need that!
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-whereis_old"></a></td><td align="left" valign="top"><p>
|
||
The last libg++ README states
|
||
<span class="quote">“<span class="quote">This package is considered obsolete and is no longer
|
||
being developed.</span>”</span>
|
||
It should not be used for new projects, and won't even compile with
|
||
recent releases of GCC (or most other C++ compilers).
|
||
</p><p>
|
||
More information can be found in the
|
||
<a class="link" href="manual/backwards.html" title="Backwards Compatibility">Backwards
|
||
Compatibility</a> section of the libstdc++ manual.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.more_questions"></a><a id="q-more_questions"></a><p><strong>1.7.</strong></p></td><td align="left" valign="top"><p>
|
||
What if I have more questions?
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-more_questions"></a></td><td align="left" valign="top"><p>
|
||
If you have read the documentation, 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 homepage (including how to browse
|
||
the list archives); to send a message to the list,
|
||
use <code class="email"><<a class="email" href="mailto:libstdc++@gcc.gnu.org">libstdc++@gcc.gnu.org</a>></code>.
|
||
</p><p>
|
||
If you have a question that you think should be included
|
||
here, or if you have a question <span class="emphasis"><em>about</em></span> a question/answer
|
||
here, please send email to the libstdc++ mailing list, as above.
|
||
</p></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>2.1. <a href="faq.html#faq.license.what">
|
||
What are the license terms for libstdc++?
|
||
</a></dt><dt>2.2. <a href="faq.html#faq.license.any_program">
|
||
So any program which uses libstdc++ falls under the GPL?
|
||
</a></dt><dt>2.3. <a href="faq.html#faq.license.lgpl">
|
||
How is that different from the GNU {Lesser,Library} GPL?
|
||
</a></dt><dt>2.4. <a href="faq.html#faq.license.what_restrictions">
|
||
I see. So, what restrictions are there on programs that use the library?
|
||
</a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.license.what"></a><a id="q-license.what"></a><p><strong>2.1.</strong></p></td><td align="left" valign="top"><p>
|
||
What are the license terms for libstdc++?
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-license.what"></a></td><td align="left" valign="top"><p>
|
||
See <a class="link" href="manual/license.html" title="License">our license description</a>
|
||
for these and related questions.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.license.any_program"></a><a id="q-license.any_program"></a><p><strong>2.2.</strong></p></td><td align="left" valign="top"><p>
|
||
So any program which uses libstdc++ falls under the GPL?
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-license.any_program"></a></td><td align="left" valign="top"><p>
|
||
No. The special exception permits use of the library in
|
||
proprietary applications.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.license.lgpl"></a><a id="q-license.lgpl"></a><p><strong>2.3.</strong></p></td><td align="left" valign="top"><p>
|
||
How is that different from the GNU {Lesser,Library} GPL?
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-license.lgpl"></a></td><td align="left" valign="top"><p>
|
||
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
|
||
shared library. But there's no way to make that work with C++, where
|
||
much of the library consists of inline functions and templates, which
|
||
are expanded inside the code that uses the library. So to allow people
|
||
to replace the library code, someone using the library would have to
|
||
distribute their own source, rendering the LGPL equivalent to the GPL.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.license.what_restrictions"></a><a id="q-license.what_restrictions"></a><p><strong>2.4.</strong></p></td><td align="left" valign="top"><p>
|
||
I see. So, what restrictions are there on programs that use the library?
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-license.what_restrictions"></a></td><td align="left" valign="top"><p>
|
||
None. We encourage such programs to be released as free software,
|
||
but we won't punish you or sue you if you choose otherwise.
|
||
</p></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>3.1. <a href="faq.html#faq.how_to_install">How do I install libstdc++?
|
||
</a></dt><dt>3.2. <a href="faq.html#faq.how_to_get_sources">How does one get current libstdc++ sources?
|
||
</a></dt><dt>3.3. <a href="faq.html#faq.how_to_test">How do I know if it works?
|
||
</a></dt><dt>3.4. <a href="faq.html#faq.how_to_set_paths">How do I insure that the dynamically linked library will be found?
|
||
</a></dt><dt>3.5. <a href="faq.html#faq.what_is_libsupcxx">
|
||
What's libsupc++?
|
||
</a></dt><dt>3.6. <a href="faq.html#faq.size">
|
||
This library is HUGE!
|
||
</a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.how_to_install"></a><a id="q-how_to_install"></a><p><strong>3.1.</strong></p></td><td align="left" valign="top"><p>How do I install libstdc++?
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how_to_install"></a></td><td align="left" valign="top"><p>
|
||
Often libstdc++ comes pre-installed as an integral part of many
|
||
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.
|
||
</p><p>
|
||
To build and install from the GNU GCC sources, please consult the
|
||
<a class="link" href="manual/setup.html" title="Chapter 2. Setup">setup
|
||
documentation</a> for detailed
|
||
instructions. You may wish to browse those files ahead
|
||
of time to get a feel for what's required.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.how_to_get_sources"></a><a id="q-how_to_get_sources"></a><p><strong>3.2.</strong></p></td><td align="left" valign="top"><p>How does one get current libstdc++ sources?
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how_to_get_sources"></a></td><td align="left" valign="top"><p>
|
||
Libstdc++ sources for all official releases can be obtained as
|
||
part of the GCC sources, available from various sites and
|
||
mirrors. A full <a class="link" href="https://gcc.gnu.org/mirrors.html" target="_top">list of
|
||
download sites</a> is provided on the main GCC site.
|
||
</p><p>
|
||
Current libstdc++ sources can always be found in the main GCC source
|
||
repository, available using the appropriate version control tool.
|
||
At this time, that tool is <span class="application">Git</span>.
|
||
For more details see the documentation on
|
||
<a class="link" href="https://gcc.gnu.org/git.html" target="_top">using the Git repository</a>.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.how_to_test"></a><a id="q-how_to_test"></a><p><strong>3.3.</strong></p></td><td align="left" valign="top"><p>How do I know if it works?
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how_to_test"></a></td><td align="left" valign="top"><p>
|
||
Libstdc++ comes with its own validation testsuite, which includes
|
||
conformance testing, regression testing, ABI testing, and
|
||
performance testing. Please consult the
|
||
<a class="link" href="http://gcc.gnu.org/install/test.html" target="_top">testing
|
||
documentation</a> for GCC and
|
||
<a class="link" href="manual/test.html" title="Testing">Testing</a> in the libstdc++
|
||
manual for more details.
|
||
</p><p>
|
||
If you find bugs in the testsuite programs themselves, or if you
|
||
think of a new test program that should be added to the suite,
|
||
<span class="emphasis"><em>please</em></span> write up your idea and send it to the list!
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.how_to_set_paths"></a><a id="q-how_to_set_paths"></a><p><strong>3.4.</strong></p></td><td align="left" valign="top"><p>How do I insure that the dynamically linked library will be found?
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how_to_set_paths"></a></td><td align="left" valign="top"><p>
|
||
Depending on your platform and library version, the error message might
|
||
be similar to one of the following:
|
||
</p><pre class="screen">
|
||
./a.out: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
|
||
|
||
/usr/libexec/ld-elf.so.1: Shared object "libstdc++.so.6" not found
|
||
</pre><p>
|
||
This doesn't mean that the shared library isn't installed, only
|
||
that the dynamic linker can't find it. When a dynamically-linked
|
||
executable is run the linker finds and loads the required shared
|
||
libraries by searching a pre-configured list of directories. If
|
||
the directory where you've installed libstdc++ is not in this list
|
||
then the libraries won't be found.
|
||
</p><p>
|
||
If you already have an older version of libstdc++ installed then the
|
||
error might look like one of the following instead:
|
||
</p><pre class="screen">
|
||
./a.out: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.20' not found
|
||
./a.out: /usr/lib/libstdc++.so.6: version `CXXABI_1.3.8' not found
|
||
</pre><p>
|
||
This means the linker found <code class="filename">/usr/lib/libstdc++.so.6</code>
|
||
but that library belongs to an older version of GCC than was used to
|
||
compile and link the program <code class="filename">a.out</code> (or some part
|
||
of it). The program depends on code defined in the newer libstdc++
|
||
that belongs to the newer version of GCC, so the linker must be told
|
||
how to find the newer libstdc++ shared library.
|
||
</p><p>
|
||
The simplest way to fix this is
|
||
to use the <code class="envar">LD_LIBRARY_PATH</code> environment variable,
|
||
which is a colon-separated list of directories in which the linker
|
||
will search for shared libraries:
|
||
</p><pre class="screen"><span class="command"><strong>
|
||
export LD_LIBRARY_PATH=${prefix}/lib:$LD_LIBRARY_PATH
|
||
</strong></span></pre><p>
|
||
Here the shell variable <code class="varname">${prefix}</code> is assumed to contain
|
||
the directory prefix where GCC was installed to. The directory containing
|
||
the library might depend on whether you want the 32-bit or 64-bit copy
|
||
of the library, so for example would be
|
||
<code class="filename">${prefix}/lib64</code> on some systems.
|
||
The exact environment variable to use will depend on your
|
||
platform, e.g. <code class="envar">DYLD_LIBRARY_PATH</code> for Darwin,
|
||
<code class="envar">LD_LIBRARY_PATH_32</code>/<code class="envar">LD_LIBRARY_PATH_64</code>
|
||
for Solaris 32-/64-bit,
|
||
and <code class="envar">SHLIB_PATH</code> for HP-UX.
|
||
</p><p>
|
||
See the man pages for <span class="command"><strong>ld</strong></span>, <span class="command"><strong>ldd</strong></span>
|
||
and <span class="command"><strong>ldconfig</strong></span> for more information. The dynamic
|
||
linker has different names on different platforms but the man page
|
||
is usually called something such as <code class="filename">ld.so</code>,
|
||
<code class="filename">rtld</code> or <code class="filename">dld.so</code>.
|
||
</p><p>
|
||
Using <code class="envar">LD_LIBRARY_PATH</code> is not always the best solution,
|
||
<a class="link" href="manual/using_dynamic_or_shared.html#manual.intro.using.linkage.dynamic" title="Finding Dynamic or Shared Libraries">Finding Dynamic or Shared
|
||
Libraries</a> in the manual gives some alternatives.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.what_is_libsupcxx"></a><a id="q-what_is_libsupcxx"></a><p><strong>3.5.</strong></p></td><td align="left" valign="top"><p>
|
||
What's libsupc++?
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-what_is_libsupcxx"></a></td><td align="left" valign="top"><p>
|
||
If the only functions from <code class="filename">libstdc++.a</code>
|
||
which you need are language support functions (those listed in
|
||
<a class="link" href="manual/support.html" title="Chapter 4. Support">clause 18</a> of the
|
||
standard, e.g., <code class="function">new</code> and
|
||
<code class="function">delete</code>), then try linking against
|
||
<code class="filename">libsupc++.a</code>, which is a subset of
|
||
<code class="filename">libstdc++.a</code>. (Using <span class="command"><strong>gcc</strong></span>
|
||
instead of <span class="command"><strong>g++</strong></span> and explicitly linking in
|
||
<code class="filename">libsupc++.a</code> via <code class="option">-lsupc++</code>
|
||
for the final link step will do it). This library contains only
|
||
those support routines, one per object file. But if you are
|
||
using anything from the rest of the library, such as IOStreams
|
||
or vectors, then you'll still need pieces from
|
||
<code class="filename">libstdc++.a</code>.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.size"></a><a id="q-size"></a><p><strong>3.6.</strong></p></td><td align="left" valign="top"><p>
|
||
This library is HUGE!
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-size"></a></td><td align="left" valign="top"><p>
|
||
Usually the size of libraries on disk isn't noticeable. When a
|
||
link editor (or simply <span class="quote">“<span class="quote">linker</span>”</span>) pulls things from a
|
||
static archive library, only the necessary object files are copied
|
||
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++ about this; it's just common behavior, given here
|
||
for background reasons.)
|
||
</p><p>
|
||
Some of the object files which make up
|
||
<code class="filename">libstdc++.a</code> are rather large.
|
||
If you create a statically-linked executable with
|
||
<code class="option">-static</code>, those large object files are suddenly part
|
||
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 <code class="filename">.o</code> 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.
|
||
</p><p>
|
||
On supported platforms, libstdc++ takes advantage of garbage
|
||
collection in the GNU linker to get a result similar to separating
|
||
each symbol into a separate source and object files. On these platforms,
|
||
GNU ld can place each function and variable into its own
|
||
section in a <code class="filename">.o</code> file. The GNU linker can then perform
|
||
garbage collection on unused sections; this reduces the situation to only
|
||
copying needed functions into the executable, as before, but all
|
||
happens automatically.
|
||
</p></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>4.1. <a href="faq.html#faq.other_compilers">
|
||
Can libstdc++ be used with non-GNU compilers?
|
||
</a></dt><dt>4.2. <a href="faq.html#faq.solaris_long_long">
|
||
No 'long long' type on Solaris?
|
||
</a></dt><dt>4.3. <a href="faq.html#faq.predefined">
|
||
_XOPEN_SOURCE and _GNU_SOURCE are always defined?
|
||
</a></dt><dt>4.4. <a href="faq.html#faq.darwin_ctype">
|
||
Mac OS X ctype.h is broken! How can I fix it?
|
||
</a></dt><dt>4.5. <a href="faq.html#faq.threads_i386">
|
||
Threading is broken on i386?
|
||
</a></dt><dt>4.6. <a href="faq.html#faq.atomic_mips">
|
||
MIPS atomic operations
|
||
</a></dt><dt>4.7. <a href="faq.html#faq.linux_glibc">
|
||
Recent GNU/Linux glibc required?
|
||
</a></dt><dt>4.8. <a href="faq.html#faq.freebsd_wchar">
|
||
Can't use wchar_t/wstring on FreeBSD
|
||
</a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.other_compilers"></a><a id="q-other_compilers"></a><p><strong>4.1.</strong></p></td><td align="left" valign="top"><p>
|
||
Can libstdc++ be used with non-GNU compilers?
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-other_compilers"></a></td><td align="left" valign="top"><p>
|
||
Perhaps.
|
||
</p><p>
|
||
Since the goal of ISO Standardization is for all C++
|
||
implementations to be able to share code, libstdc++ should be
|
||
usable under any ISO-compliant compiler, at least in theory.
|
||
</p><p>
|
||
However, the reality is that libstdc++ is targeted and optimized
|
||
for GCC/G++. This means that often libstdc++ uses specific,
|
||
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 to support these constructs.
|
||
</p><p>
|
||
Recent versions of libstdc++ are known to work with the Clang compiler.
|
||
In the near past, specific released versions of libstdc++ have
|
||
been known to work with versions of the EDG C++ compiler, and
|
||
vendor-specific proprietary C++ compilers such as the Intel ICC
|
||
C++ compiler.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.solaris_long_long"></a><a id="q-solaris_long_long"></a><p><strong>4.2.</strong></p></td><td align="left" valign="top"><p>
|
||
No '<span class="type">long long</span>' type on Solaris?
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-solaris_long_long"></a></td><td align="left" valign="top"><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>This answer is old and probably no longer be relevant.</p></div><p>
|
||
By default we try to support the C99 <span class="type">long long</span> type.
|
||
This requires that certain functions from your C library be present.
|
||
</p><p>
|
||
Up through release 3.0.2 the platform-specific tests performed by
|
||
libstdc++ were too general, resulting in a conservative approach
|
||
to enabling the <span class="type">long long</span> code paths. The most
|
||
commonly reported platform affected was Solaris.
|
||
</p><p>
|
||
This has been fixed for libstdc++ releases greater than 3.0.3.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.predefined"></a><a id="q-predefined"></a><p><strong>4.3.</strong></p></td><td align="left" valign="top"><p>
|
||
<code class="constant">_XOPEN_SOURCE</code> and <code class="constant">_GNU_SOURCE</code> are always defined?
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-predefined"></a></td><td align="left" valign="top"><p>On Solaris, <span class="command"><strong>g++</strong></span> (but not <span class="command"><strong>gcc</strong></span>)
|
||
always defines the preprocessor macro
|
||
<code class="constant">_XOPEN_SOURCE</code>. On GNU/Linux, the same happens
|
||
with <code class="constant">_GNU_SOURCE</code>. (This is not an exhaustive list;
|
||
other macros and other platforms are also affected.)
|
||
</p><p>These macros are typically used in C library headers, guarding new
|
||
versions of functions from their older versions. The C++98 standard
|
||
library includes the C standard library, but it requires the C90
|
||
version, which for backwards-compatibility reasons is often not the
|
||
default for many vendors.
|
||
</p><p>More to the point, the C++ standard requires behavior which is only
|
||
available on certain platforms after certain symbols are defined.
|
||
Usually the issue involves I/O-related typedefs. In order to
|
||
ensure correctness, the compiler simply predefines those symbols.
|
||
</p><p>Note that it's not enough to <code class="literal">#define</code> them only when the library is
|
||
being built (during installation). Since we don't have an 'export'
|
||
keyword, much of the library exists as headers, which means that
|
||
the symbols must also be defined as your programs are parsed and
|
||
compiled.
|
||
</p><p>To see which symbols are defined, look for
|
||
<code class="varname">CPLUSPLUS_CPP_SPEC</code> in
|
||
the gcc config headers for your target (and try changing them to
|
||
see what happens when building complicated code). You can also run
|
||
<span class="command"><strong>g++ -E -dM -x c++ /dev/null</strong></span> to display
|
||
a list of predefined macros for any particular installation.
|
||
</p><p>This has been discussed on the mailing lists
|
||
<a class="link" href="http://gcc.gnu.org/cgi-bin/htsearch?method=and&format=builtin-long&sort=score&words=_XOPEN_SOURCE+Solaris" target="_top">quite a bit</a>.
|
||
</p><p>This method is something of a wart. We'd like to find a cleaner
|
||
solution, but nobody yet has contributed the time.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.darwin_ctype"></a><a id="q-darwin_ctype"></a><p><strong>4.4.</strong></p></td><td align="left" valign="top"><p>
|
||
Mac OS X <code class="filename">ctype.h</code> is broken! How can I fix it?
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-darwin_ctype"></a></td><td align="left" valign="top"><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>This answer is old and probably no longer be relevant.</p></div><p>
|
||
This was a long-standing bug in the OS X support. Fortunately, the
|
||
<a class="link" href="http://gcc.gnu.org/ml/gcc/2002-03/msg00817.html" target="_top">patch</a>
|
||
was quite simple, and well-known.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.threads_i386"></a><a id="q-threads_i386"></a><p><strong>4.5.</strong></p></td><td align="left" valign="top"><p>
|
||
Threading is broken on i386?
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-threads_i386"></a></td><td align="left" valign="top"><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>This answer is old and probably no longer be relevant.</p></div><p>Support for atomic integer operations was broken on i386
|
||
platforms. The assembly code accidentally used opcodes that are
|
||
only available on the i486 and later. So if you configured GCC
|
||
to target, for example, i386-linux, but actually used the programs
|
||
on an i686, then you would encounter no problems. Only when
|
||
actually running the code on a i386 will the problem appear.
|
||
</p><p>This is fixed in 3.2.2.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.atomic_mips"></a><a id="q-atomic_mips"></a><p><strong>4.6.</strong></p></td><td align="left" valign="top"><p>
|
||
MIPS atomic operations
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-atomic_mips"></a></td><td align="left" valign="top"><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>This answer is old and probably no longer be relevant.</p></div><p>
|
||
The atomic locking routines for MIPS targets requires MIPS II
|
||
and later. A patch went in just after the 3.3 release to
|
||
make mips* use the generic implementation instead. You can also
|
||
configure for mipsel-elf as a workaround.
|
||
</p><p>
|
||
The mips*-*-linux* port continues to use the MIPS II routines, and more
|
||
work in this area is expected.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.linux_glibc"></a><a id="q-linux_glibc"></a><p><strong>4.7.</strong></p></td><td align="left" valign="top"><p>
|
||
Recent GNU/Linux glibc required?
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-linux_glibc"></a></td><td align="left" valign="top"><p>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.
|
||
All 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.
|
||
</p><p>The guideline is simple: the more recent the C++ library, the
|
||
more recent the C library. (This is also documented in the main
|
||
GCC installation instructions.)
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.freebsd_wchar"></a><a id="q-freebsd_wchar"></a><p><strong>4.8.</strong></p></td><td align="left" valign="top"><p>
|
||
Can't use <span class="type">wchar_t</span>/<code class="classname">wstring</code> on FreeBSD
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-freebsd_wchar"></a></td><td align="left" valign="top"><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>This answer is old and probably no longer be relevant.</p></div><p>
|
||
Older versions of FreeBSD's C library do not have sufficient
|
||
support for wide character functions, and as a result the
|
||
libstdc++ configury decides that <span class="type">wchar_t</span> support should be
|
||
disabled. In addition, the libstdc++ platform checks that
|
||
enabled <span class="type">wchar_t</span> were quite strict, and not granular
|
||
enough to detect when the minimal support to
|
||
enable <span class="type">wchar_t</span> and C++ library structures
|
||
like <code class="classname">wstring</code> were present. This impacted Solaris,
|
||
Darwin, and BSD variants, and is fixed in libstdc++ versions post 4.1.0.
|
||
</p><p>
|
||
</p></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>5.1. <a href="faq.html#faq.what_works">
|
||
What works already?
|
||
</a></dt><dt>5.2. <a href="faq.html#faq.standard_bugs">
|
||
Bugs in the ISO C++ language or library specification
|
||
</a></dt><dt>5.3. <a href="faq.html#faq.compiler_bugs">
|
||
Bugs in the compiler (gcc/g++) and not libstdc++
|
||
</a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.what_works"></a><a id="q-what_works"></a><p><strong>5.1.</strong></p></td><td align="left" valign="top"><p>
|
||
What works already?
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-what_works"></a></td><td align="left" valign="top"><p>
|
||
Short answer: Pretty much everything <span class="emphasis"><em>works</em></span>
|
||
except for some corner cases. Support for localization
|
||
in <code class="classname">locale</code> may be incomplete on some non-GNU
|
||
platforms. Also dependent on the underlying platform is support
|
||
for <span class="type">wchar_t</span> and <span class="type">long long</span> specializations,
|
||
and details of thread support.
|
||
</p><p>
|
||
Long answer: See the implementation status pages for
|
||
<a class="link" href="manual/status.html#status.iso.1998" title="C++ 1998/2003">C++98</a>,
|
||
<a class="link" href="manual/status.html#status.iso.tr1" title="C++ TR1">TR1</a>,
|
||
<a class="link" href="manual/status.html#status.iso.2011" title="C++ 2011">C++11</a>,
|
||
<a class="link" href="manual/status.html#status.iso.2014" title="C++ 2014">C++14</a>, and
|
||
<a class="link" href="manual/status.html#status.iso.2017" title="C++ 2017">C++17</a>.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.standard_bugs"></a><a id="q-standard_bugs"></a><p><strong>5.2.</strong></p></td><td align="left" valign="top"><p>
|
||
Bugs in the ISO C++ language or library specification
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-standard_bugs"></a></td><td align="left" valign="top"><p>
|
||
Unfortunately, there are some.
|
||
</p><p>
|
||
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 on <a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/" target="_top">the WG21
|
||
website</a>.
|
||
Many of these issues have resulted in
|
||
<a class="link" href="manual/bugs.html#manual.intro.status.bugs.iso" title="Standard Bugs">code changes in libstdc++</a>.
|
||
</p><p>
|
||
If you think you've discovered a new bug that is not listed,
|
||
please post a message describing your problem to the author of
|
||
the library issues list.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.compiler_bugs"></a><a id="q-compiler_bugs"></a><p><strong>5.3.</strong></p></td><td align="left" valign="top"><p>
|
||
Bugs in the compiler (gcc/g++) and not libstdc++
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-compiler_bugs"></a></td><td align="left" valign="top"><p>
|
||
On occasion, the compiler is wrong. Please be advised that this
|
||
happens much less often than one would think, and avoid jumping to
|
||
conclusions.
|
||
</p><p>
|
||
First, examine the ISO C++ standard. Second, try another compiler
|
||
or an older version of the GNU compilers. Third, you can find more
|
||
information on the libstdc++ and the GCC mailing lists: search
|
||
these lists with terms describing your issue.
|
||
</p><p>
|
||
Before reporting a bug, please examine the
|
||
<a class="link" href="https://gcc.gnu.org/bugs/" target="_top">bugs database</a>, with the
|
||
component set to <span class="quote">“<span class="quote">c++</span>”</span>.
|
||
</p></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>6.1. <a href="faq.html#faq.stream_reopening_fails">
|
||
Reopening a stream fails
|
||
</a></dt><dt>6.2. <a href="faq.html#faq.wefcxx_verbose">
|
||
-Weffc++ complains too much
|
||
</a></dt><dt>6.3. <a href="faq.html#faq.ambiguous_overloads">
|
||
Ambiguous overloads after including an old-style header
|
||
</a></dt><dt>6.4. <a href="faq.html#faq.v2_headers">
|
||
The g++-3 headers are not ours
|
||
</a></dt><dt>6.5. <a href="faq.html#faq.boost_concept_checks">
|
||
Errors about *Concept and
|
||
constraints in the STL
|
||
</a></dt><dt>6.6. <a href="faq.html#faq.dlopen_crash">
|
||
Program crashes when using library code in a
|
||
dynamically-loaded library
|
||
</a></dt><dt>6.7. <a href="faq.html#faq.memory_leaks">
|
||
“Memory leaks” in libstdc++
|
||
</a></dt><dt>6.8. <a href="faq.html#faq.list_size_on">
|
||
list::size() is O(n)!
|
||
</a></dt><dt>6.9. <a href="faq.html#faq.easy_to_fix">
|
||
Aw, that's easy to fix!
|
||
</a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.stream_reopening_fails"></a><a id="q-stream_reopening_fails"></a><p><strong>6.1.</strong></p></td><td align="left" valign="top"><p>
|
||
Reopening a stream fails
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-stream_reopening_fails"></a></td><td align="left" valign="top"><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>This answer is old and probably no longer be relevant.</p></div><p>
|
||
Prior to GCC 4.0 this was one of the most-reported non-bug reports.
|
||
Executing a sequence like this would fail:
|
||
</p><pre class="programlisting">
|
||
#include <fstream>
|
||
...
|
||
std::fstream fs("a_file");
|
||
// .
|
||
// . do things with fs...
|
||
// .
|
||
fs.close();
|
||
fs.open("a_new_file");
|
||
</pre><p>
|
||
All operations on the re-opened <code class="varname">fs</code> would fail, or at
|
||
least act very strangely, especially if <code class="varname">fs</code> reached the
|
||
EOF state on the previous file.
|
||
The original C++98 standard did not specify behavior in this case, and
|
||
the <a class="link" href="manual/bugs.html#manual.bugs.dr22">resolution of DR #22</a> was to
|
||
leave the state flags unchanged on a successful call to
|
||
<code class="function">open()</code>.
|
||
You had to insert a call to <code class="function">fs.clear()</code> between the
|
||
calls to <code class="function">close()</code> and <code class="function">open()</code>,
|
||
and then everything will work as expected.
|
||
<span class="emphasis"><em>Update:</em></span> For GCC 4.0 we implemented the resolution
|
||
of <a class="link" href="manual/bugs.html#manual.bugs.dr409">DR #409</a> and
|
||
<code class="function">open()</code>
|
||
now calls <code class="function">clear()</code> on success.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.wefcxx_verbose"></a><a id="q-wefcxx_verbose"></a><p><strong>6.2.</strong></p></td><td align="left" valign="top"><p>
|
||
-Weffc++ complains too much
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-wefcxx_verbose"></a></td><td align="left" valign="top"><p>
|
||
Many warnings are emitted when <code class="option">-Weffc++</code> is used. Making
|
||
libstdc++ <code class="option">-Weffc++</code>-clean is not a goal of the project,
|
||
for a few reasons. Mainly, that option tries to enforce
|
||
object-oriented programming, while the Standard Library isn't
|
||
necessarily trying to be OO. The option also enforces outdated guidelines
|
||
from old editions of the books, and the advice isn't all relevant to
|
||
modern C++ (especially C++11 and later).
|
||
</p><p>
|
||
We do, however, try to have libstdc++ sources as clean as possible. If
|
||
you see some simple changes that pacify <code class="option">-Weffc++</code>
|
||
without other drawbacks, send us a patch.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.ambiguous_overloads"></a><a id="q-ambiguous_overloads"></a><p><strong>6.3.</strong></p></td><td align="left" valign="top"><p>
|
||
Ambiguous overloads after including an old-style header
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-ambiguous_overloads"></a></td><td align="left" valign="top"><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>This answer is old and probably no longer be relevant.</p></div><p>
|
||
Another problem is the <code class="literal">rel_ops</code> namespace and the template
|
||
comparison operator functions contained therein. If they become
|
||
visible in the same namespace as other comparison functions
|
||
(e.g., <span class="quote">“<span class="quote">using</span>”</span> them and the
|
||
<code class="filename"><iterator></code> header),
|
||
then you will suddenly be faced with huge numbers of ambiguity
|
||
errors. This was discussed on the mailing list; Nathan Myers
|
||
<a class="link" href="http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html" target="_top">sums
|
||
things up here</a>. The collisions with vector/string iterator
|
||
types have been fixed for 3.1.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.v2_headers"></a><a id="q-v2_headers"></a><p><strong>6.4.</strong></p></td><td align="left" valign="top"><p>
|
||
The g++-3 headers are <span class="emphasis"><em>not ours</em></span>
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-v2_headers"></a></td><td align="left" valign="top"><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>This answer is old and probably no longer be relevant.</p></div><p>
|
||
If you are using headers in
|
||
<code class="filename">${prefix}/include/g++-3</code>, or if
|
||
the installed library's name looks like
|
||
<code class="filename">libstdc++-2.10.a</code> or
|
||
<code class="filename">libstdc++-libc6-2.10.so</code>, then
|
||
you are using the old libstdc++-v2 library, which is non-standard 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++ header files are installed in
|
||
<code class="filename">${prefix}/include/g++-v3</code>
|
||
(see the 'v'?). Starting with version 3.2 the headers are installed in
|
||
<code class="filename">${prefix}/include/c++/${version}</code>
|
||
as this prevents headers from previous versions being found by mistake.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.boost_concept_checks"></a><a id="q-boost_concept_checks"></a><p><strong>6.5.</strong></p></td><td align="left" valign="top"><p>
|
||
Errors about <span class="emphasis"><em>*Concept</em></span> and
|
||
<span class="emphasis"><em>constraints</em></span> in the STL
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-boost_concept_checks"></a></td><td align="left" valign="top"><p>
|
||
If you see compilation errors containing messages about
|
||
<span class="errortext">foo Concept</span> and something to do with a
|
||
<span class="errortext">constraints</span> member function, then most
|
||
likely you have violated one of the requirements for types used
|
||
during instantiation of template containers and functions. For
|
||
example, EqualityComparableConcept appears if your types must be
|
||
comparable with == and you have not provided this capability (a
|
||
typo, or wrong visibility, or you just plain forgot, etc).
|
||
</p><p>
|
||
More information, including how to optionally enable/disable the
|
||
checks, is available in the
|
||
<a class="link" href="manual/concept_checking.html" title="Concept Checking">Diagnostics</a>.
|
||
chapter of the manual.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.dlopen_crash"></a><a id="q-dlopen_crash"></a><p><strong>6.6.</strong></p></td><td align="left" valign="top"><p>
|
||
Program crashes when using library code in a
|
||
dynamically-loaded library
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-dlopen_crash"></a></td><td align="left" valign="top"><p>
|
||
If you are using the C++ library across dynamically-loaded
|
||
objects, make certain that you are passing the correct options
|
||
when compiling and linking:
|
||
</p><div class="literallayout"><p><br />
|
||
Compile your library components:<br />
|
||
<span class="command"><strong>g++ -fPIC -c a.cc</strong></span><br />
|
||
<span class="command"><strong>g++ -fPIC -c b.cc</strong></span><br />
|
||
...<br />
|
||
<span class="command"><strong>g++ -fPIC -c z.cc</strong></span><br />
|
||
<br />
|
||
Create your library:<br />
|
||
<span class="command"><strong>g++ -fPIC -shared -rdynamic -o libfoo.so a.o b.o ... z.o</strong></span><br />
|
||
<br />
|
||
Link the executable:<br />
|
||
<span class="command"><strong>g++ -fPIC -rdynamic -o foo ... -L. -lfoo -ldl</strong></span><br />
|
||
</p></div></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.memory_leaks"></a><a id="q-memory_leaks"></a><p><strong>6.7.</strong></p></td><td align="left" valign="top"><p>
|
||
<span class="quote">“<span class="quote">Memory leaks</span>”</span> in libstdc++
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-memory_leaks"></a></td><td align="left" valign="top"><p>
|
||
Since GCC 5.1.0, libstdc++ automatically allocates a pool
|
||
of a few dozen kilobytes on startup. This pool is used to ensure it's
|
||
possible to throw exceptions (such as <code class="classname">bad_alloc</code>)
|
||
even when <code class="code">malloc</code> is unable to allocate any more memory.
|
||
With some versions of <a class="link" href="https://valgrind.org" target="_top"><span class="command"><strong>valgrind</strong></span></a>
|
||
this pool will be shown as "still reachable" when the process exits, e.g.
|
||
<code class="code">still reachable: 72,704 bytes in 1 blocks</code>.
|
||
This memory is not a leak, because it's still in use by libstdc++,
|
||
and the memory will be returned to the OS when the process exits.
|
||
Later versions of <span class="command"><strong>valgrind</strong></span> know how to free this
|
||
pool as the process exits, and so won't show any "still reachable" memory.
|
||
</p><p>
|
||
In the past, a few people reported that the standard containers appear
|
||
to leak memory when tested with memory checkers such as
|
||
<span class="command"><strong>valgrind</strong></span>.
|
||
Under some (non-default) configurations the library's allocators keep
|
||
free memory in a
|
||
pool for later reuse, rather than deallocating it with <code class="code">delete</code>
|
||
Although this memory is always reachable by the library and is never
|
||
lost, memory debugging tools can report it as a leak. If you
|
||
want to test the library for memory leaks please read
|
||
<a class="link" href="manual/debug.html#debug.memory" title="Memory Leak Hunting">Tips for memory leak hunting</a>
|
||
first.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.list_size_on"></a><a id="q-list_size_on"></a><p><strong>6.8.</strong></p></td><td align="left" valign="top"><p>
|
||
<code class="code">list::size()</code> is O(n)!
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-list_size_on"></a></td><td align="left" valign="top"><p>
|
||
See
|
||
the <a class="link" href="manual/containers.html" title="Chapter 9. Containers">Containers</a>
|
||
chapter.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.easy_to_fix"></a><a id="q-easy_to_fix"></a><p><strong>6.9.</strong></p></td><td align="left" valign="top"><p>
|
||
Aw, that's easy to fix!
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-easy_to_fix"></a></td><td align="left" valign="top"><p>
|
||
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 <a class="link" href="http://gcc.gnu.org/contribute.html" target="_top">submitting
|
||
patches</a> 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++
|
||
<a class="link" href="manual/appendix_contributing.html" title="Appendix A. Contributing">contributors' page</a>
|
||
also talks about how to submit patches.
|
||
</p><p>
|
||
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 testsuite -
|
||
but only if such a test exists.
|
||
</p></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>7.1. <a href="faq.html#faq.iterator_as_pod">
|
||
string::iterator is not char*;
|
||
vector<T>::iterator is not T*
|
||
</a></dt><dt>7.2. <a href="faq.html#faq.what_is_next">
|
||
What's next after libstdc++?
|
||
</a></dt><dt>7.3. <a href="faq.html#faq.sgi_stl">
|
||
What about the STL from SGI?
|
||
</a></dt><dt>7.4. <a href="faq.html#faq.extensions_and_backwards_compat">
|
||
Extensions and Backward Compatibility
|
||
</a></dt><dt>7.5. <a href="faq.html#faq.tr1_support">
|
||
Does libstdc++ support TR1?
|
||
</a></dt><dt>7.6. <a href="faq.html#faq.get_iso_cxx">How do I get a copy of the ISO C++ Standard?
|
||
</a></dt><dt>7.7. <a href="faq.html#faq.what_is_abi">
|
||
What's an ABI and why is it so messy?
|
||
</a></dt><dt>7.8. <a href="faq.html#faq.size_equals_capacity">
|
||
How do I make std::vector<T>::capacity() == std::vector<T>::size?
|
||
</a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.iterator_as_pod"></a><a id="faq.iterator_as_pod_q"></a><p><strong>7.1.</strong></p></td><td align="left" valign="top"><p>
|
||
<code class="classname">string::iterator</code> is not <code class="code">char*</code>;
|
||
<code class="classname">vector<T>::iterator</code> is not <code class="code">T*</code>
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="faq.iterator_as_pod_a"></a></td><td align="left" valign="top"><p>
|
||
If you have code that depends on container<T> iterators
|
||
being implemented as pointer-to-T, your code is broken. It's
|
||
considered a feature, not a bug, that libstdc++ points this out.
|
||
</p><p>
|
||
While there are arguments for iterators to be implemented in
|
||
that manner, A) they aren't very good ones in the long term,
|
||
and B) they were never guaranteed by the Standard anyway. The
|
||
type-safety achieved by making iterators a real class rather
|
||
than a typedef for <span class="type">T*</span> outweighs nearly all opposing
|
||
arguments.
|
||
</p><p>
|
||
Code which does assume that a vector/string iterator <code class="varname">i</code>
|
||
is a pointer can often be fixed by changing <code class="varname">i</code> in
|
||
certain expressions to <code class="varname">&*i</code>.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.what_is_next"></a><a id="q-what_is_next"></a><p><strong>7.2.</strong></p></td><td align="left" valign="top"><p>
|
||
What's next after libstdc++?
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-what_is_next"></a></td><td align="left" valign="top"><p>
|
||
The goal of libstdc++ is to produce a
|
||
fully-compliant, fully-portable Standard Library.
|
||
While the C++ Standard continues to evolve the libstdc++ will
|
||
continue to track it.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.sgi_stl"></a><a id="q-sgi_stl"></a><p><strong>7.3.</strong></p></td><td align="left" valign="top"><p>
|
||
What about the STL from SGI?
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-sgi_stl"></a></td><td align="left" valign="top"><p>
|
||
The STL (Standard Template Library) was the inspiration for large chunks
|
||
of the C++ Standard Library, but the terms are not interchangeable and
|
||
they don't mean the same thing. The C++ Standard Library includes lots of
|
||
things that didn't come from the STL, and some of them aren't even
|
||
templates, such as <code class="classname">std::locale</code> and
|
||
<code class="classname">std::thread</code>.
|
||
</p><p>
|
||
Libstdc++-v3 incorporates a lot of code from
|
||
<a class="link" href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/" target="_top">the SGI STL</a>
|
||
(the final merge was from
|
||
<a class="link" href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/whats_new.html" target="_top">release 3.3</a>).
|
||
The code in libstdc++ contains many fixes and changes compared to the
|
||
original SGI code.
|
||
</p><p>
|
||
In particular, <code class="classname">string</code> is not from SGI and makes no
|
||
use of their "rope" class (although that is included as an optional
|
||
extension), neither is <code class="classname">valarray</code> nor some others.
|
||
Classes like <code class="classname">vector<></code> were from SGI, but have
|
||
been extensively modified.
|
||
</p><p>
|
||
More information on the evolution of libstdc++ can be found at the
|
||
<a class="link" href="manual/api.html" title="API Evolution and Deprecation History">API
|
||
evolution</a>
|
||
and <a class="link" href="manual/backwards.html" title="Backwards Compatibility">backwards
|
||
compatibility</a> documentation.
|
||
</p><p>
|
||
The <a class="link" href="https://web.archive.org/web/20171104092813/http://www.sgi.com/tech/stl/FAQ.html" target="_top">FAQ</a>
|
||
for SGI's STL is still recommended reading.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.extensions_and_backwards_compat"></a><a id="q-extensions_and_backwards_compat"></a><p><strong>7.4.</strong></p></td><td align="left" valign="top"><p>
|
||
Extensions and Backward Compatibility
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-extensions_and_backwards_compat"></a></td><td align="left" valign="top"><p>
|
||
See the <a class="link" href="manual/backwards.html" title="Backwards Compatibility">link</a> on backwards compatibility and <a class="link" href="manual/api.html" title="API Evolution and Deprecation History">link</a> on evolution.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.tr1_support"></a><a id="q-tr1_support"></a><p><strong>7.5.</strong></p></td><td align="left" valign="top"><p>
|
||
Does libstdc++ support TR1?
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-tr1_support"></a></td><td align="left" valign="top"><p>
|
||
Yes.
|
||
</p><p>
|
||
The C++ Standard Library
|
||
<a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf" target="_top">
|
||
Technical Report 1</a> added many new features to the library.
|
||
</p><p>
|
||
The implementation status of TR1 in libstdc++ can be tracked
|
||
<a class="link" href="manual/status.html#status.iso.tr1" title="C++ TR1">on the TR1 status page</a>.
|
||
</p><p>
|
||
New code should probably not use TR1, because almost everything in it has
|
||
been added to the main C++ Standard Library (usually with significant
|
||
improvements).
|
||
The TR1 implementation in libstdc++ is no longer actively maintained.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.get_iso_cxx"></a><a id="q-get_iso_cxx"></a><p><strong>7.6.</strong></p></td><td align="left" valign="top"><p>How do I get a copy of the ISO C++ Standard?
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-get_iso_cxx"></a></td><td align="left" valign="top"><p>
|
||
Please refer to the <a class="link" href="manual/appendix_contributing.html" title="Appendix A. Contributing">Contributing</a>
|
||
section in our manual.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.what_is_abi"></a><a id="q-what_is_abi"></a><p><strong>7.7.</strong></p></td><td align="left" valign="top"><p>
|
||
What's an ABI and why is it so messy?
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-what_is_abi"></a></td><td align="left" valign="top"><p>
|
||
<acronym class="acronym">ABI</acronym> stands for <span class="quote">“<span class="quote">Application Binary
|
||
Interface</span>”</span>. Conventionally, it refers to a great
|
||
mass of details about how arguments are arranged on the call
|
||
stack and/or in registers, and how various types are arranged
|
||
and padded in structs. A single CPU design may suffer
|
||
multiple ABIs designed by different development tool vendors
|
||
who made different choices, or even by the same vendor for
|
||
different target applications or compiler versions. In ideal
|
||
circumstances the CPU designer presents one ABI and all the
|
||
OSes and compilers use it. In practice every ABI omits
|
||
details that compiler implementers (consciously or
|
||
accidentally) must choose for themselves.
|
||
</p><p>
|
||
That ABI definition suffices for compilers to generate code so a
|
||
program can interact safely with an OS and its lowest-level libraries.
|
||
Users usually want an ABI to encompass more detail, allowing libraries
|
||
built with different compilers (or different releases of the same
|
||
compiler!) to be linked together. For C++, this includes many more
|
||
details than for C, and most CPU designers (for good reasons elaborated
|
||
below) have not stepped up to publish C++ ABIs. Such an ABI has been
|
||
defined for the Itanium architecture (see
|
||
<a class="link" href="https://itanium-cxx-abi.github.io/cxx-abi/" target="_top">C++
|
||
ABI for Itanium</a>) and that is used by G++ and other compilers
|
||
as the de facto standard ABI on many common architectures (including x86).
|
||
G++ can also use the ARM architecture's EABI, for embedded
|
||
systems relying only on a <span class="quote">“<span class="quote">free-standing implementation</span>”</span> that
|
||
doesn't include (much of) the standard library, and the GNU EABI for
|
||
hosted implementations on ARM. Those ABIs cover low-level details
|
||
such as virtual function implementation, struct inheritance layout,
|
||
name mangling, and exception handling.
|
||
</p><p>
|
||
A useful C++ ABI must also incorporate many details of the standard
|
||
library implementation. For a C ABI, the layouts of a few structs
|
||
(such as <span class="type">FILE</span>, <span class="type">stat</span>, <span class="type">jmpbuf</span>,
|
||
and the like) and a few macros suffice.
|
||
For C++, the details include the complete set of names of functions
|
||
and types used, the offsets of class members and virtual functions,
|
||
and the actual definitions of all inlines. C++ exposes many more
|
||
library details to the caller than C does. It makes defining
|
||
a complete ABI a much bigger undertaking, and requires not just
|
||
documenting library implementation details, but carefully designing
|
||
those details so that future bug fixes and optimizations don't
|
||
force breaking the ABI.
|
||
</p><p>
|
||
There are ways to help isolate library implementation details from the
|
||
ABI, but they trade off against speed. Library details used in inner
|
||
loops (e.g., <code class="function">getchar</code>) must be exposed and frozen for
|
||
all time, but many others may reasonably be kept hidden from user code,
|
||
so they may later be changed. Deciding which, and implementing
|
||
the decisions, must happen before you can reasonably document a
|
||
candidate C++ ABI that encompasses the standard library.
|
||
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.size_equals_capacity"></a><a id="q-size_equals_capacity"></a><p><strong>7.8.</strong></p></td><td align="left" valign="top"><p>
|
||
How do I make <code class="code">std::vector<T>::capacity() == std::vector<T>::size</code>?
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-size_equals_capacity"></a></td><td align="left" valign="top"><p>
|
||
Since C++11 just call the <code class="function">shrink_to_fit()</code> member
|
||
function.
|
||
</p><p>
|
||
Before C++11, the standard idiom for deallocating a
|
||
<code class="classname">vector<T></code>'s
|
||
unused memory was to create a temporary copy of the vector and swap their
|
||
contents, e.g. for <code class="classname">vector<T> v</code>
|
||
</p><div class="literallayout"><p><br />
|
||
std::vector<T>(v).swap(v);<br />
|
||
</p></div><p>
|
||
The copy will take O(n) time and the swap is constant time.
|
||
</p><p>
|
||
See <a class="link" href="manual/strings.html#strings.string.shrink" title="Shrink to Fit">Shrink-to-fit
|
||
strings</a> for a similar solution for strings.
|
||
</p></td></tr></tbody></table></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk03.html">Up</a></td><td width="40%" align="right"> </td></tr><tr><td width="40%" align="left" valign="top"> </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> </td></tr></table></div></body></html> |