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