1*404b540aSrobert<?xml version="1.0" encoding="ISO-8859-1"?> 2*404b540aSrobert<!DOCTYPE html 3*404b540aSrobert PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 4*404b540aSrobert "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 5*404b540aSrobert 6*404b540aSrobert<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> 7*404b540aSrobert<head> 8*404b540aSrobert <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> 9*404b540aSrobert <meta name="KEYWORDS" content="libstdc++, libstdc++-v3, GCC, g++, libg++, STL" /> 10*404b540aSrobert <meta name="DESCRIPTION" content="FAQ for the GNU libstdc++ effort." /> 11*404b540aSrobert <title>libstdc++-v3 FAQ</title> 12*404b540aSrobert<link rel="StyleSheet" href="../lib3styles.css" /> 13*404b540aSrobert<link rel="Start" rev="Help" href="../documentation.html" type="text/html" 14*404b540aSrobert title="GNU C++ Standard Library" /> 15*404b540aSrobert<link rel="Copyright" href="../17_intro/license.html" type="text/html" /> 16*404b540aSrobert</head> 17*404b540aSrobert<body> 18*404b540aSrobert 19*404b540aSrobert<h1 class="centered">libstdc++ Frequently Asked Questions</h1> 20*404b540aSrobert 21*404b540aSrobert<p class="fineprint"><em> 22*404b540aSrobert The latest version of this document is always available at 23*404b540aSrobert <a href="http://gcc.gnu.org/onlinedocs/libstdc++/faq/"> 24*404b540aSrobert http://gcc.gnu.org/onlinedocs/libstdc++/faq/</a>. The main documentation 25*404b540aSrobert page is at 26*404b540aSrobert <a href="http://gcc.gnu.org/onlinedocs/libstdc++/documentation.html"> 27*404b540aSrobert http://gcc.gnu.org/onlinedocs/libstdc++/documentation.html</a>. 28*404b540aSrobert</em></p> 29*404b540aSrobert 30*404b540aSrobert<p><em> 31*404b540aSrobert To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++-v3 homepage</a>. 32*404b540aSrobert</em></p> 33*404b540aSrobert 34*404b540aSrobert<!-- ####################################################### --> 35*404b540aSrobert<hr /> 36*404b540aSrobert<h1>Questions</h1> 37*404b540aSrobert<ol> 38*404b540aSrobert <li><a href="#1_0">General Information</a> 39*404b540aSrobert <!-- I suspect these will mostly be links to/into existing documents. --> 40*404b540aSrobert <ol> 41*404b540aSrobert <li><a href="#1_1">What is libstdc++-v3?</a> </li> 42*404b540aSrobert <li><a href="#1_2">Why should I use libstdc++?</a> </li> 43*404b540aSrobert <li><a href="#1_3">Who's in charge of it?</a> </li> 44*404b540aSrobert <li><a href="#1_4">How do I get libstdc++?</a> </li> 45*404b540aSrobert <li><a href="#1_5">When is libstdc++ going to be finished?</a> </li> 46*404b540aSrobert <li><a href="#1_6">How do I contribute to the effort?</a> </li> 47*404b540aSrobert <li><a href="#1_7">What happened to libg++? I need that!</a> </li> 48*404b540aSrobert <li><a href="#1_8">What if I have more questions?</a> </li> 49*404b540aSrobert <li><a href="#1_9">What are the license terms for libstdc++-v3?</a> </li> 50*404b540aSrobert </ol> 51*404b540aSrobert </li> 52*404b540aSrobert 53*404b540aSrobert <li><a href="#2_0">Installation</a> 54*404b540aSrobert <ol> 55*404b540aSrobert <li><a href="#2_1">How do I install libstdc++-v3?</a> </li> 56*404b540aSrobert <li><a href="#2_2">[removed]</a> </li> 57*404b540aSrobert <li><a href="#2_3">What is this SVN thing that you keep 58*404b540aSrobert mentioning?</a> </li> 59*404b540aSrobert <li><a href="#2_4">How do I know if it works?</a> </li> 60*404b540aSrobert <li><a href="#2_5">This library is HUGE! And what's libsupc++?</a> </li> 61*404b540aSrobert <li><a href="#2_6">Why do I get an error saying 62*404b540aSrobert <code>libstdc++.so.X</code> is missing when I 63*404b540aSrobert run my program?</a> </li> 64*404b540aSrobert </ol> 65*404b540aSrobert </li> 66*404b540aSrobert 67*404b540aSrobert <li><a href="#3_0">Platform-Specific Issues</a> 68*404b540aSrobert <ol> 69*404b540aSrobert <li><a href="#3_1">Can libstdc++-v3 be used with <my 70*404b540aSrobert favorite compiler>?</a> </li> 71*404b540aSrobert <li><a href="#3_2">[removed]</a> </li> 72*404b540aSrobert <li><a href="#3_3">[removed]</a> </li> 73*404b540aSrobert <li><a href="#3_4">I can't use 'long long' on Solaris</a> </li> 74*404b540aSrobert <li><a href="#3_5"><code>_XOPEN_SOURCE</code> / 75*404b540aSrobert <code>_GNU_SOURCE</code> / etc is always defined</a> 76*404b540aSrobert </li> 77*404b540aSrobert <li><a href="#3_6">OS X ctype.h is broken! How can I hack it?</a></li> 78*404b540aSrobert <li><a href="#3_7">Threading is broken on i386</a></li> 79*404b540aSrobert <li><a href="#3_8">Recent GNU/Linux glibc required?</a></li> 80*404b540aSrobert <li><a href="#3_9">Can't use wchar_t/wstring on FreeBSD</a></li> 81*404b540aSrobert <li><a href="#3_10">MIPS atomic operations</a></li> 82*404b540aSrobert </ol> 83*404b540aSrobert </li> 84*404b540aSrobert 85*404b540aSrobert <li><a href="#4_0">Known Bugs and Non-Bugs</a> 86*404b540aSrobert <ol> 87*404b540aSrobert <li><a href="#4_1">What works already?</a> </li> 88*404b540aSrobert <li><a href="#4_2">Bugs in gcc/g++ (not libstdc++-v3)</a> </li> 89*404b540aSrobert <li><a href="#4_3">Bugs in the C++ language/lib specification</a> </li> 90*404b540aSrobert <li><a href="#4_4">Things in libstdc++ that only look like bugs</a><ul> 91*404b540aSrobert <li><a href="#4_4_iostreamclear">reopening a stream fails</a> </li> 92*404b540aSrobert <li><a href="#4_4_Weff">-Weffc++ complains too much</a> </li> 93*404b540aSrobert <li><a href="#4_4_rel_ops">"ambiguous overloads" 94*404b540aSrobert after including an old-style header</a> </li> 95*404b540aSrobert <li><a href="#4_4_interface">The g++-3 headers are 96*404b540aSrobert <strong>not ours</strong></a> </li> 97*404b540aSrobert <li><a href="#4_4_glibc">compilation errors from streambuf.h</a> </li> 98*404b540aSrobert <li><a href="#4_4_checks">errors about <em>*Concept</em> and 99*404b540aSrobert <em>constraints</em> in the STL...</a> </li> 100*404b540aSrobert <li><a href="#4_4_dlsym">program crashes when using library code 101*404b540aSrobert in a dynamically-loaded library</a> </li> 102*404b540aSrobert <li><a href="#4_4_leak">"memory leaks" in containers</a> </li> 103*404b540aSrobert </ul> 104*404b540aSrobert </li> 105*404b540aSrobert <li><a href="#4_5">Aw, that's easy to fix!</a> </li> 106*404b540aSrobert </ol> 107*404b540aSrobert </li> 108*404b540aSrobert 109*404b540aSrobert <li><a href="#5_0">Miscellaneous</a> 110*404b540aSrobert <ol> 111*404b540aSrobert <li><a href="#5_1">string::iterator is not char*; 112*404b540aSrobert vector<T>::iterator is not T*</a> </li> 113*404b540aSrobert <li><a href="#5_2">What's next after libstdc++-v3?</a> </li> 114*404b540aSrobert <li><a href="#5_3">What about the STL from SGI?</a> </li> 115*404b540aSrobert <li><a href="#5_4">Extensions and Backward Compatibility</a> </li> 116*404b540aSrobert <li><a href="#5_5">Does libstdc++ support TR1?</a> </li> 117*404b540aSrobert <li><a href="#5_6">Is libstdc++-v3 thread-safe?</a> </li> 118*404b540aSrobert <li><a href="#5_7">How do I get a copy of the ISO C++ Standard?</a> </li> 119*404b540aSrobert <li><a href="#5_8">What's an ABI and why is it so messy?</a> </li> 120*404b540aSrobert <li><a href="#5_9">How do I make std::vector<T>::capacity() 121*404b540aSrobert == std::vector<T>::size?</a> </li> 122*404b540aSrobert </ol> 123*404b540aSrobert </li> 124*404b540aSrobert 125*404b540aSrobert</ol> 126*404b540aSrobert 127*404b540aSrobert<hr /> 128*404b540aSrobert 129*404b540aSrobert<!-- ####################################################### --> 130*404b540aSrobert 131*404b540aSrobert<h1><a name="1_0">1.0 General Information</a></h1> 132*404b540aSrobert<!-- I suspect these will mostly be links to/into existing documents. --> 133*404b540aSrobert <h2><a name="1_1">1.1 What is libstdc++-v3?</a></h2> 134*404b540aSrobert <p>The GNU Standard C++ Library v3 is an 135*404b540aSrobert ongoing project to implement the ISO 14882 Standard C++ library 136*404b540aSrobert as described in chapters 17 through 27 and annex D. 137*404b540aSrobert For those who want to see exactly how 138*404b540aSrobert far the project has come, or just want the latest 139*404b540aSrobert bleeding-edge code, the up-to-date source is available over 140*404b540aSrobert anonymous SVN, and can even be browsed over the Web (see 141*404b540aSrobert <a href="#1_4">1.4</a> below). 142*404b540aSrobert </p> 143*404b540aSrobert <p>The older libstdc++-v2 project is no longer maintained; the code 144*404b540aSrobert has been completely replaced and rewritten. 145*404b540aSrobert <a href="#4_4_interface">If you are using V2</a>, then you need to 146*404b540aSrobert report bugs to your system vendor, not to the V3 list. 147*404b540aSrobert </p> 148*404b540aSrobert <p>A more formal description of the V3 goals can be found in the 149*404b540aSrobert official <a href="../17_intro/DESIGN">design document</a>. 150*404b540aSrobert </p> 151*404b540aSrobert 152*404b540aSrobert<hr /> 153*404b540aSrobert <h2><a name="1_2">1.2 Why should I use libstdc++?</a></h2> 154*404b540aSrobert <p>The completion of the ISO C++ standardization gave the 155*404b540aSrobert C++ community a powerful set of reuseable tools in the form 156*404b540aSrobert of the C++ Standard Library. However, all existing C++ 157*404b540aSrobert implementations are (as the Draft Standard used to say) 158*404b540aSrobert "incomplet and incorrekt," and many suffer from 159*404b540aSrobert limitations of the compilers that use them. 160*404b540aSrobert </p> 161*404b540aSrobert <p>The GNU C/C++/FORTRAN/<pick-a-language> compiler 162*404b540aSrobert (<code>gcc</code>, <code>g++</code>, etc) is widely considered to be 163*404b540aSrobert one of the leading compilers in the world. Its development 164*404b540aSrobert is overseen by the 165*404b540aSrobert <a href="http://gcc.gnu.org/">GCC team</a>. All of 166*404b540aSrobert the rapid development and near-legendary 167*404b540aSrobert <a href="http://gcc.gnu.org/gcc-3.3/buildstat.html">portability</a> 168*404b540aSrobert that are the hallmarks of an open-source project are being 169*404b540aSrobert applied to libstdc++. 170*404b540aSrobert </p> 171*404b540aSrobert <p>That means that all of the Standard classes and functions 172*404b540aSrobert (such as <code>string</code>, <code>vector<></code>, iostreams, 173*404b540aSrobert and algorithms) will be freely available and fully compliant. 174*404b540aSrobert Programmers will no longer need to "roll their own" 175*404b540aSrobert nor be worried about platform-specific incompatibilities. 176*404b540aSrobert </p> 177*404b540aSrobert 178*404b540aSrobert<hr /> 179*404b540aSrobert <h2><a name="1_3">1.3 Who's in charge of it?</a></h2> 180*404b540aSrobert <p>The libstdc++ project is contributed to by several developers 181*404b540aSrobert all over the world, in the same way as GCC or Linux. 182*404b540aSrobert Benjamin Kosnik, Gabriel Dos Reis, Phil Edwards, Ulrich Drepper, 183*404b540aSrobert Loren James Rittle, and Paolo Carlini are the lead maintainers of 184*404b540aSrobert the SVN archive. 185*404b540aSrobert </p> 186*404b540aSrobert <p>Development and discussion is held on the libstdc++ mailing 187*404b540aSrobert list. Subscribing to the list, or searching the list 188*404b540aSrobert archives, is open to everyone. You can read instructions for 189*404b540aSrobert doing so on the <a href="http://gcc.gnu.org/libstdc++/">homepage</a>. 190*404b540aSrobert If you have questions, ideas, code, or are just curious, sign up! 191*404b540aSrobert </p> 192*404b540aSrobert 193*404b540aSrobert<hr /> 194*404b540aSrobert <h2><a name="1_4">1.4 How do I get libstdc++?</a></h2> 195*404b540aSrobert <p>The <a href="http://gcc.gnu.org/libstdc++/">homepage</a> 196*404b540aSrobert has instructions for retrieving the latest SVN sources, and for 197*404b540aSrobert browsing the SVN sources over the web. 198*404b540aSrobert </p> 199*404b540aSrobert <p>Stable versions of libstdc++-v3 are included with releases of 200*404b540aSrobert <a href="http://gcc.gnu.org/releases.html">the GCC compilers</a>. 201*404b540aSrobert </p> 202*404b540aSrobert <p>The subset commonly known as the Standard Template Library 203*404b540aSrobert (chapters 23 through 25, mostly) is adapted from the final release 204*404b540aSrobert of the SGI STL, with extensive changes. 205*404b540aSrobert </p> 206*404b540aSrobert 207*404b540aSrobert<hr /> 208*404b540aSrobert <h2><a name="1_5">1.5 When is libstdc++ going to be finished?</a></h2> 209*404b540aSrobert<!-- <p>Nathan Myers gave the best of all possible answers in <a 210*404b540aSrobert href="http://www.deja.com/getdoc.xp?AN=469581698&fmt=text">a 211*404b540aSrobert Usenet article</a>.</p> 212*404b540aSrobertwhich is no longer available, thanks deja...--> 213*404b540aSrobert <p>Nathan Myers gave the best of all possible answers, responding to a 214*404b540aSrobert Usenet article asking this question: <em>Sooner, if you help.</em> 215*404b540aSrobert </p> 216*404b540aSrobert 217*404b540aSrobert<hr /> 218*404b540aSrobert <h2><a name="1_6">1.6 How do I contribute to the effort?</a></h2> 219*404b540aSrobert <p>Here is <a href="../17_intro/contribute.html">a 220*404b540aSrobert page devoted to this topic</a>. Subscribing to the mailing 221*404b540aSrobert list (see above, or the homepage) is a very good idea if you 222*404b540aSrobert have something to contribute, or if you have spare time and 223*404b540aSrobert want to help. Contributions don't have to be in the form of 224*404b540aSrobert source code; anybody who is willing to help write 225*404b540aSrobert documentation, for example, or has found a bug in code that 226*404b540aSrobert we all thought was working, is more than welcome! 227*404b540aSrobert </p> 228*404b540aSrobert 229*404b540aSrobert<hr /> 230*404b540aSrobert <h2><a name="1_7">1.7 What happened to libg++? I need that!</a></h2> 231*404b540aSrobert <p>The most recent libg++ README states that libg++ is no longer 232*404b540aSrobert being actively maintained. It should not be used for new 233*404b540aSrobert projects, and is only being kicked along to support older code. 234*404b540aSrobert </p> 235*404b540aSrobert <p>The libg++ was designed and created when there was no Standard 236*404b540aSrobert to provide guidance. Classes like linked lists are now provided 237*404b540aSrobert for by <code>list<T></code> and do not need to be created by 238*404b540aSrobert <code>genclass</code>. (For that matter, templates exist now and 239*404b540aSrobert are well-supported, whereas genclass (mostly) predates them.) 240*404b540aSrobert </p> 241*404b540aSrobert <p>There are other classes in libg++ that are not specified in the 242*404b540aSrobert ISO Standard (e.g., statistical analysis). While there are a 243*404b540aSrobert lot of really useful things that are used by a lot of people 244*404b540aSrobert (e.g., statistics :-), the Standards Committee couldn't include 245*404b540aSrobert everything, and so a lot of those "obvious" classes 246*404b540aSrobert didn't get included. 247*404b540aSrobert </p> 248*404b540aSrobert <p>Since libstdc++ is an implementation of the Standard Library, we 249*404b540aSrobert have no plans at this time to include non-Standard utilities 250*404b540aSrobert in the implementation, however handy they are. (The extensions 251*404b540aSrobert provided in the SGI STL aren't maintained by us and don't get 252*404b540aSrobert a lot of our attention, because they don't require a lot of our 253*404b540aSrobert time.) It is entirely plausible that the "useful stuff" 254*404b540aSrobert from libg++ might be extracted into an updated utilities library, 255*404b540aSrobert but nobody has started such a project yet. 256*404b540aSrobert </p> 257*404b540aSrobert <p>(The <a href="http://www.boost.org/">Boost</a> site houses free 258*404b540aSrobert C++ libraries that do varying things, and happened to be started 259*404b540aSrobert by members of the Standards Committee. Certain "useful 260*404b540aSrobert stuff" classes will probably migrate there.) 261*404b540aSrobert </p> 262*404b540aSrobert <p>For the bold and/or desperate, the 263*404b540aSrobert <a href="http://gcc.gnu.org/extensions.html">GCC extensions page</a> 264*404b540aSrobert describes where to find the last libg++ source. 265*404b540aSrobert </p> 266*404b540aSrobert 267*404b540aSrobert<hr /> 268*404b540aSrobert <h2><a name="1_8">1.8 What if I have more questions?</a></h2> 269*404b540aSrobert <p>If you have read the README and RELEASE-NOTES files, and your 270*404b540aSrobert question remains unanswered, then just ask the mailing list. 271*404b540aSrobert At present, you do not need to be subscribed to the list to 272*404b540aSrobert send a message to it. More information is available on the 273*404b540aSrobert homepage (including how to browse the list archives); to send 274*404b540aSrobert to the list, use <a href="mailto:libstdc++@gcc.gnu.org"> 275*404b540aSrobert <code>libstdc++@gcc.gnu.org</code></a>. 276*404b540aSrobert </p> 277*404b540aSrobert <p>If you have a question that you think should be included here, 278*404b540aSrobert or if you have a question <em>about</em> a question/answer here, 279*404b540aSrobert contact <a href="mailto:pme@gcc.gnu.org">Phil Edwards</a> 280*404b540aSrobert or <a href="mailto:gdr@gcc.gnu.org">Gabriel Dos Reis</a>. 281*404b540aSrobert </p> 282*404b540aSrobert 283*404b540aSrobert<hr /> 284*404b540aSrobert <h2><a name="1_9">1.9 What are the license terms for libstdc++-v3?</a></h2> 285*404b540aSrobert <p>See <a href="../17_intro/license.html">our license description</a> 286*404b540aSrobert for these and related questions. 287*404b540aSrobert </p> 288*404b540aSrobert 289*404b540aSrobert<hr /> 290*404b540aSrobert<h1><a name="2_0">2.0 Installation</a></h1> 291*404b540aSrobert <h2><a name="2_1">2.1 How do I install libstdc++-v3?</a></h2> 292*404b540aSrobert <p>Complete instructions are not given here (this is a FAQ, not 293*404b540aSrobert an installation document), but the tools required are few: 294*404b540aSrobert </p> 295*404b540aSrobert <ul> 296*404b540aSrobert <li> A 3.x release of GCC. Note that building GCC is much 297*404b540aSrobert easier and more automated than building the GCC 2.[78] 298*404b540aSrobert series was. If you are using GCC 2.95, you can still 299*404b540aSrobert build earlier snapshots of libstdc++. 300*404b540aSrobert </li> 301*404b540aSrobert <li> GNU Make is required for GCC 3.4 and later. 302*404b540aSrobert </li> 303*404b540aSrobert <li> The GNU Autotools are needed if you are messing with 304*404b540aSrobert the configury or makefiles. 305*404b540aSrobert </li> 306*404b540aSrobert </ul> 307*404b540aSrobert <p>The file <a href="../documentation.html">documentation.html</a> 308*404b540aSrobert provides a good overview of the steps necessary to build, install, 309*404b540aSrobert and use the library. Instructions for configuring the library 310*404b540aSrobert with new flags such as --enable-threads are there also, as well as 311*404b540aSrobert patches and instructions for working with GCC 2.95. 312*404b540aSrobert </p> 313*404b540aSrobert <p>The top-level install.html and 314*404b540aSrobert <a href="../17_intro/RELEASE-NOTES">RELEASE-NOTES</a> files contain 315*404b540aSrobert the exact build and installation instructions. You may wish to 316*404b540aSrobert browse those files over ViewVC ahead of time to get a feel for 317*404b540aSrobert what's required. RELEASE-NOTES is located in the 318*404b540aSrobert ".../docs/17_intro/" directory of the distribution. 319*404b540aSrobert </p> 320*404b540aSrobert 321*404b540aSrobert<hr /> 322*404b540aSrobert <h2><a name="2_2">2.2 [removed]</a></h2> 323*404b540aSrobert <p>This question has become moot and has been removed. The stub 324*404b540aSrobert is here to preserve numbering (and hence links/bookmarks). 325*404b540aSrobert </p> 326*404b540aSrobert 327*404b540aSrobert<hr /> 328*404b540aSrobert <h2><a name="2_3">2.3 What is this SVN thing that you 329*404b540aSrobert keep mentioning?</a></h2> 330*404b540aSrobert <p><em>Subversion</em> is one of several revision control packages. 331*404b540aSrobert It was selected for GNU projects because it's free (speech), free (beer), 332*404b540aSrobert and very high quality. The <a href="http://subversion.tigris.org"> 333*404b540aSrobert Subversion home page</a> has a better description. 334*404b540aSrobert </p> 335*404b540aSrobert <p>The "anonymous client checkout" feature of SVN is 336*404b540aSrobert similar to anonymous FTP in that it allows anyone to retrieve 337*404b540aSrobert the latest libstdc++ sources. 338*404b540aSrobert </p> 339*404b540aSrobert <p>After the first of April, American users will have a 340*404b540aSrobert "/pharmacy" command-line option... 341*404b540aSrobert <!-- wonder how long that'll live --> 342*404b540aSrobert </p> 343*404b540aSrobert 344*404b540aSrobert<hr /> 345*404b540aSrobert <h2><a name="2_4">2.4 How do I know if it works?</a></h2> 346*404b540aSrobert <p>libstdc++-v3 comes with its own testsuite. You do not need 347*404b540aSrobert to actually install the library ("<code>make 348*404b540aSrobert install</code>") to run the testsuite, but you do need 349*404b540aSrobert DejaGNU, as described 350*404b540aSrobert <a href="http://gcc.gnu.org/install/test.html">here</a>. 351*404b540aSrobert </p> 352*404b540aSrobert <p>To run the testsuite on the library after building it, use 353*404b540aSrobert "make check" while in your build directory. To run 354*404b540aSrobert the testsuite on the library after building and installing it, 355*404b540aSrobert use "make check-install" instead. 356*404b540aSrobert </p> 357*404b540aSrobert <p>If you find bugs in the testsuite programs themselves, or if you 358*404b540aSrobert think of a new test program that should be added to the suite, 359*404b540aSrobert <strong>please</strong> write up your idea and send it to the list! 360*404b540aSrobert </p> 361*404b540aSrobert 362*404b540aSrobert<hr /> 363*404b540aSrobert <h2><a name="2_5">2.5 This library is HUGE! And what's libsupc++?</a></h2> 364*404b540aSrobert <p>Usually the size of libraries on disk isn't noticeable. When a 365*404b540aSrobert link editor (or simply "linker") pulls things from a 366*404b540aSrobert static archive library, only the necessary object files are copied 367*404b540aSrobert into your executable, not the entire library. Unfortunately, even 368*404b540aSrobert if you only need a single function or variable from an object file, 369*404b540aSrobert the entire object file is extracted. (There's nothing unique to C++ 370*404b540aSrobert or libstdc++-v3 about this; it's just common behavior, given here 371*404b540aSrobert for background reasons.) 372*404b540aSrobert </p> 373*404b540aSrobert <p>Some of the object files which make up libstdc++.a are rather large. 374*404b540aSrobert If you create a statically-linked executable with 375*404b540aSrobert <code> -static</code>, those large object files are suddenly part 376*404b540aSrobert of your executable. Historically the best way around this was to 377*404b540aSrobert only place a very few functions (often only a single one) in each 378*404b540aSrobert source/object file; then extracting a single function is the same 379*404b540aSrobert as extracting a single .o file. For libstdc++-v3 this is only 380*404b540aSrobert possible to a certain extent; the object files in question contain 381*404b540aSrobert template classes and template functions, pre-instantiated, and 382*404b540aSrobert splitting those up causes severe maintenance headaches. 383*404b540aSrobert </p> 384*404b540aSrobert <p>It's not a bug, and it's not really a problem. Nevertheless, some 385*404b540aSrobert people don't like it, so here are two pseudo-solutions: 386*404b540aSrobert </p> 387*404b540aSrobert <p>If the only functions from libstdc++.a which you need are 388*404b540aSrobert language support functions (those listed in <a 389*404b540aSrobert href="../18_support/howto.html">clause 18</a> of the 390*404b540aSrobert standard, e.g., <code>new</code> and <code>delete</code>), 391*404b540aSrobert then try linking against <code>libsupc++.a</code> (Using 392*404b540aSrobert <code>gcc</code> instead of <code>g++</code> and explicitly 393*404b540aSrobert linking in <code>-lsupc++</code> for the final link step will 394*404b540aSrobert do it). This library contains only those support routines, 395*404b540aSrobert one per object file. But if you are using anything from the 396*404b540aSrobert rest of the library, such as IOStreams or vectors, then 397*404b540aSrobert you'll still need pieces from <code>libstdc++.a</code>. 398*404b540aSrobert </p> 399*404b540aSrobert <p>The second method is one we hope to incorporate into the library 400*404b540aSrobert build process. Some platforms can place each function and variable 401*404b540aSrobert into its own section in a .o file. The GNU linker can then perform 402*404b540aSrobert garbage collection on unused sections; this reduces the situation 403*404b540aSrobert to only copying needed functions into the executable, as before, 404*404b540aSrobert but all happens automatically. 405*404b540aSrobert </p> 406*404b540aSrobert <p>Unfortunately the garbage collection in GNU ld is buggy; sections 407*404b540aSrobert (corresponding to functions and variables) which <em>are</em> used 408*404b540aSrobert are mistakenly removed, leading to horrible crashes when your 409*404b540aSrobert executable starts up. For the time being, this feature is not used 410*404b540aSrobert when building the library. 411*404b540aSrobert </p> 412*404b540aSrobert 413*404b540aSrobert<hr /> 414*404b540aSrobert <h2><a name="2_6">2.6 Why do I get an error saying 415*404b540aSrobert <code>libstdc++.so.X</code> is missing when I run 416*404b540aSrobert my program?</a></h2> 417*404b540aSrobert <p>Depending on your platform and library version, the message might 418*404b540aSrobert be similar to one of the following: 419*404b540aSrobert </p> 420*404b540aSrobert <pre> 421*404b540aSrobert ./a.out: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory 422*404b540aSrobert 423*404b540aSrobert /usr/libexec/ld-elf.so.1: Shared object "libstdc++.so.6" not found </pre> 424*404b540aSrobert 425*404b540aSrobert <p>This doesn't mean that the shared library isn't installed, only 426*404b540aSrobert that the dynamic linker can't find it. When a dynamically-linked 427*404b540aSrobert executable is run the linker finds and loads the required shared 428*404b540aSrobert libraries by searching a pre-configured list of directories. If 429*404b540aSrobert the directory where you've installed libstdc++ is not in this 430*404b540aSrobert list then the libraries won't be found. The simplest way to fix 431*404b540aSrobert this is to use the <code>LD_LIBRARY_PATH</code> environment 432*404b540aSrobert variable, which is a colon-separated list of directories in which 433*404b540aSrobert the linker will search for shared libraries: 434*404b540aSrobert </p> 435*404b540aSrobert <pre> 436*404b540aSrobert LD_LIBRARY_PATH=${prefix}/lib:$LD_LIBRARY_PATH 437*404b540aSrobert export LD_LIBRARY_PATH </pre> 438*404b540aSrobert <p>The exact environment variable to use will depend on your platform, 439*404b540aSrobert e.g. DYLD_LIBRARY_PATH for Darwin, 440*404b540aSrobert LD_LIBRARY_PATH_32/LD_LIBRARY_PATH_64 for Solaris 32-/64-bit, 441*404b540aSrobert LD_LIBRARYN32_PATH/LD_LIBRARY64_PATH for Irix N32/64-bit ABIs 442*404b540aSrobert and SHLIB_PATH for HP-UX. 443*404b540aSrobert </p> 444*404b540aSrobert <p>See the man pages for <code>ld(1)</code>, <code>ldd(1)</code> and 445*404b540aSrobert <code>ldconfig(8)</code> for more information. The dynamic linker 446*404b540aSrobert has different names on different platforms but the man page is 447*404b540aSrobert usually called something such as <code>ld.so / rtld / dld.so</code>. 448*404b540aSrobert </p> 449*404b540aSrobert 450*404b540aSrobert<hr /> 451*404b540aSrobert<h1><a name="3_0">3.0 Platform-Specific Issues</a></h1> 452*404b540aSrobert <h2><a name="3_1">3.1 Can libstdc++-v3 be used with <my 453*404b540aSrobert favorite compiler>?</a></h2> 454*404b540aSrobert <p>Probably not. Yet.</p> 455*404b540aSrobert <p>Because GCC advances so rapidly, development and testing of 456*404b540aSrobert libstdc++ is being done almost entirely under that compiler. 457*404b540aSrobert If you are curious about whether other, lesser compilers 458*404b540aSrobert (*grin*) support libstdc++, you are more than welcome to try. 459*404b540aSrobert Configuring and building the library (see above) will still 460*404b540aSrobert require certain tools, however. Also keep in mind that 461*404b540aSrobert <em>building</em> libstdc++ does not imply that your compiler 462*404b540aSrobert will be able to <em>use</em> all of the features found in the 463*404b540aSrobert C++ Standard Library. 464*404b540aSrobert </p> 465*404b540aSrobert <p>Since the goal of ISO Standardization is for all C++ 466*404b540aSrobert implementations to be able to share code, the final libstdc++ 467*404b540aSrobert should, in theory, be usable under any ISO-compliant 468*404b540aSrobert compiler. It will still be targeted and optimized for 469*404b540aSrobert GCC/g++, however. 470*404b540aSrobert </p> 471*404b540aSrobert 472*404b540aSrobert<hr /> 473*404b540aSrobert <h2><a name="3_2">3.2 [removed]</a></h2> 474*404b540aSrobert <p>This question has become moot and has been removed. The stub 475*404b540aSrobert is here to preserve numbering (and hence links/bookmarks). 476*404b540aSrobert </p> 477*404b540aSrobert 478*404b540aSrobert<hr /> 479*404b540aSrobert <h2><a name="3_3">3.3 [removed]</a></h2> 480*404b540aSrobert <p>This question has become moot and has been removed. The stub 481*404b540aSrobert is here to preserve numbering (and hence links/bookmarks). 482*404b540aSrobert </p> 483*404b540aSrobert 484*404b540aSrobert<hr /> 485*404b540aSrobert <h2><a name="3_4">3.4 I can't use 'long long' on Solaris</a></h2> 486*404b540aSrobert <p>By default we try to support the C99 <code>long long</code> type. 487*404b540aSrobert This requires that certain functions from your C library be present. 488*404b540aSrobert </p> 489*404b540aSrobert <p>Up through release 3.0.2 the tests performed were too general, and 490*404b540aSrobert this feature was disabled when it did not need to be. The most 491*404b540aSrobert commonly reported platform affected was Solaris. 492*404b540aSrobert </p> 493*404b540aSrobert <p>This has been fixed for 3.0.3 and onwards. 494*404b540aSrobert </p> 495*404b540aSrobert 496*404b540aSrobert<hr /> 497*404b540aSrobert <h2><a name="3_5">3.5 <code>_XOPEN_SOURCE</code> / <code>_GNU_SOURCE</code> 498*404b540aSrobert / etc is always defined</a></h2> 499*404b540aSrobert <p>On Solaris, g++ (but not gcc) always defines the preprocessor 500*404b540aSrobert macro <code>_XOPEN_SOURCE</code>. On GNU/Linux, the same happens 501*404b540aSrobert with <code>_GNU_SOURCE</code>. (This is not an exhaustive list; 502*404b540aSrobert other macros and other platforms are also affected.) 503*404b540aSrobert </p> 504*404b540aSrobert <p>These macros are typically used in C library headers, guarding new 505*404b540aSrobert versions of functions from their older versions. The C++ standard 506*404b540aSrobert library includes the C standard library, but it requires the C90 507*404b540aSrobert version, which for backwards-compatibility reasons is often not the 508*404b540aSrobert default for many vendors. 509*404b540aSrobert </p> 510*404b540aSrobert <p>More to the point, the C++ standard requires behavior which is only 511*404b540aSrobert available on certain platforms after certain symbols are defined. 512*404b540aSrobert Usually the issue involves I/O-related typedefs. In order to 513*404b540aSrobert ensure correctness, the compiler simply predefines those symbols. 514*404b540aSrobert </p> 515*404b540aSrobert <p>Note that it's not enough to #define them only when the library is 516*404b540aSrobert being built (during installation). Since we don't have an 'export' 517*404b540aSrobert keyword, much of the library exists as headers, which means that 518*404b540aSrobert the symbols must also be defined as your programs are parsed and 519*404b540aSrobert compiled. 520*404b540aSrobert </p> 521*404b540aSrobert <p>To see which symbols are defined, look for CPLUSPLUS_CPP_SPEC in 522*404b540aSrobert the gcc config headers for your target (and try changing them to 523*404b540aSrobert see what happens when building complicated code). You can also run 524*404b540aSrobert <code>"g++ -E -dM - < /dev/null"</code> to display 525*404b540aSrobert a list of predefined macros for any particular installation. 526*404b540aSrobert </p> 527*404b540aSrobert <p>This has been discussed on the mailing lists 528*404b540aSrobert <a href="http://gcc.gnu.org/cgi-bin/htsearch?method=and&format=builtin-long&sort=score&words=_XOPEN_SOURCE+Solaris">quite a bit</a>. 529*404b540aSrobert </p> 530*404b540aSrobert <p>This method is something of a wart. We'd like to find a cleaner 531*404b540aSrobert solution, but nobody yet has contributed the time. 532*404b540aSrobert </p> 533*404b540aSrobert 534*404b540aSrobert<hr /> 535*404b540aSrobert <h2><a name="3_6">3.6 OS X ctype.h is broken! How can I hack it?</a></h2> 536*404b540aSrobert <p>This is a long-standing bug in the OS X support. Fortunately, 537*404b540aSrobert the patch is quite simple, and well-known. 538*404b540aSrobert <a href="http://gcc.gnu.org/ml/gcc/2002-03/msg00817.html"> Here's a 539*404b540aSrobert link to the solution.</a> 540*404b540aSrobert </p> 541*404b540aSrobert 542*404b540aSrobert<hr /> 543*404b540aSrobert <h2><a name="3_7">3.7 Threading is broken on i386</a></h2> 544*404b540aSrobert <p>Support for atomic integer operations is/was broken on i386 545*404b540aSrobert platforms. The assembly code accidentally used opcodes that are 546*404b540aSrobert only available on the i486 and later. So if you configured GCC 547*404b540aSrobert to target, for example, i386-linux, but actually used the programs 548*404b540aSrobert on an i686, then you would encounter no problems. Only when 549*404b540aSrobert actually running the code on a i386 will the problem appear. 550*404b540aSrobert </p> 551*404b540aSrobert <p>This is fixed in 3.2.2. 552*404b540aSrobert </p> 553*404b540aSrobert 554*404b540aSrobert<hr /> 555*404b540aSrobert <h2><a name="3_8">3.8 Recent GNU/Linux glibc required?</a></h2> 556*404b540aSrobert <p>When running on GNU/Linux, libstdc++ 3.2.1 (shared library version 557*404b540aSrobert 5.0.1) and later uses localization and formatting code from the system 558*404b540aSrobert C library (glibc) version 2.2.5. That version of glibc is over a 559*404b540aSrobert year old and contains necessary bugfixes. Many GNU/Linux distros make 560*404b540aSrobert glibc version 2.3.x available now. 561*404b540aSrobert </p> 562*404b540aSrobert <p>The guideline is simple: the more recent the C++ library, the 563*404b540aSrobert more recent the C library. (This is also documented in the main 564*404b540aSrobert GCC installation instructions.) 565*404b540aSrobert </p> 566*404b540aSrobert 567*404b540aSrobert<hr /> 568*404b540aSrobert <h2><a name="3_9">3.9 Can't use wchar_t/wstring on FreeBSD</a></h2> 569*404b540aSrobert <p>At the moment there are a few problems in FreeBSD's support for 570*404b540aSrobert wide character functions, and as a result the libstdc++ configury 571*404b540aSrobert decides that wchar_t support should be disabled. Once the underlying 572*404b540aSrobert problems are fixed in FreeBSD (soon), the library support will 573*404b540aSrobert automatically enable itself. 574*404b540aSrobert </p> 575*404b540aSrobert <p>You can fix the problems yourself, and learn more about the situation, 576*404b540aSrobert by reading 577*404b540aSrobert <a href="http://gcc.gnu.org/ml/libstdc++/2003-02/subjects.html#00286"> 578*404b540aSrobert this short thread</a> ("_GLIBCPP_USE_WCHAR_T undefined in 579*404b540aSrobert FreeBSD's c++config.h?"). 580*404b540aSrobert </p> 581*404b540aSrobert 582*404b540aSrobert<hr /> 583*404b540aSrobert <h2><a name="3_10">3.10 MIPS atomic operations</a></h2> 584*404b540aSrobert <p>The atomic locking routines for MIPS targets requires MIPS II 585*404b540aSrobert and later. A patch went in just after the 3.3 release to 586*404b540aSrobert make mips* use the generic implementation instead. You can also 587*404b540aSrobert configure for mipsel-elf as a workaround. 588*404b540aSrobert </p> 589*404b540aSrobert <p>mips*-*-linux* continues to use the MIPS II routines, and more 590*404b540aSrobert work in this area is expected. 591*404b540aSrobert </p> 592*404b540aSrobert 593*404b540aSrobert<hr /> 594*404b540aSrobert<h1><a name="4_0">4.0 Known Bugs and Non-Bugs</a></h1> 595*404b540aSrobert <em>Note that this section can get rapidly outdated -- such is the 596*404b540aSrobert nature of an open-source project. For the latest information, join 597*404b540aSrobert the mailing list or look through recent archives. The RELEASE- 598*404b540aSrobert NOTES and BUGS files are generally kept up-to-date.</em> 599*404b540aSrobert 600*404b540aSrobert <p>For 3.0.1, the most common "bug" is an apparently missing 601*404b540aSrobert "<code>../</code>" in include/Makefile, resulting in files 602*404b540aSrobert like gthr.h and gthr-single.h not being found. Please read 603*404b540aSrobert <a href="http://gcc.gnu.org/install/configure.html">the configuration 604*404b540aSrobert instructions for GCC</a>, 605*404b540aSrobert specifically the part about configuring in a separate build directory, 606*404b540aSrobert and how strongly recommended it is. Building in the source directory 607*404b540aSrobert is fragile, is rarely tested, and tends to break, as in this case. 608*404b540aSrobert This was fixed for 3.0.2. 609*404b540aSrobert </p> 610*404b540aSrobert 611*404b540aSrobert <p>For 3.1, the most common "bug" is a parse error when using 612*404b540aSrobert <code><fstream></code>, ending with a message, 613*404b540aSrobert "<code>bits/basic_file.h:52: parse error before `{' 614*404b540aSrobert token</code>." Please read 615*404b540aSrobert <a href="http://gcc.gnu.org/install/">the installation instructions for 616*404b540aSrobert GCC</a>, specifically the part about not installing newer versions on 617*404b540aSrobert top of older versions. If you install 3.1 over a 3.0.x release, then 618*404b540aSrobert the wrong basic_file.h header will be found (its location changed 619*404b540aSrobert between releases). 620*404b540aSrobert </p> 621*404b540aSrobert 622*404b540aSrobert <p><strong>Please do not report these as bugs. We know about them.</strong> 623*404b540aSrobert Reporting this -- or any other problem that's already been fixed -- 624*404b540aSrobert hinders the development of GCC, because we have to take time to 625*404b540aSrobert respond to your report. Thank you. 626*404b540aSrobert </p> 627*404b540aSrobert 628*404b540aSrobert<hr /> 629*404b540aSrobert <h2><a name="4_1">4.1 What works already?</a></h2> 630*404b540aSrobert <p>Short answer: Pretty much everything <em>works</em> except for some 631*404b540aSrobert corner cases. Also, localization is incomplete. For whether it works 632*404b540aSrobert well, or as you expect it to work, see 5.2. 633*404b540aSrobert </p> 634*404b540aSrobert <p>Long answer: See the docs/html/17_intro/CHECKLIST file, which is 635*404b540aSrobert badly outdated... Also see the RELEASE-NOTES file, which is kept 636*404b540aSrobert more up to date. 637*404b540aSrobert </p> 638*404b540aSrobert 639*404b540aSrobert<hr /> 640*404b540aSrobert <h2><a name="4_2">4.2 Bugs in gcc/g++ (not libstdc++-v3)</a></h2> 641*404b540aSrobert <p>This is by no means meant to be complete nor exhaustive, but 642*404b540aSrobert mentions some problems that users may encounter when building 643*404b540aSrobert or using libstdc++. If you are experiencing one of these 644*404b540aSrobert problems, you can find more information on the libstdc++ and 645*404b540aSrobert the GCC mailing lists. 646*404b540aSrobert </p> 647*404b540aSrobert <p>Before reporting a bug, examine the 648*404b540aSrobert <a href="http://gcc.gnu.org/bugs.html">bugs database</a> with the 649*404b540aSrobert category set to "libstdc++". The BUGS file in the source 650*404b540aSrobert tree also tracks known serious problems. 651*404b540aSrobert </p> 652*404b540aSrobert <ul> 653*404b540aSrobert <li>Debugging is problematic, due to bugs in line-number generation 654*404b540aSrobert (mostly fixed in the compiler) and gdb lagging behind the 655*404b540aSrobert compiler (lack of personnel). We recommend configuring the 656*404b540aSrobert compiler using <code>--with-dwarf2</code> if the DWARF2 657*404b540aSrobert debugging format is not already the default on your platform. 658*404b540aSrobert Also, 659*404b540aSrobert<a href="http://gcc.gnu.org/ml/libstdc++/2002-02/msg00034.html">changing your 660*404b540aSrobert GDB settings</a> can have a profound effect on your C++ debugging 661*404b540aSrobert experiences. :-)</li> 662*404b540aSrobert </ul> 663*404b540aSrobert 664*404b540aSrobert<hr /> 665*404b540aSrobert <h2><a name="4_3">4.3 Bugs in the C++ language/lib specification</a></h2> 666*404b540aSrobert <p>Yes, unfortunately, there are some. In a 667*404b540aSrobert <a href="http://gcc.gnu.org/ml/libstdc++/1998/msg00006.html">message 668*404b540aSrobert to the list</a>, Nathan Myers announced that he has started a list of 669*404b540aSrobert problems in the ISO C++ Standard itself, especially with 670*404b540aSrobert regard to the chapters that concern the library. The list 671*404b540aSrobert itself is 672*404b540aSrobert <a href="http://www.cantrip.org/draft-bugs.txt">posted on his 673*404b540aSrobert website</a>. Developers who are having problems interpreting 674*404b540aSrobert the Standard may wish to consult his notes. 675*404b540aSrobert </p> 676*404b540aSrobert <p>For those people who are not part of the ISO Library Group 677*404b540aSrobert (i.e., nearly all of us needing to read this page in the first 678*404b540aSrobert place :-), a public list of the library defects is occasionally 679*404b540aSrobert published <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/">here</a>. 680*404b540aSrobert Some of these have resulted in <a href="#5_2">code changes</a>. 681*404b540aSrobert </p> 682*404b540aSrobert 683*404b540aSrobert<hr /> 684*404b540aSrobert <h2><a name="4_4">4.4 Things in libstdc++ that only look like bugs</a></h2> 685*404b540aSrobert <p>There are things which are not bugs in the compiler (4.2) nor 686*404b540aSrobert the language specification (4.3), but aren't really bugs in 687*404b540aSrobert libstdc++, either. Really! Please do not report these as bugs. 688*404b540aSrobert </p> 689*404b540aSrobert <p><a name="4_4_Weff"><strong>-Weffc++</strong></a> 690*404b540aSrobert The biggest of these is the quadzillions of warnings about the 691*404b540aSrobert library headers emitted when <code>-Weffc++</code> is used. Making 692*404b540aSrobert libstdc++ "-Weffc++-clean" is not a goal of the project, 693*404b540aSrobert for a few reasons. Mainly, that option tries to enforce 694*404b540aSrobert object-oriented programming, while the Standard Library isn't 695*404b540aSrobert necessarily trying to be OO. 696*404b540aSrobert </p> 697*404b540aSrobert <p><a name="4_4_iostreamclear"><strong>reopening a stream fails</strong> 698*404b540aSrobert </a> Did I just say that -Weffc++ was our biggest false-bug report? 699*404b540aSrobert I lied. (It used to be.) Today it seems to be reports that after 700*404b540aSrobert executing a sequence like 701*404b540aSrobert </p> 702*404b540aSrobert <pre> 703*404b540aSrobert #include <fstream> 704*404b540aSrobert ... 705*404b540aSrobert std::fstream fs("a_file"); 706*404b540aSrobert // . 707*404b540aSrobert // . do things with fs... 708*404b540aSrobert // . 709*404b540aSrobert fs.close(); 710*404b540aSrobert fs.open("a_new_file");</pre> 711*404b540aSrobert <p>all operations on the re-opened <code>fs</code> will fail, or at 712*404b540aSrobert least act very strangely. Yes, they often will, especially if 713*404b540aSrobert <code>fs</code> reached the EOF state on the previous file. The 714*404b540aSrobert reason is that the state flags are <strong>not</strong> cleared 715*404b540aSrobert on a successful call to open(). The standard unfortunately did 716*404b540aSrobert not specify behavior in this case, and to everybody's great sorrow, 717*404b540aSrobert the <a href="../ext/howto.html#5">proposed LWG resolution in 718*404b540aSrobert DR #22</a> is to leave the flags unchanged. You must insert a call 719*404b540aSrobert to <code>fs.clear()</code> between the calls to close() and open(), 720*404b540aSrobert and then everything will work like we all expect it to work. 721*404b540aSrobert <strong>Update:</strong> for GCC 4.0 we implemented the resolution 722*404b540aSrobert of <a href="../ext/howto.html#5">DR #409</a> and open() now calls 723*404b540aSrobert <code>clear()</code> on success! 724*404b540aSrobert </p> 725*404b540aSrobert <p><a name="4_4_rel_ops"><strong>rel_ops</strong></a> 726*404b540aSrobert Another is the <code>rel_ops</code> namespace and the template 727*404b540aSrobert comparison operator functions contained therein. If they become 728*404b540aSrobert visible in the same namespace as other comparison functions 729*404b540aSrobert (e.g., '<code>using</code>' them and the <iterator> header), 730*404b540aSrobert then you will suddenly be faced with huge numbers of ambiguity 731*404b540aSrobert errors. This was discussed on the -v3 list; Nathan Myers 732*404b540aSrobert <a href="http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html">sums 733*404b540aSrobert things up here</a>. The collisions with vector/string iterator 734*404b540aSrobert types have been fixed for 3.1. <!-- more links to email here --> 735*404b540aSrobert </p> 736*404b540aSrobert <h3><a name="4_4_interface">The g++-3 headers are <em>not ours</em></a></h3> 737*404b540aSrobert <p>If you have found an extremely broken header file which is 738*404b540aSrobert causing problems for you, look carefully before submitting a 739*404b540aSrobert "high" priority bug report (which you probably shouldn't 740*404b540aSrobert do anyhow; see the last paragraph of the page describing 741*404b540aSrobert <a href="http://gcc.gnu.org/bugs.html">the GCC bug database</a>). 742*404b540aSrobert </p> 743*404b540aSrobert <p>If the headers are in <code>${prefix}/include/g++-3</code>, or if 744*404b540aSrobert the installed library's name looks like <code>libstdc++-2.10.a</code> 745*404b540aSrobert or <code>libstdc++-libc6-2.10.so</code>, then you are using the old 746*404b540aSrobert libstdc++-v2 library, which is nonstandard and unmaintained. Do not 747*404b540aSrobert report problems with -v2 to the -v3 mailing list. 748*404b540aSrobert </p> 749*404b540aSrobert <p>For GCC versions 3.0 and 3.1 the libstdc++-v3 header files are 750*404b540aSrobert installed in <code>${prefix}/include/g++-v3</code> (see the 'v'?). 751*404b540aSrobert Starting with version 3.2 the headers are installed in 752*404b540aSrobert <code>${prefix}/include/c++/${version}</code> as this prevents 753*404b540aSrobert headers from previous versions being found by mistake. 754*404b540aSrobert </p> 755*404b540aSrobert <p><a name="4_4_glibc"><strong>glibc</strong></a> 756*404b540aSrobert If you're on a GNU/Linux system and have just upgraded to 757*404b540aSrobert glibc 2.2, but are still using gcc 2.95.2, then you should have 758*404b540aSrobert read the glibc FAQ, specifically 2.34: 759*404b540aSrobert </p> 760*404b540aSrobert <pre> 761*404b540aSrobert2.34. When compiling C++ programs, I get a compilation error in streambuf.h. 762*404b540aSrobert 763*404b540aSrobert{BH} You are using g++ 2.95.2? After upgrading to glibc 2.2, you need to 764*404b540aSrobertapply a patch to the include files in /usr/include/g++, because the fpos_t 765*404b540aSroberttype has changed in glibc 2.2. The patch is at 766*404b540aSroberthttp://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff 767*404b540aSrobert </pre> 768*404b540aSrobert <p>Note that 2.95.x shipped with the 769*404b540aSrobert <a href="#4_4_interface">old v2 library</a> which is no longer 770*404b540aSrobert maintained. Also note that gcc 2.95.3 fixes this problem, but 771*404b540aSrobert requires a separate patch for libstdc++-v3. 772*404b540aSrobert </p> 773*404b540aSrobert <p><a name="4_4_checks"><strong>concept checks</strong></a> 774*404b540aSrobert If you see compilation errors containing messages about 775*404b540aSrobert <code> <em>foo</em>Concept </code>and a<code> constraints </code> 776*404b540aSrobert member function, then most likely you have violated one of the 777*404b540aSrobert requirements for types used during instantiation of template 778*404b540aSrobert containers and functions. For example, EqualityComparableConcept 779*404b540aSrobert appears if your types must be comparable with == and you have not 780*404b540aSrobert provided this capability (a typo, or wrong visibility, or you 781*404b540aSrobert just plain forgot, etc). 782*404b540aSrobert </p> 783*404b540aSrobert <p>More information, including how to optionally enable/disable the 784*404b540aSrobert checks, is available 785*404b540aSrobert <a href="../19_diagnostics/howto.html#3">here</a>. 786*404b540aSrobert </p> 787*404b540aSrobert <p><a name="4_4_dlsym"><strong>dlopen/dlsym</strong></a> 788*404b540aSrobert If you are using the C++ library across dynamically-loaded 789*404b540aSrobert objects, make certain that you are passing the correct options 790*404b540aSrobert when compiling and linking: 791*404b540aSrobert </p> 792*404b540aSrobert <pre> 793*404b540aSrobert // compile your library components 794*404b540aSrobert g++ -fPIC -c a.cc 795*404b540aSrobert g++ -fPIC -c b.cc 796*404b540aSrobert ... 797*404b540aSrobert g++ -fPIC -c z.cc 798*404b540aSrobert 799*404b540aSrobert // create your library 800*404b540aSrobert g++ -fPIC -shared -rdynamic -o libfoo.so a.o b.o ... z.o 801*404b540aSrobert 802*404b540aSrobert // link the executable 803*404b540aSrobert g++ -fPIC -rdynamic -o foo ... -L. -lfoo -ldl</pre> 804*404b540aSrobert <p><a name="4_4_leak"><strong>"memory leaks" in containers</strong></a> 805*404b540aSrobert A few people have reported that the standard containers appear 806*404b540aSrobert to leak memory when tested with memory checkers such as 807*404b540aSrobert <a href="http://developer.kde.org/~sewardj/">valgrind</a>. 808*404b540aSrobert The library's default allocators keep free memory in a pool 809*404b540aSrobert for later reuse, rather than returning it to the OS. Although 810*404b540aSrobert this memory is always reachable by the library and is never 811*404b540aSrobert lost, memory debugging tools can report it as a leak. If you 812*404b540aSrobert want to test the library for memory leaks please read 813*404b540aSrobert <a href="../debug.html#mem">Tips for memory leak hunting</a> 814*404b540aSrobert first. 815*404b540aSrobert </p> 816*404b540aSrobert 817*404b540aSrobert<hr /> 818*404b540aSrobert <h2><a name="4_5">4.5 Aw, that's easy to fix!</a></h2> 819*404b540aSrobert <p>If you have found a bug in the library and you think you have 820*404b540aSrobert a working fix, then send it in! The main GCC site has a page 821*404b540aSrobert on <a href="http://gcc.gnu.org/contribute.html">submitting 822*404b540aSrobert patches</a> that covers the procedure, but for libstdc++ you 823*404b540aSrobert should also send the patch to our mailing list in addition to 824*404b540aSrobert the GCC patches mailing list. The libstdc++ 825*404b540aSrobert <a href="../17_intro/contribute.html">contributors' page</a> 826*404b540aSrobert also talks about how to submit patches. 827*404b540aSrobert </p> 828*404b540aSrobert <p>In addition to the description, the patch, and the ChangeLog 829*404b540aSrobert entry, it is a Good Thing if you can additionally create a small 830*404b540aSrobert test program to test for the presence of the bug that your 831*404b540aSrobert patch fixes. Bugs have a way of being reintroduced; if an old 832*404b540aSrobert bug creeps back in, it will be caught immediately by the 833*404b540aSrobert <a href="#2_4">testsuite</a> -- but only if such a test exists. 834*404b540aSrobert </p> 835*404b540aSrobert 836*404b540aSrobert<hr /> 837*404b540aSrobert<h1><a name="5_0">5.0 Miscellaneous</a></h1> 838*404b540aSrobert <h2><a name="5_1">5.1 string::iterator is not char*; 839*404b540aSrobert vector<T>::iterator is not T*</a></h2> 840*404b540aSrobert <p>If you have code that depends on container<T> iterators 841*404b540aSrobert being implemented as pointer-to-T, your code is broken. 842*404b540aSrobert </p> 843*404b540aSrobert <p>While there are arguments for iterators to be implemented in 844*404b540aSrobert that manner, A) they aren't very good ones in the long term, 845*404b540aSrobert and B) they were never guaranteed by the Standard anyway. The 846*404b540aSrobert type-safety achieved by making iterators a real class rather 847*404b540aSrobert than a typedef for <code>T*</code> outweighs nearly all opposing 848*404b540aSrobert arguments. 849*404b540aSrobert </p> 850*404b540aSrobert <p>Code which does assume that a vector iterator <code> i </code> 851*404b540aSrobert is a pointer can often be fixed by changing <code> i </code> in 852*404b540aSrobert certain expressions to <code> &*i </code>. Future revisions 853*404b540aSrobert of the Standard are expected to bless this usage for 854*404b540aSrobert vector<> (but not for basic_string<>). 855*404b540aSrobert </p> 856*404b540aSrobert 857*404b540aSrobert<hr /> 858*404b540aSrobert <h2><a name="5_2">5.2 What's next after libstdc++-v3?</a></h2> 859*404b540aSrobert <p>Hopefully, not much. The goal of libstdc++-v3 is to produce 860*404b540aSrobert a fully-compliant, fully-portable Standard Library. After that, 861*404b540aSrobert we're mostly done: there won't <em>be</em> any more compliance 862*404b540aSrobert work to do. However: 863*404b540aSrobert </p> 864*404b540aSrobert <ol> 865*404b540aSrobert <li><p>The ISO Committee will meet periodically to review Defect Reports 866*404b540aSrobert in the C++ Standard. Undoubtedly some of these will result in 867*404b540aSrobert changes to the Standard, which will be reflected in patches to 868*404b540aSrobert libstdc++. Some of that is already happening, see <a href="#4_3">4.3</a>. Some of 869*404b540aSrobert those changes are being predicted by the library maintainers, and 870*404b540aSrobert we add code to the library based on what the current proposed 871*404b540aSrobert resolution specifies. Those additions are listed in 872*404b540aSrobert <a href="../ext/howto.html#5">the extensions page</a>. 873*404b540aSrobert </p></li> 874*404b540aSrobert <li><p>Performance tuning. Lots of performance tuning. This too is 875*404b540aSrobert already underway for post-3.0 releases, starting with memory 876*404b540aSrobert expansion in container classes and buffer usage in synchronized 877*404b540aSrobert stream objects. 878*404b540aSrobert </p></li> 879*404b540aSrobert <li><p>An ABI for libstdc++ is being developed, so that 880*404b540aSrobert multiple binary-incompatible copies of the library can be replaced 881*404b540aSrobert with a single backwards-compatible library, like libgcc_s.so is. 882*404b540aSrobert </p></li> 883*404b540aSrobert <li><p>The current libstdc++ contains extensions to the Library which 884*404b540aSrobert must be explicitly requested by client code (for example, the 885*404b540aSrobert hash tables from SGI). Other extensions may be added to 886*404b540aSrobert libstdc++-v3 if they seem to be "standard" enough. 887*404b540aSrobert (For example, the "long long" type from C99.) 888*404b540aSrobert Bugfixes and rewrites (to improve or fix thread safety, for 889*404b540aSrobert instance) will of course be a continuing task. 890*404b540aSrobert </p></li> 891*404b540aSrobert <li><p>There is an effort underway to add significant extensions to 892*404b540aSrobert the standard library specification. The latest version of this effort is 893*404b540aSrobert described in 894*404b540aSrobert <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf"> 895*404b540aSrobert The C++ Library Technical Report 1</a>. 896*404b540aSrobert See <a href="#5_5">5.5</a>. 897*404b540aSrobert </p></li> 898*404b540aSrobert </ol> 899*404b540aSrobert <p><a href="http://gcc.gnu.org/ml/libstdc++/1999/msg00080.html">This 900*404b540aSrobert question</a> about the next libstdc++ prompted some brief but 901*404b540aSrobert interesting 902*404b540aSrobert <a href="http://gcc.gnu.org/ml/libstdc++/1999/msg00084.html">speculation</a>. 903*404b540aSrobert </p> 904*404b540aSrobert 905*404b540aSrobert<hr /> 906*404b540aSrobert <h2><a name="5_3">5.3 What about the STL from SGI?</a></h2> 907*404b540aSrobert <p>The <a href="http://www.sgi.com/tech/stl/">STL from SGI</a>, 908*404b540aSrobert version 3.3, was the final merge of the STL codebase. The 909*404b540aSrobert code in libstdc++ contains many fixes and changes, and 910*404b540aSrobert the SGI code is no longer under active 911*404b540aSrobert development. We expect that no future merges will take place. 912*404b540aSrobert </p> 913*404b540aSrobert <p>In particular, <code>string</code> is not from SGI and makes no 914*404b540aSrobert use of their "rope" class (which is included as an 915*404b540aSrobert optional extension), nor is <code>valarray</code> and some others. 916*404b540aSrobert Classes like <code>vector<></code> are, however we have 917*404b540aSrobert made significant changes to them since then. 918*404b540aSrobert </p> 919*404b540aSrobert <p>The FAQ for SGI's STL (one jump off of their main page) is 920*404b540aSrobert recommended reading. 921*404b540aSrobert </p> 922*404b540aSrobert 923*404b540aSrobert<hr /> 924*404b540aSrobert <h2><a name="5_4">5.4 Extensions and Backward Compatibility</a></h2> 925*404b540aSrobert <p>Headers in the <code>ext</code> and <code>backward</code> 926*404b540aSrobert subdirectories should be referred to by their relative paths: 927*404b540aSrobert <!-- Careful, the leading spaces in PRE show up directly. --> 928*404b540aSrobert </p> 929*404b540aSrobert <pre> 930*404b540aSrobert #include <ext/hash_map> </pre> 931*404b540aSrobert <p>rather than using <code>-I</code> or other options. This is more 932*404b540aSrobert portable and forward-compatible. (The situation is the same as 933*404b540aSrobert that of other headers whose directories are not searched directly, 934*404b540aSrobert e.g., <code><sys/stat.h></code>, <code><X11/Xlib.h></code>. 935*404b540aSrobert </p> 936*404b540aSrobert 937*404b540aSrobert <p>At this time most of the features of the SGI STL extension have been 938*404b540aSrobert replaced by standardized libraries. 939*404b540aSrobert In particular, the unordered_map and unordered_set containers of TR1 940*404b540aSrobert are suitable replacement for the non-standard hash_map and hash_set 941*404b540aSrobert containers in the SGI STL. See <a href="#5_5">5.5</a> for more details. 942*404b540aSrobert </p> 943*404b540aSrobert 944*404b540aSrobert <p>The extensions are no longer in the global or <code>std</code> 945*404b540aSrobert namespaces, instead they are declared in the <code>__gnu_cxx</code> 946*404b540aSrobert namespace. For maximum portability, consider defining a namespace 947*404b540aSrobert alias to use to talk about extensions, e.g.: 948*404b540aSrobert </p> 949*404b540aSrobert <pre> 950*404b540aSrobert #ifdef __GNUC__ 951*404b540aSrobert #if __GNUC__ < 3 952*404b540aSrobert #include <hash_map.h> 953*404b540aSrobert namespace Sgi { using ::hash_map; }; // inherit globals 954*404b540aSrobert #else 955*404b540aSrobert #include <ext/hash_map> 956*404b540aSrobert #if __GNUC_MINOR__ == 0 957*404b540aSrobert namespace Sgi = std; // GCC 3.0 958*404b540aSrobert #else 959*404b540aSrobert namespace Sgi = ::__gnu_cxx; // GCC 3.1 and later 960*404b540aSrobert #endif 961*404b540aSrobert #endif 962*404b540aSrobert #else // ... there are other compilers, right? 963*404b540aSrobert namespace Sgi = std; 964*404b540aSrobert #endif 965*404b540aSrobert 966*404b540aSrobert Sgi::hash_map<int,int> my_map; </pre> 967*404b540aSrobert <p>This is a bit cleaner than defining typedefs for all the 968*404b540aSrobert instantiations you might need. 969*404b540aSrobert </p> 970*404b540aSrobert <p><strong>Note:</strong> explicit template specializations must 971*404b540aSrobert be declared in the same namespace as the original template. 972*404b540aSrobert This means you cannot use a namespace alias when declaring 973*404b540aSrobert an explicit specialization. 974*404b540aSrobert </p> 975*404b540aSrobert <p>Extensions to the library have 976*404b540aSrobert <a href="../ext/howto.html">their own page</a>. 977*404b540aSrobert </p> 978*404b540aSrobert 979*404b540aSrobert<hr /> 980*404b540aSrobert <h2><a name="5_5">5.5 Does libstdc++ support TR1?</a></h2> 981*404b540aSrobert 982*404b540aSrobert <p>The C++ Standard Library Technical Report adds many new features to 983*404b540aSrobert the library. The latest version of this effort is described in 984*404b540aSrobert <a href= 985*404b540aSrobert "http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf"> 986*404b540aSrobert Technical Report 1</a>. 987*404b540aSrobert </p> 988*404b540aSrobert 989*404b540aSrobert <p>libstdc++ strives to implement all of TR1. 990*404b540aSrobert An <a href="../ext/tr1.html">overview</a> of the implementation status 991*404b540aSrobert is available. 992*404b540aSrobert </p> 993*404b540aSrobert 994*404b540aSrobert <p>Briefly, the features of TR1 and the current status are: 995*404b540aSrobert </p> 996*404b540aSrobert 997*404b540aSrobert <p><strong>Reference_wrapper - Complete -</strong> 998*404b540aSrobert Useful to pass references to functions that take their parameters 999*404b540aSrobert by value. 1000*404b540aSrobert </p> 1001*404b540aSrobert 1002*404b540aSrobert <p><strong>Reference-counted smart pointers - Complete -</strong> 1003*404b540aSrobert The shared_ptr and weak_ptr allow several object to know about a 1004*404b540aSrobert pointer and whether it is valid. When the last reference to the 1005*404b540aSrobert pointer is destroyed the pointer is freed. 1006*404b540aSrobert </p> 1007*404b540aSrobert 1008*404b540aSrobert <p><strong>Function objects - Complete -</strong> 1009*404b540aSrobert Function return types (i.e., result_of), the functions template 1010*404b540aSrobert mem_fn (a generalization of mem_fun and mem_fun_red), function 1011*404b540aSrobert object binders (e.g., bind, a generalization of bind1st and bind2nd), 1012*404b540aSrobert and polymorphic function wrappers (e.g, class template function). 1013*404b540aSrobert </p> 1014*404b540aSrobert 1015*404b540aSrobert <p><strong>Type traits - Complete -</strong> 1016*404b540aSrobert The type_traits class gives templates the ability to probe 1017*404b540aSrobert information about the input type and enable type-dependent logic 1018*404b540aSrobert to be performed without the need of template specializations. 1019*404b540aSrobert </p> 1020*404b540aSrobert 1021*404b540aSrobert <p><strong>A random number engine - Complete -</strong> 1022*404b540aSrobert This library contains random number generators with several different 1023*404b540aSrobert choices of distribution. 1024*404b540aSrobert </p> 1025*404b540aSrobert 1026*404b540aSrobert <p><strong>Tuples - Complete -</strong> 1027*404b540aSrobert The tuple class implements small heterogeneous arrays. This is an 1028*404b540aSrobert enhanced pair. In fact, the standard pair is enhanced with a tuple 1029*404b540aSrobert interface. 1030*404b540aSrobert </p> 1031*404b540aSrobert 1032*404b540aSrobert <p><strong>Fixed-size arrays - Complete -</strong> 1033*404b540aSrobert The array class implements small fixed-sized arrays with container 1034*404b540aSrobert semantics. 1035*404b540aSrobert </p> 1036*404b540aSrobert 1037*404b540aSrobert <p><strong>Unordered containers - Complete -</strong> 1038*404b540aSrobert The unordered_set, unordered_map, unordered_multiset, and 1039*404b540aSrobert unordered_multimap containers are hashed versions of the map, set, 1040*404b540aSrobert multimap, and multiset containers respectively. These classes are 1041*404b540aSrobert suitable replacements for the SGI STL hash_map and hash_set 1042*404b540aSrobert extensions. 1043*404b540aSrobert </p> 1044*404b540aSrobert 1045*404b540aSrobert <p><strong>C99 compatibility - Under construction - </strong> 1046*404b540aSrobert There are many features designed to minimize the divergence of the C 1047*404b540aSrobert and the C++ languages. 1048*404b540aSrobert </p> 1049*404b540aSrobert 1050*404b540aSrobert <p><strong>Special functions - Under construction - </strong> 1051*404b540aSrobert Twenty-three mathematical functions familiar to physicists and 1052*404b540aSrobert engineers are included: cylindrical and spherical Bessel and Neumann 1053*404b540aSrobert functions, hypergeometric functions, Laguerre polynomials, Legendre 1054*404b540aSrobert functions, elliptic integrals, exponential integrals and the Riemann 1055*404b540aSrobert zeta function all for your computing pleasure. 1056*404b540aSrobert </p> 1057*404b540aSrobert 1058*404b540aSrobert <p><strong>A regular expression engine</strong> 1059*404b540aSrobert This library provides for regular expression objects with traversal 1060*404b540aSrobert of text with return of subexpressions. 1061*404b540aSrobert </p> 1062*404b540aSrobert 1063*404b540aSrobert<hr /> 1064*404b540aSrobert <h2><a name="5_6">5.6 Is libstdc++-v3 thread-safe?</a></h2> 1065*404b540aSrobert <p>libstdc++-v3 strives to be thread-safe when all of the following 1066*404b540aSrobert conditions are met: 1067*404b540aSrobert </p> 1068*404b540aSrobert <ul> 1069*404b540aSrobert <li>The system's libc is itself thread-safe,</li> 1070*404b540aSrobert <li><code>gcc -v</code> reports a thread model other than 'single',</li> 1071*404b540aSrobert <li>[pre-3.3 only] a non-generic implementation of atomicity.h 1072*404b540aSrobert exists for the architecture in question.</li> 1073*404b540aSrobert </ul> 1074*404b540aSrobert <p>The user-code must guard against concurrent method calls which may 1075*404b540aSrobert access any particular library object's state. Typically, the 1076*404b540aSrobert application programmer may infer what object locks must be held 1077*404b540aSrobert based on the objects referenced in a method call. Without getting 1078*404b540aSrobert into great detail, here is an example which requires user-level 1079*404b540aSrobert locks: 1080*404b540aSrobert </p> 1081*404b540aSrobert <pre> 1082*404b540aSrobert library_class_a shared_object_a; 1083*404b540aSrobert 1084*404b540aSrobert thread_main () { 1085*404b540aSrobert library_class_b *object_b = new library_class_b; 1086*404b540aSrobert shared_object_a.add_b (object_b); // must hold lock for shared_object_a 1087*404b540aSrobert shared_object_a.mutate (); // must hold lock for shared_object_a 1088*404b540aSrobert } 1089*404b540aSrobert 1090*404b540aSrobert // Multiple copies of thread_main() are started in independent threads.</pre> 1091*404b540aSrobert <p>Under the assumption that object_a and object_b are never exposed to 1092*404b540aSrobert another thread, here is an example that should not require any 1093*404b540aSrobert user-level locks: 1094*404b540aSrobert </p> 1095*404b540aSrobert <pre> 1096*404b540aSrobert thread_main () { 1097*404b540aSrobert library_class_a object_a; 1098*404b540aSrobert library_class_b *object_b = new library_class_b; 1099*404b540aSrobert object_a.add_b (object_b); 1100*404b540aSrobert object_a.mutate (); 1101*404b540aSrobert } </pre> 1102*404b540aSrobert <p>All library objects are safe to use in a multithreaded program as 1103*404b540aSrobert long as each thread carefully locks out access by any other 1104*404b540aSrobert thread while it uses any object visible to another thread, i.e., 1105*404b540aSrobert treat library objects like any other shared resource. In general, 1106*404b540aSrobert this requirement includes both read and write access to objects; 1107*404b540aSrobert unless otherwise documented as safe, do not assume that two threads 1108*404b540aSrobert may access a shared standard library object at the same time. 1109*404b540aSrobert </p> 1110*404b540aSrobert <p>See chapters <a href="../17_intro/howto.html#3">17</a> (library 1111*404b540aSrobert introduction), <a href="../23_containers/howto.html#3">23</a> 1112*404b540aSrobert (containers), and <a href="../27_io/howto.html#9">27</a> (I/O) for 1113*404b540aSrobert more information. 1114*404b540aSrobert </p> 1115*404b540aSrobert 1116*404b540aSrobert<hr /> 1117*404b540aSrobert <h2><a name="5_7">5.7 How do I get a copy of the ISO C++ Standard?</a></h2> 1118*404b540aSrobert <p>Copies of the full ISO 14882 standard are available on line via the 1119*404b540aSrobert ISO mirror site for committee members. Non-members, or those who 1120*404b540aSrobert have not paid for the privilege of sitting on the committee and 1121*404b540aSrobert sustained their two-meeting commitment for voting rights, may get a 1122*404b540aSrobert copy of the standard from their respective national standards 1123*404b540aSrobert organization. In the USA, this national standards organization is 1124*404b540aSrobert ANSI and their website is right <a href="http://www.ansi.org">here</a>. 1125*404b540aSrobert (And if you've already registered with them, clicking this link will 1126*404b540aSrobert take you to directly to the place where you can 1127*404b540aSrobert<a href="http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%3A2003">buy 1128*404b540aSrobert the standard on-line</a>. 1129*404b540aSrobert </p> 1130*404b540aSrobert <p>Who is your country's member body? Visit the 1131*404b540aSrobert <a href="http://www.iso.ch/">ISO homepage</a> and find out! 1132*404b540aSrobert </p> 1133*404b540aSrobert 1134*404b540aSrobert<hr /> 1135*404b540aSrobert <h2><a name="5_8">5.8 What's an ABI and why is it so messy?</a></h2> 1136*404b540aSrobert <p>"ABI" stands for "Application Binary Interface." 1137*404b540aSrobert Conventionally, it refers to a great mass of details about how 1138*404b540aSrobert arguments are arranged on the call stack and/or in registers, and 1139*404b540aSrobert how various types are arranged and padded in structs. A single CPU 1140*404b540aSrobert design may suffer multiple ABIs designed by different development 1141*404b540aSrobert tool vendors who made different choices, or even by the same vendor 1142*404b540aSrobert for different target applications or compiler versions. In ideal 1143*404b540aSrobert circumstances the CPU designer presents one ABI and all the OSes and 1144*404b540aSrobert compilers use it. In practice every ABI omits details that compiler 1145*404b540aSrobert implementers (consciously or accidentally) must choose for themselves. 1146*404b540aSrobert </p> 1147*404b540aSrobert <p>That ABI definition suffices for compilers to generate code so a 1148*404b540aSrobert program can interact safely with an OS and its lowest-level libraries. 1149*404b540aSrobert Users usually want an ABI to encompass more detail, allowing libraries 1150*404b540aSrobert built with different compilers (or different releases of the same 1151*404b540aSrobert compiler!) to be linked together. For C++, this includes many more 1152*404b540aSrobert details than for C, and CPU designers (for good reasons elaborated 1153*404b540aSrobert below) have not stepped up to publish C++ ABIs. The details include 1154*404b540aSrobert virtual function implementation, struct inheritance layout, name 1155*404b540aSrobert mangling, and exception handling. Such an ABI has been defined for 1156*404b540aSrobert GNU C++, and is immediately useful for embedded work relying only on 1157*404b540aSrobert a "free-standing implementation" that doesn't include (much 1158*404b540aSrobert of) the standard library. It is a good basis for the work to come. 1159*404b540aSrobert </p> 1160*404b540aSrobert <p>A useful C++ ABI must also incorporate many details of the standard 1161*404b540aSrobert library implementation. For a C ABI, the layouts of a few structs 1162*404b540aSrobert (such as FILE, stat, jmpbuf, and the like) and a few macros suffice. 1163*404b540aSrobert For C++, the details include the complete set of names of functions 1164*404b540aSrobert and types used, the offsets of class members and virtual functions, 1165*404b540aSrobert and the actual definitions of all inlines. C++ exposes many more 1166*404b540aSrobert library details to the caller than C does. It makes defining 1167*404b540aSrobert a complete ABI a much bigger undertaking, and requires not just 1168*404b540aSrobert documenting library implementation details, but carefully designing 1169*404b540aSrobert those details so that future bug fixes and optimizations don't 1170*404b540aSrobert force breaking the ABI. 1171*404b540aSrobert </p> 1172*404b540aSrobert <p>There are ways to help isolate library implementation details from the 1173*404b540aSrobert ABI, but they trade off against speed. Library details used in 1174*404b540aSrobert inner loops (e.g., getchar) must be exposed and frozen for all 1175*404b540aSrobert time, but many others may reasonably be kept hidden from user code, 1176*404b540aSrobert so they may later be changed. Deciding which, and implementing 1177*404b540aSrobert the decisions, must happen before you can reasonably document a 1178*404b540aSrobert candidate C++ ABI that encompasses the standard library. 1179*404b540aSrobert </p> 1180*404b540aSrobert 1181*404b540aSrobert<hr /> 1182*404b540aSrobert <h2><a name="5_9">5.9 How do I make std::vector<T>::capacity() 1183*404b540aSrobert == std::vector<T>::size()?</a> </h2> 1184*404b540aSrobert <!-- referenced by 21_strings/howto.html#6 --> 1185*404b540aSrobert <p>The standard idiom for deallocating a <code>std::vector<T></code>'s 1186*404b540aSrobert unused memory is to create a temporary copy of the vector and swap their 1187*404b540aSrobert contents, e.g. for <code>std::vector<T> v</code> 1188*404b540aSrobert </p> 1189*404b540aSrobert <pre> 1190*404b540aSrobert std::vector<T>(v).swap(v); 1191*404b540aSrobert </pre> 1192*404b540aSrobert <p>The copy will take O(n) time and the swap is constant time. 1193*404b540aSrobert </p> 1194*404b540aSrobert <p>See <a href='../21_strings/howto.html#6'>Shrink-to-fit strings</a> for 1195*404b540aSrobert a similar solution for strings. 1196*404b540aSrobert </p> 1197*404b540aSrobert 1198*404b540aSrobert<!-- ####################################################### --> 1199*404b540aSrobert 1200*404b540aSrobert<hr /> 1201*404b540aSrobert<p class="fineprint"><em> 1202*404b540aSrobertSee <a href="../17_intro/license.html">license.html</a> for copying conditions. 1203*404b540aSrobertComments and suggestions are welcome, and may be sent to 1204*404b540aSrobert<a href="mailto:libstdc++@gcc.gnu.org">the libstdc++ mailing list</a>. 1205*404b540aSrobert</em></p> 1206*404b540aSrobert 1207*404b540aSrobert 1208*404b540aSrobert</body> 1209*404b540aSrobert</html> 1210*404b540aSrobert 1211