gcc/libstdc++-v3/doc/html/faq.html - Issue 3050029: [gcc] GCC 4.5.0=>4.5.1

Unified Diff: gcc/libstdc++-v3/doc/html/faq.html

Issue 3050029: [gcc] GCC 4.5.0=>4.5.1 (Closed) Base URL: ssh://git@gitrw.chromium.org:9222/nacl-toolchain.git

Patch Set: Created 10 years, 5 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View side-by-side diff with in-line comments

Index: gcc/libstdc++-v3/doc/html/faq.html

diff --git a/gcc/libstdc++-v3/doc/html/faq.html b/gcc/libstdc++-v3/doc/html/faq.html

deleted file mode 100644

index 74fa9fa54b9e5869609e2570e6853658a7d45182..0000000000000000000000000000000000000000

--- a/gcc/libstdc++-v3/doc/html/faq.html

+++ /dev/null

@@ -1,874 +0,0 @@

-<?xml version="1.0" encoding="UTF-8" standalone="no"?>

-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Frequently Asked Questions</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><link rel="home" href="spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="bk03.html" title="" /><link rel="prev" href="bk03.html" title="" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Frequently Asked Questions</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="bk03.html">Prev</a> </td><th width="60%" align="center"></th><td width="20%" align="right"> </td></tr></table><hr /></div><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="faq"></a>Frequently Asked Questions</h2></div><div>Copyright ©

- 2008

- <a class="ulink" href="http://fsf.org" target="_top">FSF</a>

- </div></div><hr /></div><div class="qandaset"><dl><dt>1. <a href="faq.html#faq.info">General Information</a></dt><dd><dl><dt>1.1. <a href="faq.html#faq.what">

- What is libstdc++?

- </a></dt><dt>1.2. <a href="faq.html#faq.why">

- Why should I use libstdc++?

- </a></dt><dt>1.3. <a href="faq.html#faq.who">

- Who's in charge of it?

- </a></dt><dt>1.4. <a href="faq.html#faq.when">

- When is libstdc++ going to be finished?

- </a></dt><dt>1.5. <a href="faq.html#faq.how">

- How do I contribute to the effort?

- </a></dt><dt>1.6. <a href="faq.html#faq.whereis_old">

- What happened to the older libg++? I need that!

- </a></dt><dt>1.7. <a href="faq.html#faq.more_questions">

- What if I have more questions?

- </a></dt></dl></dd><dt>2. <a href="faq.html#faq.license">License</a></dt><dd><dl><dt>2.1. <a href="faq.html#faq.license.what">

- What are the license terms for libstdc++?

- </a></dt><dt>2.2. <a href="faq.html#faq.license.any_program">

- So any program which uses libstdc++ falls under the GPL?

- </a></dt><dt>2.3. <a href="faq.html#faq.license.lgpl">

- How is that different from the GNU {Lesser,Library} GPL?

- </a></dt><dt>2.4. <a href="faq.html#faq.license.what_restrictions">

- I see. So, what restrictions are there on programs that use the library?

- </a></dt></dl></dd><dt>3. <a href="faq.html#faq.installation">Installation</a></dt><dd><dl><dt>3.1. <a href="faq.html#faq.how_to_install">How do I install libstdc++?

- </a></dt><dt>3.2. <a href="faq.html#faq.how_to_get_sources">How does one get current libstdc++ sources?

- </a></dt><dt>3.3. <a href="faq.html#faq.how_to_test">How do I know if it works?

- </a></dt><dt>3.4. <a href="faq.html#faq.how_to_set_paths">How do I insure that the dynamically linked library will be found?

- </a></dt><dt>3.5. <a href="faq.html#faq.what_is_libsupcxx">

- What's libsupc++?

- </a></dt><dt>3.6. <a href="faq.html#faq.size">

- This library is HUGE!

- </a></dt></dl></dd><dt>4. <a href="faq.html#faq.platform-specific">Platform-Specific Issues</a></dt><dd><dl><dt>4.1. <a href="faq.html#faq.other_compilers">

- Can libstdc++ be used with non-GNU compilers?

- </a></dt><dt>4.2. <a href="faq.html#faq.solaris_long_long">

- No 'long long' type on Solaris?

- </a></dt><dt>4.3. <a href="faq.html#faq.predefined">

- _XOPEN_SOURCE and _GNU_SOURCE are always defined?

- </a></dt><dt>4.4. <a href="faq.html#faq.darwin_ctype">

- Mac OS X ctype.h is broken! How can I fix it?

- </a></dt><dt>4.5. <a href="faq.html#faq.threads_i386">

- Threading is broken on i386?

- </a></dt><dt>4.6. <a href="faq.html#faq.atomic_mips">

- MIPS atomic operations

- </a></dt><dt>4.7. <a href="faq.html#faq.linux_glibc">

- Recent GNU/Linux glibc required?

- </a></dt><dt>4.8. <a href="faq.html#faq.freebsd_wchar">

- Can't use wchar_t/wstring on FreeBSD

- </a></dt></dl></dd><dt>5. <a href="faq.html#faq.known_bugs">Known Bugs</a></dt><dd><dl><dt>5.1. <a href="faq.html#faq.what_works">

- What works already?

- </a></dt><dt>5.2. <a href="faq.html#faq.standard_bugs">

- Bugs in the ISO C++ language or library specification

- </a></dt><dt>5.3. <a href="faq.html#faq.compiler_bugs">

