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