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