- Bugs in the compiler (gcc/g++) and not libstdc++

- </a></dt></dl></dd><dt>6. <a href="faq.html#faq.known_non-bugs">Known Non-Bugs</a></dt><dd><dl><dt>6.1. <a href="faq.html#faq.stream_reopening_fails">

- Reopening a stream fails

- </a></dt><dt>6.2. <a href="faq.html#faq.wefcxx_verbose">

- -Weffc++ complains too much

- </a></dt><dt>6.3. <a href="faq.html#faq.ambiguous_overloads">

- Ambiguous overloads after including an old-style header

- </a></dt><dt>6.4. <a href="faq.html#faq.v2_headers">

- The g++-3 headers are not ours

- </a></dt><dt>6.5. <a href="faq.html#faq.boost_concept_checks">

- Errors about *Concept and

- constraints in the STL

- </a></dt><dt>6.6. <a href="faq.html#faq.dlopen_crash">

- Program crashes when using library code in a

- dynamically-loaded library

- </a></dt><dt>6.7. <a href="faq.html#faq.memory_leaks">

- “Memory leaks” in containers

- </a></dt><dt>6.8. <a href="faq.html#faq.list_size_on">

- list::size() is O(n)!

- </a></dt><dt>6.9. <a href="faq.html#faq.easy_to_fix">

- Aw, that's easy to fix!

- </a></dt></dl></dd><dt>7. <a href="faq.html#faq.misc">Miscellaneous</a></dt><dd><dl><dt>7.1. <a href="faq.html#faq.iterator_as_pod">

- string::iterator is not char*; vector<T>::iterator is not T*

- </a></dt><dt>7.2. <a href="faq.html#faq.what_is_next">

- What's next after libstdc++?

- </a></dt><dt>7.3. <a href="faq.html#faq.sgi_stl">

- What about the STL from SGI?

- </a></dt><dt>7.4. <a href="faq.html#faq.extensions_and_backwards_compat">

- Extensions and Backward Compatibility

- </a></dt><dt>7.5. <a href="faq.html#faq.tr1_support">

- Does libstdc++ support TR1?

- </a></dt><dt>7.6. <a href="faq.html#faq.get_iso_cxx">How do I get a copy of the ISO C++ Standard?

- </a></dt><dt>7.7. <a href="faq.html#faq.what_is_abi">

- What's an ABI and why is it so messy?

- </a></dt><dt>7.8. <a href="faq.html#faq.size_equals_capacity">

- How do I make std::vector<T>::capacity() == std::vector<T>::size?

- </a></dt></dl></dd></dl><table border="0" summary="Q and A Set"><col align="left" width="1%" /><tbody><tr class="qandadiv"><td align="left" valign="top" colspan="2"><h3 class="title"><a id="faq.info"></a>1. General Information</h3></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>1.1. <a href="faq.html#faq.what">

- What is libstdc++?

- </a></dt><dt>1.2. <a href="faq.html#faq.why">

- Why should I use libstdc++?

- </a></dt><dt>1.3. <a href="faq.html#faq.who">

- Who's in charge of it?

- </a></dt><dt>1.4. <a href="faq.html#faq.when">

- When is libstdc++ going to be finished?

- </a></dt><dt>1.5. <a href="faq.html#faq.how">

- How do I contribute to the effort?

- </a></dt><dt>1.6. <a href="faq.html#faq.whereis_old">

- What happened to the older libg++? I need that!

- </a></dt><dt>1.7. <a href="faq.html#faq.more_questions">

- What if I have more questions?

- </a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.what"></a><a id="faq.what.q"></a>1.1.</td><td align="left" valign="top">

- What is libstdc++?

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="faq.what.a"></a></td><td align="left" valign="top">

- 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. 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 SVN, and can even be browsed over

- the <a class="ulink" href="http://gcc.gnu.org/svn.html" target="_top">web</a>.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.why"></a><a id="q-why"></a>1.2.</td><td align="left" valign="top">

- Why should I use libstdc++?

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-why"></a></td><td align="left" valign="top">

- 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 compiler collection

- (gcc, g++, etc) is widely

- considered to be one of the leading compilers in the world. Its

- development is overseen by the

- <a class="ulink" href="http://gcc.gnu.org/" target="_top">GCC team</a>. All of

- the rapid development and near-legendary

- <a class="ulink" href="http://gcc.gnu.org/buildstat.html" target="_top">portability</a>

- that are the hallmarks of an open-source project are being

- applied to libstdc++.

-

- That means that all of the Standard classes and functions will be

- freely available and fully compliant. (Such as

- <code class="classname">string</code>,

- <code class="classname">vector<></code>, iostreams, and algorithms.)

- Programmers will no longer need to “roll their own”

- nor be worried about platform-specific incompatibilities.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.who"></a><a id="q-who"></a>1.3.</td><td align="left" valign="top">

- Who's in charge of it?

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-who"></a></td><td align="left" valign="top">

- 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 SVN 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 <a class="ulink" href="http://gcc.gnu.org/libstdc++/" target="_top">homepage</a>.

- If you have questions, ideas, code, or are just curious, sign up!

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.when"></a><a id="q-when"></a>1.4.</td><td align="left" valign="top">

- When is libstdc++ going to be finished?

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-when"></a></td><td align="left" valign="top">

- Nathan Myers gave the best of all possible answers, responding to

- a Usenet article asking this question: Sooner, if you

