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