The latest version of this document is always available at - - http://gcc.gnu.org/onlinedocs/libstdc++/faq/. The main documentation - page is at - - http://gcc.gnu.org/onlinedocs/libstdc++/documentation.html. -
- -To the libstdc++-v3 homepage. -
- - -The GNU Standard C++ Library v3 is an - ongoing project to implement the ISO 14882 Standard C++ library - as described in chapters 17 through 27 and annex D. As the - library reaches stable plateaus, it is captured in a snapshot - and released. The latest release is - the - fourteenth snapshot but newer versions have been included - in recent GCC releases. For those who want to see exactly how - far the project has come, or just want the latest - bleeding-edge code, the up-to-date source is available over - anonymous CVS, and can even be browsed over the Web (see - 1.4 below). -
-The older libstdc++-v2 project is no longer maintained; the code - has been completely replaced and rewritten. - If you are using V2, then you need to - report bugs to your system vendor, not to the V3 list. -
-A more formal description of the V3 goals can be found in the - official design document. -
- -The completion of the ISO C++ standardization gave the - C++ community a powerful set of reuseable tools in the form - of the C++ Standard Library. However, all existing C++ - implementations are (as the Draft Standard used to say) - "incomplet and incorrekt," and many suffer from - limitations of the compilers that use them. -
-The GNU C/C++/FORTRAN/<pick-a-language> compiler
- (gcc, g++, etc) is widely considered to be
- one of the leading compilers in the world. Its development
- has recently been taken over by the
- GCC team. All of
- the rapid development and near-legendary
- portability
- that are the hallmarks of an open-source project are being
- applied to libstdc++.
-
That means that all of the Standard classes and functions
- (such as string, vector<>, iostreams,
- and algorithms) will be freely available and fully compliant.
- Programmers will no longer need to "roll their own"
- nor be worried about platform-specific incompatibilities.
-
The libstdc++ project is contributed to by several developers - all over the world, in the same way as GCC or Linux. - Benjamin Kosnik, Gabriel Dos Reis, Phil Edwards, Ulrich Drepper, - Loren James Rittle, and Paolo Carlini are the lead maintainers of - the CVS archive. -
-Development and discussion is held on the libstdc++ mailing - list. Subscribing to the list, or searching the list - archives, is open to everyone. You can read instructions for - doing so on the homepage. - If you have questions, ideas, code, or are just curious, sign up! -
- -The fourteenth (and latest) snapshot of libstdc++-v3 is - available - via ftp. -
-The homepage - has instructions for retrieving the latest CVS sources, and for - browsing the CVS sources over the web. -
-The subset commonly known as the Standard Template Library - (chapters 23 through 25, mostly) is adapted from the final release - of the SGI STL. -
- -Nathan Myers gave the best of all possible answers, responding to a - Usenet article asking this question: Sooner, if you help. -
- -Here is a - page devoted to this topic. Subscribing to the mailing - list (see above, or the homepage) is a very good idea if you - have something to contribute, or if you have spare time and - want to help. Contributions don't have to be in the form of - source code; anybody who is willing to help write - documentation, for example, or has found a bug in code that - we all thought was working, is more than welcome! -
- -The most recent libg++ README states that libg++ is no longer - being actively maintained. It should not be used for new - projects, and is only being kicked along to support older code. -
-The libg++ was designed and created when there was no Standard
- to provide guidance. Classes like linked lists are now provided
- for by list<T> and do not need to be created by
- genclass. (For that matter, templates exist now and
- are well-supported, whereas genclass (mostly) predates them.)
-
There are other classes in libg++ that are not specified in the - ISO Standard (e.g., statistical analysis). While there are a - lot of really useful things that are used by a lot of people - (e.g., statistics :-), the Standards Committee couldn't include - everything, and so a lot of those "obvious" classes - didn't get included. -
-Since libstdc++ is an implementation of the Standard Library, we - have no plans at this time to include non-Standard utilities - in the implementation, however handy they are. (The extensions - provided in the SGI STL aren't maintained by us and don't get - a lot of our attention, because they don't require a lot of our - time.) It is entirely plausable that the "useful stuff" - from libg++ might be extracted into an updated utilities library, - but nobody has stated such a project yet. -
- -(The Boost site houses free - C++ libraries that do varying things, and happened to be started - by members of the Standards Committee. Certain "useful - stuff" classes will probably migrate there.) -
-For the bold and/or desperate, the - GCC FAQ - describes where to find the last libg++ source. -
- -If you have read the README and RELEASE-NOTES files, and your
- question remains unanswered, then just ask the mailing list.
- At present, you do not need to be subscribed to the list to
- send a message to it. More information is available on the
- homepage (including how to browse the list archives); to send
- to the list, use
- libstdc++@gcc.gnu.org.
-
If you have a question that you think should be included here, - or if you have a question about a question/answer here, - contact Phil Edwards - or Gabriel Dos Reis. -
- -See our license description - for these and related questions. -
- -Complete instructions are not given here (this is a FAQ, not - an installation document), but the tools required are few: -
-The file documentation.html - provides a good overview of the steps necessary to build, install, - and use the library. Instructions for configuring the library - with new flags such as --enable-threads are there also, as well as - patches and instructions for working with GCC 2.95. -
-The top-level install.html and - RELEASE-NOTES files contain - the exact build and installation instructions. You may wish to - browse those files over CVSweb ahead of time to get a feel for - what's required. RELEASE-NOTES is located in the - ".../docs/17_intro/" directory of the distribution. -
- -This question has become moot and has been removed. The stub - is here to preserve numbering (and hence links/bookmarks). -
- -The Concurrent Versions System is one of several revision - control packages. It was selected for GNU projects because it's - free (speech), free (beer), and very high quality. The CVS entry in - the GNU software catalogue has a better description as - well as a - link to the makers of CVS. -
-The "anonymous client checkout" feature of CVS is - similar to anonymous FTP in that it allows anyone to retrieve - the latest libstdc++ sources. -
-After the first of April, American users will have a - "/pharmacy" command-line option... - -
- -libstdc++-v3 comes with its own testsuite. You do not need
- to actually install the library ("make
- install") to run the testsuite.
-
To run the testsuite on the library after building it, use - "make check" while in your build directory. To run - the testsuite on the library after building and installing it, - use "make check-install" instead. -
-If you find bugs in the testsuite programs themselves, or if you - think of a new test program that should be added to the suite, - please write up your idea and send it to the list! -
- -Usually the size of libraries on disk isn't noticeable. When a - link editor (or simply "linker") pulls things from a - static archive library, only the necessary object files are copied - into your executable, not the entire library. Unfortunately, even - if you only need a single function or variable from an object file, - the entire object file is extracted. (There's nothing unique to C++ - or libstdc++-v3 about this; it's just common behavior, given here - for background reasons.) -
-Some of the object files which make up libstdc++.a are rather large.
- If you create a statically-linked executable with
- -static, those large object files are suddenly part
- of your executable. Historically the best way around this was to
- only place a very few functions (often only a single one) in each
- source/object file; then extracting a single function is the same
- as extracting a single .o file. For libstdc++-v3 this is only
- possible to a certain extent; the object files in question contain
- template classes and template functions, pre-instantiated, and
- splitting those up causes severe maintenance headaches.
-
It's not a bug, and it's not really a problem. Nevertheless, some - people don't like it, so here are two pseudo-solutions: -
-If the only functions from libstdc++.a which you need are language
- support functions (those listed in
- clause 18 of the standard,
- e.g., new and delete), then try linking
- against libsupc++.a (usually specifying
- -lsupc++ when calling g++ for the final link step will
- do it). This library contains only those support routines, one per
- object file. But if you are using anything from the rest of the
- library, such as IOStreams or vectors, then you'll still need
- pieces from libstdc++.a.
-
The second method is one we hope to incorporate into the library - build process. Some platforms can place each function and variable - into its own section in a .o file. The GNU linker can then perform - garbage collection on unused sections; this reduces the situation - to only copying needed functions into the executable, as before, - but all happens automatically. -
-Unfortunately the garbage collection in GNU ld is buggy; sections - (corresponding to functions and variables) which are used - are mistakenly removed, leading to horrible crashes when your - executable starts up. For the time being, this feature is not used - when building the library. -
- -Probably not. Yet.
-Because GCC advances so rapidly, development and testing of - libstdc++ is being done almost entirely under that compiler. - If you are curious about whether other, lesser compilers - (*grin*) support libstdc++, you are more than welcome to try. - Configuring and building the library (see above) will still - require certain tools, however. Also keep in mind that - building libstdc++ does not imply that your compiler - will be able to use all of the features found in the - C++ Standard Library. -
-Since the goal of ISO Standardization is for all C++ - implementations to be able to share code, the final libstdc++ - should, in theory, be usable under any ISO-compliant - compiler. It will still be targeted and optimized for - GCC/g++, however. -
- -This question has become moot and has been removed. The stub - is here to preserve numbering (and hence links/bookmarks). -
- -This question has become moot and has been removed. The stub - is here to preserve numbering (and hence links/bookmarks). -
- -By default we try to support the C99 long long type.
- This requires that certain functions from your C library be present.
-
Up through release 3.0.2 the tests performed were too general, and - this feature was disabled when it did not need to be. The most - commonly reported platform affected was Solaris. -
-This has been fixed for 3.0.3 and onwards. -
- -_XOPEN_SOURCE / _GNU_SOURCE
- / etc is always definedOn Solaris, g++ (but not gcc) always defines the preprocessor
- macro _XOPEN_SOURCE. On GNU/Linux, the same happens
- with _GNU_SOURCE. (This is not an exhaustive list;
- other macros and other platforms are also affected.)
-
These macros are typically used in C library headers, guarding new - versions of functions from their older versions. The C++ standard - library includes the C standard library, but it requires the C90 - version, which for backwards-compatability reasons is often not the - default for many vendors. -
-More to the point, the C++ standard requires behavior which is only - available on certain platforms after certain symbols are defined. - Usually the issue involves I/O-related typedefs. In order to - ensure correctness, the compiler simply predefines those symbols. -
-Note that it's not enough to #define them only when the library is - being built (during installation). Since we don't have an 'export' - keyword, much of the library exists as headers, which means that - the symbols must also be defined as your programs are parsed and - compiled. -
-To see which symbols are defined, look for CPLUSPLUS_CPP_SPEC in
- the gcc config headers for your target (and try changing them to
- see what happens when building complicated code). You can also run
- "g++ -E -dM - < /dev/null" to display
- a list of predefined macros for any particular installation.
-
This has been discussed on the mailing lists - quite a bit. -
-This method is something of a wart. We'd like to find a cleaner - solution, but nobody yet has contributed the time. -
- -This is a long-standing bug in the OS X support. Fortunately, - the patch is quite simple, and well-known. - Here's a - link to the solution. -
- -Support for atomic integer operations is/was broken on i386 - platforms. The assembly code accidentally used opcodes that are - only available on the i486 and later. So if you configured GCC - to target, for example, i386-linux, but actually used the programs - on an i686, then you would encounter no problems. Only when - actually running the code on a i386 will the problem appear. -
-This is fixed in 3.2.2. -
- -For 3.0.1, the most common "bug" is an apparently missing
- "../" in include/Makefile, resulting in files
- like gthr.h and gthr-single.h not being found. Please read
- the configuration
- instructions for GCC,
- specifically the part about configuring in a separate build directory,
- and how strongly recommended it is. Building in the source directory
- is fragile, is rarely tested, and tends to break, as in this case.
- This was fixed for 3.0.2.
-
For 3.1, the most common "bug" is a parse error when using
- <fstream>, ending with a message,
- "bits/basic_file.h:52: parse error before `{'
- token." Please read
- the installation instructions for
- GCC, specifically the part about not installing newer versions on
- top of older versions. If you install 3.1 over a 3.0.x release, then
- the wrong basic_file.h header will be found (its location changed
- between releases).
-
Please do not report these as bugs. We know about them. - Reporting this -- or any other problem that's already been fixed -- - hinders the development of GCC, because we have to take time to - respond to your report. Thank you. -
- -This is a verbatim clip from the "Status" section - of the RELEASE-NOTES for the latest snapshot. For a list of - fixed bugs, see that file. -
- - - --New: ---- -(post 3.0.97) -- more doxygen documentation -- more named locale fixups -- stdio_filebuf that takes fd, FILE -- io performance tuning -- allocation tuning, valgrind fixups -- __cxa_demangle now supported -(3.0.97) -- more doxygen documentation. -- more named locale bug fixes -- support for symbol versioning when using GNU ld >= 2.12 -- wide-io -- tuning for executable size -(3.0.96) -- more doxygen documentation. -- extensions moved out of namespace std -- HPUX long long support -- more string optimizations -- support for NetBSD cross compiles -- concept_check merge from boost -- header simplification -- named locale bug shakeout -- thread testsuite -(3.0.95) -- add S390, m68k, x86-64 support. -- doxygen documentation has been extended, including man pages. -- verbose terminate handling has been added. -- some libsupc++ tweaks -- warnings for deprecated headers now active. -- dejagnu testsuite preliminary documentation. -- dejagnu testsuite default. -- dejagnu testsuite cross compiler, multilib safe. -- long long iostreams on by default, rework of ISO C99 support. -- iterator re-write and testsuites. -- container testsuites. -- allocator revamp and testsuites. -- more concept-checking work. -- basic_string optimization and MT fixes. -- new limits implementation. -- update -fno-exceptions code, verify it works. -- full named locale support fpr all facets, choice of gnu, - ieee_1003.1-200x (POSIX 2), or generic models. Full support depends - on target OS and underlying "C" library support. -- - -
This is by no means meant to be complete nor exhaustive, but - mentions some problems that users may encounter when building - or using libstdc++. If you are experiencing one of these - problems, you can find more information on the libstdc++ and - the GCC mailing lists. -
-Before reporting a bug, examine the - bugs database with the - category set to "libstdc++". The BUGS file in the source - tree also tracks known serious problems. -
---with-dwarf2 if the DWARF2
- debugging format is not already the default on your platform.
- Also,
-changing your
- GDB settings can have a profound effect on your C++ debugging
- experiences. :-)Yes, unfortunately, there are some. In a - message - to the list, Nathan Myers announced that he has started a list of - problems in the ISO C++ Standard itself, especially with - regard to the chapters that concern the library. The list - itself is - posted on his - website. Developers who are having problems interpreting - the Standard may wish to consult his notes. -
-For those people who are not part of the ISO Library Group - (i.e., nearly all of us needing to read this page in the first - place :-), a public list of the library defects is occasionally - published here. - Some of these have resulted in code changes. -
- -There are things which are not bugs in the compiler (4.2) nor - the language specification (4.3), but aren't really bugs in - libstdc++, either. Really! Please do not report these as bugs. -
--Weffc++
- The biggest of these is the quadzillions of warnings about the
- library headers emitted when -Weffc++ is used. Making
- libstdc++ "-Weffc++-clean" is not a goal of the project,
- for a few reasons. Mainly, that option tries to enforce
- object-oriented programming, while the Standard Library isn't
- necessarily trying to be OO.
-
reopening a stream fails - Did I just say that -Weffc++ was our biggest false-bug report? - I lied. (It used to be.) Today it seems to be reports that after - executing a sequence like -
-
- #include <fstream>
- ...
- std::fstream fs("a_file");
- // .
- // . do things with fs...
- // .
- fs.close();
- fs.open("a_new_file");
- all operations on the re-opened fs will fail, or at
- least act very strangely. Yes, they often will, especially if
- fs reached the EOF state on the previous file. The
- reason is that the state flags are not cleared
- on a successful call to open(). The standard unfortunately did
- not specify behavior in this case, and to everybody's great sorrow,
- the proposed LWG resolution (see
- DR #22) is to leave the flags unchanged. You must insert a call
- to fs.clear() between the calls to close() and open(),
- and then everything will work like we all expect it to work.
-
rel_ops
- Another is the rel_ops namespace and the template
- comparison operator functions contained therein. If they become
- visible in the same namespace as other comparison functions
- (e.g., 'using' them and the <iterator> header),
- then you will suddenly be faced with huge numbers of ambiguity
- errors. This was discussed on the -v3 list; Nathan Myers
- sums
- things up here. The collisions with vector/string iterator
- types have been fixed for 3.1.
-
If you have found an extremely broken header file which is - causing problems for you, look carefully before submitting a - "high" priority bug report (which you probably shouldn't - do anyhow; see the last paragraph of the page describing - the GCC bug database). -
-If the headers are in ${prefix}/include/g++-3, or if
- the installed library's name looks like libstdc++-2.10.a
- or libstdc++-libc6-2.10.so,
- then you are using the old libstdc++-v2 library, which is nonstandard
- and unmaintained. Do not report problems with -v2 to the -v3
- mailing list.
-
Currently our header files are installed in
- ${prefix}/include/g++-v3 (see the 'v'?). This may
- change with the next release of GCC, as it may be too confusing,
- but the
- question has not yet been decided.
-
glibc - If you're on a GNU/Linux system and have just upgraded to - glibc 2.2, but are still using gcc 2.95.2, then you should have - read the glibc FAQ, specifically 2.34: -
-
-2.34. When compiling C++ programs, I get a compilation error in streambuf.h.
-
-{BH} You are using g++ 2.95.2? After upgrading to glibc 2.2, you need to
-apply a patch to the include files in /usr/include/g++, because the fpos_t
-type has changed in glibc 2.2. The patch is at
-http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
-
- Note that 2.95.x shipped with the - old v2 library which is no longer - maintained. Also note that gcc 2.95.3 fixes this problem, but - requires a separate patch for libstdc++-v3. -
-concept checks
- If you see compilation errors containing messages about
- fooConcept and a constraints
- member function, then most likely you have violated one of the
- requirements for types used during instantiation of template
- containers and functions. For example, EqualityComparableConcept
- appears if your types must be comparable with == and you have not
- provided this capability (a typo, or wrong visibility, or you
- just plain forgot, etc).
-
More information, including how to optionally enable/disable the - checks, is available - here. -
-dlopen/dlsym - If you are using the C++ library across dynamically-loaded - objects, make certain that you are passing the correct options - when compiling and linking: -
-- // compile the library components - g++ -fPIC -c a.cc - g++ -fPIC -c b.cc - ... - g++ -fPIC -c z.cc - - // create the library - g++ -fPIC -shared -rdynamic -o libfoo.so a.o b.o ... z.o - - // link the executable - g++ -fPIC -rdynamic -o foo ... -L. -lfoo -ldl- -
If you have found a bug in the library and you think you have - a working fix, then send it in! The main GCC site has a page - on submitting - patches that covers the procedure, but for libstdc++ you - should also send the patch to our mailing list in addition to - the GCC patches mailing list. The libstdc++ - contributors' page - also talks about how to submit patches. -
-In addition to the description, the patch, and the ChangeLog - entry, it is a Good Thing if you can additionally create a small - test program to test for the presence of the bug that your - patch fixes. Bugs have a way of being reintroduced; if an old - bug creeps back in, it will be caught immediately by the - testsuite -- but only if such a test exists. -
- -If you have code that depends on container<T> iterators - being implemented as pointer-to-T, your code is broken. -
-While there are arguments for iterators to be implemented in
- that manner, A) they aren't very good ones in the long term,
- and B) they were never guaranteed by the Standard anyway. The
- type-safety achieved by making iterators a real class rather
- than a typedef for T* outweighs nearly all opposing
- arguments.
-
Code which does assume that a vector iterator i
- is a pointer can often be fixed by changing i in
- certain expressions to &*i . Future revisions
- of the Standard are expected to bless this usage for
- vector<> (but not for basic_string<>).
-
Hopefully, not much. The goal of libstdc++-v3 is to produce - a fully-compliant, fully-portable Standard Library. After that, - we're mostly done: there won't be any more compliance - work to do. However: -
-The ISO Committee will meet periodically to review Defect Reports - in the C++ Standard. Undoubtedly some of these will result in - changes to the Standard, which will be reflected in patches to - libstdc++. Some of that is already happening, see 4.2. Some of - those changes are being predicted by the library maintainers, and - we add code to the library based on what the current proposed - resolution specifies. Those additions are listed in - the extensions page. -
Performance tuning. Lots of performance tuning. This too is - already underway for post-3.0 releases, starting with memory - expansion in container classes and buffer usage in synchronized - stream objects. -
An ABI for libstdc++ is being developed, so that - multiple binary-incompatible copies of the library can be replaced - with a single backwards-compatible library, like libgcc_s.so is. -
The current libstdc++ contains extensions to the Library which - must be explicitly requested by client code (for example, the - hash tables from SGI). Other extensions may be added to - libstdc++-v3 if they seem to be "standard" enough. - (For example, the "long long" type from C99.) - Bugfixes and rewrites (to improve or fix thread safety, for - instance) will of course be a continuing task. -
This - question about the next libstdc++ prompted some brief but - interesting - speculation. -
- -The STL from SGI, - version 3.3, was the most recent merge of the STL codebase. The - code in libstdc++ contains many fixes and changes, and it is - very likely that the SGI code is no longer under active - development. We expect that no future merges will take place. -
-In particular, string is not from SGI and makes no
- use of their "rope" class (which is included as an
- optional extension), nor is valarray and some others.
- Classes like vector<> are, however.
-
The FAQ for SGI's STL (one jump off of their main page) is - recommended reading. -
- -Headers in the ext and backward
- subdirectories should be referred to by their relative paths:
-
-
- #include <ext/hash_map>-
rather than using -I or other options. This is more
- portable and forward-compatible. (The situation is the same as
- that of other headers whose directories are not searched directly,
- e.g., <sys/stat.h>, <X11/Xlib.h>.
-
The extensions are no longer in the global or std
- namespaces, instead they are declared in the __gnu_cxx
- namespace. For maximum portability, consider defining a namespace
- alias to use to talk about extensions, e.g.:
-
- #ifdef __GNUC__
- #if __GNUC__ < 3
- #include <hash_map.h>
- namespace Sgi { using ::hash_map; }; // inherit globals
- #else
- #include <ext/hash_map>
- #if __GNUC_MINOR__ == 0
- namespace Sgi = std; // GCC 3.0
- #else
- namespace Sgi = ::__gnu_cxx; // GCC 3.1 and later
- #endif
- #endif
- #else // ... there are other compilers, right?
- namespace Sgi = std;
- #endif
-
- Sgi::hash_map<int,int> my_map;
- This is a bit cleaner than defining typedefs for all the - instantiations you might need. -
- -Extensions to the library have - their own page. -
- -This question has become moot and has been removed. The stub - is here to preserve numbering (and hence links/bookmarks). -
- -When the system's libc is itself thread-safe, a non-generic - implementation of atomicity.h exists for the architecture, and gcc - itself reports a thread model other than single; libstdc++-v3 - strives to be thread-safe. The user-code must guard against - concurrent method calls which may access any particular library - object's state. Typically, the application programmer may infer - what object locks must be held based on the objects referenced in - a method call. Without getting into great detail, here is an - example which requires user-level locks: -
-
- library_class_a shared_object_a;
-
- thread_main () {
- library_class_b *object_b = new library_class_b;
- shared_object_a.add_b (object_b); // must hold lock for shared_object_a
- shared_object_a.mutate (); // must hold lock for shared_object_a
- }
-
- // Multiple copies of thread_main() are started in independent threads.
- Under the assumption that object_a and object_b are never exposed to - another thread, here is an example that should not require any - user-level locks: -
-
- thread_main () {
- library_class_a object_a;
- library_class_b *object_b = new library_class_b;
- object_a.add_b (object_b);
- object_a.mutate ();
- }
- All library objects are safe to use in a multithreaded program as - long as each thread carefully locks out access by any other thread - while it uses any object visible to another thread. In general, - this requirement includes both read and write access to objects; - unless otherwise documented as safe, do not assume that two - threads may access a shared standard library object at the - same time. -
-See chapters 17 (library - introduction), 23 - (containers), and 27 (I/O) for - more information. -
- -Copies of the full ISO 14882 standard are available on line via the - ISO mirror site for committee members. Non-members, or those who - have not paid for the privilege of sitting on the committee and - sustained their two-meeting commitment for voting rights, may get a - copy of the standard from their respective national standards - organization. In the USA, this national standards organization is - ANSI and their website is right here. - (And if you've already registered with them, clicking this link will - take you to directly to the place where you can -buy - the standard on-line. -
-Who is your country's member body? Visit the - ISO homepage and find out! -
- -"ABI" stands for "Application Binary Interface." - Conventionally, it refers to a great mass of details about how - arguments are arranged on the call stack and/or in registers, and - how various types are arranged and padded in structs. A single CPU - design may suffer multiple ABIs designed by different development - tool vendors who made different choices, or even by the same vendor - for different target applications or compiler versions. In ideal - circumstances the CPU designer presents one ABI and all the OSes and - compilers use it. In practice every ABI omits details that compiler - implementers (consciously or accidentally) must choose for themselves. -
-That ABI definition suffices for compilers to generate code so a - program can interact safely with an OS and its lowest-level libraries. - Users usually want an ABI to encompass more detail, allowing libraries - built with different compilers (or different releases of the same - compiler!) to be linked together. For C++, this includes many more - details than for C, and CPU designers (for good reasons elaborated - below) have not stepped up to publish C++ ABIs. The details include - virtual function implementation, struct inheritance layout, name - mangling, and exception handling. Such an ABI has been defined for - GNU C++, and is immediately useful for embedded work relying only on - a "free-standing implementation" that doesn't include (much - of) the standard library. It is a good basis for the work to come. -
-A useful C++ ABI must also incorporate many details of the standard - library implementation. For a C ABI, the layouts of a few structs - (such as FILE, stat, jmpbuf, and the like) and a few macros suffice. - For C++, the details include the complete set of names of functions - and types used, the offsets of class members and virtual functions, - and the actual definitions of all inlines. C++ exposes many more - library details to the caller than C does. It makes defining - a complete ABI a much bigger undertaking, and requires not just - documenting library implementation details, but carefully designing - those details so that future bug fixes and optimizations don't - force breaking the ABI. -
-There are ways to help isolate library implementation details from the - ABI, but they trade off against speed. Library details used in - inner loops (e.g., getchar) must be exposed and frozen for all - time, but many others may reasonably be kept hidden from user code, - so they may later be changed. Deciding which, and implementing - the decisions, must happen before you can reasonably document a - candidate C++ ABI that encompasses the standard library. -
- - - --See license.html for copying conditions. -Comments and suggestions are welcome, and may be sent to -the libstdc++ mailing list. -
- - - - -