- help.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.how"></a><a id="q-how"></a>1.5.</td><td align="left" valign="top">

- How do I contribute to the effort?

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how"></a></td><td align="left" valign="top">

- Here is <a class="link" href="manual/appendix_contributing.html" title="Appendix A. Contributing">a page devoted to

- this topic</a>. 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 and is

- willing to provide details, is more than welcome!

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.whereis_old"></a><a id="q-whereis_old"></a>1.6.</td><td align="left" valign="top">

- What happened to the older libg++? I need that!

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-whereis_old"></a></td><td align="left" valign="top">

- 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.

-

- More information in the <a class="link" href="manual/backwards.html" title="Backwards Compatibility">backwards compatibility documentation</a>

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.more_questions"></a><a id="q-more_questions"></a>1.7.</td><td align="left" valign="top">

- What if I have more questions?

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-more_questions"></a></td><td align="left" valign="top">

- If you have read the README file, 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 a message to the list,

- use <code class="email"><<a class="email" href="mailto:libstdc++@gcc.gnu.org">libstdc++@gcc.gnu.org</a>></code>.

-

- If you have a question that you think should be included

- here, or if you have a question about a question/answer

- here, please send email to the libstdc++ mailing list, as above.

- </td></tr><tr class="qandadiv"><td align="left" valign="top" colspan="2"><h3 class="title"><a id="faq.license"></a>2. License</h3></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>2.1. <a href="faq.html#faq.license.what">

- What are the license terms for libstdc++?

- </a></dt><dt>2.2. <a href="faq.html#faq.license.any_program">

- So any program which uses libstdc++ falls under the GPL?

- </a></dt><dt>2.3. <a href="faq.html#faq.license.lgpl">

- How is that different from the GNU {Lesser,Library} GPL?

- </a></dt><dt>2.4. <a href="faq.html#faq.license.what_restrictions">

- I see. So, what restrictions are there on programs that use the library?

- </a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.license.what"></a><a id="q-license.what"></a>2.1.</td><td align="left" valign="top">

- What are the license terms for libstdc++?

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-license.what"></a></td><td align="left" valign="top">

- See <a class="link" href="manual/license.html" title="License">our license description</a>

- for these and related questions.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.license.any_program"></a><a id="q-license.any_program"></a>2.2.</td><td align="left" valign="top">

- So any program which uses libstdc++ falls under the GPL?

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-license.any_program"></a></td><td align="left" valign="top">

- No. The special exception permits use of the library in

- proprietary applications.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.license.lgpl"></a><a id="q-license.lgpl"></a>2.3.</td><td align="left" valign="top">

- How is that different from the GNU {Lesser,Library} GPL?

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-license.lgpl"></a></td><td align="left" valign="top">

- The LGPL requires that users be able to replace the LGPL code with a

- modified version; this is trivial if the library in question is a C

- shared library. But there's no way to make that work with C++, where

- much of the library consists of inline functions and templates, which

- are expanded inside the code that uses the library. So to allow people

- to replace the library code, someone using the library would have to

- distribute their own source, rendering the LGPL equivalent to the GPL.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.license.what_restrictions"></a><a id="q-license.what_restrictions"></a>2.4.</td><td align="left" valign="top">

- I see. So, what restrictions are there on programs that use the library?

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-license.what_restrictions"></a></td><td align="left" valign="top">

- None. We encourage such programs to be released as open source,

- but we won't punish you or sue you if you choose otherwise.

- </td></tr><tr class="qandadiv"><td align="left" valign="top" colspan="2"><h3 class="title"><a id="faq.installation"></a>3. Installation</h3></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>3.1. <a href="faq.html#faq.how_to_install">How do I install libstdc++?

- </a></dt><dt>3.2. <a href="faq.html#faq.how_to_get_sources">How does one get current libstdc++ sources?

- </a></dt><dt>3.3. <a href="faq.html#faq.how_to_test">How do I know if it works?

- </a></dt><dt>3.4. <a href="faq.html#faq.how_to_set_paths">How do I insure that the dynamically linked library will be found?

- </a></dt><dt>3.5. <a href="faq.html#faq.what_is_libsupcxx">

- What's libsupc++?

- </a></dt><dt>3.6. <a href="faq.html#faq.size">

- This library is HUGE!

- </a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.how_to_install"></a><a id="q-how_to_install"></a>3.1.</td><td align="left" valign="top">How do I install libstdc++?

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how_to_install"></a></td><td align="left" valign="top">

- Often libstdc++ comes pre-installed as an integral part of many

- existing Linux and Unix systems, as well as many embedded

- development tools. It may be necessary to install extra

- development packages to get the headers, or the documentation, or

- the source: please consult your vendor for details.

-

- To build and install from the GNU GCC sources, please consult the

- <a class="link" href="manual/setup.html" title="Chapter 2. Setup">setup

- documentation</a> for detailed

- instructions. You may wish to browse those files ahead

- of time to get a feel for what's required.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.how_to_get_sources"></a><a id="q-how_to_get_sources"></a>3.2.</td><td align="left" valign="top">How does one get current libstdc++ sources?

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how_to_get_sources"></a></td><td align="left" valign="top">

- Libstdc++ sources for all official releases can be obtained as

- part of the GCC sources, available from various sites and

- mirrors. A full <a class="ulink" href="http://gcc.gnu.org/mirrors.html" target="_top">list of

- download sites</a> is provided on the main GCC site.

-

