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