| 1 |
742 |
jeremybenn |
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
| 2 |
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
|
| 3 |
|
|
<html xmlns="http://www.w3.org/1999/xhtml"><head><title>Frequently Asked Questions</title><meta name="generator" content="DocBook XSL-NS Stylesheets V1.76.1"/><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 align="left"><a accesskey="p" href="bk03.html">Prev</a> </td><th width="60%" align="center"/><td align="right"> </td></tr></table><hr/></div><div class="article" title="Frequently Asked Questions"><div class="titlepage"><div><div><h1 class="title"><a id="faq"/>Frequently Asked Questions</h1></div><div><p class="copyright">Copyright ©
|
| 4 |
|
|
2008, 2010
|
| 5 |
|
|
|
| 6 |
|
|
<a class="link" href="http://www.fsf.org">FSF</a>
|
| 7 |
|
|
</p></div></div><hr/></div><div class="qandaset" title="Frequently Asked Questions"><a id="id373797"/><dl><dt/><dd><dl><dt>1.1. <a href="faq.html#faq.what">
|
| 8 |
|
|
What is libstdc++?
|
| 9 |
|
|
</a></dt><dt>1.2. <a href="faq.html#faq.why">
|
| 10 |
|
|
Why should I use libstdc++?
|
| 11 |
|
|
</a></dt><dt>1.3. <a href="faq.html#faq.who">
|
| 12 |
|
|
Who's in charge of it?
|
| 13 |
|
|
</a></dt><dt>1.4. <a href="faq.html#faq.when">
|
| 14 |
|
|
When is libstdc++ going to be finished?
|
| 15 |
|
|
</a></dt><dt>1.5. <a href="faq.html#faq.how">
|
| 16 |
|
|
How do I contribute to the effort?
|
| 17 |
|
|
</a></dt><dt>1.6. <a href="faq.html#faq.whereis_old">
|
| 18 |
|
|
What happened to the older libg++? I need that!
|
| 19 |
|
|
</a></dt><dt>1.7. <a href="faq.html#faq.more_questions">
|
| 20 |
|
|
What if I have more questions?
|
| 21 |
|
|
</a></dt></dl></dd><dt/><dd><dl><dt>2.1. <a href="faq.html#faq.license.what">
|
| 22 |
|
|
What are the license terms for libstdc++?
|
| 23 |
|
|
</a></dt><dt>2.2. <a href="faq.html#faq.license.any_program">
|
| 24 |
|
|
So any program which uses libstdc++ falls under the GPL?
|
| 25 |
|
|
</a></dt><dt>2.3. <a href="faq.html#faq.license.lgpl">
|
| 26 |
|
|
How is that different from the GNU {Lesser,Library} GPL?
|
| 27 |
|
|
</a></dt><dt>2.4. <a href="faq.html#faq.license.what_restrictions">
|
| 28 |
|
|
I see. So, what restrictions are there on programs that use the library?
|
| 29 |
|
|
</a></dt></dl></dd><dt/><dd><dl><dt>3.1. <a href="faq.html#faq.how_to_install">How do I install libstdc++?
|
| 30 |
|
|
</a></dt><dt>3.2. <a href="faq.html#faq.how_to_get_sources">How does one get current libstdc++ sources?
|
| 31 |
|
|
</a></dt><dt>3.3. <a href="faq.html#faq.how_to_test">How do I know if it works?
|
| 32 |
|
|
</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?
|
| 33 |
|
|
</a></dt><dt>3.5. <a href="faq.html#faq.what_is_libsupcxx">
|
| 34 |
|
|
What's libsupc++?
|
| 35 |
|
|
</a></dt><dt>3.6. <a href="faq.html#faq.size">
|
| 36 |
|
|
This library is HUGE!
|
| 37 |
|
|
</a></dt></dl></dd><dt/><dd><dl><dt>4.1. <a href="faq.html#faq.other_compilers">
|
| 38 |
|
|
Can libstdc++ be used with non-GNU compilers?
|
| 39 |
|
|
</a></dt><dt>4.2. <a href="faq.html#faq.solaris_long_long">
|
| 40 |
|
|
No 'long long' type on Solaris?
|
| 41 |
|
|
</a></dt><dt>4.3. <a href="faq.html#faq.predefined">
|
| 42 |
|
|
_XOPEN_SOURCE and _GNU_SOURCE are always defined?
|
| 43 |
|
|
</a></dt><dt>4.4. <a href="faq.html#faq.darwin_ctype">
|
| 44 |
|
|
Mac OS X ctype.h is broken! How can I fix it?
|
| 45 |
|
|
</a></dt><dt>4.5. <a href="faq.html#faq.threads_i386">
|
| 46 |
|
|
Threading is broken on i386?
|
| 47 |
|
|
</a></dt><dt>4.6. <a href="faq.html#faq.atomic_mips">
|
| 48 |
|
|
MIPS atomic operations
|
| 49 |
|
|
</a></dt><dt>4.7. <a href="faq.html#faq.linux_glibc">
|
| 50 |
|
|
Recent GNU/Linux glibc required?
|
| 51 |
|
|
</a></dt><dt>4.8. <a href="faq.html#faq.freebsd_wchar">
|
| 52 |
|
|
Can't use wchar_t/wstring on FreeBSD
|
| 53 |
|
|
</a></dt></dl></dd><dt/><dd><dl><dt>5.1. <a href="faq.html#faq.what_works">
|
| 54 |
|
|
What works already?
|
| 55 |
|
|
</a></dt><dt>5.2. <a href="faq.html#faq.standard_bugs">
|
| 56 |
|
|
Bugs in the ISO C++ language or library specification
|
| 57 |
|
|
</a></dt><dt>5.3. <a href="faq.html#faq.compiler_bugs">
|
| 58 |
|
|
Bugs in the compiler (gcc/g++) and not libstdc++
|
| 59 |
|
|
</a></dt></dl></dd><dt/><dd><dl><dt>6.1. <a href="faq.html#faq.stream_reopening_fails">
|
| 60 |
|
|
Reopening a stream fails
|
| 61 |
|
|
</a></dt><dt>6.2. <a href="faq.html#faq.wefcxx_verbose">
|
| 62 |
|
|
-Weffc++ complains too much
|
| 63 |
|
|
</a></dt><dt>6.3. <a href="faq.html#faq.ambiguous_overloads">
|
| 64 |
|
|
Ambiguous overloads after including an old-style header
|
| 65 |
|
|
</a></dt><dt>6.4. <a href="faq.html#faq.v2_headers">
|
| 66 |
|
|
The g++-3 headers are not ours
|
| 67 |
|
|
</a></dt><dt>6.5. <a href="faq.html#faq.boost_concept_checks">
|
| 68 |
|
|
Errors about *Concept and
|
| 69 |
|
|
constraints in the STL
|
| 70 |
|
|
</a></dt><dt>6.6. <a href="faq.html#faq.dlopen_crash">
|
| 71 |
|
|
Program crashes when using library code in a
|
| 72 |
|
|
dynamically-loaded library
|
| 73 |
|
|
</a></dt><dt>6.7. <a href="faq.html#faq.memory_leaks">
|
| 74 |
|
|
“Memory leaks” in containers
|
| 75 |
|
|
</a></dt><dt>6.8. <a href="faq.html#faq.list_size_on">
|
| 76 |
|
|
list::size() is O(n)!
|
| 77 |
|
|
</a></dt><dt>6.9. <a href="faq.html#faq.easy_to_fix">
|
| 78 |
|
|
Aw, that's easy to fix!
|
| 79 |
|
|
</a></dt></dl></dd><dt/><dd><dl><dt>7.1. <a href="faq.html#faq.iterator_as_pod">
|
| 80 |
|
|
string::iterator is not char*; vector<T>::iterator is not T*
|
| 81 |
|
|
</a></dt><dt>7.2. <a href="faq.html#faq.what_is_next">
|
| 82 |
|
|
What's next after libstdc++?
|
| 83 |
|
|
</a></dt><dt>7.3. <a href="faq.html#faq.sgi_stl">
|
| 84 |
|
|
What about the STL from SGI?
|
| 85 |
|
|
</a></dt><dt>7.4. <a href="faq.html#faq.extensions_and_backwards_compat">
|
| 86 |
|
|
Extensions and Backward Compatibility
|
| 87 |
|
|
</a></dt><dt>7.5. <a href="faq.html#faq.tr1_support">
|
| 88 |
|
|
Does libstdc++ support TR1?
|
| 89 |
|
|
</a></dt><dt>7.6. <a href="faq.html#faq.get_iso_cxx">How do I get a copy of the ISO C++ Standard?
|
| 90 |
|
|
</a></dt><dt>7.7. <a href="faq.html#faq.what_is_abi">
|
| 91 |
|
|
What's an ABI and why is it so messy?
|
| 92 |
|
|
</a></dt><dt>7.8. <a href="faq.html#faq.size_equals_capacity">
|
| 93 |
|
|
How do I make std::vector<T>::capacity() == std::vector<T>::size?
|
| 94 |
|
|
</a></dt></dl></dd></dl><table border="0" width="100%" summary="Q and A Set"><col align="left" width="1%"/><col/><tbody><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>1.1. <a href="faq.html#faq.what">
|
| 95 |
|
|
What is libstdc++?
|
| 96 |
|
|
</a></dt><dt>1.2. <a href="faq.html#faq.why">
|
| 97 |
|
|
Why should I use libstdc++?
|
| 98 |
|
|
</a></dt><dt>1.3. <a href="faq.html#faq.who">
|
| 99 |
|
|
Who's in charge of it?
|
| 100 |
|
|
</a></dt><dt>1.4. <a href="faq.html#faq.when">
|
| 101 |
|
|
When is libstdc++ going to be finished?
|
| 102 |
|
|
</a></dt><dt>1.5. <a href="faq.html#faq.how">
|
| 103 |
|
|
How do I contribute to the effort?
|
| 104 |
|
|
</a></dt><dt>1.6. <a href="faq.html#faq.whereis_old">
|
| 105 |
|
|
What happened to the older libg++? I need that!
|
| 106 |
|
|
</a></dt><dt>1.7. <a href="faq.html#faq.more_questions">
|
| 107 |
|
|
What if I have more questions?
|
| 108 |
|
|
</a></dt></dl></td></tr><tr class="question" title="1.1."><td align="left" valign="top"><a id="faq.what"/><a id="faq.what.q"/><p><strong>1.1.</strong></p></td><td align="left" valign="top"><p>
|
| 109 |
|
|
What is libstdc++?
|
| 110 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="faq.what.a"/></td><td align="left" valign="top"><p>
|
| 111 |
|
|
The GNU Standard C++ Library v3 is an ongoing project to
|
| 112 |
|
|
implement the ISO 14882 Standard C++ library as described in
|
| 113 |
|
|
chapters 17 through 27 and annex D. For those who want to see
|
| 114 |
|
|
exactly how far the project has come, or just want the latest
|
| 115 |
|
|
bleeding-edge code, the up-to-date source is available over
|
| 116 |
|
|
anonymous SVN, and can even be browsed over
|
| 117 |
|
|
the <a class="link" href="http://gcc.gnu.org/svn.html">web</a>.
|
| 118 |
|
|
</p></td></tr><tr class="question" title="1.2."><td align="left" valign="top"><a id="faq.why"/><a id="q-why"/><p><strong>1.2.</strong></p></td><td align="left" valign="top"><p>
|
| 119 |
|
|
Why should I use libstdc++?
|
| 120 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-why"/></td><td align="left" valign="top"><p>
|
| 121 |
|
|
The completion of the ISO C++ standardization gave the C++
|
| 122 |
|
|
community a powerful set of reuseable tools in the form of the C++
|
| 123 |
|
|
Standard Library. However, all existing C++ implementations are
|
| 124 |
|
|
(as the Draft Standard used to say) <span class="quote">“<span class="quote">incomplet and
|
| 125 |
|
|
incorrekt</span>”</span>, and many suffer from limitations of the compilers
|
| 126 |
|
|
that use them.
|
| 127 |
|
|
</p><p>
|
| 128 |
|
|
The GNU compiler collection
|
| 129 |
|
|
(<span class="command"><strong>gcc</strong></span>, <span class="command"><strong>g++</strong></span>, etc) is widely
|
| 130 |
|
|
considered to be one of the leading compilers in the world. Its
|
| 131 |
|
|
development is overseen by the
|
| 132 |
|
|
<a class="link" href="http://gcc.gnu.org/">GCC team</a>. All of
|
| 133 |
|
|
the rapid development and near-legendary
|
| 134 |
|
|
<a class="link" href="http://gcc.gnu.org/buildstat.html">portability</a>
|
| 135 |
|
|
that are the hallmarks of an open-source project are being
|
| 136 |
|
|
applied to libstdc++.
|
| 137 |
|
|
</p><p>
|
| 138 |
|
|
That means that all of the Standard classes and functions will be
|
| 139 |
|
|
freely available and fully compliant. (Such as
|
| 140 |
|
|
<code class="classname">string</code>,
|
| 141 |
|
|
<code class="classname">vector<></code>, iostreams, and algorithms.)
|
| 142 |
|
|
Programmers will no longer need to <span class="quote">“<span class="quote">roll their own</span>”</span>
|
| 143 |
|
|
nor be worried about platform-specific incompatibilities.
|
| 144 |
|
|
</p></td></tr><tr class="question" title="1.3."><td align="left" valign="top"><a id="faq.who"/><a id="q-who"/><p><strong>1.3.</strong></p></td><td align="left" valign="top"><p>
|
| 145 |
|
|
Who's in charge of it?
|
| 146 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-who"/></td><td align="left" valign="top"><p>
|
| 147 |
|
|
The libstdc++ project is contributed to by several developers
|
| 148 |
|
|
all over the world, in the same way as GCC or the Linux kernel.
|
| 149 |
|
|
Benjamin Kosnik, Gabriel Dos Reis, Phil Edwards, Ulrich Drepper,
|
| 150 |
|
|
Loren James Rittle, and Paolo Carlini are the lead maintainers of
|
| 151 |
|
|
the SVN archive.
|
| 152 |
|
|
</p><p>
|
| 153 |
|
|
Development and discussion is held on the libstdc++ mailing
|
| 154 |
|
|
list. Subscribing to the list, or searching the list
|
| 155 |
|
|
archives, is open to everyone. You can read instructions for
|
| 156 |
|
|
doing so on the <a class="link" href="http://gcc.gnu.org/libstdc++/">homepage</a>.
|
| 157 |
|
|
If you have questions, ideas, code, or are just curious, sign up!
|
| 158 |
|
|
</p></td></tr><tr class="question" title="1.4."><td align="left" valign="top"><a id="faq.when"/><a id="q-when"/><p><strong>1.4.</strong></p></td><td align="left" valign="top"><p>
|
| 159 |
|
|
When is libstdc++ going to be finished?
|
| 160 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-when"/></td><td align="left" valign="top"><p>
|
| 161 |
|
|
Nathan Myers gave the best of all possible answers, responding to
|
| 162 |
|
|
a Usenet article asking this question: <span class="emphasis"><em>Sooner, if you
|
| 163 |
|
|
help.</em></span>
|
| 164 |
|
|
</p></td></tr><tr class="question" title="1.5."><td align="left" valign="top"><a id="faq.how"/><a id="q-how"/><p><strong>1.5.</strong></p></td><td align="left" valign="top"><p>
|
| 165 |
|
|
How do I contribute to the effort?
|
| 166 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how"/></td><td align="left" valign="top"><p>
|
| 167 |
|
|
Here is <a class="link" href="manual/appendix_contributing.html" title="Appendix A. Contributing">a page devoted to
|
| 168 |
|
|
this topic</a>. Subscribing to the mailing list (see above, or
|
| 169 |
|
|
the homepage) is a very good idea if you have something to
|
| 170 |
|
|
contribute, or if you have spare time and want to
|
| 171 |
|
|
help. Contributions don't have to be in the form of source code;
|
| 172 |
|
|
anybody who is willing to help write documentation, for example,
|
| 173 |
|
|
or has found a bug in code that we all thought was working and is
|
| 174 |
|
|
willing to provide details, is more than welcome!
|
| 175 |
|
|
</p></td></tr><tr class="question" title="1.6."><td align="left" valign="top"><a id="faq.whereis_old"/><a id="q-whereis_old"/><p><strong>1.6.</strong></p></td><td align="left" valign="top"><p>
|
| 176 |
|
|
What happened to the older libg++? I need that!
|
| 177 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-whereis_old"/></td><td align="left" valign="top"><p>
|
| 178 |
|
|
The most recent libg++ README states that libg++ is no longer
|
| 179 |
|
|
being actively maintained. It should not be used for new
|
| 180 |
|
|
projects, and is only being kicked along to support older code.
|
| 181 |
|
|
</p><p>
|
| 182 |
|
|
More information in the <a class="link" href="manual/backwards.html" title="Backwards Compatibility">backwards compatibility documentation</a>
|
| 183 |
|
|
</p></td></tr><tr class="question" title="1.7."><td align="left" valign="top"><a id="faq.more_questions"/><a id="q-more_questions"/><p><strong>1.7.</strong></p></td><td align="left" valign="top"><p>
|
| 184 |
|
|
What if I have more questions?
|
| 185 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-more_questions"/></td><td align="left" valign="top"><p>
|
| 186 |
|
|
If you have read the README file, and your question remains
|
| 187 |
|
|
unanswered, then just ask the mailing list. At present, you do not
|
| 188 |
|
|
need to be subscribed to the list to send a message to it. More
|
| 189 |
|
|
information is available on the homepage (including how to browse
|
| 190 |
|
|
the list archives); to send a message to the list,
|
| 191 |
|
|
use <code class="email"><<a class="email" href="mailto:libstdc++@gcc.gnu.org">libstdc++@gcc.gnu.org</a>></code>.
|
| 192 |
|
|
</p><p>
|
| 193 |
|
|
If you have a question that you think should be included
|
| 194 |
|
|
here, or if you have a question <span class="emphasis"><em>about</em></span> a question/answer
|
| 195 |
|
|
here, please send email to the libstdc++ mailing list, as above.
|
| 196 |
|
|
</p></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>2.1. <a href="faq.html#faq.license.what">
|
| 197 |
|
|
What are the license terms for libstdc++?
|
| 198 |
|
|
</a></dt><dt>2.2. <a href="faq.html#faq.license.any_program">
|
| 199 |
|
|
So any program which uses libstdc++ falls under the GPL?
|
| 200 |
|
|
</a></dt><dt>2.3. <a href="faq.html#faq.license.lgpl">
|
| 201 |
|
|
How is that different from the GNU {Lesser,Library} GPL?
|
| 202 |
|
|
</a></dt><dt>2.4. <a href="faq.html#faq.license.what_restrictions">
|
| 203 |
|
|
I see. So, what restrictions are there on programs that use the library?
|
| 204 |
|
|
</a></dt></dl></td></tr><tr class="question" title="2.1."><td align="left" valign="top"><a id="faq.license.what"/><a id="q-license.what"/><p><strong>2.1.</strong></p></td><td align="left" valign="top"><p>
|
| 205 |
|
|
What are the license terms for libstdc++?
|
| 206 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-license.what"/></td><td align="left" valign="top"><p>
|
| 207 |
|
|
See <a class="link" href="manual/license.html" title="License">our license description</a>
|
| 208 |
|
|
for these and related questions.
|
| 209 |
|
|
</p></td></tr><tr class="question" title="2.2."><td align="left" valign="top"><a id="faq.license.any_program"/><a id="q-license.any_program"/><p><strong>2.2.</strong></p></td><td align="left" valign="top"><p>
|
| 210 |
|
|
So any program which uses libstdc++ falls under the GPL?
|
| 211 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-license.any_program"/></td><td align="left" valign="top"><p>
|
| 212 |
|
|
No. The special exception permits use of the library in
|
| 213 |
|
|
proprietary applications.
|
| 214 |
|
|
</p></td></tr><tr class="question" title="2.3."><td align="left" valign="top"><a id="faq.license.lgpl"/><a id="q-license.lgpl"/><p><strong>2.3.</strong></p></td><td align="left" valign="top"><p>
|
| 215 |
|
|
How is that different from the GNU {Lesser,Library} GPL?
|
| 216 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-license.lgpl"/></td><td align="left" valign="top"><p>
|
| 217 |
|
|
The LGPL requires that users be able to replace the LGPL code with a
|
| 218 |
|
|
modified version; this is trivial if the library in question is a C
|
| 219 |
|
|
shared library. But there's no way to make that work with C++, where
|
| 220 |
|
|
much of the library consists of inline functions and templates, which
|
| 221 |
|
|
are expanded inside the code that uses the library. So to allow people
|
| 222 |
|
|
to replace the library code, someone using the library would have to
|
| 223 |
|
|
distribute their own source, rendering the LGPL equivalent to the GPL.
|
| 224 |
|
|
</p></td></tr><tr class="question" title="2.4."><td align="left" valign="top"><a id="faq.license.what_restrictions"/><a id="q-license.what_restrictions"/><p><strong>2.4.</strong></p></td><td align="left" valign="top"><p>
|
| 225 |
|
|
I see. So, what restrictions are there on programs that use the library?
|
| 226 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-license.what_restrictions"/></td><td align="left" valign="top"><p>
|
| 227 |
|
|
None. We encourage such programs to be released as open source,
|
| 228 |
|
|
but we won't punish you or sue you if you choose otherwise.
|
| 229 |
|
|
</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++?
|
| 230 |
|
|
</a></dt><dt>3.2. <a href="faq.html#faq.how_to_get_sources">How does one get current libstdc++ sources?
|
| 231 |
|
|
</a></dt><dt>3.3. <a href="faq.html#faq.how_to_test">How do I know if it works?
|
| 232 |
|
|
</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?
|
| 233 |
|
|
</a></dt><dt>3.5. <a href="faq.html#faq.what_is_libsupcxx">
|
| 234 |
|
|
What's libsupc++?
|
| 235 |
|
|
</a></dt><dt>3.6. <a href="faq.html#faq.size">
|
| 236 |
|
|
This library is HUGE!
|
| 237 |
|
|
</a></dt></dl></td></tr><tr class="question" title="3.1."><td align="left" valign="top"><a id="faq.how_to_install"/><a id="q-how_to_install"/><p><strong>3.1.</strong></p></td><td align="left" valign="top"><p>How do I install libstdc++?
|
| 238 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how_to_install"/></td><td align="left" valign="top"><p>
|
| 239 |
|
|
Often libstdc++ comes pre-installed as an integral part of many
|
| 240 |
|
|
existing GNU/Linux and Unix systems, as well as many embedded
|
| 241 |
|
|
development tools. It may be necessary to install extra
|
| 242 |
|
|
development packages to get the headers, or the documentation, or
|
| 243 |
|
|
the source: please consult your vendor for details.
|
| 244 |
|
|
</p><p>
|
| 245 |
|
|
To build and install from the GNU GCC sources, please consult the
|
| 246 |
|
|
<a class="link" href="manual/setup.html" title="Chapter 2. Setup">setup
|
| 247 |
|
|
documentation</a> for detailed
|
| 248 |
|
|
instructions. You may wish to browse those files ahead
|
| 249 |
|
|
of time to get a feel for what's required.
|
| 250 |
|
|
</p></td></tr><tr class="question" title="3.2."><td align="left" valign="top"><a id="faq.how_to_get_sources"/><a id="q-how_to_get_sources"/><p><strong>3.2.</strong></p></td><td align="left" valign="top"><p>How does one get current libstdc++ sources?
|
| 251 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how_to_get_sources"/></td><td align="left" valign="top"><p>
|
| 252 |
|
|
Libstdc++ sources for all official releases can be obtained as
|
| 253 |
|
|
part of the GCC sources, available from various sites and
|
| 254 |
|
|
mirrors. A full <a class="link" href="http://gcc.gnu.org/mirrors.html">list of
|
| 255 |
|
|
download sites</a> is provided on the main GCC site.
|
| 256 |
|
|
</p><p>
|
| 257 |
|
|
Current libstdc++ sources can always be checked out of the main
|
| 258 |
|
|
GCC source repository using the appropriate version control
|
| 259 |
|
|
tool. At this time, that tool
|
| 260 |
|
|
is <span class="application">Subversion</span>.
|
| 261 |
|
|
</p><p>
|
| 262 |
|
|
<span class="application">Subversion</span>, or <acronym class="acronym">SVN</acronym>, is
|
| 263 |
|
|
one of several revision control packages. It was selected for GNU
|
| 264 |
|
|
projects because it's free (speech), free (beer), and very high
|
| 265 |
|
|
quality. The <a class="link" href="http://subversion.tigris.org"> Subversion
|
| 266 |
|
|
home page</a> has a better description.
|
| 267 |
|
|
</p><p>
|
| 268 |
|
|
The <span class="quote">“<span class="quote">anonymous client checkout</span>”</span> feature of SVN is
|
| 269 |
|
|
similar to anonymous FTP in that it allows anyone to retrieve
|
| 270 |
|
|
the latest libstdc++ sources.
|
| 271 |
|
|
</p><p>
|
| 272 |
|
|
For more information
|
| 273 |
|
|
see <a class="link" href="http://gcc.gnu.org/svn.html"><acronym class="acronym">SVN</acronym>
|
| 274 |
|
|
details</a>.
|
| 275 |
|
|
</p></td></tr><tr class="question" title="3.3."><td align="left" valign="top"><a id="faq.how_to_test"/><a id="q-how_to_test"/><p><strong>3.3.</strong></p></td><td align="left" valign="top"><p>How do I know if it works?
|
| 276 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how_to_test"/></td><td align="left" valign="top"><p>
|
| 277 |
|
|
Libstdc++ comes with its own validation testsuite, which includes
|
| 278 |
|
|
conformance testing, regression testing, ABI testing, and
|
| 279 |
|
|
performance testing. Please consult the
|
| 280 |
|
|
<a class="link" href="http://gcc.gnu.org/install/test.html">testing
|
| 281 |
|
|
documentation</a> for more details.
|
| 282 |
|
|
</p><p>
|
| 283 |
|
|
If you find bugs in the testsuite programs themselves, or if you
|
| 284 |
|
|
think of a new test program that should be added to the suite,
|
| 285 |
|
|
<span class="emphasis"><em>please</em></span> write up your idea and send it to the list!
|
| 286 |
|
|
</p></td></tr><tr class="question" title="3.4."><td align="left" valign="top"><a id="faq.how_to_set_paths"/><a id="q-how_to_set_paths"/><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?
|
| 287 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how_to_set_paths"/></td><td align="left" valign="top"><p>
|
| 288 |
|
|
Depending on your platform and library version, the error message might
|
| 289 |
|
|
be similar to one of the following:
|
| 290 |
|
|
</p><pre class="screen">
|
| 291 |
|
|
./a.out: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
|
| 292 |
|
|
|
| 293 |
|
|
/usr/libexec/ld-elf.so.1: Shared object "libstdc++.so.6" not found
|
| 294 |
|
|
</pre><p>
|
| 295 |
|
|
This doesn't mean that the shared library isn't installed, only
|
| 296 |
|
|
that the dynamic linker can't find it. When a dynamically-linked
|
| 297 |
|
|
executable is run the linker finds and loads the required shared
|
| 298 |
|
|
libraries by searching a pre-configured list of directories. If
|
| 299 |
|
|
the directory where you've installed libstdc++ is not in this list
|
| 300 |
|
|
then the libraries won't be found. The simplest way to fix this is
|
| 301 |
|
|
to use the <code class="literal">LD_LIBRARY_PATH</code> environment variable,
|
| 302 |
|
|
which is a colon-separated list of directories in which the linker
|
| 303 |
|
|
will search for shared libraries:
|
| 304 |
|
|
</p><pre class="screen">
|
| 305 |
|
|
LD_LIBRARY_PATH=${prefix}/lib:$LD_LIBRARY_PATH
|
| 306 |
|
|
export LD_LIBRARY_PATH
|
| 307 |
|
|
</pre><p>
|
| 308 |
|
|
The exact environment variable to use will depend on your
|
| 309 |
|
|
platform, e.g. DYLD_LIBRARY_PATH for Darwin,
|
| 310 |
|
|
LD_LIBRARY_PATH_32/LD_LIBRARY_PATH_64 for Solaris 32-/64-bit,
|
| 311 |
|
|
LD_LIBRARYN32_PATH/LD_LIBRARY64_PATH for Irix N32/64-bit ABIs and
|
| 312 |
|
|
SHLIB_PATH for HP-UX.
|
| 313 |
|
|
</p><p>
|
| 314 |
|
|
See the man pages for <span class="command"><strong>ld</strong></span>, <span class="command"><strong>ldd</strong></span>
|
| 315 |
|
|
and <span class="command"><strong>ldconfig</strong></span> for more information. The dynamic
|
| 316 |
|
|
linker has different names on different platforms but the man page
|
| 317 |
|
|
is usually called something such as <code class="filename">ld.so/rtld/dld.so</code>.
|
| 318 |
|
|
</p><p>
|
| 319 |
|
|
Using LD_LIBRARY_PATH 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
|
| 320 |
|
|
Libraries</a> in the manual gives some alternatives.
|
| 321 |
|
|
</p></td></tr><tr class="question" title="3.5."><td align="left" valign="top"><a id="faq.what_is_libsupcxx"/><a id="q-what_is_libsupcxx"/><p><strong>3.5.</strong></p></td><td align="left" valign="top"><p>
|
| 322 |
|
|
What's libsupc++?
|
| 323 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-what_is_libsupcxx"/></td><td align="left" valign="top"><p>
|
| 324 |
|
|
If the only functions from <code class="filename">libstdc++.a</code>
|
| 325 |
|
|
which you need are language support functions (those listed in
|
| 326 |
|
|
<a class="link" href="manual/support.html" title="Chapter 4. Support">clause 18</a> of the
|
| 327 |
|
|
standard, e.g., <code class="function">new</code> and
|
| 328 |
|
|
<code class="function">delete</code>), then try linking against
|
| 329 |
|
|
<code class="filename">libsupc++.a</code>, which is a subset of
|
| 330 |
|
|
<code class="filename">libstdc++.a</code>. (Using <span class="command"><strong>gcc</strong></span>
|
| 331 |
|
|
instead of <span class="command"><strong>g++</strong></span> and explicitly linking in
|
| 332 |
|
|
<code class="filename">libsupc++.a</code> via <code class="literal">-lsupc++</code>
|
| 333 |
|
|
for the final link step will do it). This library contains only
|
| 334 |
|
|
those support routines, one per object file. But if you are
|
| 335 |
|
|
using anything from the rest of the library, such as IOStreams
|
| 336 |
|
|
or vectors, then you'll still need pieces from
|
| 337 |
|
|
<code class="filename">libstdc++.a</code>.
|
| 338 |
|
|
</p></td></tr><tr class="question" title="3.6."><td align="left" valign="top"><a id="faq.size"/><a id="q-size"/><p><strong>3.6.</strong></p></td><td align="left" valign="top"><p>
|
| 339 |
|
|
This library is HUGE!
|
| 340 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-size"/></td><td align="left" valign="top"><p>
|
| 341 |
|
|
Usually the size of libraries on disk isn't noticeable. When a
|
| 342 |
|
|
link editor (or simply <span class="quote">“<span class="quote">linker</span>”</span>) pulls things from a
|
| 343 |
|
|
static archive library, only the necessary object files are copied
|
| 344 |
|
|
into your executable, not the entire library. Unfortunately, even
|
| 345 |
|
|
if you only need a single function or variable from an object file,
|
| 346 |
|
|
the entire object file is extracted. (There's nothing unique to C++
|
| 347 |
|
|
or libstdc++ about this; it's just common behavior, given here
|
| 348 |
|
|
for background reasons.)
|
| 349 |
|
|
</p><p>
|
| 350 |
|
|
Some of the object files which make up libstdc++.a are rather large.
|
| 351 |
|
|
If you create a statically-linked executable with
|
| 352 |
|
|
<code class="literal">-static</code>, those large object files are suddenly part
|
| 353 |
|
|
of your executable. Historically the best way around this was to
|
| 354 |
|
|
only place a very few functions (often only a single one) in each
|
| 355 |
|
|
source/object file; then extracting a single function is the same
|
| 356 |
|
|
as extracting a single .o file. For libstdc++ this is only
|
| 357 |
|
|
possible to a certain extent; the object files in question contain
|
| 358 |
|
|
template classes and template functions, pre-instantiated, and
|
| 359 |
|
|
splitting those up causes severe maintenance headaches.
|
| 360 |
|
|
</p><p>
|
| 361 |
|
|
On supported platforms, libstdc++ takes advantage of garbage
|
| 362 |
|
|
collection in the GNU linker to get a result similar to separating
|
| 363 |
|
|
each symbol into a separate source and object files. On these platforms,
|
| 364 |
|
|
GNU ld can place each function and variable into its own
|
| 365 |
|
|
section in a .o file. The GNU linker can then perform garbage
|
| 366 |
|
|
collection on unused sections; this reduces the situation to only
|
| 367 |
|
|
copying needed functions into the executable, as before, but all
|
| 368 |
|
|
happens automatically.
|
| 369 |
|
|
</p></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>4.1. <a href="faq.html#faq.other_compilers">
|
| 370 |
|
|
Can libstdc++ be used with non-GNU compilers?
|
| 371 |
|
|
</a></dt><dt>4.2. <a href="faq.html#faq.solaris_long_long">
|
| 372 |
|
|
No 'long long' type on Solaris?
|
| 373 |
|
|
</a></dt><dt>4.3. <a href="faq.html#faq.predefined">
|
| 374 |
|
|
_XOPEN_SOURCE and _GNU_SOURCE are always defined?
|
| 375 |
|
|
</a></dt><dt>4.4. <a href="faq.html#faq.darwin_ctype">
|
| 376 |
|
|
Mac OS X ctype.h is broken! How can I fix it?
|
| 377 |
|
|
</a></dt><dt>4.5. <a href="faq.html#faq.threads_i386">
|
| 378 |
|
|
Threading is broken on i386?
|
| 379 |
|
|
</a></dt><dt>4.6. <a href="faq.html#faq.atomic_mips">
|
| 380 |
|
|
MIPS atomic operations
|
| 381 |
|
|
</a></dt><dt>4.7. <a href="faq.html#faq.linux_glibc">
|
| 382 |
|
|
Recent GNU/Linux glibc required?
|
| 383 |
|
|
</a></dt><dt>4.8. <a href="faq.html#faq.freebsd_wchar">
|
| 384 |
|
|
Can't use wchar_t/wstring on FreeBSD
|
| 385 |
|
|
</a></dt></dl></td></tr><tr class="question" title="4.1."><td align="left" valign="top"><a id="faq.other_compilers"/><a id="q-other_compilers"/><p><strong>4.1.</strong></p></td><td align="left" valign="top"><p>
|
| 386 |
|
|
Can libstdc++ be used with non-GNU compilers?
|
| 387 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-other_compilers"/></td><td align="left" valign="top"><p>
|
| 388 |
|
|
Perhaps.
|
| 389 |
|
|
</p><p>
|
| 390 |
|
|
Since the goal of ISO Standardization is for all C++
|
| 391 |
|
|
implementations to be able to share code, libstdc++ should be
|
| 392 |
|
|
usable under any ISO-compliant compiler, at least in theory.
|
| 393 |
|
|
</p><p>
|
| 394 |
|
|
However, the reality is that libstdc++ is targeted and optimized
|
| 395 |
|
|
for GCC/g++. This means that often libstdc++ uses specific,
|
| 396 |
|
|
non-standard features of g++ that are not present in older
|
| 397 |
|
|
versions of proprietary compilers. It may take as much as a year or two
|
| 398 |
|
|
after an official release of GCC that contains these features for
|
| 399 |
|
|
proprietary tools to support these constructs.
|
| 400 |
|
|
</p><p>
|
| 401 |
|
|
In the near past, specific released versions of libstdc++ have
|
| 402 |
|
|
been known to work with versions of the EDG C++ compiler, and
|
| 403 |
|
|
vendor-specific proprietary C++ compilers such as the Intel ICC
|
| 404 |
|
|
C++ compiler.
|
| 405 |
|
|
</p></td></tr><tr class="question" title="4.2."><td align="left" valign="top"><a id="faq.solaris_long_long"/><a id="q-solaris_long_long"/><p><strong>4.2.</strong></p></td><td align="left" valign="top"><p>
|
| 406 |
|
|
No 'long long' type on Solaris?
|
| 407 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-solaris_long_long"/></td><td align="left" valign="top"><p>
|
| 408 |
|
|
By default we try to support the C99 <span class="type">long long</span> type.
|
| 409 |
|
|
This requires that certain functions from your C library be present.
|
| 410 |
|
|
</p><p>
|
| 411 |
|
|
Up through release 3.0.2 the platform-specific tests performed by
|
| 412 |
|
|
libstdc++ were too general, resulting in a conservative approach
|
| 413 |
|
|
to enabling the <span class="type">long long</span> code paths. The most
|
| 414 |
|
|
commonly reported platform affected was Solaris.
|
| 415 |
|
|
</p><p>
|
| 416 |
|
|
This has been fixed for libstdc++ releases greater than 3.0.3.
|
| 417 |
|
|
</p></td></tr><tr class="question" title="4.3."><td align="left" valign="top"><a id="faq.predefined"/><a id="q-predefined"/><p><strong>4.3.</strong></p></td><td align="left" valign="top"><p>
|
| 418 |
|
|
<code class="constant">_XOPEN_SOURCE</code> and <code class="constant">_GNU_SOURCE</code> are always defined?
|
| 419 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-predefined"/></td><td align="left" valign="top"><p>On Solaris, g++ (but not gcc) always defines the preprocessor
|
| 420 |
|
|
macro <code class="constant">_XOPEN_SOURCE</code>. On GNU/Linux, the same happens
|
| 421 |
|
|
with <code class="constant">_GNU_SOURCE</code>. (This is not an exhaustive list;
|
| 422 |
|
|
other macros and other platforms are also affected.)
|
| 423 |
|
|
</p><p>These macros are typically used in C library headers, guarding new
|
| 424 |
|
|
versions of functions from their older versions. The C++ standard
|
| 425 |
|
|
library includes the C standard library, but it requires the C90
|
| 426 |
|
|
version, which for backwards-compatibility reasons is often not the
|
| 427 |
|
|
default for many vendors.
|
| 428 |
|
|
</p><p>More to the point, the C++ standard requires behavior which is only
|
| 429 |
|
|
available on certain platforms after certain symbols are defined.
|
| 430 |
|
|
Usually the issue involves I/O-related typedefs. In order to
|
| 431 |
|
|
ensure correctness, the compiler simply predefines those symbols.
|
| 432 |
|
|
</p><p>Note that it's not enough to #define them only when the library is
|
| 433 |
|
|
being built (during installation). Since we don't have an 'export'
|
| 434 |
|
|
keyword, much of the library exists as headers, which means that
|
| 435 |
|
|
the symbols must also be defined as your programs are parsed and
|
| 436 |
|
|
compiled.
|
| 437 |
|
|
</p><p>To see which symbols are defined, look for CPLUSPLUS_CPP_SPEC in
|
| 438 |
|
|
the gcc config headers for your target (and try changing them to
|
| 439 |
|
|
see what happens when building complicated code). You can also run
|
| 440 |
|
|
<span class="command"><strong>g++ -E -dM - < /dev/null"</strong></span> to display
|
| 441 |
|
|
a list of predefined macros for any particular installation.
|
| 442 |
|
|
</p><p>This has been discussed on the mailing lists
|
| 443 |
|
|
<a class="link" href="http://gcc.gnu.org/cgi-bin/htsearch?method=and&format=builtin-long&sort=score&words=_XOPEN_SOURCE+Solaris">quite a bit</a>.
|
| 444 |
|
|
</p><p>This method is something of a wart. We'd like to find a cleaner
|
| 445 |
|
|
solution, but nobody yet has contributed the time.
|
| 446 |
|
|
</p></td></tr><tr class="question" title="4.4."><td align="left" valign="top"><a id="faq.darwin_ctype"/><a id="q-darwin_ctype"/><p><strong>4.4.</strong></p></td><td align="left" valign="top"><p>
|
| 447 |
|
|
Mac OS X <code class="filename">ctype.h</code> is broken! How can I fix it?
|
| 448 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-darwin_ctype"/></td><td align="left" valign="top"><p>This is a long-standing bug in the OS X support. Fortunately,
|
| 449 |
|
|
the patch is quite simple, and well-known.
|
| 450 |
|
|
<a class="link" href="http://gcc.gnu.org/ml/gcc/2002-03/msg00817.html"> Here's a
|
| 451 |
|
|
link to the solution</a>.
|
| 452 |
|
|
</p></td></tr><tr class="question" title="4.5."><td align="left" valign="top"><a id="faq.threads_i386"/><a id="q-threads_i386"/><p><strong>4.5.</strong></p></td><td align="left" valign="top"><p>
|
| 453 |
|
|
Threading is broken on i386?
|
| 454 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-threads_i386"/></td><td align="left" valign="top"><p>
|
| 455 |
|
|
</p><p>Support for atomic integer operations is/was broken on i386
|
| 456 |
|
|
platforms. The assembly code accidentally used opcodes that are
|
| 457 |
|
|
only available on the i486 and later. So if you configured GCC
|
| 458 |
|
|
to target, for example, i386-linux, but actually used the programs
|
| 459 |
|
|
on an i686, then you would encounter no problems. Only when
|
| 460 |
|
|
actually running the code on a i386 will the problem appear.
|
| 461 |
|
|
</p><p>This is fixed in 3.2.2.
|
| 462 |
|
|
</p></td></tr><tr class="question" title="4.6."><td align="left" valign="top"><a id="faq.atomic_mips"/><a id="q-atomic_mips"/><p><strong>4.6.</strong></p></td><td align="left" valign="top"><p>
|
| 463 |
|
|
MIPS atomic operations
|
| 464 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-atomic_mips"/></td><td align="left" valign="top"><p>
|
| 465 |
|
|
The atomic locking routines for MIPS targets requires MIPS II
|
| 466 |
|
|
and later. A patch went in just after the 3.3 release to
|
| 467 |
|
|
make mips* use the generic implementation instead. You can also
|
| 468 |
|
|
configure for mipsel-elf as a workaround.
|
| 469 |
|
|
</p><p>
|
| 470 |
|
|
The mips*-*-linux* port continues to use the MIPS II routines, and more
|
| 471 |
|
|
work in this area is expected.
|
| 472 |
|
|
</p></td></tr><tr class="question" title="4.7."><td align="left" valign="top"><a id="faq.linux_glibc"/><a id="q-linux_glibc"/><p><strong>4.7.</strong></p></td><td align="left" valign="top"><p>
|
| 473 |
|
|
Recent GNU/Linux glibc required?
|
| 474 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-linux_glibc"/></td><td align="left" valign="top"><p>When running on GNU/Linux, libstdc++ 3.2.1 (shared library version
|
| 475 |
|
|
5.0.1) and later uses localization and formatting code from the system
|
| 476 |
|
|
C library (glibc) version 2.2.5 which contains necessary bugfixes.
|
| 477 |
|
|
Most GNU/Linux distros make more recent versions available now.
|
| 478 |
|
|
libstdc++ 4.6.0 and later require glibc 2.3 or later for this
|
| 479 |
|
|
localization and formatting code.
|
| 480 |
|
|
</p><p>The guideline is simple: the more recent the C++ library, the
|
| 481 |
|
|
more recent the C library. (This is also documented in the main
|
| 482 |
|
|
GCC installation instructions.)
|
| 483 |
|
|
</p></td></tr><tr class="question" title="4.8."><td align="left" valign="top"><a id="faq.freebsd_wchar"/><a id="q-freebsd_wchar"/><p><strong>4.8.</strong></p></td><td align="left" valign="top"><p>
|
| 484 |
|
|
Can't use wchar_t/wstring on FreeBSD
|
| 485 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-freebsd_wchar"/></td><td align="left" valign="top"><p>
|
| 486 |
|
|
Older versions of FreeBSD's C library do not have sufficient
|
| 487 |
|
|
support for wide character functions, and as a result the
|
| 488 |
|
|
libstdc++ configury decides that wchar_t support should be
|
| 489 |
|
|
disabled. In addition, the libstdc++ platform checks that
|
| 490 |
|
|
enabled <span class="type">wchar_t</span> were quite strict, and not granular
|
| 491 |
|
|
enough to detect when the minimal support to
|
| 492 |
|
|
enable <span class="type">wchar_t</span> and C++ library structures
|
| 493 |
|
|
like <code class="classname">wstring</code> were present. This impacted Solaris,
|
| 494 |
|
|
Darwin, and BSD variants, and is fixed in libstdc++ versions post 4.1.0.
|
| 495 |
|
|
</p><p>
|
| 496 |
|
|
</p></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>5.1. <a href="faq.html#faq.what_works">
|
| 497 |
|
|
What works already?
|
| 498 |
|
|
</a></dt><dt>5.2. <a href="faq.html#faq.standard_bugs">
|
| 499 |
|
|
Bugs in the ISO C++ language or library specification
|
| 500 |
|
|
</a></dt><dt>5.3. <a href="faq.html#faq.compiler_bugs">
|
| 501 |
|
|
Bugs in the compiler (gcc/g++) and not libstdc++
|
| 502 |
|
|
</a></dt></dl></td></tr><tr class="question" title="5.1."><td align="left" valign="top"><a id="faq.what_works"/><a id="q-what_works"/><p><strong>5.1.</strong></p></td><td align="left" valign="top"><p>
|
| 503 |
|
|
What works already?
|
| 504 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-what_works"/></td><td align="left" valign="top"><p>
|
| 505 |
|
|
Short answer: Pretty much everything <span class="emphasis"><em>works</em></span>
|
| 506 |
|
|
except for some corner cases. Support for localization
|
| 507 |
|
|
in <code class="classname">locale</code> may be incomplete on non-GNU
|
| 508 |
|
|
platforms. Also dependant on the underlying platform is support
|
| 509 |
|
|
for <span class="type">wchar_t</span> and <span class="type">long
|
| 510 |
|
|
long</span> specializations, and details of thread support.
|
| 511 |
|
|
</p><p>
|
| 512 |
|
|
Long answer: See the implementation status pages for
|
| 513 |
|
|
<a class="link" href="manual/status.html#status.iso.1998" title="C++ 1998/2003">C++98</a>,
|
| 514 |
|
|
<a class="link" href="manual/status.html#status.iso.tr1" title="C++ TR1">TR1</a>, and
|
| 515 |
|
|
<a class="link" href="manual/status.html#status.iso.2011" title="C++ 2011">C++11</a>.
|
| 516 |
|
|
</p></td></tr><tr class="question" title="5.2."><td align="left" valign="top"><a id="faq.standard_bugs"/><a id="q-standard_bugs"/><p><strong>5.2.</strong></p></td><td align="left" valign="top"><p>
|
| 517 |
|
|
Bugs in the ISO C++ language or library specification
|
| 518 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-standard_bugs"/></td><td align="left" valign="top"><p>
|
| 519 |
|
|
Unfortunately, there are some.
|
| 520 |
|
|
</p><p>
|
| 521 |
|
|
For those people who are not part of the ISO Library Group
|
| 522 |
|
|
(i.e., nearly all of us needing to read this page in the first
|
| 523 |
|
|
place), a public list of the library defects is occasionally
|
| 524 |
|
|
published on <a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/">the WG21
|
| 525 |
|
|
website</a>.
|
| 526 |
|
|
Some of these issues have resulted in code changes in libstdc++.
|
| 527 |
|
|
</p><p>
|
| 528 |
|
|
If you think you've discovered a new bug that is not listed,
|
| 529 |
|
|
please post a message describing your problem to the author of
|
| 530 |
|
|
the library issues list or the Usenet group comp.lang.c++.moderated.
|
| 531 |
|
|
</p></td></tr><tr class="question" title="5.3."><td align="left" valign="top"><a id="faq.compiler_bugs"/><a id="q-compiler_bugs"/><p><strong>5.3.</strong></p></td><td align="left" valign="top"><p>
|
| 532 |
|
|
Bugs in the compiler (gcc/g++) and not libstdc++
|
| 533 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-compiler_bugs"/></td><td align="left" valign="top"><p>
|
| 534 |
|
|
On occasion, the compiler is wrong. Please be advised that this
|
| 535 |
|
|
happens much less often than one would think, and avoid jumping to
|
| 536 |
|
|
conclusions.
|
| 537 |
|
|
</p><p>
|
| 538 |
|
|
First, examine the ISO C++ standard. Second, try another compiler
|
| 539 |
|
|
or an older version of the GNU compilers. Third, you can find more
|
| 540 |
|
|
information on the libstdc++ and the GCC mailing lists: search
|
| 541 |
|
|
these lists with terms describing your issue.
|
| 542 |
|
|
</p><p>
|
| 543 |
|
|
Before reporting a bug, please examine the
|
| 544 |
|
|
<a class="link" href="http://gcc.gnu.org/bugs/">bugs database</a> with the
|
| 545 |
|
|
category set to <span class="quote">“<span class="quote">g++</span>”</span>.
|
| 546 |
|
|
</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">
|
| 547 |
|
|
Reopening a stream fails
|
| 548 |
|
|
</a></dt><dt>6.2. <a href="faq.html#faq.wefcxx_verbose">
|
| 549 |
|
|
-Weffc++ complains too much
|
| 550 |
|
|
</a></dt><dt>6.3. <a href="faq.html#faq.ambiguous_overloads">
|
| 551 |
|
|
Ambiguous overloads after including an old-style header
|
| 552 |
|
|
</a></dt><dt>6.4. <a href="faq.html#faq.v2_headers">
|
| 553 |
|
|
The g++-3 headers are not ours
|
| 554 |
|
|
</a></dt><dt>6.5. <a href="faq.html#faq.boost_concept_checks">
|
| 555 |
|
|
Errors about *Concept and
|
| 556 |
|
|
constraints in the STL
|
| 557 |
|
|
</a></dt><dt>6.6. <a href="faq.html#faq.dlopen_crash">
|
| 558 |
|
|
Program crashes when using library code in a
|
| 559 |
|
|
dynamically-loaded library
|
| 560 |
|
|
</a></dt><dt>6.7. <a href="faq.html#faq.memory_leaks">
|
| 561 |
|
|
“Memory leaks” in containers
|
| 562 |
|
|
</a></dt><dt>6.8. <a href="faq.html#faq.list_size_on">
|
| 563 |
|
|
list::size() is O(n)!
|
| 564 |
|
|
</a></dt><dt>6.9. <a href="faq.html#faq.easy_to_fix">
|
| 565 |
|
|
Aw, that's easy to fix!
|
| 566 |
|
|
</a></dt></dl></td></tr><tr class="question" title="6.1."><td align="left" valign="top"><a id="faq.stream_reopening_fails"/><a id="q-stream_reopening_fails"/><p><strong>6.1.</strong></p></td><td align="left" valign="top"><p>
|
| 567 |
|
|
Reopening a stream fails
|
| 568 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-stream_reopening_fails"/></td><td align="left" valign="top"><p>
|
| 569 |
|
|
One of the most-reported non-bug reports. Executing a sequence like:
|
| 570 |
|
|
</p><div class="literallayout"><p><br/>
|
| 571 |
|
|
#include <fstream><br/>
|
| 572 |
|
|
...<br/>
|
| 573 |
|
|
std::fstream fs(<span class="quote">“<span class="quote">a_file</span>”</span>);<br/>
|
| 574 |
|
|
// .<br/>
|
| 575 |
|
|
// . do things with fs...<br/>
|
| 576 |
|
|
// .<br/>
|
| 577 |
|
|
fs.close();<br/>
|
| 578 |
|
|
fs.open(<span class="quote">“<span class="quote">a_new_file</span>”</span>);<br/>
|
| 579 |
|
|
</p></div><p>
|
| 580 |
|
|
All operations on the re-opened <code class="varname">fs</code> will fail, or at
|
| 581 |
|
|
least act very strangely. Yes, they often will, especially if
|
| 582 |
|
|
<code class="varname">fs</code> reached the EOF state on the previous file. The
|
| 583 |
|
|
reason is that the state flags are <span class="emphasis"><em>not</em></span> cleared
|
| 584 |
|
|
on a successful call to open(). The standard unfortunately did
|
| 585 |
|
|
not specify behavior in this case, and to everybody's great sorrow,
|
| 586 |
|
|
the <a class="link" href="manual/bugs.html" title="Bugs">proposed LWG resolution in
|
| 587 |
|
|
DR #22</a> is to leave the flags unchanged. You must insert a call
|
| 588 |
|
|
to <code class="function">fs.clear()</code> between the calls to close() and open(),
|
| 589 |
|
|
and then everything will work like we all expect it to work.
|
| 590 |
|
|
<span class="emphasis"><em>Update:</em></span> for GCC 4.0 we implemented the resolution
|
| 591 |
|
|
of <a class="link" href="manual/bugs.html" title="Bugs">DR #409</a> and open()
|
| 592 |
|
|
now calls <code class="function">clear()</code> on success!
|
| 593 |
|
|
</p></td></tr><tr class="question" title="6.2."><td align="left" valign="top"><a id="faq.wefcxx_verbose"/><a id="q-wefcxx_verbose"/><p><strong>6.2.</strong></p></td><td align="left" valign="top"><p>
|
| 594 |
|
|
-Weffc++ complains too much
|
| 595 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-wefcxx_verbose"/></td><td align="left" valign="top"><p>
|
| 596 |
|
|
Many warnings are emitted when <code class="literal">-Weffc++</code> is used. Making
|
| 597 |
|
|
libstdc++ <code class="literal">-Weffc++</code>-clean is not a goal of the project,
|
| 598 |
|
|
for a few reasons. Mainly, that option tries to enforce
|
| 599 |
|
|
object-oriented programming, while the Standard Library isn't
|
| 600 |
|
|
necessarily trying to be OO.
|
| 601 |
|
|
</p><p>
|
| 602 |
|
|
We do, however, try to have libstdc++ sources as clean as possible. If
|
| 603 |
|
|
you see some simple changes that pacify <code class="literal">-Weffc++</code>
|
| 604 |
|
|
without other drawbacks, send us a patch.
|
| 605 |
|
|
</p></td></tr><tr class="question" title="6.3."><td align="left" valign="top"><a id="faq.ambiguous_overloads"/><a id="q-ambiguous_overloads"/><p><strong>6.3.</strong></p></td><td align="left" valign="top"><p>
|
| 606 |
|
|
Ambiguous overloads after including an old-style header
|
| 607 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-ambiguous_overloads"/></td><td align="left" valign="top"><p>
|
| 608 |
|
|
Another problem is the <code class="literal">rel_ops</code> namespace and the template
|
| 609 |
|
|
comparison operator functions contained therein. If they become
|
| 610 |
|
|
visible in the same namespace as other comparison functions
|
| 611 |
|
|
(e.g., <span class="quote">“<span class="quote">using</span>”</span> them and the <iterator> header),
|
| 612 |
|
|
then you will suddenly be faced with huge numbers of ambiguity
|
| 613 |
|
|
errors. This was discussed on the -v3 list; Nathan Myers
|
| 614 |
|
|
<a class="link" href="http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html">sums
|
| 615 |
|
|
things up here</a>. The collisions with vector/string iterator
|
| 616 |
|
|
types have been fixed for 3.1.
|
| 617 |
|
|
</p></td></tr><tr class="question" title="6.4."><td align="left" valign="top"><a id="faq.v2_headers"/><a id="q-v2_headers"/><p><strong>6.4.</strong></p></td><td align="left" valign="top"><p>
|
| 618 |
|
|
The g++-3 headers are <span class="emphasis"><em>not ours</em></span>
|
| 619 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-v2_headers"/></td><td align="left" valign="top"><p>
|
| 620 |
|
|
If you are using headers in
|
| 621 |
|
|
<code class="filename">${prefix}/include/g++-3</code>, or if the installed
|
| 622 |
|
|
library's name looks like <code class="filename">libstdc++-2.10.a</code> or
|
| 623 |
|
|
<code class="filename">libstdc++-libc6-2.10.so</code>, then you are using the
|
| 624 |
|
|
old libstdc++-v2 library, which is nonstandard and
|
| 625 |
|
|
unmaintained. Do not report problems with -v2 to the -v3
|
| 626 |
|
|
mailing list.
|
| 627 |
|
|
</p><p>
|
| 628 |
|
|
For GCC versions 3.0 and 3.1 the libstdc++ header files are
|
| 629 |
|
|
installed in <code class="filename">${prefix}/include/g++-v3</code> (see the
|
| 630 |
|
|
'v'?). Starting with version 3.2 the headers are installed in
|
| 631 |
|
|
<code class="filename">${prefix}/include/c++/${version}</code> as this prevents
|
| 632 |
|
|
headers from previous versions being found by mistake.
|
| 633 |
|
|
</p></td></tr><tr class="question" title="6.5."><td align="left" valign="top"><a id="faq.boost_concept_checks"/><a id="q-boost_concept_checks"/><p><strong>6.5.</strong></p></td><td align="left" valign="top"><p>
|
| 634 |
|
|
Errors about <span class="emphasis"><em>*Concept</em></span> and
|
| 635 |
|
|
<span class="emphasis"><em>constraints</em></span> in the STL
|
| 636 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-boost_concept_checks"/></td><td align="left" valign="top"><p>
|
| 637 |
|
|
If you see compilation errors containing messages about
|
| 638 |
|
|
<span class="errortext">foo Concept </span>and something to do with a
|
| 639 |
|
|
<span class="errortext">constraints</span> member function, then most
|
| 640 |
|
|
likely you have violated one of the requirements for types used
|
| 641 |
|
|
during instantiation of template containers and functions. For
|
| 642 |
|
|
example, EqualityComparableConcept appears if your types must be
|
| 643 |
|
|
comparable with == and you have not provided this capability (a
|
| 644 |
|
|
typo, or wrong visibility, or you just plain forgot, etc).
|
| 645 |
|
|
</p><p>
|
| 646 |
|
|
More information, including how to optionally enable/disable the
|
| 647 |
|
|
checks, is available in the
|
| 648 |
|
|
<a class="link" href="manual/bk01pt02ch05s02.html" title="Concept Checking">Diagnostics</a>.
|
| 649 |
|
|
chapter of the manual.
|
| 650 |
|
|
</p></td></tr><tr class="question" title="6.6."><td align="left" valign="top"><a id="faq.dlopen_crash"/><a id="q-dlopen_crash"/><p><strong>6.6.</strong></p></td><td align="left" valign="top"><p>
|
| 651 |
|
|
Program crashes when using library code in a
|
| 652 |
|
|
dynamically-loaded library
|
| 653 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-dlopen_crash"/></td><td align="left" valign="top"><p>
|
| 654 |
|
|
If you are using the C++ library across dynamically-loaded
|
| 655 |
|
|
objects, make certain that you are passing the correct options
|
| 656 |
|
|
when compiling and linking:
|
| 657 |
|
|
</p><div class="literallayout"><p><br/>
|
| 658 |
|
|
// compile your library components<br/>
|
| 659 |
|
|
g++ -fPIC -c a.cc<br/>
|
| 660 |
|
|
g++ -fPIC -c b.cc<br/>
|
| 661 |
|
|
...<br/>
|
| 662 |
|
|
g++ -fPIC -c z.cc<br/>
|
| 663 |
|
|
<br/>
|
| 664 |
|
|
// create your library<br/>
|
| 665 |
|
|
g++ -fPIC -shared -rdynamic -o libfoo.so a.o b.o ... z.o<br/>
|
| 666 |
|
|
<br/>
|
| 667 |
|
|
// link the executable<br/>
|
| 668 |
|
|
g++ -fPIC -rdynamic -o foo ... -L. -lfoo -ldl<br/>
|
| 669 |
|
|
</p></div></td></tr><tr class="question" title="6.7."><td align="left" valign="top"><a id="faq.memory_leaks"/><a id="q-memory_leaks"/><p><strong>6.7.</strong></p></td><td align="left" valign="top"><p>
|
| 670 |
|
|
<span class="quote">“<span class="quote">Memory leaks</span>”</span> in containers
|
| 671 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-memory_leaks"/></td><td align="left" valign="top"><p>
|
| 672 |
|
|
A few people have reported that the standard containers appear
|
| 673 |
|
|
to leak memory when tested with memory checkers such as
|
| 674 |
|
|
<a class="link" href="http://valgrind.org/">valgrind</a>.
|
| 675 |
|
|
The library's default allocators keep free memory in a pool
|
| 676 |
|
|
for later reuse, rather than returning it to the OS. Although
|
| 677 |
|
|
this memory is always reachable by the library and is never
|
| 678 |
|
|
lost, memory debugging tools can report it as a leak. If you
|
| 679 |
|
|
want to test the library for memory leaks please read
|
| 680 |
|
|
<a class="link" href="manual/debug.html#debug.memory" title="Memory Leak Hunting">Tips for memory leak hunting</a>
|
| 681 |
|
|
first.
|
| 682 |
|
|
</p></td></tr><tr class="question" title="6.8."><td align="left" valign="top"><a id="faq.list_size_on"/><a id="q-list_size_on"/><p><strong>6.8.</strong></p></td><td align="left" valign="top"><p>
|
| 683 |
|
|
list::size() is O(n)!
|
| 684 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-list_size_on"/></td><td align="left" valign="top"><p>
|
| 685 |
|
|
See
|
| 686 |
|
|
the <a class="link" href="manual/containers.html" title="Chapter 9. Containers">Containers</a>
|
| 687 |
|
|
chapter.
|
| 688 |
|
|
</p></td></tr><tr class="question" title="6.9."><td align="left" valign="top"><a id="faq.easy_to_fix"/><a id="q-easy_to_fix"/><p><strong>6.9.</strong></p></td><td align="left" valign="top"><p>
|
| 689 |
|
|
Aw, that's easy to fix!
|
| 690 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-easy_to_fix"/></td><td align="left" valign="top"><p>
|
| 691 |
|
|
If you have found a bug in the library and you think you have
|
| 692 |
|
|
a working fix, then send it in! The main GCC site has a page
|
| 693 |
|
|
on <a class="link" href="http://gcc.gnu.org/contribute.html">submitting
|
| 694 |
|
|
patches</a> that covers the procedure, but for libstdc++ you
|
| 695 |
|
|
should also send the patch to our mailing list in addition to
|
| 696 |
|
|
the GCC patches mailing list. The libstdc++
|
| 697 |
|
|
<a class="link" href="manual/appendix_contributing.html" title="Appendix A. Contributing">contributors' page</a>
|
| 698 |
|
|
also talks about how to submit patches.
|
| 699 |
|
|
</p><p>
|
| 700 |
|
|
In addition to the description, the patch, and the ChangeLog
|
| 701 |
|
|
entry, it is a Good Thing if you can additionally create a small
|
| 702 |
|
|
test program to test for the presence of the bug that your patch
|
| 703 |
|
|
fixes. Bugs have a way of being reintroduced; if an old bug
|
| 704 |
|
|
creeps back in, it will be caught immediately by the testsuite -
|
| 705 |
|
|
but only if such a test exists.
|
| 706 |
|
|
</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">
|
| 707 |
|
|
string::iterator is not char*; vector<T>::iterator is not T*
|
| 708 |
|
|
</a></dt><dt>7.2. <a href="faq.html#faq.what_is_next">
|
| 709 |
|
|
What's next after libstdc++?
|
| 710 |
|
|
</a></dt><dt>7.3. <a href="faq.html#faq.sgi_stl">
|
| 711 |
|
|
What about the STL from SGI?
|
| 712 |
|
|
</a></dt><dt>7.4. <a href="faq.html#faq.extensions_and_backwards_compat">
|
| 713 |
|
|
Extensions and Backward Compatibility
|
| 714 |
|
|
</a></dt><dt>7.5. <a href="faq.html#faq.tr1_support">
|
| 715 |
|
|
Does libstdc++ support TR1?
|
| 716 |
|
|
</a></dt><dt>7.6. <a href="faq.html#faq.get_iso_cxx">How do I get a copy of the ISO C++ Standard?
|
| 717 |
|
|
</a></dt><dt>7.7. <a href="faq.html#faq.what_is_abi">
|
| 718 |
|
|
What's an ABI and why is it so messy?
|
| 719 |
|
|
</a></dt><dt>7.8. <a href="faq.html#faq.size_equals_capacity">
|
| 720 |
|
|
How do I make std::vector<T>::capacity() == std::vector<T>::size?
|
| 721 |
|
|
</a></dt></dl></td></tr><tr class="question" title="7.1."><td align="left" valign="top"><a id="faq.iterator_as_pod"/><a id="faq.iterator_as_pod_q"/><p><strong>7.1.</strong></p></td><td align="left" valign="top"><p>
|
| 722 |
|
|
string::iterator is not char*; vector<T>::iterator is not T*
|
| 723 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="faq.iterator_as_pod_a"/></td><td align="left" valign="top"><p>
|
| 724 |
|
|
If you have code that depends on container<T> iterators
|
| 725 |
|
|
being implemented as pointer-to-T, your code is broken. It's
|
| 726 |
|
|
considered a feature, not a bug, that libstdc++ points this out.
|
| 727 |
|
|
</p><p>
|
| 728 |
|
|
While there are arguments for iterators to be implemented in
|
| 729 |
|
|
that manner, A) they aren't very good ones in the long term,
|
| 730 |
|
|
and B) they were never guaranteed by the Standard anyway. The
|
| 731 |
|
|
type-safety achieved by making iterators a real class rather
|
| 732 |
|
|
than a typedef for <span class="type">T*</span> outweighs nearly all opposing
|
| 733 |
|
|
arguments.
|
| 734 |
|
|
</p><p>
|
| 735 |
|
|
Code which does assume that a vector iterator <code class="varname">i</code>
|
| 736 |
|
|
is a pointer can often be fixed by changing <code class="varname">i</code> in
|
| 737 |
|
|
certain expressions to <code class="varname">&*i</code>. Future revisions
|
| 738 |
|
|
of the Standard are expected to bless this usage for
|
| 739 |
|
|
vector<> (but not for basic_string<>).
|
| 740 |
|
|
</p></td></tr><tr class="question" title="7.2."><td align="left" valign="top"><a id="faq.what_is_next"/><a id="q-what_is_next"/><p><strong>7.2.</strong></p></td><td align="left" valign="top"><p>
|
| 741 |
|
|
What's next after libstdc++?
|
| 742 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-what_is_next"/></td><td align="left" valign="top"><p>
|
| 743 |
|
|
Hopefully, not much. The goal of libstdc++ is to produce a
|
| 744 |
|
|
fully-compliant, fully-portable Standard Library. After that,
|
| 745 |
|
|
we're mostly done: there won't <span class="emphasis"><em>be</em></span> any
|
| 746 |
|
|
more compliance work to do.
|
| 747 |
|
|
</p><p>
|
| 748 |
|
|
There is an effort underway to add significant extensions to
|
| 749 |
|
|
the standard library specification. The latest version of
|
| 750 |
|
|
this effort is described in
|
| 751 |
|
|
<a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">
|
| 752 |
|
|
The C++ Library Technical Report 1</a>.
|
| 753 |
|
|
</p></td></tr><tr class="question" title="7.3."><td align="left" valign="top"><a id="faq.sgi_stl"/><a id="q-sgi_stl"/><p><strong>7.3.</strong></p></td><td align="left" valign="top"><p>
|
| 754 |
|
|
What about the STL from SGI?
|
| 755 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-sgi_stl"/></td><td align="left" valign="top"><p>
|
| 756 |
|
|
The <a class="link" href="http://www.sgi.com/tech/stl/">STL from SGI</a>,
|
| 757 |
|
|
version 3.3, was the final merge of the STL codebase. The
|
| 758 |
|
|
code in libstdc++ contains many fixes and changes, and
|
| 759 |
|
|
the SGI code is no longer under active
|
| 760 |
|
|
development. We expect that no future merges will take place.
|
| 761 |
|
|
</p><p>
|
| 762 |
|
|
In particular, <code class="classname">string</code> is not from SGI and makes no
|
| 763 |
|
|
use of their "rope" class (which is included as an
|
| 764 |
|
|
optional extension), nor is <code class="classname">valarray</code> and some others.
|
| 765 |
|
|
Classes like <code class="classname">vector<></code> are, but have been
|
| 766 |
|
|
extensively modified.
|
| 767 |
|
|
</p><p>
|
| 768 |
|
|
More information on the evolution of libstdc++ can be found at the
|
| 769 |
|
|
<a class="link" href="manual/api.html" title="API Evolution and Deprecation History">API
|
| 770 |
|
|
evolution</a>
|
| 771 |
|
|
and <a class="link" href="manual/backwards.html" title="Backwards Compatibility">backwards
|
| 772 |
|
|
compatibility</a> documentation.
|
| 773 |
|
|
</p><p>
|
| 774 |
|
|
The FAQ for SGI's STL (one jump off of their main page) is
|
| 775 |
|
|
still recommended reading.
|
| 776 |
|
|
</p></td></tr><tr class="question" title="7.4."><td align="left" valign="top"><a id="faq.extensions_and_backwards_compat"/><a id="q-extensions_and_backwards_compat"/><p><strong>7.4.</strong></p></td><td align="left" valign="top"><p>
|
| 777 |
|
|
Extensions and Backward Compatibility
|
| 778 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-extensions_and_backwards_compat"/></td><td align="left" valign="top"><p>
|
| 779 |
|
|
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.
|
| 780 |
|
|
</p></td></tr><tr class="question" title="7.5."><td align="left" valign="top"><a id="faq.tr1_support"/><a id="q-tr1_support"/><p><strong>7.5.</strong></p></td><td align="left" valign="top"><p>
|
| 781 |
|
|
Does libstdc++ support TR1?
|
| 782 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-tr1_support"/></td><td align="left" valign="top"><p>
|
| 783 |
|
|
Yes.
|
| 784 |
|
|
</p><p>
|
| 785 |
|
|
The C++ Standard Library Technical Report adds many new features to
|
| 786 |
|
|
the library. The latest version of this effort is described in
|
| 787 |
|
|
<a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">
|
| 788 |
|
|
Technical Report 1</a>.
|
| 789 |
|
|
</p><p>
|
| 790 |
|
|
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
|
| 791 |
|
|
page</a>.
|
| 792 |
|
|
</p></td></tr><tr class="question" title="7.6."><td align="left" valign="top"><a id="faq.get_iso_cxx"/><a id="q-get_iso_cxx"/><p><strong>7.6.</strong></p></td><td align="left" valign="top"><p>How do I get a copy of the ISO C++ Standard?
|
| 793 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-get_iso_cxx"/></td><td align="left" valign="top"><p>
|
| 794 |
|
|
Copies of the full ISO 14882 standard are available on line via
|
| 795 |
|
|
the ISO mirror site for committee members. Non-members, or those
|
| 796 |
|
|
who have not paid for the privilege of sitting on the committee
|
| 797 |
|
|
and sustained their two-meeting commitment for voting rights, may
|
| 798 |
|
|
get a copy of the standard from their respective national
|
| 799 |
|
|
standards organization. In the USA, this national standards
|
| 800 |
|
|
organization is ANSI and their website is
|
| 801 |
|
|
right <a class="link" href="http://www.ansi.org">here</a>. (And if
|
| 802 |
|
|
you've already registered with them, clicking this link will take
|
| 803 |
|
|
you to directly to the place where you can
|
| 804 |
|
|
<a class="link" href="http://webstore.ansi.org/RecordDetail.aspx?sku=ISO%2FIEC+14882:2003">buy the standard on-line</a>.
|
| 805 |
|
|
</p><p>
|
| 806 |
|
|
Who is your country's member body? Visit the
|
| 807 |
|
|
<a class="link" href="http://www.iso.ch/">ISO homepage</a> and find out!
|
| 808 |
|
|
</p><p>
|
| 809 |
|
|
The 2003 version of the standard (the 1998 version plus TC1) is
|
| 810 |
|
|
available in print, ISBN 0-470-84674-7.
|
| 811 |
|
|
</p></td></tr><tr class="question" title="7.7."><td align="left" valign="top"><a id="faq.what_is_abi"/><a id="q-what_is_abi"/><p><strong>7.7.</strong></p></td><td align="left" valign="top"><p>
|
| 812 |
|
|
What's an ABI and why is it so messy?
|
| 813 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-what_is_abi"/></td><td align="left" valign="top"><p>
|
| 814 |
|
|
<acronym class="acronym">ABI</acronym> stands for <span class="quote">“<span class="quote">Application Binary
|
| 815 |
|
|
Interface</span>”</span>. Conventionally, it refers to a great
|
| 816 |
|
|
mass of details about how arguments are arranged on the call
|
| 817 |
|
|
stack and/or in registers, and how various types are arranged
|
| 818 |
|
|
and padded in structs. A single CPU design may suffer
|
| 819 |
|
|
multiple ABIs designed by different development tool vendors
|
| 820 |
|
|
who made different choices, or even by the same vendor for
|
| 821 |
|
|
different target applications or compiler versions. In ideal
|
| 822 |
|
|
circumstances the CPU designer presents one ABI and all the
|
| 823 |
|
|
OSes and compilers use it. In practice every ABI omits
|
| 824 |
|
|
details that compiler implementers (consciously or
|
| 825 |
|
|
accidentally) must choose for themselves.
|
| 826 |
|
|
</p><p>
|
| 827 |
|
|
That ABI definition suffices for compilers to generate code so a
|
| 828 |
|
|
program can interact safely with an OS and its lowest-level libraries.
|
| 829 |
|
|
Users usually want an ABI to encompass more detail, allowing libraries
|
| 830 |
|
|
built with different compilers (or different releases of the same
|
| 831 |
|
|
compiler!) to be linked together. For C++, this includes many more
|
| 832 |
|
|
details than for C, and CPU designers (for good reasons elaborated
|
| 833 |
|
|
below) have not stepped up to publish C++ ABIs. The details include
|
| 834 |
|
|
virtual function implementation, struct inheritance layout, name
|
| 835 |
|
|
mangling, and exception handling. Such an ABI has been defined for
|
| 836 |
|
|
GNU C++, and is immediately useful for embedded work relying only on
|
| 837 |
|
|
a <span class="quote">“<span class="quote">free-standing implementation</span>”</span> that doesn't include (much
|
| 838 |
|
|
of) the standard library. It is a good basis for the work to come.
|
| 839 |
|
|
</p><p>
|
| 840 |
|
|
A useful C++ ABI must also incorporate many details of the standard
|
| 841 |
|
|
library implementation. For a C ABI, the layouts of a few structs
|
| 842 |
|
|
(such as FILE, stat, jmpbuf, and the like) and a few macros suffice.
|
| 843 |
|
|
For C++, the details include the complete set of names of functions
|
| 844 |
|
|
and types used, the offsets of class members and virtual functions,
|
| 845 |
|
|
and the actual definitions of all inlines. C++ exposes many more
|
| 846 |
|
|
library details to the caller than C does. It makes defining
|
| 847 |
|
|
a complete ABI a much bigger undertaking, and requires not just
|
| 848 |
|
|
documenting library implementation details, but carefully designing
|
| 849 |
|
|
those details so that future bug fixes and optimizations don't
|
| 850 |
|
|
force breaking the ABI.
|
| 851 |
|
|
</p><p>
|
| 852 |
|
|
There are ways to help isolate library implementation details from the
|
| 853 |
|
|
ABI, but they trade off against speed. Library details used in
|
| 854 |
|
|
inner loops (e.g., getchar) must be exposed and frozen for all
|
| 855 |
|
|
time, but many others may reasonably be kept hidden from user code,
|
| 856 |
|
|
so they may later be changed. Deciding which, and implementing
|
| 857 |
|
|
the decisions, must happen before you can reasonably document a
|
| 858 |
|
|
candidate C++ ABI that encompasses the standard library.
|
| 859 |
|
|
</p></td></tr><tr class="question" title="7.8."><td align="left" valign="top"><a id="faq.size_equals_capacity"/><a id="q-size_equals_capacity"/><p><strong>7.8.</strong></p></td><td align="left" valign="top"><p>
|
| 860 |
|
|
How do I make std::vector<T>::capacity() == std::vector<T>::size?
|
| 861 |
|
|
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-size_equals_capacity"/></td><td align="left" valign="top"><p>
|
| 862 |
|
|
The standard idiom for deallocating a <code class="classname">vector<T></code>'s
|
| 863 |
|
|
unused memory is to create a temporary copy of the vector and swap their
|
| 864 |
|
|
contents, e.g. for <code class="classname">vector<T> v</code>
|
| 865 |
|
|
</p><div class="literallayout"><p><br/>
|
| 866 |
|
|
std::vector<T>(v).swap(v);<br/>
|
| 867 |
|
|
</p></div><p>
|
| 868 |
|
|
The copy will take O(n) time and the swap is constant time.
|
| 869 |
|
|
</p><p>
|
| 870 |
|
|
See <a class="link" href="manual/strings.html#strings.string.shrink" title="Shrink to Fit">Shrink-to-fit
|
| 871 |
|
|
strings</a> for a similar solution for strings.
|
| 872 |
|
|
</p></td></tr></tbody></table></div></div><div class="navfooter"><hr/><table width="100%" summary="Navigation footer"><tr><td align="left"><a accesskey="p" href="bk03.html">Prev</a> </td><td align="center"><a accesskey="u" href="bk03.html">Up</a></td><td align="right"> </td></tr><tr><td align="left" valign="top"> </td><td align="center"><a accesskey="h" href="index.html">Home</a></td><td align="right" valign="top"> </td></tr></table></div></body></html>
|