- Current libstdc++ sources can always be checked out of the main

- GCC source repository using the appropriate version control

- tool. At this time, that tool

- is Subversion.

-

- Subversion, or <acronym class="acronym">SVN</acronym>, 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 <a class="ulink" href="http://subversion.tigris.org" target="_top"> Subversion

- home page</a> has a better description.

-

- The “anonymous client checkout” feature of SVN is

- similar to anonymous FTP in that it allows anyone to retrieve

- the latest libstdc++ sources.

-

- For more information

- see <a class="ulink" href="http://gcc.gnu.org/svn.html" target="_top"><acronym class="acronym">SVN</acronym>

- details</a>.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.how_to_test"></a><a id="q-how_to_test"></a>3.3.</td><td align="left" valign="top">How do I know if it works?

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how_to_test"></a></td><td align="left" valign="top">

- Libstdc++ comes with its own validation testsuite, which includes

- conformance testing, regression testing, ABI testing, and

- performance testing. Please consult the

- <a class="ulink" href="http://gcc.gnu.org/install/test.html" target="_top">testing

- documentation</a> for more details.

-

- 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!

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.how_to_set_paths"></a><a id="q-how_to_set_paths"></a>3.4.</td><td align="left" valign="top">How do I insure that the dynamically linked library will be found?

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how_to_set_paths"></a></td><td align="left" valign="top">

- Depending on your platform and library version, the error message might

- be similar to one of the following:

- <pre class="screen">

- ./a.out: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

- /usr/libexec/ld-elf.so.1: Shared object "libstdc++.so.6" not found

- </pre>

- This doesn't mean that the shared library isn't installed, only

- that the dynamic linker can't find it. When a dynamically-linked

- executable is run the linker finds and loads the required shared

- libraries by searching a pre-configured list of directories. If

- the directory where you've installed libstdc++ is not in this list

- then the libraries won't be found. The simplest way to fix this is

- to use the <code class="literal">LD_LIBRARY_PATH</code> environment variable,

- which is a colon-separated list of directories in which the linker

- will search for shared libraries:

- <pre class="screen">

- LD_LIBRARY_PATH=${prefix}/lib:$LD_LIBRARY_PATH

- export LD_LIBRARY_PATH

- </pre>

- The exact environment variable to use will depend on your

- platform, e.g. DYLD_LIBRARY_PATH for Darwin,

- LD_LIBRARY_PATH_32/LD_LIBRARY_PATH_64 for Solaris 32-/64-bit,

- LD_LIBRARYN32_PATH/LD_LIBRARY64_PATH for Irix N32/64-bit ABIs and

- SHLIB_PATH for HP-UX.

-

- See the man pages for ld, ldd

- and ldconfig for more information. The dynamic

- linker has different names on different platforms but the man page

- is usually called something such as <code class="filename">ld.so/rtld/dld.so</code>.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.what_is_libsupcxx"></a><a id="q-what_is_libsupcxx"></a>3.5.</td><td align="left" valign="top">

- What's libsupc++?

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-what_is_libsupcxx"></a></td><td align="left" valign="top">

- If the only functions from <code class="filename">libstdc++.a</code>

- which you need are language support functions (those listed in

- <a class="link" href="manual/support.html" title="Part II. Support">clause 18</a> of the

- standard, e.g., <code class="function">new</code> and

- <code class="function">delete</code>), then try linking against

- <code class="filename">libsupc++.a</code>, which is a subset of

