14fee23f9Smrg<?xml version="1.0" encoding="UTF-8" standalone="no"?> 2d79abf08Smrg<!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 © 3a3e9eb18Smrg 2008-2018 44fee23f9Smrg 5a3e9eb18Smrg <a class="link" href="https://www.fsf.org" target="_top">FSF</a> 64d5abbe8Smrg </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"> 74fee23f9Smrg What is libstdc++? 84fee23f9Smrg </a></dt><dt>1.2. <a href="faq.html#faq.why"> 94fee23f9Smrg Why should I use libstdc++? 104fee23f9Smrg </a></dt><dt>1.3. <a href="faq.html#faq.who"> 114fee23f9Smrg Who's in charge of it? 124fee23f9Smrg </a></dt><dt>1.4. <a href="faq.html#faq.when"> 134fee23f9Smrg When is libstdc++ going to be finished? 144fee23f9Smrg </a></dt><dt>1.5. <a href="faq.html#faq.how"> 154fee23f9Smrg How do I contribute to the effort? 164fee23f9Smrg </a></dt><dt>1.6. <a href="faq.html#faq.whereis_old"> 174fee23f9Smrg What happened to the older libg++? I need that! 184fee23f9Smrg </a></dt><dt>1.7. <a href="faq.html#faq.more_questions"> 194fee23f9Smrg What if I have more questions? 2048fb7bfaSmrg </a></dt></dl></dd><dt></dt><dd><dl><dt>2.1. <a href="faq.html#faq.license.what"> 214fee23f9Smrg What are the license terms for libstdc++? 224fee23f9Smrg </a></dt><dt>2.2. <a href="faq.html#faq.license.any_program"> 234fee23f9Smrg So any program which uses libstdc++ falls under the GPL? 244fee23f9Smrg </a></dt><dt>2.3. <a href="faq.html#faq.license.lgpl"> 254fee23f9Smrg How is that different from the GNU {Lesser,Library} GPL? 264fee23f9Smrg </a></dt><dt>2.4. <a href="faq.html#faq.license.what_restrictions"> 274fee23f9Smrg I see. So, what restrictions are there on programs that use the library? 2848fb7bfaSmrg </a></dt></dl></dd><dt></dt><dd><dl><dt>3.1. <a href="faq.html#faq.how_to_install">How do I install libstdc++? 294fee23f9Smrg </a></dt><dt>3.2. <a href="faq.html#faq.how_to_get_sources">How does one get current libstdc++ sources? 304fee23f9Smrg </a></dt><dt>3.3. <a href="faq.html#faq.how_to_test">How do I know if it works? 314fee23f9Smrg </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? 324fee23f9Smrg </a></dt><dt>3.5. <a href="faq.html#faq.what_is_libsupcxx"> 334fee23f9Smrg What's libsupc++? 344fee23f9Smrg </a></dt><dt>3.6. <a href="faq.html#faq.size"> 354fee23f9Smrg This library is HUGE! 3648fb7bfaSmrg </a></dt></dl></dd><dt></dt><dd><dl><dt>4.1. <a href="faq.html#faq.other_compilers"> 374fee23f9Smrg Can libstdc++ be used with non-GNU compilers? 384fee23f9Smrg </a></dt><dt>4.2. <a href="faq.html#faq.solaris_long_long"> 394fee23f9Smrg No 'long long' type on Solaris? 404fee23f9Smrg </a></dt><dt>4.3. <a href="faq.html#faq.predefined"> 414fee23f9Smrg _XOPEN_SOURCE and _GNU_SOURCE are always defined? 424fee23f9Smrg </a></dt><dt>4.4. <a href="faq.html#faq.darwin_ctype"> 434fee23f9Smrg Mac OS X ctype.h is broken! How can I fix it? 444fee23f9Smrg </a></dt><dt>4.5. <a href="faq.html#faq.threads_i386"> 454fee23f9Smrg Threading is broken on i386? 464fee23f9Smrg </a></dt><dt>4.6. <a href="faq.html#faq.atomic_mips"> 474fee23f9Smrg MIPS atomic operations 484fee23f9Smrg </a></dt><dt>4.7. <a href="faq.html#faq.linux_glibc"> 494fee23f9Smrg Recent GNU/Linux glibc required? 504fee23f9Smrg </a></dt><dt>4.8. <a href="faq.html#faq.freebsd_wchar"> 514fee23f9Smrg Can't use wchar_t/wstring on FreeBSD 5248fb7bfaSmrg </a></dt></dl></dd><dt></dt><dd><dl><dt>5.1. <a href="faq.html#faq.what_works"> 534fee23f9Smrg What works already? 544fee23f9Smrg </a></dt><dt>5.2. <a href="faq.html#faq.standard_bugs"> 554fee23f9Smrg Bugs in the ISO C++ language or library specification 564fee23f9Smrg </a></dt><dt>5.3. <a href="faq.html#faq.compiler_bugs"> 574fee23f9Smrg Bugs in the compiler (gcc/g++) and not libstdc++ 5848fb7bfaSmrg </a></dt></dl></dd><dt></dt><dd><dl><dt>6.1. <a href="faq.html#faq.stream_reopening_fails"> 594fee23f9Smrg Reopening a stream fails 604fee23f9Smrg </a></dt><dt>6.2. <a href="faq.html#faq.wefcxx_verbose"> 614fee23f9Smrg -Weffc++ complains too much 624fee23f9Smrg </a></dt><dt>6.3. <a href="faq.html#faq.ambiguous_overloads"> 634fee23f9Smrg Ambiguous overloads after including an old-style header 644fee23f9Smrg </a></dt><dt>6.4. <a href="faq.html#faq.v2_headers"> 654fee23f9Smrg The g++-3 headers are not ours 664fee23f9Smrg </a></dt><dt>6.5. <a href="faq.html#faq.boost_concept_checks"> 674fee23f9Smrg Errors about *Concept and 684fee23f9Smrg constraints in the STL 694fee23f9Smrg </a></dt><dt>6.6. <a href="faq.html#faq.dlopen_crash"> 704fee23f9Smrg Program crashes when using library code in a 714fee23f9Smrg dynamically-loaded library 724fee23f9Smrg </a></dt><dt>6.7. <a href="faq.html#faq.memory_leaks"> 73a3e9eb18Smrg “Memory leaks” in libstdc++ 744fee23f9Smrg </a></dt><dt>6.8. <a href="faq.html#faq.list_size_on"> 754fee23f9Smrg list::size() is O(n)! 764fee23f9Smrg </a></dt><dt>6.9. <a href="faq.html#faq.easy_to_fix"> 774fee23f9Smrg Aw, that's easy to fix! 7848fb7bfaSmrg </a></dt></dl></dd><dt></dt><dd><dl><dt>7.1. <a href="faq.html#faq.iterator_as_pod"> 79a3e9eb18Smrg string::iterator is not char*; 80a3e9eb18Smrg vector<T>::iterator is not T* 814fee23f9Smrg </a></dt><dt>7.2. <a href="faq.html#faq.what_is_next"> 824fee23f9Smrg What's next after libstdc++? 834fee23f9Smrg </a></dt><dt>7.3. <a href="faq.html#faq.sgi_stl"> 844fee23f9Smrg What about the STL from SGI? 854fee23f9Smrg </a></dt><dt>7.4. <a href="faq.html#faq.extensions_and_backwards_compat"> 864fee23f9Smrg Extensions and Backward Compatibility 874fee23f9Smrg </a></dt><dt>7.5. <a href="faq.html#faq.tr1_support"> 884fee23f9Smrg Does libstdc++ support TR1? 894fee23f9Smrg </a></dt><dt>7.6. <a href="faq.html#faq.get_iso_cxx">How do I get a copy of the ISO C++ Standard? 904fee23f9Smrg </a></dt><dt>7.7. <a href="faq.html#faq.what_is_abi"> 914fee23f9Smrg What's an ABI and why is it so messy? 924fee23f9Smrg </a></dt><dt>7.8. <a href="faq.html#faq.size_equals_capacity"> 934fee23f9Smrg How do I make std::vector<T>::capacity() == std::vector<T>::size? 9448fb7bfaSmrg </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"> 954fee23f9Smrg What is libstdc++? 964fee23f9Smrg </a></dt><dt>1.2. <a href="faq.html#faq.why"> 974fee23f9Smrg Why should I use libstdc++? 984fee23f9Smrg </a></dt><dt>1.3. <a href="faq.html#faq.who"> 994fee23f9Smrg Who's in charge of it? 1004fee23f9Smrg </a></dt><dt>1.4. <a href="faq.html#faq.when"> 1014fee23f9Smrg When is libstdc++ going to be finished? 1024fee23f9Smrg </a></dt><dt>1.5. <a href="faq.html#faq.how"> 1034fee23f9Smrg How do I contribute to the effort? 1044fee23f9Smrg </a></dt><dt>1.6. <a href="faq.html#faq.whereis_old"> 1054fee23f9Smrg What happened to the older libg++? I need that! 1064fee23f9Smrg </a></dt><dt>1.7. <a href="faq.html#faq.more_questions"> 1074fee23f9Smrg What if I have more questions? 10848fb7bfaSmrg </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> 1094fee23f9Smrg What is libstdc++? 1104fee23f9Smrg </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="faq.what.a"></a></td><td align="left" valign="top"><p> 1114fee23f9Smrg The GNU Standard C++ Library v3 is an ongoing project to 112a3e9eb18Smrg implement the ISO 14882 C++ Standard Library as described in 113a3e9eb18Smrg clauses 20 through 33 and annex D (prior to the 2017 standard 114a3e9eb18Smrg the library clauses started with 17). For those who want to see 1154fee23f9Smrg exactly how far the project has come, or just want the latest 116a3e9eb18Smrg bleeding-edge code, the up-to-date source can be cloned via 117a3e9eb18Smrg <a class="link" href="https://gcc.gnu.org/git.html" target="_top">Git</a>. 118a3e9eb18Smrg </p><p> 119a3e9eb18Smrg N.B. The library is called libstdc++ <span class="emphasis"><em>not</em></span> stdlibc++. 12048fb7bfaSmrg </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> 1214fee23f9Smrg Why should I use libstdc++? 1224fee23f9Smrg </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-why"></a></td><td align="left" valign="top"><p> 1234d5abbe8Smrg The completion of the initial ISO C++ standardization effort gave the C++ 1244fee23f9Smrg community a powerful set of reuseable tools in the form of the C++ 1254d5abbe8Smrg Standard Library. However, for several years C++ implementations were 1264fee23f9Smrg (as the Draft Standard used to say) <span class="quote">“<span class="quote">incomplet and 1274d5abbe8Smrg incorrekt</span>”</span>, and many suffered from limitations of the compilers 1284d5abbe8Smrg that used them. 1294fee23f9Smrg </p><p> 1304fee23f9Smrg The GNU compiler collection 1314fee23f9Smrg (<span class="command"><strong>gcc</strong></span>, <span class="command"><strong>g++</strong></span>, etc) is widely 1324fee23f9Smrg considered to be one of the leading compilers in the world. Its 1334fee23f9Smrg development is overseen by the 1344d5abbe8Smrg <a class="link" href="https://gcc.gnu.org/" target="_top">GCC team</a>. All of 1354fee23f9Smrg the rapid development and near-legendary 1364d5abbe8Smrg <a class="link" href="https://gcc.gnu.org/buildstat.html" target="_top">portability</a> 1374d5abbe8Smrg that are the hallmarks of an open-source project are applied to libstdc++. 1384fee23f9Smrg </p><p> 139a3e9eb18Smrg All of the standard classes and functions from C++98/C++03, C++11 and C++14 1404d5abbe8Smrg (such as <code class="classname">string</code>, 1414d5abbe8Smrg <code class="classname">vector<></code>, iostreams, algorithms etc.) 142a3e9eb18Smrg are freely available and attempt to be fully compliant. 1434d5abbe8Smrg Work is ongoing to complete support for the current revision of the 1444d5abbe8Smrg ISO C++ Standard. 14548fb7bfaSmrg </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> 1464fee23f9Smrg Who's in charge of it? 1474fee23f9Smrg </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-who"></a></td><td align="left" valign="top"><p> 1484fee23f9Smrg The libstdc++ project is contributed to by several developers 14948fb7bfaSmrg all over the world, in the same way as GCC or the Linux kernel. 1504d5abbe8Smrg The current maintainers are listed in the 1514d5abbe8Smrg <a class="link" href="https://gcc.gnu.org/viewcvs/gcc/trunk/MAINTAINERS?view=co" target="_top"><code class="filename">MAINTAINERS</code></a> 1524d5abbe8Smrg file (look for "c++ runtime libs"). 1534fee23f9Smrg </p><p> 1544fee23f9Smrg Development and discussion is held on the libstdc++ mailing 1554fee23f9Smrg list. Subscribing to the list, or searching the list 1564fee23f9Smrg archives, is open to everyone. You can read instructions for 1574d5abbe8Smrg doing so on the <a class="link" href="https://gcc.gnu.org/lists.html" target="_top">GCC mailing lists</a> page. 1584fee23f9Smrg If you have questions, ideas, code, or are just curious, sign up! 15948fb7bfaSmrg </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> 1604fee23f9Smrg When is libstdc++ going to be finished? 1614fee23f9Smrg </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-when"></a></td><td align="left" valign="top"><p> 1624fee23f9Smrg Nathan Myers gave the best of all possible answers, responding to 1634fee23f9Smrg a Usenet article asking this question: <span class="emphasis"><em>Sooner, if you 1644fee23f9Smrg help.</em></span> 16548fb7bfaSmrg </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> 1664fee23f9Smrg How do I contribute to the effort? 1674fee23f9Smrg </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how"></a></td><td align="left" valign="top"><p> 1684d5abbe8Smrg See the <a class="link" href="manual/appendix_contributing.html" title="Appendix A. Contributing">Contributing</a> section in 1694d5abbe8Smrg the manual. Subscribing to the mailing list (see above, or 1704fee23f9Smrg the homepage) is a very good idea if you have something to 1714fee23f9Smrg contribute, or if you have spare time and want to 1724fee23f9Smrg help. Contributions don't have to be in the form of source code; 1734fee23f9Smrg anybody who is willing to help write documentation, for example, 1744fee23f9Smrg or has found a bug in code that we all thought was working and is 1754fee23f9Smrg willing to provide details, is more than welcome! 17648fb7bfaSmrg </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> 1774fee23f9Smrg What happened to the older libg++? I need that! 1784fee23f9Smrg </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-whereis_old"></a></td><td align="left" valign="top"><p> 1794d5abbe8Smrg The last libg++ README states 1804d5abbe8Smrg <span class="quote">“<span class="quote">This package is considered obsolete and is no longer 1814d5abbe8Smrg being developed.</span>”</span> 1824d5abbe8Smrg It should not be used for new projects, and won't even compile with 1834d5abbe8Smrg recent releases of GCC (or most other C++ compilers). 1844fee23f9Smrg </p><p> 1854d5abbe8Smrg More information can be found in the 1864d5abbe8Smrg <a class="link" href="manual/backwards.html" title="Backwards Compatibility">Backwards 1874d5abbe8Smrg Compatibility</a> section of the libstdc++ manual. 18848fb7bfaSmrg </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> 1894fee23f9Smrg What if I have more questions? 1904fee23f9Smrg </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-more_questions"></a></td><td align="left" valign="top"><p> 1914d5abbe8Smrg If you have read the documentation, and your question remains 1924fee23f9Smrg unanswered, then just ask the mailing list. At present, you do not 1934fee23f9Smrg need to be subscribed to the list to send a message to it. More 1944fee23f9Smrg information is available on the homepage (including how to browse 1954fee23f9Smrg the list archives); to send a message to the list, 1964fee23f9Smrg use <code class="email"><<a class="email" href="mailto:libstdc++@gcc.gnu.org">libstdc++@gcc.gnu.org</a>></code>. 1974fee23f9Smrg </p><p> 1984fee23f9Smrg If you have a question that you think should be included 1994fee23f9Smrg here, or if you have a question <span class="emphasis"><em>about</em></span> a question/answer 2004fee23f9Smrg here, please send email to the libstdc++ mailing list, as above. 20148fb7bfaSmrg </p></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>2.1. <a href="faq.html#faq.license.what"> 2024fee23f9Smrg What are the license terms for libstdc++? 2034fee23f9Smrg </a></dt><dt>2.2. <a href="faq.html#faq.license.any_program"> 2044fee23f9Smrg So any program which uses libstdc++ falls under the GPL? 2054fee23f9Smrg </a></dt><dt>2.3. <a href="faq.html#faq.license.lgpl"> 2064fee23f9Smrg How is that different from the GNU {Lesser,Library} GPL? 2074fee23f9Smrg </a></dt><dt>2.4. <a href="faq.html#faq.license.what_restrictions"> 2084fee23f9Smrg I see. So, what restrictions are there on programs that use the library? 20948fb7bfaSmrg </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> 2104fee23f9Smrg What are the license terms for libstdc++? 2114fee23f9Smrg </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-license.what"></a></td><td align="left" valign="top"><p> 2124fee23f9Smrg See <a class="link" href="manual/license.html" title="License">our license description</a> 2134fee23f9Smrg for these and related questions. 21448fb7bfaSmrg </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> 2154fee23f9Smrg So any program which uses libstdc++ falls under the GPL? 2164fee23f9Smrg </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> 2174fee23f9Smrg No. The special exception permits use of the library in 2184fee23f9Smrg proprietary applications. 21948fb7bfaSmrg </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> 2204fee23f9Smrg How is that different from the GNU {Lesser,Library} GPL? 2214fee23f9Smrg </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-license.lgpl"></a></td><td align="left" valign="top"><p> 2224fee23f9Smrg The LGPL requires that users be able to replace the LGPL code with a 2234fee23f9Smrg modified version; this is trivial if the library in question is a C 2244fee23f9Smrg shared library. But there's no way to make that work with C++, where 2254fee23f9Smrg much of the library consists of inline functions and templates, which 2264fee23f9Smrg are expanded inside the code that uses the library. So to allow people 2274fee23f9Smrg to replace the library code, someone using the library would have to 2284fee23f9Smrg distribute their own source, rendering the LGPL equivalent to the GPL. 22948fb7bfaSmrg </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> 2304fee23f9Smrg I see. So, what restrictions are there on programs that use the library? 2314fee23f9Smrg </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> 2325f4cdc7dSskrll None. We encourage such programs to be released as free software, 2334fee23f9Smrg but we won't punish you or sue you if you choose otherwise. 23448fb7bfaSmrg </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++? 2354fee23f9Smrg </a></dt><dt>3.2. <a href="faq.html#faq.how_to_get_sources">How does one get current libstdc++ sources? 2364fee23f9Smrg </a></dt><dt>3.3. <a href="faq.html#faq.how_to_test">How do I know if it works? 2374fee23f9Smrg </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? 2384fee23f9Smrg </a></dt><dt>3.5. <a href="faq.html#faq.what_is_libsupcxx"> 2394fee23f9Smrg What's libsupc++? 2404fee23f9Smrg </a></dt><dt>3.6. <a href="faq.html#faq.size"> 2414fee23f9Smrg This library is HUGE! 24248fb7bfaSmrg </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++? 2434fee23f9Smrg </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> 2444fee23f9Smrg Often libstdc++ comes pre-installed as an integral part of many 24548fb7bfaSmrg existing GNU/Linux and Unix systems, as well as many embedded 2464fee23f9Smrg development tools. It may be necessary to install extra 2474fee23f9Smrg development packages to get the headers, or the documentation, or 2484fee23f9Smrg the source: please consult your vendor for details. 2494fee23f9Smrg </p><p> 2504fee23f9Smrg To build and install from the GNU GCC sources, please consult the 2514fee23f9Smrg <a class="link" href="manual/setup.html" title="Chapter 2. Setup">setup 2524fee23f9Smrg documentation</a> for detailed 2534fee23f9Smrg instructions. You may wish to browse those files ahead 2544fee23f9Smrg of time to get a feel for what's required. 25548fb7bfaSmrg </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? 2564fee23f9Smrg </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> 2574fee23f9Smrg Libstdc++ sources for all official releases can be obtained as 2584fee23f9Smrg part of the GCC sources, available from various sites and 2594d5abbe8Smrg mirrors. A full <a class="link" href="https://gcc.gnu.org/mirrors.html" target="_top">list of 2604fee23f9Smrg download sites</a> is provided on the main GCC site. 2614fee23f9Smrg </p><p> 262a3e9eb18Smrg Current libstdc++ sources can always be found in the main GCC source 263a3e9eb18Smrg repository, available using the appropriate version control tool. 264a3e9eb18Smrg At this time, that tool is <span class="application">Git</span>. 265a3e9eb18Smrg For more details see the documentation on 266a3e9eb18Smrg <a class="link" href="https://gcc.gnu.org/git.html" target="_top">using the Git repository</a>. 26748fb7bfaSmrg </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? 2684fee23f9Smrg </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> 2694fee23f9Smrg Libstdc++ comes with its own validation testsuite, which includes 2704fee23f9Smrg conformance testing, regression testing, ABI testing, and 2714fee23f9Smrg performance testing. Please consult the 27248fb7bfaSmrg <a class="link" href="http://gcc.gnu.org/install/test.html" target="_top">testing 2734d5abbe8Smrg documentation</a> for GCC and 274b17d1066Smrg <a class="link" href="manual/test.html" title="Testing">Testing</a> in the libstdc++ 2754d5abbe8Smrg manual for more details. 2764fee23f9Smrg </p><p> 2774fee23f9Smrg If you find bugs in the testsuite programs themselves, or if you 2784fee23f9Smrg think of a new test program that should be added to the suite, 2794fee23f9Smrg <span class="emphasis"><em>please</em></span> write up your idea and send it to the list! 28048fb7bfaSmrg </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? 2814fee23f9Smrg </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> 2824fee23f9Smrg Depending on your platform and library version, the error message might 2834fee23f9Smrg be similar to one of the following: 2844fee23f9Smrg </p><pre class="screen"> 2854fee23f9Smrg ./a.out: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory 2864fee23f9Smrg 2874fee23f9Smrg /usr/libexec/ld-elf.so.1: Shared object "libstdc++.so.6" not found 2884fee23f9Smrg </pre><p> 2894fee23f9Smrg This doesn't mean that the shared library isn't installed, only 2904fee23f9Smrg that the dynamic linker can't find it. When a dynamically-linked 2914fee23f9Smrg executable is run the linker finds and loads the required shared 2924fee23f9Smrg libraries by searching a pre-configured list of directories. If 2934fee23f9Smrg the directory where you've installed libstdc++ is not in this list 2944d5abbe8Smrg then the libraries won't be found. 2954d5abbe8Smrg </p><p> 2964d5abbe8Smrg If you already have an older version of libstdc++ installed then the 2974d5abbe8Smrg error might look like one of the following instead: 2984d5abbe8Smrg </p><pre class="screen"> 2994d5abbe8Smrg ./a.out: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.20' not found 3004d5abbe8Smrg ./a.out: /usr/lib/libstdc++.so.6: version `CXXABI_1.3.8' not found 3014d5abbe8Smrg </pre><p> 3024d5abbe8Smrg This means the linker found <code class="filename">/usr/lib/libstdc++.so.6</code> 3034d5abbe8Smrg but that library belongs to an older version of GCC than was used to 3044d5abbe8Smrg compile and link the program <code class="filename">a.out</code> (or some part 3054d5abbe8Smrg of it). The program depends on code defined in the newer libstdc++ 3064d5abbe8Smrg that belongs to the newer version of GCC, so the linker must be told 3074d5abbe8Smrg how to find the newer libstdc++ shared library. 3084d5abbe8Smrg </p><p> 3094d5abbe8Smrg The simplest way to fix this is 3104d5abbe8Smrg to use the <code class="envar">LD_LIBRARY_PATH</code> environment variable, 3114fee23f9Smrg which is a colon-separated list of directories in which the linker 3124fee23f9Smrg will search for shared libraries: 3134d5abbe8Smrg </p><pre class="screen"><span class="command"><strong> 3144d5abbe8Smrg export LD_LIBRARY_PATH=${prefix}/lib:$LD_LIBRARY_PATH 3154d5abbe8Smrg </strong></span></pre><p> 3164d5abbe8Smrg Here the shell variable <code class="varname">${prefix}</code> is assumed to contain 3174d5abbe8Smrg the directory prefix where GCC was installed to. The directory containing 3184d5abbe8Smrg the library might depend on whether you want the 32-bit or 64-bit copy 3194d5abbe8Smrg of the library, so for example would be 3204d5abbe8Smrg <code class="filename">${prefix}/lib64</code> on some systems. 3214fee23f9Smrg The exact environment variable to use will depend on your 3224d5abbe8Smrg platform, e.g. <code class="envar">DYLD_LIBRARY_PATH</code> for Darwin, 3234d5abbe8Smrg <code class="envar">LD_LIBRARY_PATH_32</code>/<code class="envar">LD_LIBRARY_PATH_64</code> 3244d5abbe8Smrg for Solaris 32-/64-bit, 3254d5abbe8Smrg and <code class="envar">SHLIB_PATH</code> for HP-UX. 3264fee23f9Smrg </p><p> 3274fee23f9Smrg See the man pages for <span class="command"><strong>ld</strong></span>, <span class="command"><strong>ldd</strong></span> 3284fee23f9Smrg and <span class="command"><strong>ldconfig</strong></span> for more information. The dynamic 3294fee23f9Smrg linker has different names on different platforms but the man page 3304d5abbe8Smrg is usually called something such as <code class="filename">ld.so</code>, 3314d5abbe8Smrg <code class="filename">rtld</code> or <code class="filename">dld.so</code>. 33248fb7bfaSmrg </p><p> 3334d5abbe8Smrg Using <code class="envar">LD_LIBRARY_PATH</code> is not always the best solution, 3344d5abbe8Smrg <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 33548fb7bfaSmrg Libraries</a> in the manual gives some alternatives. 33648fb7bfaSmrg </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> 3374fee23f9Smrg What's libsupc++? 3384fee23f9Smrg </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> 3394fee23f9Smrg If the only functions from <code class="filename">libstdc++.a</code> 3404fee23f9Smrg which you need are language support functions (those listed in 34148fb7bfaSmrg <a class="link" href="manual/support.html" title="Chapter 4. Support">clause 18</a> of the 3424fee23f9Smrg standard, e.g., <code class="function">new</code> and 3434fee23f9Smrg <code class="function">delete</code>), then try linking against 3444fee23f9Smrg <code class="filename">libsupc++.a</code>, which is a subset of 3454fee23f9Smrg <code class="filename">libstdc++.a</code>. (Using <span class="command"><strong>gcc</strong></span> 3464fee23f9Smrg instead of <span class="command"><strong>g++</strong></span> and explicitly linking in 3474d5abbe8Smrg <code class="filename">libsupc++.a</code> via <code class="option">-lsupc++</code> 3484fee23f9Smrg for the final link step will do it). This library contains only 3494fee23f9Smrg those support routines, one per object file. But if you are 3504fee23f9Smrg using anything from the rest of the library, such as IOStreams 3514fee23f9Smrg or vectors, then you'll still need pieces from 3524fee23f9Smrg <code class="filename">libstdc++.a</code>. 35348fb7bfaSmrg </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> 3544fee23f9Smrg This library is HUGE! 3554fee23f9Smrg </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-size"></a></td><td align="left" valign="top"><p> 3564fee23f9Smrg Usually the size of libraries on disk isn't noticeable. When a 3574fee23f9Smrg link editor (or simply <span class="quote">“<span class="quote">linker</span>”</span>) pulls things from a 3584fee23f9Smrg static archive library, only the necessary object files are copied 3594fee23f9Smrg into your executable, not the entire library. Unfortunately, even 3604fee23f9Smrg if you only need a single function or variable from an object file, 3614fee23f9Smrg the entire object file is extracted. (There's nothing unique to C++ 3624fee23f9Smrg or libstdc++ about this; it's just common behavior, given here 3634fee23f9Smrg for background reasons.) 3644fee23f9Smrg </p><p> 3654d5abbe8Smrg Some of the object files which make up 3664d5abbe8Smrg <code class="filename">libstdc++.a</code> are rather large. 3674fee23f9Smrg If you create a statically-linked executable with 3684d5abbe8Smrg <code class="option">-static</code>, those large object files are suddenly part 3694fee23f9Smrg of your executable. Historically the best way around this was to 3704fee23f9Smrg only place a very few functions (often only a single one) in each 3714fee23f9Smrg source/object file; then extracting a single function is the same 3724d5abbe8Smrg as extracting a single <code class="filename">.o</code> file. For libstdc++ this 3734d5abbe8Smrg is only possible to a certain extent; the object files in question contain 3744fee23f9Smrg template classes and template functions, pre-instantiated, and 3754fee23f9Smrg splitting those up causes severe maintenance headaches. 3764fee23f9Smrg </p><p> 3774fee23f9Smrg On supported platforms, libstdc++ takes advantage of garbage 3784fee23f9Smrg collection in the GNU linker to get a result similar to separating 3794fee23f9Smrg each symbol into a separate source and object files. On these platforms, 3804fee23f9Smrg GNU ld can place each function and variable into its own 3814d5abbe8Smrg section in a <code class="filename">.o</code> file. The GNU linker can then perform 3824d5abbe8Smrg garbage collection on unused sections; this reduces the situation to only 3834fee23f9Smrg copying needed functions into the executable, as before, but all 3844fee23f9Smrg happens automatically. 38548fb7bfaSmrg </p></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>4.1. <a href="faq.html#faq.other_compilers"> 3864fee23f9Smrg Can libstdc++ be used with non-GNU compilers? 3874fee23f9Smrg </a></dt><dt>4.2. <a href="faq.html#faq.solaris_long_long"> 3884fee23f9Smrg No 'long long' type on Solaris? 3894fee23f9Smrg </a></dt><dt>4.3. <a href="faq.html#faq.predefined"> 3904fee23f9Smrg _XOPEN_SOURCE and _GNU_SOURCE are always defined? 3914fee23f9Smrg </a></dt><dt>4.4. <a href="faq.html#faq.darwin_ctype"> 3924fee23f9Smrg Mac OS X ctype.h is broken! How can I fix it? 3934fee23f9Smrg </a></dt><dt>4.5. <a href="faq.html#faq.threads_i386"> 3944fee23f9Smrg Threading is broken on i386? 3954fee23f9Smrg </a></dt><dt>4.6. <a href="faq.html#faq.atomic_mips"> 3964fee23f9Smrg MIPS atomic operations 3974fee23f9Smrg </a></dt><dt>4.7. <a href="faq.html#faq.linux_glibc"> 3984fee23f9Smrg Recent GNU/Linux glibc required? 3994fee23f9Smrg </a></dt><dt>4.8. <a href="faq.html#faq.freebsd_wchar"> 4004fee23f9Smrg Can't use wchar_t/wstring on FreeBSD 40148fb7bfaSmrg </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> 4024fee23f9Smrg Can libstdc++ be used with non-GNU compilers? 4034fee23f9Smrg </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-other_compilers"></a></td><td align="left" valign="top"><p> 4044fee23f9Smrg Perhaps. 4054fee23f9Smrg </p><p> 4064fee23f9Smrg Since the goal of ISO Standardization is for all C++ 4074fee23f9Smrg implementations to be able to share code, libstdc++ should be 4084fee23f9Smrg usable under any ISO-compliant compiler, at least in theory. 4094fee23f9Smrg </p><p> 4104fee23f9Smrg However, the reality is that libstdc++ is targeted and optimized 4114d5abbe8Smrg for GCC/G++. This means that often libstdc++ uses specific, 4124d5abbe8Smrg non-standard features of G++ that are not present in older 4134fee23f9Smrg versions of proprietary compilers. It may take as much as a year or two 4144fee23f9Smrg after an official release of GCC that contains these features for 41548fb7bfaSmrg proprietary tools to support these constructs. 4164fee23f9Smrg </p><p> 4174d5abbe8Smrg Recent versions of libstdc++ are known to work with the Clang compiler. 4184fee23f9Smrg In the near past, specific released versions of libstdc++ have 4194fee23f9Smrg been known to work with versions of the EDG C++ compiler, and 4204fee23f9Smrg vendor-specific proprietary C++ compilers such as the Intel ICC 4214fee23f9Smrg C++ compiler. 42248fb7bfaSmrg </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> 4234d5abbe8Smrg No '<span class="type">long long</span>' type on Solaris? 424a3e9eb18Smrg </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> 4254fee23f9Smrg By default we try to support the C99 <span class="type">long long</span> type. 4264fee23f9Smrg This requires that certain functions from your C library be present. 4274fee23f9Smrg </p><p> 4284fee23f9Smrg Up through release 3.0.2 the platform-specific tests performed by 4294fee23f9Smrg libstdc++ were too general, resulting in a conservative approach 4304fee23f9Smrg to enabling the <span class="type">long long</span> code paths. The most 4314fee23f9Smrg commonly reported platform affected was Solaris. 4324fee23f9Smrg </p><p> 4334fee23f9Smrg This has been fixed for libstdc++ releases greater than 3.0.3. 43448fb7bfaSmrg </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> 4354fee23f9Smrg <code class="constant">_XOPEN_SOURCE</code> and <code class="constant">_GNU_SOURCE</code> are always defined? 4364d5abbe8Smrg </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>) 4374d5abbe8Smrg always defines the preprocessor macro 4384d5abbe8Smrg <code class="constant">_XOPEN_SOURCE</code>. On GNU/Linux, the same happens 4394fee23f9Smrg with <code class="constant">_GNU_SOURCE</code>. (This is not an exhaustive list; 4404fee23f9Smrg other macros and other platforms are also affected.) 4414fee23f9Smrg </p><p>These macros are typically used in C library headers, guarding new 4424d5abbe8Smrg versions of functions from their older versions. The C++98 standard 4434fee23f9Smrg library includes the C standard library, but it requires the C90 4444fee23f9Smrg version, which for backwards-compatibility reasons is often not the 4454fee23f9Smrg default for many vendors. 4464fee23f9Smrg </p><p>More to the point, the C++ standard requires behavior which is only 4474fee23f9Smrg available on certain platforms after certain symbols are defined. 4484fee23f9Smrg Usually the issue involves I/O-related typedefs. In order to 4494fee23f9Smrg ensure correctness, the compiler simply predefines those symbols. 4504d5abbe8Smrg </p><p>Note that it's not enough to <code class="literal">#define</code> them only when the library is 4514fee23f9Smrg being built (during installation). Since we don't have an 'export' 4524fee23f9Smrg keyword, much of the library exists as headers, which means that 4534fee23f9Smrg the symbols must also be defined as your programs are parsed and 4544fee23f9Smrg compiled. 4554d5abbe8Smrg </p><p>To see which symbols are defined, look for 4564d5abbe8Smrg <code class="varname">CPLUSPLUS_CPP_SPEC</code> in 4574fee23f9Smrg the gcc config headers for your target (and try changing them to 4584fee23f9Smrg see what happens when building complicated code). You can also run 459a448f87cSmrg <span class="command"><strong>g++ -E -dM -x c++ /dev/null</strong></span> to display 4604fee23f9Smrg a list of predefined macros for any particular installation. 4614fee23f9Smrg </p><p>This has been discussed on the mailing lists 46248fb7bfaSmrg <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>. 4634fee23f9Smrg </p><p>This method is something of a wart. We'd like to find a cleaner 4644fee23f9Smrg solution, but nobody yet has contributed the time. 46548fb7bfaSmrg </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> 4664fee23f9Smrg Mac OS X <code class="filename">ctype.h</code> is broken! How can I fix it? 4674d5abbe8Smrg </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> 4684d5abbe8Smrg This was a long-standing bug in the OS X support. Fortunately, the 4694d5abbe8Smrg <a class="link" href="http://gcc.gnu.org/ml/gcc/2002-03/msg00817.html" target="_top">patch</a> 4704d5abbe8Smrg was quite simple, and well-known. 47148fb7bfaSmrg </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> 4724fee23f9Smrg Threading is broken on i386? 4734d5abbe8Smrg </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 4744fee23f9Smrg platforms. The assembly code accidentally used opcodes that are 4754fee23f9Smrg only available on the i486 and later. So if you configured GCC 4764fee23f9Smrg to target, for example, i386-linux, but actually used the programs 4774fee23f9Smrg on an i686, then you would encounter no problems. Only when 4784fee23f9Smrg actually running the code on a i386 will the problem appear. 4794fee23f9Smrg </p><p>This is fixed in 3.2.2. 48048fb7bfaSmrg </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> 4814fee23f9Smrg MIPS atomic operations 4824d5abbe8Smrg </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> 4834fee23f9Smrg The atomic locking routines for MIPS targets requires MIPS II 4844fee23f9Smrg and later. A patch went in just after the 3.3 release to 4854fee23f9Smrg make mips* use the generic implementation instead. You can also 4864fee23f9Smrg configure for mipsel-elf as a workaround. 4874fee23f9Smrg </p><p> 4884fee23f9Smrg The mips*-*-linux* port continues to use the MIPS II routines, and more 4894fee23f9Smrg work in this area is expected. 49048fb7bfaSmrg </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> 4914fee23f9Smrg Recent GNU/Linux glibc required? 4924fee23f9Smrg </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 4934fee23f9Smrg 5.0.1) and later uses localization and formatting code from the system 49448fb7bfaSmrg C library (glibc) version 2.2.5 which contains necessary bugfixes. 4954d5abbe8Smrg All GNU/Linux distros make more recent versions available now. 49648fb7bfaSmrg libstdc++ 4.6.0 and later require glibc 2.3 or later for this 49748fb7bfaSmrg localization and formatting code. 4984fee23f9Smrg </p><p>The guideline is simple: the more recent the C++ library, the 4994fee23f9Smrg more recent the C library. (This is also documented in the main 5004fee23f9Smrg GCC installation instructions.) 50148fb7bfaSmrg </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> 502a3e9eb18Smrg Can't use <span class="type">wchar_t</span>/<code class="classname">wstring</code> on FreeBSD 5034d5abbe8Smrg </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> 5044fee23f9Smrg Older versions of FreeBSD's C library do not have sufficient 5054fee23f9Smrg support for wide character functions, and as a result the 5064d5abbe8Smrg libstdc++ configury decides that <span class="type">wchar_t</span> support should be 5074fee23f9Smrg disabled. In addition, the libstdc++ platform checks that 5084fee23f9Smrg enabled <span class="type">wchar_t</span> were quite strict, and not granular 5094fee23f9Smrg enough to detect when the minimal support to 5104fee23f9Smrg enable <span class="type">wchar_t</span> and C++ library structures 5114fee23f9Smrg like <code class="classname">wstring</code> were present. This impacted Solaris, 5124fee23f9Smrg Darwin, and BSD variants, and is fixed in libstdc++ versions post 4.1.0. 5134fee23f9Smrg </p><p> 51448fb7bfaSmrg </p></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>5.1. <a href="faq.html#faq.what_works"> 5154fee23f9Smrg What works already? 5164fee23f9Smrg </a></dt><dt>5.2. <a href="faq.html#faq.standard_bugs"> 5174fee23f9Smrg Bugs in the ISO C++ language or library specification 5184fee23f9Smrg </a></dt><dt>5.3. <a href="faq.html#faq.compiler_bugs"> 5194fee23f9Smrg Bugs in the compiler (gcc/g++) and not libstdc++ 52048fb7bfaSmrg </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> 5214fee23f9Smrg What works already? 5224fee23f9Smrg </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-what_works"></a></td><td align="left" valign="top"><p> 5234fee23f9Smrg Short answer: Pretty much everything <span class="emphasis"><em>works</em></span> 5244fee23f9Smrg except for some corner cases. Support for localization 5254d5abbe8Smrg in <code class="classname">locale</code> may be incomplete on some non-GNU 52648fb7bfaSmrg platforms. Also dependent on the underlying platform is support 527b17d1066Smrg for <span class="type">wchar_t</span> and <span class="type">long long</span> specializations, 528b17d1066Smrg and details of thread support. 5294fee23f9Smrg </p><p> 5304fee23f9Smrg Long answer: See the implementation status pages for 5314fee23f9Smrg <a class="link" href="manual/status.html#status.iso.1998" title="C++ 1998/2003">C++98</a>, 532b17d1066Smrg <a class="link" href="manual/status.html#status.iso.tr1" title="C++ TR1">TR1</a>, 533b17d1066Smrg <a class="link" href="manual/status.html#status.iso.2011" title="C++ 2011">C++11</a>, 534b17d1066Smrg <a class="link" href="manual/status.html#status.iso.2014" title="C++ 2014">C++14</a>, and 535b17d1066Smrg <a class="link" href="manual/status.html#status.iso.2017" title="C++ 2017">C++17</a>. 53648fb7bfaSmrg </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> 5374fee23f9Smrg Bugs in the ISO C++ language or library specification 5384fee23f9Smrg </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-standard_bugs"></a></td><td align="left" valign="top"><p> 5394fee23f9Smrg Unfortunately, there are some. 5404fee23f9Smrg </p><p> 5414fee23f9Smrg For those people who are not part of the ISO Library Group 5424fee23f9Smrg (i.e., nearly all of us needing to read this page in the first 5434fee23f9Smrg place), a public list of the library defects is occasionally 54448fb7bfaSmrg published on <a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/" target="_top">the WG21 54548fb7bfaSmrg website</a>. 546a3e9eb18Smrg Many of these issues have resulted in 547a3e9eb18Smrg <a class="link" href="manual/bugs.html#manual.intro.status.bugs.iso" title="Standard Bugs">code changes in libstdc++</a>. 5484fee23f9Smrg </p><p> 5494fee23f9Smrg If you think you've discovered a new bug that is not listed, 55048fb7bfaSmrg please post a message describing your problem to the author of 5514d5abbe8Smrg the library issues list. 55248fb7bfaSmrg </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> 5534fee23f9Smrg Bugs in the compiler (gcc/g++) and not libstdc++ 5544fee23f9Smrg </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-compiler_bugs"></a></td><td align="left" valign="top"><p> 5554fee23f9Smrg On occasion, the compiler is wrong. Please be advised that this 5564fee23f9Smrg happens much less often than one would think, and avoid jumping to 5574fee23f9Smrg conclusions. 5584fee23f9Smrg </p><p> 5594fee23f9Smrg First, examine the ISO C++ standard. Second, try another compiler 5604fee23f9Smrg or an older version of the GNU compilers. Third, you can find more 5614fee23f9Smrg information on the libstdc++ and the GCC mailing lists: search 5624fee23f9Smrg these lists with terms describing your issue. 5634fee23f9Smrg </p><p> 5644fee23f9Smrg Before reporting a bug, please examine the 565a3e9eb18Smrg <a class="link" href="https://gcc.gnu.org/bugs/" target="_top">bugs database</a>, with the 566a3e9eb18Smrg component set to <span class="quote">“<span class="quote">c++</span>”</span>. 56748fb7bfaSmrg </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"> 5684fee23f9Smrg Reopening a stream fails 5694fee23f9Smrg </a></dt><dt>6.2. <a href="faq.html#faq.wefcxx_verbose"> 5704fee23f9Smrg -Weffc++ complains too much 5714fee23f9Smrg </a></dt><dt>6.3. <a href="faq.html#faq.ambiguous_overloads"> 5724fee23f9Smrg Ambiguous overloads after including an old-style header 5734fee23f9Smrg </a></dt><dt>6.4. <a href="faq.html#faq.v2_headers"> 5744fee23f9Smrg The g++-3 headers are not ours 5754fee23f9Smrg </a></dt><dt>6.5. <a href="faq.html#faq.boost_concept_checks"> 5764fee23f9Smrg Errors about *Concept and 5774fee23f9Smrg constraints in the STL 5784fee23f9Smrg </a></dt><dt>6.6. <a href="faq.html#faq.dlopen_crash"> 5794fee23f9Smrg Program crashes when using library code in a 5804fee23f9Smrg dynamically-loaded library 5814fee23f9Smrg </a></dt><dt>6.7. <a href="faq.html#faq.memory_leaks"> 582a3e9eb18Smrg “Memory leaks” in libstdc++ 5834fee23f9Smrg </a></dt><dt>6.8. <a href="faq.html#faq.list_size_on"> 5844fee23f9Smrg list::size() is O(n)! 5854fee23f9Smrg </a></dt><dt>6.9. <a href="faq.html#faq.easy_to_fix"> 5864fee23f9Smrg Aw, that's easy to fix! 58748fb7bfaSmrg </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> 5884fee23f9Smrg Reopening a stream fails 589a3e9eb18Smrg </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> 590a3e9eb18Smrg Prior to GCC 4.0 this was one of the most-reported non-bug reports. 591a3e9eb18Smrg Executing a sequence like this would fail: 5924d5abbe8Smrg </p><pre class="programlisting"> 5934d5abbe8Smrg #include <fstream> 5944d5abbe8Smrg ... 5954d5abbe8Smrg std::fstream fs("a_file"); 5964d5abbe8Smrg // . 5974d5abbe8Smrg // . do things with fs... 5984d5abbe8Smrg // . 5994d5abbe8Smrg fs.close(); 6004d5abbe8Smrg fs.open("a_new_file"); 6014d5abbe8Smrg </pre><p> 602a3e9eb18Smrg All operations on the re-opened <code class="varname">fs</code> would fail, or at 603a3e9eb18Smrg least act very strangely, especially if <code class="varname">fs</code> reached the 604a3e9eb18Smrg EOF state on the previous file. 605a3e9eb18Smrg The original C++98 standard did not specify behavior in this case, and 606a3e9eb18Smrg the <a class="link" href="manual/bugs.html#manual.bugs.dr22">resolution of DR #22</a> was to 607a3e9eb18Smrg leave the state flags unchanged on a successful call to 608a3e9eb18Smrg <code class="function">open()</code>. 609a3e9eb18Smrg You had to insert a call to <code class="function">fs.clear()</code> between the 610a3e9eb18Smrg calls to <code class="function">close()</code> and <code class="function">open()</code>, 611a3e9eb18Smrg and then everything will work as expected. 612a3e9eb18Smrg <span class="emphasis"><em>Update:</em></span> For GCC 4.0 we implemented the resolution 613a3e9eb18Smrg of <a class="link" href="manual/bugs.html#manual.bugs.dr409">DR #409</a> and 614a3e9eb18Smrg <code class="function">open()</code> 615a3e9eb18Smrg now calls <code class="function">clear()</code> on success. 61648fb7bfaSmrg </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> 6174fee23f9Smrg -Weffc++ complains too much 6184fee23f9Smrg </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-wefcxx_verbose"></a></td><td align="left" valign="top"><p> 6194d5abbe8Smrg Many warnings are emitted when <code class="option">-Weffc++</code> is used. Making 6204d5abbe8Smrg libstdc++ <code class="option">-Weffc++</code>-clean is not a goal of the project, 6214fee23f9Smrg for a few reasons. Mainly, that option tries to enforce 6224fee23f9Smrg object-oriented programming, while the Standard Library isn't 623a3e9eb18Smrg necessarily trying to be OO. The option also enforces outdated guidelines 624a3e9eb18Smrg from old editions of the books, and the advice isn't all relevant to 625a3e9eb18Smrg modern C++ (especially C++11 and later). 6264fee23f9Smrg </p><p> 6274fee23f9Smrg We do, however, try to have libstdc++ sources as clean as possible. If 6284d5abbe8Smrg you see some simple changes that pacify <code class="option">-Weffc++</code> 6294fee23f9Smrg without other drawbacks, send us a patch. 63048fb7bfaSmrg </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> 6314fee23f9Smrg Ambiguous overloads after including an old-style header 632b17d1066Smrg </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> 6334fee23f9Smrg Another problem is the <code class="literal">rel_ops</code> namespace and the template 6344fee23f9Smrg comparison operator functions contained therein. If they become 6354fee23f9Smrg visible in the same namespace as other comparison functions 636a3e9eb18Smrg (e.g., <span class="quote">“<span class="quote">using</span>”</span> them and the 637a3e9eb18Smrg <code class="filename"><iterator></code> header), 6384fee23f9Smrg then you will suddenly be faced with huge numbers of ambiguity 639a3e9eb18Smrg errors. This was discussed on the mailing list; Nathan Myers 64048fb7bfaSmrg <a class="link" href="http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html" target="_top">sums 6414fee23f9Smrg things up here</a>. The collisions with vector/string iterator 6424fee23f9Smrg types have been fixed for 3.1. 64348fb7bfaSmrg </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> 6444fee23f9Smrg The g++-3 headers are <span class="emphasis"><em>not ours</em></span> 645a3e9eb18Smrg </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> 64648fb7bfaSmrg If you are using headers in 6474d5abbe8Smrg <code class="filename">${prefix}/include/g++-3</code>, or if 6484d5abbe8Smrg the installed library's name looks like 6494d5abbe8Smrg <code class="filename">libstdc++-2.10.a</code> or 6504d5abbe8Smrg <code class="filename">libstdc++-libc6-2.10.so</code>, then 6514d5abbe8Smrg you are using the old libstdc++-v2 library, which is non-standard and 6524fee23f9Smrg unmaintained. Do not report problems with -v2 to the -v3 6534fee23f9Smrg mailing list. 6544fee23f9Smrg </p><p> 6554d5abbe8Smrg For GCC versions 3.0 and 3.1 the libstdc++ header files are installed in 6564d5abbe8Smrg <code class="filename">${prefix}/include/g++-v3</code> 6574d5abbe8Smrg (see the 'v'?). Starting with version 3.2 the headers are installed in 6584d5abbe8Smrg <code class="filename">${prefix}/include/c++/${version}</code> 6594d5abbe8Smrg as this prevents headers from previous versions being found by mistake. 66048fb7bfaSmrg </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> 6614fee23f9Smrg Errors about <span class="emphasis"><em>*Concept</em></span> and 6624fee23f9Smrg <span class="emphasis"><em>constraints</em></span> in the STL 6634fee23f9Smrg </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> 6644fee23f9Smrg If you see compilation errors containing messages about 6654fee23f9Smrg <span class="errortext">foo Concept</span> and something to do with a 6664fee23f9Smrg <span class="errortext">constraints</span> member function, then most 6674fee23f9Smrg likely you have violated one of the requirements for types used 6684fee23f9Smrg during instantiation of template containers and functions. For 6694fee23f9Smrg example, EqualityComparableConcept appears if your types must be 6704fee23f9Smrg comparable with == and you have not provided this capability (a 6714fee23f9Smrg typo, or wrong visibility, or you just plain forgot, etc). 6724fee23f9Smrg </p><p> 6734fee23f9Smrg More information, including how to optionally enable/disable the 67448fb7bfaSmrg checks, is available in the 67548fb7bfaSmrg <a class="link" href="manual/concept_checking.html" title="Concept Checking">Diagnostics</a>. 67648fb7bfaSmrg chapter of the manual. 67748fb7bfaSmrg </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> 6784fee23f9Smrg Program crashes when using library code in a 6794fee23f9Smrg dynamically-loaded library 6804fee23f9Smrg </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-dlopen_crash"></a></td><td align="left" valign="top"><p> 6814fee23f9Smrg If you are using the C++ library across dynamically-loaded 6824fee23f9Smrg objects, make certain that you are passing the correct options 6834fee23f9Smrg when compiling and linking: 6844fee23f9Smrg </p><div class="literallayout"><p><br /> 6854d5abbe8Smrg Compile your library components:<br /> 6864d5abbe8Smrg <span class="command"><strong>g++ -fPIC -c a.cc</strong></span><br /> 6874d5abbe8Smrg <span class="command"><strong>g++ -fPIC -c b.cc</strong></span><br /> 6884fee23f9Smrg ...<br /> 6894d5abbe8Smrg <span class="command"><strong>g++ -fPIC -c z.cc</strong></span><br /> 6904fee23f9Smrg<br /> 6914d5abbe8Smrg Create your library:<br /> 6924d5abbe8Smrg <span class="command"><strong>g++ -fPIC -shared -rdynamic -o libfoo.so a.o b.o ... z.o</strong></span><br /> 6934fee23f9Smrg<br /> 6944d5abbe8Smrg Link the executable:<br /> 6954d5abbe8Smrg <span class="command"><strong>g++ -fPIC -rdynamic -o foo ... -L. -lfoo -ldl</strong></span><br /> 69648fb7bfaSmrg </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> 697a3e9eb18Smrg <span class="quote">“<span class="quote">Memory leaks</span>”</span> in libstdc++ 698003ba354Smrg </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-memory_leaks"></a></td><td align="left" valign="top"><p> 699a3e9eb18Smrg Since GCC 5.1.0, libstdc++ automatically allocates a pool 700a3e9eb18Smrg of a few dozen kilobytes on startup. This pool is used to ensure it's 701a3e9eb18Smrg possible to throw exceptions (such as <code class="classname">bad_alloc</code>) 702a3e9eb18Smrg even when <code class="code">malloc</code> is unable to allocate any more memory. 703*b1e83836Smrg With some versions of <a class="link" href="https://valgrind.org" target="_top"><span class="command"><strong>valgrind</strong></span></a> 704a3e9eb18Smrg this pool will be shown as "still reachable" when the process exits, e.g. 705a3e9eb18Smrg <code class="code">still reachable: 72,704 bytes in 1 blocks</code>. 706a3e9eb18Smrg This memory is not a leak, because it's still in use by libstdc++, 707a3e9eb18Smrg and the memory will be returned to the OS when the process exits. 708a3e9eb18Smrg Later versions of <span class="command"><strong>valgrind</strong></span> know how to free this 709a3e9eb18Smrg pool as the process exits, and so won't show any "still reachable" memory. 710a3e9eb18Smrg </p><p> 711a3e9eb18Smrg In the past, a few people reported that the standard containers appear 7124fee23f9Smrg to leak memory when tested with memory checkers such as 713*b1e83836Smrg <span class="command"><strong>valgrind</strong></span>. 714a3e9eb18Smrg Under some (non-default) configurations the library's allocators keep 715a3e9eb18Smrg free memory in a 716a3e9eb18Smrg pool for later reuse, rather than deallocating it with <code class="code">delete</code> 717a3e9eb18Smrg Although this memory is always reachable by the library and is never 7184fee23f9Smrg lost, memory debugging tools can report it as a leak. If you 7194fee23f9Smrg want to test the library for memory leaks please read 7204fee23f9Smrg <a class="link" href="manual/debug.html#debug.memory" title="Memory Leak Hunting">Tips for memory leak hunting</a> 7214fee23f9Smrg first. 72248fb7bfaSmrg </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> 723a3e9eb18Smrg <code class="code">list::size()</code> is O(n)! 7244fee23f9Smrg </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> 7254fee23f9Smrg See 72648fb7bfaSmrg the <a class="link" href="manual/containers.html" title="Chapter 9. Containers">Containers</a> 7274fee23f9Smrg chapter. 72848fb7bfaSmrg </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> 7294fee23f9Smrg Aw, that's easy to fix! 7304fee23f9Smrg </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> 7314fee23f9Smrg If you have found a bug in the library and you think you have 7324fee23f9Smrg a working fix, then send it in! The main GCC site has a page 73348fb7bfaSmrg on <a class="link" href="http://gcc.gnu.org/contribute.html" target="_top">submitting 7344fee23f9Smrg patches</a> that covers the procedure, but for libstdc++ you 7354fee23f9Smrg should also send the patch to our mailing list in addition to 7364fee23f9Smrg the GCC patches mailing list. The libstdc++ 7374fee23f9Smrg <a class="link" href="manual/appendix_contributing.html" title="Appendix A. Contributing">contributors' page</a> 7384fee23f9Smrg also talks about how to submit patches. 7394fee23f9Smrg </p><p> 7404fee23f9Smrg In addition to the description, the patch, and the ChangeLog 7414fee23f9Smrg entry, it is a Good Thing if you can additionally create a small 74248fb7bfaSmrg test program to test for the presence of the bug that your patch 74348fb7bfaSmrg fixes. Bugs have a way of being reintroduced; if an old bug 74448fb7bfaSmrg creeps back in, it will be caught immediately by the testsuite - 74548fb7bfaSmrg but only if such a test exists. 74648fb7bfaSmrg </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"> 747a3e9eb18Smrg string::iterator is not char*; 748a3e9eb18Smrg vector<T>::iterator is not T* 7494fee23f9Smrg </a></dt><dt>7.2. <a href="faq.html#faq.what_is_next"> 7504fee23f9Smrg What's next after libstdc++? 7514fee23f9Smrg </a></dt><dt>7.3. <a href="faq.html#faq.sgi_stl"> 7524fee23f9Smrg What about the STL from SGI? 7534fee23f9Smrg </a></dt><dt>7.4. <a href="faq.html#faq.extensions_and_backwards_compat"> 7544fee23f9Smrg Extensions and Backward Compatibility 7554fee23f9Smrg </a></dt><dt>7.5. <a href="faq.html#faq.tr1_support"> 7564fee23f9Smrg Does libstdc++ support TR1? 7574fee23f9Smrg </a></dt><dt>7.6. <a href="faq.html#faq.get_iso_cxx">How do I get a copy of the ISO C++ Standard? 7584fee23f9Smrg </a></dt><dt>7.7. <a href="faq.html#faq.what_is_abi"> 7594fee23f9Smrg What's an ABI and why is it so messy? 7604fee23f9Smrg </a></dt><dt>7.8. <a href="faq.html#faq.size_equals_capacity"> 7614fee23f9Smrg How do I make std::vector<T>::capacity() == std::vector<T>::size? 76248fb7bfaSmrg </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> 763a3e9eb18Smrg <code class="classname">string::iterator</code> is not <code class="code">char*</code>; 764a3e9eb18Smrg <code class="classname">vector<T>::iterator</code> is not <code class="code">T*</code> 7654fee23f9Smrg </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> 7664fee23f9Smrg If you have code that depends on container<T> iterators 7674fee23f9Smrg being implemented as pointer-to-T, your code is broken. It's 7684fee23f9Smrg considered a feature, not a bug, that libstdc++ points this out. 7694fee23f9Smrg </p><p> 7704fee23f9Smrg While there are arguments for iterators to be implemented in 7714fee23f9Smrg that manner, A) they aren't very good ones in the long term, 7724fee23f9Smrg and B) they were never guaranteed by the Standard anyway. The 7734fee23f9Smrg type-safety achieved by making iterators a real class rather 7744fee23f9Smrg than a typedef for <span class="type">T*</span> outweighs nearly all opposing 7754fee23f9Smrg arguments. 7764fee23f9Smrg </p><p> 777a3e9eb18Smrg Code which does assume that a vector/string iterator <code class="varname">i</code> 7784fee23f9Smrg is a pointer can often be fixed by changing <code class="varname">i</code> in 779a3e9eb18Smrg certain expressions to <code class="varname">&*i</code>. 78048fb7bfaSmrg </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> 7814fee23f9Smrg What's next after libstdc++? 7824fee23f9Smrg </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> 783a3e9eb18Smrg The goal of libstdc++ is to produce a 784a3e9eb18Smrg fully-compliant, fully-portable Standard Library. 785a3e9eb18Smrg While the C++ Standard continues to evolve the libstdc++ will 786a3e9eb18Smrg continue to track it. 78748fb7bfaSmrg </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> 7884fee23f9Smrg What about the STL from SGI? 7894fee23f9Smrg </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-sgi_stl"></a></td><td align="left" valign="top"><p> 790a3e9eb18Smrg The STL (Standard Template Library) was the inspiration for large chunks 791a3e9eb18Smrg of the C++ Standard Library, but the terms are not interchangeable and 792a3e9eb18Smrg they don't mean the same thing. The C++ Standard Library includes lots of 793a3e9eb18Smrg things that didn't come from the STL, and some of them aren't even 794a3e9eb18Smrg templates, such as <code class="classname">std::locale</code> and 795a3e9eb18Smrg <code class="classname">std::thread</code>. 796a3e9eb18Smrg </p><p> 797a3e9eb18Smrg Libstdc++-v3 incorporates a lot of code from 798a3e9eb18Smrg <a class="link" href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/" target="_top">the SGI STL</a> 799a3e9eb18Smrg (the final merge was from 800a3e9eb18Smrg <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>). 801a3e9eb18Smrg The code in libstdc++ contains many fixes and changes compared to the 802a3e9eb18Smrg original SGI code. 8034fee23f9Smrg </p><p> 8044fee23f9Smrg In particular, <code class="classname">string</code> is not from SGI and makes no 805a3e9eb18Smrg use of their "rope" class (although that is included as an optional 806a3e9eb18Smrg extension), neither is <code class="classname">valarray</code> nor some others. 807a3e9eb18Smrg Classes like <code class="classname">vector<></code> were from SGI, but have 808a3e9eb18Smrg been extensively modified. 8094fee23f9Smrg </p><p> 8104fee23f9Smrg More information on the evolution of libstdc++ can be found at the 8114fee23f9Smrg <a class="link" href="manual/api.html" title="API Evolution and Deprecation History">API 8124fee23f9Smrg evolution</a> 8134fee23f9Smrg and <a class="link" href="manual/backwards.html" title="Backwards Compatibility">backwards 8144fee23f9Smrg compatibility</a> documentation. 8154fee23f9Smrg </p><p> 816fb8a8121Smrg The <a class="link" href="https://web.archive.org/web/20171104092813/http://www.sgi.com/tech/stl/FAQ.html" target="_top">FAQ</a> 8174d5abbe8Smrg for SGI's STL is still recommended reading. 81848fb7bfaSmrg </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> 8194fee23f9Smrg Extensions and Backward Compatibility 8204fee23f9Smrg </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> 8214fee23f9Smrg 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. 82248fb7bfaSmrg </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> 8234fee23f9Smrg Does libstdc++ support TR1? 8244fee23f9Smrg </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-tr1_support"></a></td><td align="left" valign="top"><p> 8254fee23f9Smrg Yes. 8264fee23f9Smrg </p><p> 827a3e9eb18Smrg The C++ Standard Library 82848fb7bfaSmrg <a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf" target="_top"> 829a3e9eb18Smrg Technical Report 1</a> added many new features to the library. 8304fee23f9Smrg </p><p> 831a3e9eb18Smrg The implementation status of TR1 in libstdc++ can be tracked 832a3e9eb18Smrg <a class="link" href="manual/status.html#status.iso.tr1" title="C++ TR1">on the TR1 status page</a>. 833a3e9eb18Smrg </p><p> 834a3e9eb18Smrg New code should probably not use TR1, because almost everything in it has 835a3e9eb18Smrg been added to the main C++ Standard Library (usually with significant 836a3e9eb18Smrg improvements). 837a3e9eb18Smrg The TR1 implementation in libstdc++ is no longer actively maintained. 83848fb7bfaSmrg </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? 8394fee23f9Smrg </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> 840b17d1066Smrg Please refer to the <a class="link" href="manual/appendix_contributing.html" title="Appendix A. Contributing">Contributing</a> 841b17d1066Smrg section in our manual. 84248fb7bfaSmrg </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> 8434fee23f9Smrg What's an ABI and why is it so messy? 8444fee23f9Smrg </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> 8454fee23f9Smrg <acronym class="acronym">ABI</acronym> stands for <span class="quote">“<span class="quote">Application Binary 8464fee23f9Smrg Interface</span>”</span>. Conventionally, it refers to a great 8474fee23f9Smrg mass of details about how arguments are arranged on the call 8484fee23f9Smrg stack and/or in registers, and how various types are arranged 8494fee23f9Smrg and padded in structs. A single CPU design may suffer 8504fee23f9Smrg multiple ABIs designed by different development tool vendors 8514fee23f9Smrg who made different choices, or even by the same vendor for 8524fee23f9Smrg different target applications or compiler versions. In ideal 8534fee23f9Smrg circumstances the CPU designer presents one ABI and all the 8544fee23f9Smrg OSes and compilers use it. In practice every ABI omits 8554fee23f9Smrg details that compiler implementers (consciously or 8564fee23f9Smrg accidentally) must choose for themselves. 8574fee23f9Smrg </p><p> 8584fee23f9Smrg That ABI definition suffices for compilers to generate code so a 8594fee23f9Smrg program can interact safely with an OS and its lowest-level libraries. 8604fee23f9Smrg Users usually want an ABI to encompass more detail, allowing libraries 8614fee23f9Smrg built with different compilers (or different releases of the same 8624fee23f9Smrg compiler!) to be linked together. For C++, this includes many more 8634d5abbe8Smrg details than for C, and most CPU designers (for good reasons elaborated 8644d5abbe8Smrg below) have not stepped up to publish C++ ABIs. Such an ABI has been 8654d5abbe8Smrg defined for the Itanium architecture (see 866b17d1066Smrg <a class="link" href="https://itanium-cxx-abi.github.io/cxx-abi/" target="_top">C++ 8674d5abbe8Smrg ABI for Itanium</a>) and that is used by G++ and other compilers 8684d5abbe8Smrg as the de facto standard ABI on many common architectures (including x86). 8694d5abbe8Smrg G++ can also use the ARM architecture's EABI, for embedded 8704d5abbe8Smrg systems relying only on a <span class="quote">“<span class="quote">free-standing implementation</span>”</span> that 8714d5abbe8Smrg doesn't include (much of) the standard library, and the GNU EABI for 8724d5abbe8Smrg hosted implementations on ARM. Those ABIs cover low-level details 8734d5abbe8Smrg such as virtual function implementation, struct inheritance layout, 8744d5abbe8Smrg name mangling, and exception handling. 8754fee23f9Smrg </p><p> 8764fee23f9Smrg A useful C++ ABI must also incorporate many details of the standard 8774fee23f9Smrg library implementation. For a C ABI, the layouts of a few structs 8784d5abbe8Smrg (such as <span class="type">FILE</span>, <span class="type">stat</span>, <span class="type">jmpbuf</span>, 8794d5abbe8Smrg and the like) and a few macros suffice. 8804fee23f9Smrg For C++, the details include the complete set of names of functions 8814fee23f9Smrg and types used, the offsets of class members and virtual functions, 8824fee23f9Smrg and the actual definitions of all inlines. C++ exposes many more 8834fee23f9Smrg library details to the caller than C does. It makes defining 8844fee23f9Smrg a complete ABI a much bigger undertaking, and requires not just 8854fee23f9Smrg documenting library implementation details, but carefully designing 8864fee23f9Smrg those details so that future bug fixes and optimizations don't 8874fee23f9Smrg force breaking the ABI. 8884fee23f9Smrg </p><p> 8894fee23f9Smrg There are ways to help isolate library implementation details from the 8904d5abbe8Smrg ABI, but they trade off against speed. Library details used in inner 8914d5abbe8Smrg loops (e.g., <code class="function">getchar</code>) must be exposed and frozen for 8924d5abbe8Smrg all time, but many others may reasonably be kept hidden from user code, 8934fee23f9Smrg so they may later be changed. Deciding which, and implementing 8944fee23f9Smrg the decisions, must happen before you can reasonably document a 8954fee23f9Smrg candidate C++ ABI that encompasses the standard library. 89648fb7bfaSmrg </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> 897a3e9eb18Smrg How do I make <code class="code">std::vector<T>::capacity() == std::vector<T>::size</code>? 8984fee23f9Smrg </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> 899a3e9eb18Smrg Since C++11 just call the <code class="function">shrink_to_fit()</code> member 900a3e9eb18Smrg function. 901a3e9eb18Smrg </p><p> 902a3e9eb18Smrg Before C++11, the standard idiom for deallocating a 903a3e9eb18Smrg <code class="classname">vector<T></code>'s 904a3e9eb18Smrg unused memory was to create a temporary copy of the vector and swap their 9054fee23f9Smrg contents, e.g. for <code class="classname">vector<T> v</code> 9064fee23f9Smrg </p><div class="literallayout"><p><br /> 9074fee23f9Smrg std::vector<T>(v).swap(v);<br /> 9084fee23f9Smrg </p></div><p> 9094fee23f9Smrg The copy will take O(n) time and the swap is constant time. 9104fee23f9Smrg </p><p> 91148fb7bfaSmrg See <a class="link" href="manual/strings.html#strings.string.shrink" title="Shrink to Fit">Shrink-to-fit 9124fee23f9Smrg strings</a> for a similar solution for strings. 91348fb7bfaSmrg </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>