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