- <code class="filename">libstdc++.a</code>. (Using gcc

- instead of g++ and explicitly linking in

- <code class="filename">libsupc++.a</code> via <code class="literal">-lsupc++</code>

- 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

- <code class="filename">libstdc++.a</code>.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.size"></a><a id="q-size"></a>3.6.</td><td align="left" valign="top">

- This library is HUGE!

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-size"></a></td><td align="left" valign="top">

- 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++ 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

- <code class="literal">-static</code>, 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++ 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.

-

- On supported platforms, libstdc++ takes advantage of garbage

- collection in the GNU linker to get a result similar to separating

- each symbol into a separate source and object files. On these platforms,

- GNU ld 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.

- </td></tr><tr class="qandadiv"><td align="left" valign="top" colspan="2"><h3 class="title"><a id="faq.platform-specific"></a>4. Platform-Specific Issues</h3></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>4.1. <a href="faq.html#faq.other_compilers">

- Can libstdc++ be used with non-GNU compilers?

- </a></dt><dt>4.2. <a href="faq.html#faq.solaris_long_long">

- No 'long long' type on Solaris?

- </a></dt><dt>4.3. <a href="faq.html#faq.predefined">

- _XOPEN_SOURCE and _GNU_SOURCE are always defined?

- </a></dt><dt>4.4. <a href="faq.html#faq.darwin_ctype">

- Mac OS X ctype.h is broken! How can I fix it?

- </a></dt><dt>4.5. <a href="faq.html#faq.threads_i386">

- Threading is broken on i386?

- </a></dt><dt>4.6. <a href="faq.html#faq.atomic_mips">

- MIPS atomic operations

- </a></dt><dt>4.7. <a href="faq.html#faq.linux_glibc">

- Recent GNU/Linux glibc required?

- </a></dt><dt>4.8. <a href="faq.html#faq.freebsd_wchar">

- Can't use wchar_t/wstring on FreeBSD

- </a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.other_compilers"></a><a id="q-other_compilers"></a>4.1.</td><td align="left" valign="top">

- Can libstdc++ be used with non-GNU compilers?

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-other_compilers"></a></td><td align="left" valign="top">

- Perhaps.

-

- Since the goal of ISO Standardization is for all C++

- implementations to be able to share code, libstdc++ should be

- usable under any ISO-compliant compiler, at least in theory.

-

- However, the reality is that libstdc++ is targeted and optimized

- for GCC/g++. This means that often libstdc++ uses specific,

- non-standard features of g++ that are not present in older

- versions of proprietary compilers. It may take as much as a year or two

- after an official release of GCC that contains these features for

- proprietary tools support these constructs.

-

- In the near past, specific released versions of libstdc++ have

- been known to work with versions of the EDG C++ compiler, and

- vendor-specific proprietary C++ compilers such as the Intel ICC

- C++ compiler.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.solaris_long_long"></a><a id="q-solaris_long_long"></a>4.2.</td><td align="left" valign="top">

- No 'long long' type on Solaris?

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-solaris_long_long"></a></td><td align="left" valign="top">

- 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 platform-specific tests performed by

- libstdc++ were too general, resulting in a conservative approach

- to enabling the long long code paths. The most

- commonly reported platform affected was Solaris.

-

- This has been fixed for libstdc++ releases greater than 3.0.3.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.predefined"></a><a id="q-predefined"></a>4.3.</td><td align="left" valign="top">

- <code class="constant">_XOPEN_SOURCE</code> and <code class="constant">_GNU_SOURCE</code> are always defined?

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-predefined"></a></td><td align="left" valign="top">On Solaris, g++ (but not gcc) always defines the preprocessor

- macro <code class="constant">_XOPEN_SOURCE</code>. On GNU/Linux, the same happens

- with <code class="constant">_GNU_SOURCE</code>. (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-compatibility 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

- <a class="ulink" href="http://gcc.gnu.org/cgi-bin/htsearch?method=and&format=builtin-long&sort=score&words=_XOPEN_SOURCE+Solaris" target="_top">quite a bit</a>.

- This method is something of a wart. We'd like to find a cleaner

- solution, but nobody yet has contributed the time.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.darwin_ctype"></a><a id="q-darwin_ctype"></a>4.4.</td><td align="left" valign="top">

- Mac OS X <code class="filename">ctype.h</code> is broken! How can I fix it?

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-darwin_ctype"></a></td><td align="left" valign="top">This is a long-standing bug in the OS X support. Fortunately,

- the patch is quite simple, and well-known.

- <a class="ulink" href="http://gcc.gnu.org/ml/gcc/2002-03/msg00817.html" target="_top"> Here's a

- link to the solution</a>.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.threads_i386"></a><a id="q-threads_i386"></a>4.5.</td><td align="left" valign="top">

- Threading is broken on i386?

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-threads_i386"></a></td><td align="left" valign="top">

- 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.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.atomic_mips"></a><a id="q-atomic_mips"></a>4.6.</td><td align="left" valign="top">

- MIPS atomic operations

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-atomic_mips"></a></td><td align="left" valign="top">

- The atomic locking routines for MIPS targets requires MIPS II

- and later. A patch went in just after the 3.3 release to

- make mips* use the generic implementation instead. You can also

- configure for mipsel-elf as a workaround.

-

- The mips*-*-linux* port continues to use the MIPS II routines, and more

- work in this area is expected.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.linux_glibc"></a><a id="q-linux_glibc"></a>4.7.</td><td align="left" valign="top">

- Recent GNU/Linux glibc required?

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-linux_glibc"></a></td><td align="left" valign="top">When running on GNU/Linux, libstdc++ 3.2.1 (shared library version

- 5.0.1) and later uses localization and formatting code from the system

- C library (glibc) version 2.2.5. That version of glibc is over a

- year old and contains necessary bugfixes. Many GNU/Linux distros make

- glibc version 2.3.x available now.

- The guideline is simple: the more recent the C++ library, the

- more recent the C library. (This is also documented in the main

- GCC installation instructions.)

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.freebsd_wchar"></a><a id="q-freebsd_wchar"></a>4.8.</td><td align="left" valign="top">

- Can't use wchar_t/wstring on FreeBSD

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-freebsd_wchar"></a></td><td align="left" valign="top">

- Older versions of FreeBSD's C library do not have sufficient

- support for wide character functions, and as a result the

- libstdc++ configury decides that wchar_t support should be

- disabled. In addition, the libstdc++ platform checks that

- enabled wchar_t were quite strict, and not granular

- enough to detect when the minimal support to

- enable wchar_t and C++ library structures

- like <code class="classname">wstring</code> were present. This impacted Solaris,

- Darwin, and BSD variants, and is fixed in libstdc++ versions post 4.1.0.

-

- </td></tr><tr class="qandadiv"><td align="left" valign="top" colspan="2"><h3 class="title"><a id="faq.known_bugs"></a>5. Known Bugs</h3></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>5.1. <a href="faq.html#faq.what_works">

- What works already?

- </a></dt><dt>5.2. <a href="faq.html#faq.standard_bugs">

- Bugs in the ISO C++ language or library specification

- </a></dt><dt>5.3. <a href="faq.html#faq.compiler_bugs">

- Bugs in the compiler (gcc/g++) and not libstdc++

- </a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.what_works"></a><a id="q-what_works"></a>5.1.</td><td align="left" valign="top">

- What works already?

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-what_works"></a></td><td align="left" valign="top">

- Short answer: Pretty much everything works

- except for some corner cases. Support for localization

- in <code class="classname">locale</code> may be incomplete on non-GNU

- platforms. Also dependant on the underlying platform is support

- for wchar_t and long

- long specializations, and details of thread support.

-

- Long answer: See the implementation status pages for

- <a class="link" href="manual/status.html#manual.intro.status.standard.1998" title="C++ 1998/2003">C++98</a>,

- <a class="link" href="manual/status.html#manual.intro.status.standard.tr1" title="C++ TR1">TR1</a>, and

- <a class="link" href="manual/status.html#manual.intro.status.standard.200x" title="C++ 200x">C++0x</a>.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.standard_bugs"></a><a id="q-standard_bugs"></a>5.2.</td><td align="left" valign="top">

- Bugs in the ISO C++ language or library specification

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-standard_bugs"></a></td><td align="left" valign="top">

- Unfortunately, there are some.

-

- 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 <a class="ulink" href="http://anubis.dkuug.dk/jtc1/sc22/wg21/" target="_top">here</a>.

- Some of these issues have resulted in code changes in libstdc++.

-

- If you think you've discovered a new bug that is not listed,

- please post a message describing your problem

- to <code class="email"><<a class="email" href="mailto:libstdc++@gcc.gnu.org">libstdc++@gcc.gnu.org</a>></code> or the Usenet group

- comp.lang.c++.moderated.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.compiler_bugs"></a><a id="q-compiler_bugs"></a>5.3.</td><td align="left" valign="top">

- Bugs in the compiler (gcc/g++) and not libstdc++

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-compiler_bugs"></a></td><td align="left" valign="top">

- On occasion, the compiler is wrong. Please be advised that this

- happens much less often than one would think, and avoid jumping to

- conclusions.

-

- First, examine the ISO C++ standard. Second, try another compiler

- or an older version of the GNU compilers. Third, you can find more

- information on the libstdc++ and the GCC mailing lists: search

- these lists with terms describing your issue.

-

- Before reporting a bug, please examine the

- <a class="ulink" href="http://gcc.gnu.org/bugs.html" target="_top">bugs database</a> with the

- category set to “g++”.

- </td></tr><tr class="qandadiv"><td align="left" valign="top" colspan="2"><h3 class="title"><a id="faq.known_non-bugs"></a>6. Known Non-Bugs</h3></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>6.1. <a href="faq.html#faq.stream_reopening_fails">

- Reopening a stream fails

- </a></dt><dt>6.2. <a href="faq.html#faq.wefcxx_verbose">

- -Weffc++ complains too much

- </a></dt><dt>6.3. <a href="faq.html#faq.ambiguous_overloads">

- Ambiguous overloads after including an old-style header

- </a></dt><dt>6.4. <a href="faq.html#faq.v2_headers">

- The g++-3 headers are not ours

- </a></dt><dt>6.5. <a href="faq.html#faq.boost_concept_checks">

- Errors about *Concept and

- constraints in the STL

- </a></dt><dt>6.6. <a href="faq.html#faq.dlopen_crash">

- Program crashes when using library code in a

- dynamically-loaded library

- </a></dt><dt>6.7. <a href="faq.html#faq.memory_leaks">

- “Memory leaks” in containers

- </a></dt><dt>6.8. <a href="faq.html#faq.list_size_on">

- list::size() is O(n)!

- </a></dt><dt>6.9. <a href="faq.html#faq.easy_to_fix">

- Aw, that's easy to fix!

- </a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.stream_reopening_fails"></a><a id="q-stream_reopening_fails"></a>6.1.</td><td align="left" valign="top">

- Reopening a stream fails

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-stream_reopening_fails"></a></td><td align="left" valign="top">

- One of the most-reported non-bug reports. Executing a sequence like:

- <div class="literallayout">

- #include <fstream>

- ...

- std::fstream fs(“a_file”);

- // .

- // . do things with fs...

- // .

- fs.close();

- fs.open(“a_new_file”);

- </div>

- All operations on the re-opened <code class="varname">fs</code> will fail, or at

- least act very strangely. Yes, they often will, especially if

- <code class="varname">fs</code> 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 <a class="link" href="manual/bugs.html" title="Bugs">proposed LWG resolution in

- DR #22</a> is to leave the flags unchanged. You must insert a call

- to <code class="function">fs.clear()</code> between the calls to close() and open(),

- and then everything will work like we all expect it to work.

- Update: for GCC 4.0 we implemented the resolution

- of <a class="link" href="manual/bugs.html" title="Bugs">DR #409</a> and open()

- now calls <code class="function">clear()</code> on success!

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.wefcxx_verbose"></a><a id="q-wefcxx_verbose"></a>6.2.</td><td align="left" valign="top">

- -Weffc++ complains too much

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-wefcxx_verbose"></a></td><td align="left" valign="top">

- Many warnings are emitted when <code class="literal">-Weffc++</code> is used. Making

- libstdc++ <code class="literal">-Weffc++</code>-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.

-

- We do, however, try to have libstdc++ sources as clean as possible. If

- you see some simple changes that pacify <code class="literal">-Weffc++</code>

- without other drawbacks, send us a patch.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.ambiguous_overloads"></a><a id="q-ambiguous_overloads"></a>6.3.</td><td align="left" valign="top">

- Ambiguous overloads after including an old-style header

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-ambiguous_overloads"></a></td><td align="left" valign="top">

- Another problem is the <code class="literal">rel_ops</code> 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

- <a class="ulink" href="http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html" target="_top">sums

- things up here</a>. The collisions with vector/string iterator

- types have been fixed for 3.1.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.v2_headers"></a><a id="q-v2_headers"></a>6.4.</td><td align="left" valign="top">

- The g++-3 headers are not ours

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-v2_headers"></a></td><td align="left" valign="top">

- 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 <a class="ulink" href="http://gcc.gnu.org/bugs.html" target="_top">the GCC

- bug database</a>).

