2 #[1]GNU C++ Standard Library [2]Copyright
4 libstdc++ Frequently Asked Questions
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.
11 To the [5]libstdc++-v3 homepage.
12 _________________________________________________________________
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?
27 1. [17]How do I install libstdc++-v3?
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>?
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
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!
62 1. [49]string::iterator is not char*; vector<T>::iterator is not
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() ==
73 _________________________________________________________________
75 1.0 General Information
77 1.1 What is libstdc++-v3?
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).
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.
90 A more formal description of the V3 goals can be found in the official
92 _________________________________________________________________
94 1.2 Why should I use libstdc++?
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.
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++.
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 _________________________________________________________________
114 1.3 Who's in charge of it?
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.
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 _________________________________________________________________
127 1.4 How do I get libstdc++?
129 The [64]homepage has instructions for retrieving the latest CVS
130 sources, and for browsing the CVS sources over the web.
132 Stable versions of libstdc++-v3 are included with releases of [65]the
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 _________________________________________________________________
140 1.5 When is libstdc++ going to be finished?
142 Nathan Myers gave the best of all possible answers, responding to a
143 Usenet article asking this question: Sooner, if you help.
144 _________________________________________________________________
146 1.6 How do I contribute to the effort?
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 _________________________________________________________________
156 1.7 What happened to libg++? I need that!
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.
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)
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.
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
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.)
187 For the bold and/or desperate, the [68]GCC extensions page describes
188 where to find the last libg++ source.
189 _________________________________________________________________
191 1.8 What if I have more questions?
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.
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 _________________________________________________________________
204 1.9 What are the license terms for libstdc++-v3?
206 See [72]our license description for these and related questions.
207 _________________________________________________________________
211 2.1 How do I install libstdc++-v3?
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
219 * GNU Make is required for GCC 3.4 and later.
220 * The GNU Autotools are needed if you are messing with the configury
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
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 _________________________________________________________________
238 This question has become moot and has been removed. The stub is here
239 to preserve numbering (and hence links/bookmarks).
240 _________________________________________________________________
242 2.3 What is this CVS thing that you keep mentioning?
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
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.
253 After the first of April, American users will have a "/pharmacy"
254 command-line option...
255 _________________________________________________________________
257 2.4 How do I know if it works?
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.
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"
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 _________________________________________________________________
273 2.5 This library is HUGE! And what's libsupc++?
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
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
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:
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.
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.
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
319 _________________________________________________________________
321 2.6 Why do I get an error saying libstdc++.so.X is missing when I run my
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
327 shared object file: No such file or directory
329 /usr/libexec/ld-elf.so.1: Shared object "libstdc++.so.6" not found
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
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.
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 /
352 _________________________________________________________________
354 3.0 Platform-Specific Issues
356 3.1 Can libstdc++-v3 be used with <my favorite compiler>?
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.
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 _________________________________________________________________
376 This question has become moot and has been removed. The stub is here
377 to preserve numbering (and hence links/bookmarks).
378 _________________________________________________________________
382 This question has become moot and has been removed. The stub is here
383 to preserve numbering (and hence links/bookmarks).
384 _________________________________________________________________
386 3.4 I can't use 'long long' on Solaris
388 By default we try to support the C99 long long type. This requires
389 that certain functions from your C library be present.
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.
395 This has been fixed for 3.0.3 and onwards.
396 _________________________________________________________________
398 3.5 _XOPEN_SOURCE / _GNU_SOURCE / etc is always defined
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
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.
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.
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.
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.
427 This has been discussed on the mailing lists [79]quite a bit.
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 _________________________________________________________________
433 3.6 OS X ctype.h is broken! How can I hack it?
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
438 _________________________________________________________________
440 3.7 Threading is broken on i386
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.
449 This is fixed in 3.2.2.
450 _________________________________________________________________
452 3.8 Recent GNU/Linux glibc required?
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.
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 _________________________________________________________________
465 3.9 Can't use wchar_t/wstring on FreeBSD
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
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 _________________________________________________________________
478 3.10 MIPS atomic operations
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.
485 mips*-*-linux* continues to use the MIPS II routines, and more work in
486 this area is expected.
487 _________________________________________________________________
489 4.0 Known Bugs and Non-Bugs
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.
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.
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
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
516 _________________________________________________________________
518 4.1 What works already?
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.
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
527 _________________________________________________________________
529 4.2 Bugs in gcc/g++ (not libstdc++-v3)
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.
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 _________________________________________________________________
547 4.3 Bugs in the C++ language/lib specification
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.
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 _________________________________________________________________
562 4.4 Things in libstdc++ that only look like bugs
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.
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.
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
579 std::fstream fs("a_file");
581 // . do things with fs...
584 fs.open("a_new_file");
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!
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.
605 The g++-3 headers are not ours
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).
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
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.
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:
627 2.34. When compiling C++ programs, I get a compilation error in streambuf.h.
629 {BH} You are using g++ 2.95.2? After upgrading to glibc 2.2, you need to
630 apply a patch to the include files in /usr/include/g++, because the fpos_t
631 type has changed in glibc 2.2. The patch is at
632 http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
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.
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).
647 More information, including how to optionally enable/disable the
648 checks, is available [95]here.
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
659 // create your library
660 g++ -fPIC -shared -rdynamic -o libfoo.so a.o b.o ... z.o
662 // link the executable
663 g++ -fPIC -rdynamic -o foo ... -L. -lfoo -ldl
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 _________________________________________________________________
675 4.5 Aw, that's easy to fix!
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.
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
690 _________________________________________________________________
694 5.1 string::iterator is not char*; vector<T>::iterator is not T*
696 If you have code that depends on container<T> iterators being
697 implemented as pointer-to-T, your code is broken.
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.
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 _________________________________________________________________
711 5.2 What's next after libstdc++-v3?
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
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
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
742 [105]This question about the next libstdc++ prompted some brief but
743 interesting [106]speculation.
744 _________________________________________________________________
746 5.3 What about the STL from SGI?
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.
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.
758 The FAQ for SGI's STL (one jump off of their main page) is recommended
760 _________________________________________________________________
762 5.4 Extensions and Backward Compatibility
764 Headers in the ext and backward subdirectories should be referred to
765 by their relative paths:
766 #include <ext/hash_map>
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>.
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.
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,
785 #include <hash_map.h>
786 namespace Sgi { using ::hash_map; }; // inherit globals
788 #include <ext/hash_map>
789 #if __GNUC_MINOR__ == 0
790 namespace Sgi = std; // GCC 3.0
792 namespace Sgi = ::__gnu_cxx; // GCC 3.1 and later
795 #else // ... there are other compilers, right?
799 Sgi::hash_map<int,int> my_map;
801 This is a bit cleaner than defining typedefs for all the
802 instantiations you might need.
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.
808 Extensions to the library have [109]their own page.
809 _________________________________________________________________
811 5.5 Does libstdc++ support TR1?
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.
817 libstdc++ strives to implement all of TR1. An [111]overview of the
818 implementation status is available.
820 Briefly, the features of TR1 and the current status are:
822 Unordered containers - Complete - The unordered_set, unordered_map,
823 unordered_multiset, and unordered_multimap containers are hashed
824 versions of the map, set, multimap, and multiset containers
825 respectively. These classes are suitable replacements for the SGI STL
826 hash_map and hash_set extensions.
828 Reference-counted smart pointers - Complete - The shared_ptr and
829 weak_ptr allow several object to know about a pointer and whether it
830 is valid. When the last reference to the pointer is destroyed the
833 Type traits - Complete - The type_traits class gives templates the
834 ability to probe information about the input type and enable
835 type-dependent logic to be performed without the need of template
838 Fixed-size arrays - Complete - The array class implements small
839 fixed-sized arrays with container semantics.
841 Tuples - Complete - The tuple class implements small heterogeneous
842 arrays. This is an enhanced pair. In fact, the standard pair is
843 enhanced with a tuple interface.
845 A regular expression engine This library provides for regular
846 expression objects with traversal of text with return of
849 A random number engine This library contains randow number generators
850 with several different choices of distribution.
852 Special functions - Under construction - Twenty-three mathematical
853 functions familiar to physicists and engineers are included:
854 cylindrical and spherical Bessel and Neumann functions, hypergeometric
855 functions, Laguerre polynomials, Legendre functions, elliptic
856 integrals, exponential integrals and the Riemann zeta function all for
857 your computing pleasure.
859 C99 compatibility - Under construction - There are many features
860 designed to minimize the divergence of the C and the C++ languages.
861 _________________________________________________________________
863 5.6 Is libstdc++-v3 thread-safe?
865 libstdc++-v3 strives to be thread-safe when all of the following
867 * The system's libc is itself thread-safe,
868 * gcc -v reports a thread model other than 'single',
869 * [pre-3.3 only] a non-generic implementation of atomicity.h exists
870 for the architecture in question.
872 The user-code must guard against concurrent method calls which may
873 access any particular library object's state. Typically, the
874 application programmer may infer what object locks must be held based
875 on the objects referenced in a method call. Without getting into great
876 detail, here is an example which requires user-level locks:
877 library_class_a shared_object_a;
880 library_class_b *object_b = new library_class_b;
881 shared_object_a.add_b (object_b); // must hold lock for shared_object_
883 shared_object_a.mutate (); // must hold lock for shared_object_
887 // Multiple copies of thread_main() are started in independent threads.
889 Under the assumption that object_a and object_b are never exposed to
890 another thread, here is an example that should not require any
893 library_class_a object_a;
894 library_class_b *object_b = new library_class_b;
895 object_a.add_b (object_b);
899 All library objects are safe to use in a multithreaded program as long
900 as each thread carefully locks out access by any other thread while it
901 uses any object visible to another thread, i.e., treat library objects
902 like any other shared resource. In general, this requirement includes
903 both read and write access to objects; unless otherwise documented as
904 safe, do not assume that two threads may access a shared standard
905 library object at the same time.
907 See chapters [112]17 (library introduction), [113]23 (containers), and
908 [114]27 (I/O) for more information.
909 _________________________________________________________________
911 5.7 How do I get a copy of the ISO C++ Standard?
913 Copies of the full ISO 14882 standard are available on line via the
914 ISO mirror site for committee members. Non-members, or those who have
915 not paid for the privilege of sitting on the committee and sustained
916 their two-meeting commitment for voting rights, may get a copy of the
917 standard from their respective national standards organization. In the
918 USA, this national standards organization is ANSI and their website is
919 right [115]here. (And if you've already registered with them, clicking
920 this link will take you to directly to the place where you can
921 [116]buy the standard on-line.
923 Who is your country's member body? Visit the [117]ISO homepage and
925 _________________________________________________________________
927 5.8 What's an ABI and why is it so messy?
929 "ABI" stands for "Application Binary Interface." Conventionally, it
930 refers to a great mass of details about how arguments are arranged on
931 the call stack and/or in registers, and how various types are arranged
932 and padded in structs. A single CPU design may suffer multiple ABIs
933 designed by different development tool vendors who made different
934 choices, or even by the same vendor for different target applications
935 or compiler versions. In ideal circumstances the CPU designer presents
936 one ABI and all the OSes and compilers use it. In practice every ABI
937 omits details that compiler implementers (consciously or accidentally)
938 must choose for themselves.
940 That ABI definition suffices for compilers to generate code so a
941 program can interact safely with an OS and its lowest-level libraries.
942 Users usually want an ABI to encompass more detail, allowing libraries
943 built with different compilers (or different releases of the same
944 compiler!) to be linked together. For C++, this includes many more
945 details than for C, and CPU designers (for good reasons elaborated
946 below) have not stepped up to publish C++ ABIs. The details include
947 virtual function implementation, struct inheritance layout, name
948 mangling, and exception handling. Such an ABI has been defined for GNU
949 C++, and is immediately useful for embedded work relying only on a
950 "free-standing implementation" that doesn't include (much of) the
951 standard library. It is a good basis for the work to come.
953 A useful C++ ABI must also incorporate many details of the standard
954 library implementation. For a C ABI, the layouts of a few structs
955 (such as FILE, stat, jmpbuf, and the like) and a few macros suffice.
956 For C++, the details include the complete set of names of functions
957 and types used, the offsets of class members and virtual functions,
958 and the actual definitions of all inlines. C++ exposes many more
959 library details to the caller than C does. It makes defining a
960 complete ABI a much bigger undertaking, and requires not just
961 documenting library implementation details, but carefully designing
962 those details so that future bug fixes and optimizations don't force
965 There are ways to help isolate library implementation details from the
966 ABI, but they trade off against speed. Library details used in inner
967 loops (e.g., getchar) must be exposed and frozen for all time, but
968 many others may reasonably be kept hidden from user code, so they may
969 later be changed. Deciding which, and implementing the decisions, must
970 happen before you can reasonably document a candidate C++ ABI that
971 encompasses the standard library.
972 _________________________________________________________________
974 5.9 How do I make std::vector<T>::capacity() == std::vector<T>::size()?
976 The standard idiom for deallocating a std::vector<T>'s unused memory
977 is to create a temporary copy of the vector and swap their contents,
978 e.g. for std::vector<T> v
979 std::vector<T>(v).swap(v);
982 The copy will take O(n) time and the swap is constant time.
984 See [118]Shrink-to-fit strings for a similar solution for strings.
985 _________________________________________________________________
987 See [119]license.html for copying conditions. Comments and suggestions
988 are welcome, and may be sent to [120]the libstdc++ mailing list.
992 1. ../documentation.html
993 2. ../17_intro/license.html
994 3. http://gcc.gnu.org/onlinedocs/libstdc++/faq/
995 4. http://gcc.gnu.org/onlinedocs/libstdc++/documentation.html
996 5. http://gcc.gnu.org/libstdc++/
997 6. ../faq/index.html#1_0
998 7. ../faq/index.html#1_1
999 8. ../faq/index.html#1_2
1000 9. ../faq/index.html#1_3
1001 10. ../faq/index.html#1_4
1002 11. ../faq/index.html#1_5
1003 12. ../faq/index.html#1_6
1004 13. ../faq/index.html#1_7
1005 14. ../faq/index.html#1_8
1006 15. ../faq/index.html#1_9
1007 16. ../faq/index.html#2_0
1008 17. ../faq/index.html#2_1
1009 18. ../faq/index.html#2_2
1010 19. ../faq/index.html#2_3
1011 20. ../faq/index.html#2_4
1012 21. ../faq/index.html#2_5
1013 22. ../faq/index.html#2_6
1014 23. ../faq/index.html#3_0
1015 24. ../faq/index.html#3_1
1016 25. ../faq/index.html#3_2
1017 26. ../faq/index.html#3_3
1018 27. ../faq/index.html#3_4
1019 28. ../faq/index.html#3_5
1020 29. ../faq/index.html#3_6
1021 30. ../faq/index.html#3_7
1022 31. ../faq/index.html#3_8
1023 32. ../faq/index.html#3_9
1024 33. ../faq/index.html#3_10
1025 34. ../faq/index.html#4_0
1026 35. ../faq/index.html#4_1
1027 36. ../faq/index.html#4_2
1028 37. ../faq/index.html#4_3
1029 38. ../faq/index.html#4_4
1030 39. ../faq/index.html#4_4_iostreamclear
1031 40. ../faq/index.html#4_4_Weff
1032 41. ../faq/index.html#4_4_rel_ops
1033 42. ../faq/index.html#4_4_interface
1034 43. ../faq/index.html#4_4_glibc
1035 44. ../faq/index.html#4_4_checks
1036 45. ../faq/index.html#4_4_dlsym
1037 46. ../faq/index.html#4_4_leak
1038 47. ../faq/index.html#4_5
1039 48. ../faq/index.html#5_0
1040 49. ../faq/index.html#5_1
1041 50. ../faq/index.html#5_2
1042 51. ../faq/index.html#5_3
1043 52. ../faq/index.html#5_4
1044 53. ../faq/index.html#5_5
1045 54. ../faq/index.html#5_6
1046 55. ../faq/index.html#5_7
1047 56. ../faq/index.html#5_8
1048 57. ../faq/index.html#5_9
1049 58. ../faq/index.html#1_4
1050 59. ../faq/index.html#4_4_interface
1051 60. ../17_intro/DESIGN
1052 61. http://gcc.gnu.org/
1053 62. http://gcc.gnu.org/gcc-3.3/buildstat.html
1054 63. http://gcc.gnu.org/libstdc++/
1055 64. http://gcc.gnu.org/libstdc++/
1056 65. http://gcc.gnu.org/releases.html
1057 66. ../17_intro/contribute.html
1058 67. http://www.boost.org/
1059 68. http://gcc.gnu.org/extensions.html
1060 69. mailto:libstdc++@gcc.gnu.org
1061 70. mailto:pme@gcc.gnu.org
1062 71. mailto:gdr@gcc.gnu.org
1063 72. ../17_intro/license.html
1064 73. ../documentation.html
1065 74. ../17_intro/RELEASE-NOTES
1066 75. http://www.gnu.org/software/cvs/cvs.html
1067 76. http://www.cvshome.org/
1068 77. http://gcc.gnu.org/install/test.html
1069 78. ../18_support/howto.html
1070 79. http://gcc.gnu.org/cgi-bin/htsearch?method=and&format=builtin-long&sort=score&words=_XOPEN_SOURCE+Solaris
1071 80. http://gcc.gnu.org/ml/gcc/2002-03/msg00817.html
1072 81. http://gcc.gnu.org/ml/libstdc++/2003-02/subjects.html#00286
1073 82. http://gcc.gnu.org/install/configure.html
1074 83. http://gcc.gnu.org/install/
1075 84. http://gcc.gnu.org/bugs.html
1076 85. http://gcc.gnu.org/ml/libstdc++/2002-02/msg00034.html
1077 86. http://gcc.gnu.org/ml/libstdc++/1998/msg00006.html
1078 87. http://www.cantrip.org/draft-bugs.txt
1079 88. http://anubis.dkuug.dk/jtc1/sc22/wg21/
1080 89. ../faq/index.html#5_2
1081 90. ../ext/howto.html#5
1082 91. ../ext/howto.html#5
1083 92. http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html
1084 93. http://gcc.gnu.org/bugs.html
1085 94. ../faq/index.html#4_4_interface
1086 95. ../19_diagnostics/howto.html#3
1087 96. http://developer.kde.org/~sewardj/
1088 97. ../debug.html#mem
1089 98. http://gcc.gnu.org/contribute.html
1090 99. ../17_intro/contribute.html
1091 100. ../faq/index.html#2_4
1092 101. ../faq/index.html#4_3
1093 102. ../ext/howto.html#5
1094 103. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf
1095 104. ../faq/index.html#5_5
1096 105. http://gcc.gnu.org/ml/libstdc++/1999/msg00080.html
1097 106. http://gcc.gnu.org/ml/libstdc++/1999/msg00084.html
1098 107. http://www.sgi.com/tech/stl/
1099 108. ../faq/index.html#5_5
1100 109. ../ext/howto.html
1101 110. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf
1102 111. ../ext/tr1.html
1103 112. ../17_intro/howto.html#3
1104 113. ../23_containers/howto.html#3
1105 114. ../27_io/howto.html#9
1106 115. http://www.ansi.org/
1107 116. http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%3A2003
1108 117. http://www.iso.ch/
1109 118. ../21_strings/howto.html#6
1110 119. ../17_intro/license.html
1111 120. mailto:libstdc++@gcc.gnu.org