-

- If the headers are in <code class="filename">${prefix}/include/g++-3</code>, or

- if the installed library's name looks like

- <code class="filename">libstdc++-2.10.a</code> or

- <code class="filename">libstdc++-libc6-2.10.so</code>, 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.

-

- For GCC versions 3.0 and 3.1 the libstdc++ header files are

- installed in <code class="filename">${prefix}/include/g++-v3</code> (see the

- 'v'?). Starting with version 3.2 the headers are installed in

- <code class="filename">${prefix}/include/c++/${version}</code> as this prevents

- headers from previous versions being found by mistake.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.boost_concept_checks"></a><a id="q-boost_concept_checks"></a>6.5.</td><td align="left" valign="top">

- Errors about *Concept and

- constraints in the STL

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-boost_concept_checks"></a></td><td align="left" valign="top">

- If you see compilation errors containing messages about

- foo Concept and something to do with 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

- <a class="link" href="manual/bk01pt03ch08.html" title="Chapter 8. Concept Checking">here</a>.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.dlopen_crash"></a><a id="q-dlopen_crash"></a>6.6.</td><td align="left" valign="top">

- Program crashes when using library code in a

- dynamically-loaded library

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-dlopen_crash"></a></td><td align="left" valign="top">

- If you are using the C++ library across dynamically-loaded

- objects, make certain that you are passing the correct options

- when compiling and linking:

- <div class="literallayout">

- // compile your library components

- g++ -fPIC -c a.cc

- g++ -fPIC -c b.cc

- ...

- g++ -fPIC -c z.cc

-

- // create your 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

- </div></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.memory_leaks"></a><a id="q-memory_leaks"></a>6.7.</td><td align="left" valign="top">

- “Memory leaks” in containers

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-memory_leaks"></a></td><td align="left" valign="top">

- A few people have reported that the standard containers appear

- to leak memory when tested with memory checkers such as

- <a class="ulink" href="http://valgrind.org/" target="_top">valgrind</a>.

- The library's default allocators keep free memory in a pool

- for later reuse, rather than returning it to the OS. Although

- this memory is always reachable by the library and is never

- lost, memory debugging tools can report it as a leak. If you

- want to test the library for memory leaks please read

- <a class="link" href="manual/debug.html#debug.memory" title="Memory Leak Hunting">Tips for memory leak hunting</a>

- first.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.list_size_on"></a><a id="q-list_size_on"></a>6.8.</td><td align="left" valign="top">

- list::size() is O(n)!

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-list_size_on"></a></td><td align="left" valign="top">

- See

- the <a class="link" href="manual/containers.html" title="Part VII. Containers">Containers</a>

- chapter.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.easy_to_fix"></a><a id="q-easy_to_fix"></a>6.9.</td><td align="left" valign="top">

- Aw, that's easy to fix!

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-easy_to_fix"></a></td><td align="left" valign="top">

- 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 <a class="ulink" href="http://gcc.gnu.org/contribute.html" target="_top">submitting

- patches</a> 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++

- <a class="link" href="manual/appendix_contributing.html" title="Appendix A. Contributing">contributors' page</a>

- 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

- <a class="ulink" href="#2_4" target="_top">testsuite</a> -- but only if such a test exists.

- </td></tr><tr class="qandadiv"><td align="left" valign="top" colspan="2"><h3 class="title"><a id="faq.misc"></a>7. Miscellaneous</h3></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>7.1. <a href="faq.html#faq.iterator_as_pod">

- string::iterator is not char*; vector<T>::iterator is not T*

- </a></dt><dt>7.2. <a href="faq.html#faq.what_is_next">

- What's next after libstdc++?

- </a></dt><dt>7.3. <a href="faq.html#faq.sgi_stl">

- What about the STL from SGI?

- </a></dt><dt>7.4. <a href="faq.html#faq.extensions_and_backwards_compat">

- Extensions and Backward Compatibility

- </a></dt><dt>7.5. <a href="faq.html#faq.tr1_support">

- Does libstdc++ support TR1?

- </a></dt><dt>7.6. <a href="faq.html#faq.get_iso_cxx">How do I get a copy of the ISO C++ Standard?

- </a></dt><dt>7.7. <a href="faq.html#faq.what_is_abi">

- What's an ABI and why is it so messy?

- </a></dt><dt>7.8. <a href="faq.html#faq.size_equals_capacity">

- How do I make std::vector<T>::capacity() == std::vector<T>::size?

- </a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.iterator_as_pod"></a><a id="faq.iterator_as_pod_q"></a>7.1.</td><td align="left" valign="top">

- string::iterator is not char*; vector<T>::iterator is not T*

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="faq.iterator_as_pod_a"></a></td><td align="left" valign="top">

- If you have code that depends on container<T> iterators

- being implemented as pointer-to-T, your code is broken. It's

- considered a feature, not a bug, that libstdc++ points this out.

-

- 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 <code class="varname">i</code>

- is a pointer can often be fixed by changing <code class="varname">i</code> in

- certain expressions to <code class="varname">&*i</code>. Future revisions

- of the Standard are expected to bless this usage for

- vector<> (but not for basic_string<>).

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.what_is_next"></a><a id="q-what_is_next"></a>7.2.</td><td align="left" valign="top">

- What's next after libstdc++?

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-what_is_next"></a></td><td align="left" valign="top">

- Hopefully, not much. The goal of libstdc++ 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.

-

- There is an effort underway to add significant extensions to

- the standard library specification. The latest version of

- this effort is described in

- <a class="ulink" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf" target="_top">

- The C++ Library Technical Report 1</a>.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.sgi_stl"></a><a id="q-sgi_stl"></a>7.3.</td><td align="left" valign="top">

- What about the STL from SGI?

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-sgi_stl"></a></td><td align="left" valign="top">

- The <a class="ulink" href="http://www.sgi.com/tech/stl/" target="_top">STL from SGI</a>,

- version 3.3, was the final merge of the STL codebase. The

- code in libstdc++ contains many fixes and changes, and

- the SGI code is no longer under active

- development. We expect that no future merges will take place.

-

- In particular, <code class="classname">string</code> is not from SGI and makes no

- use of their "rope" class (which is included as an

- optional extension), nor is <code class="classname">valarray</code> and some others.

- Classes like <code class="classname">vector<></code> are, but have been

- extensively modified.

-

- More information on the evolution of libstdc++ can be found at the

- <a class="link" href="manual/api.html" title="API Evolution and Deprecation History">API

- evolution</a>

- and <a class="link" href="manual/backwards.html" title="Backwards Compatibility">backwards

- compatibility</a> documentation.

-

- The FAQ for SGI's STL (one jump off of their main page) is

- still recommended reading.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.extensions_and_backwards_compat"></a><a id="q-extensions_and_backwards_compat"></a>7.4.</td><td align="left" valign="top">

- Extensions and Backward Compatibility

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-extensions_and_backwards_compat"></a></td><td align="left" valign="top">

- See the <a class="link" href="manual/backwards.html" title="Backwards Compatibility">link</a> on backwards compatibility and <a class="link" href="manual/api.html" title="API Evolution and Deprecation History">link</a> on evolution.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.tr1_support"></a><a id="q-tr1_support"></a>7.5.</td><td align="left" valign="top">

- Does libstdc++ support TR1?

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-tr1_support"></a></td><td align="left" valign="top">

- Yes.

-

- The C++ Standard Library Technical Report adds many new features to

- the library. The latest version of this effort is described in

- <a class="ulink" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf" target="_top">

- Technical Report 1</a>.

-

- The implementation status of TR1 in libstdc++ can be tracked <a class="link" href="manual/status.html#manual.intro.status.standard.tr1" title="C++ TR1">on the TR1 status

- page</a>.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.get_iso_cxx"></a><a id="q-get_iso_cxx"></a>7.6.</td><td align="left" valign="top">How do I get a copy of the ISO C++ Standard?

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-get_iso_cxx"></a></td><td align="left" valign="top">

- 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 <a class="ulink" href="http://www.ansi.org" target="_top">here</a>. (And if

- you've already registered with them, clicking this link will take

- you to directly to the place where you can

- <a class="ulink" href="http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%3A2003" target="_top">buy the standard on-line</a>.

-

- Who is your country's member body? Visit the

- <a class="ulink" href="http://www.iso.ch/" target="_top">ISO homepage</a> and find out!

-

- The 2003 version of the standard (the 1998 version plus TC1) is

- available in print, ISBN 0-470-84674-7.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.what_is_abi"></a><a id="q-what_is_abi"></a>7.7.</td><td align="left" valign="top">

- What's an ABI and why is it so messy?

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-what_is_abi"></a></td><td align="left" valign="top">

- <acronym class="acronym">ABI</acronym> 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.

- </td></tr><tr class="question"><td align="left" valign="top"><a id="faq.size_equals_capacity"></a><a id="q-size_equals_capacity"></a>7.8.</td><td align="left" valign="top">

- How do I make std::vector<T>::capacity() == std::vector<T>::size?

- </td></tr><tr class="answer"><td align="left" valign="top"><a id="a-size_equals_capacity"></a></td><td align="left" valign="top">

- The standard idiom for deallocating a <code class="classname">vector<T></code>'s

- unused memory is to create a temporary copy of the vector and swap their

- contents, e.g. for <code class="classname">vector<T> v</code>

- <div class="literallayout">

- std::vector<T>(v).swap(v);

- </div>

- The copy will take O(n) time and the swap is constant time.

-

- See <a class="link" href="manual/bk01pt05ch13s05.html" title="Shrink to Fit">Shrink-to-fit

- strings</a> for a similar solution for strings.

- </td></tr></tbody></table></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="bk03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="bk03.html">Up</a></td><td width="40%" align="right"> </td></tr><tr><td width="40%" align="left" valign="top"> </td><td width="20%" align="center"><a accesskey="h" href="spine.html">Home</a></td><td width="40%" align="right" valign="top"> </td></tr></table></div></body></html>

« no previous file with comments | « gcc/libstdc++-v3/doc/html/ext/pb_ds/update_policy_cd.png ('k') | gcc/libstdc++-v3/doc/html/index.html » ('j') | no next file with comments »