diff options
| author | upstream source tree <ports@midipix.org> | 2015-03-15 20:14:05 -0400 |
|---|---|---|
| committer | upstream source tree <ports@midipix.org> | 2015-03-15 20:14:05 -0400 |
| commit | 554fd8c5195424bdbcabf5de30fdc183aba391bd (patch) | |
| tree | 976dc5ab7fddf506dadce60ae936f43f58787092 /libstdc++-v3/doc/html/faq.html | |
| download | cbb-gcc-4.6.4-554fd8c5195424bdbcabf5de30fdc183aba391bd.tar.bz2 cbb-gcc-4.6.4-554fd8c5195424bdbcabf5de30fdc183aba391bd.tar.xz | |
obtained gcc-4.6.4.tar.bz2 from upstream website;upstream
verified gcc-4.6.4.tar.bz2.sig;
imported gcc-4.6.4 source tree from verified upstream tarball.
downloading a git-generated archive based on the 'upstream' tag
should provide you with a source tree that is binary identical
to the one extracted from the above tarball.
if you have obtained the source via the command 'git clone',
however, do note that line-endings of files in your working
directory might differ from line-endings of the respective
files in the upstream repository.
Diffstat (limited to 'libstdc++-v3/doc/html/faq.html')
| -rw-r--r-- | libstdc++-v3/doc/html/faq.html | 872 |
1 files changed, 872 insertions, 0 deletions
diff --git a/libstdc++-v3/doc/html/faq.html b/libstdc++-v3/doc/html/faq.html new file mode 100644 index 000000000..7b333ed75 --- /dev/null +++ b/libstdc++-v3/doc/html/faq.html @@ -0,0 +1,872 @@ +<?xml version="1.0" encoding="UTF-8" standalone="no"?> +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> +<html xmlns="http://www.w3.org/1999/xhtml"><head><title>Frequently Asked Questions</title><meta name="generator" content="DocBook XSL-NS Stylesheets V1.76.1"/><link rel="home" href="spine.html" title="The GNU C++ Library"/><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 align="left"><a accesskey="p" href="bk03.html">Prev</a> </td><th width="60%" align="center"/><td align="right"> </td></tr></table><hr/></div><div class="article" title="Frequently Asked Questions"><div class="titlepage"><div><div><h1 class="title"><a id="faq"/>Frequently Asked Questions</h1></div><div><p class="copyright">Copyright © + 2008, 2010 + + <a class="link" href="http://www.fsf.org">FSF</a> + </p></div></div><hr/></div><div class="qandaset" title="Frequently Asked Questions"><a id="id384449"/><dl><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/><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/><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/><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/><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/><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/><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" width="100%" summary="Q and A Set"><col align="left" width="1%"/><col/><tbody><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" title="1.1."><td align="left" valign="top"><a id="faq.what"/><a id="faq.what.q"/><p><strong>1.1.</strong></p></td><td align="left" valign="top"><p> + What is libstdc++? + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="faq.what.a"/></td><td align="left" valign="top"><p> + 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="link" href="http://gcc.gnu.org/svn.html">web</a>. + </p></td></tr><tr class="question" title="1.2."><td align="left" valign="top"><a id="faq.why"/><a id="q-why"/><p><strong>1.2.</strong></p></td><td align="left" valign="top"><p> + Why should I use libstdc++? + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-why"/></td><td align="left" valign="top"><p> + 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) <span class="quote">“<span class="quote">incomplet and + incorrekt</span>”</span>, and many suffer from limitations of the compilers + that use them. + </p><p> + The GNU compiler collection + (<span class="command"><strong>gcc</strong></span>, <span class="command"><strong>g++</strong></span>, etc) is widely + considered to be one of the leading compilers in the world. Its + development is overseen by the + <a class="link" href="http://gcc.gnu.org/">GCC team</a>. All of + the rapid development and near-legendary + <a class="link" href="http://gcc.gnu.org/buildstat.html">portability</a> + that are the hallmarks of an open-source project are being + applied to libstdc++. + </p><p> + 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 <span class="quote">“<span class="quote">roll their own</span>”</span> + nor be worried about platform-specific incompatibilities. + </p></td></tr><tr class="question" title="1.3."><td align="left" valign="top"><a id="faq.who"/><a id="q-who"/><p><strong>1.3.</strong></p></td><td align="left" valign="top"><p> + Who's in charge of it? + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-who"/></td><td align="left" valign="top"><p> + 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. + </p><p> + 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="link" href="http://gcc.gnu.org/libstdc++/">homepage</a>. + If you have questions, ideas, code, or are just curious, sign up! + </p></td></tr><tr class="question" title="1.4."><td align="left" valign="top"><a id="faq.when"/><a id="q-when"/><p><strong>1.4.</strong></p></td><td align="left" valign="top"><p> + When is libstdc++ going to be finished? + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-when"/></td><td align="left" valign="top"><p> + Nathan Myers gave the best of all possible answers, responding to + a Usenet article asking this question: <span class="emphasis"><em>Sooner, if you + help.</em></span> + </p></td></tr><tr class="question" title="1.5."><td align="left" valign="top"><a id="faq.how"/><a id="q-how"/><p><strong>1.5.</strong></p></td><td align="left" valign="top"><p> + How do I contribute to the effort? + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how"/></td><td align="left" valign="top"><p> + 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! + </p></td></tr><tr class="question" title="1.6."><td align="left" valign="top"><a id="faq.whereis_old"/><a id="q-whereis_old"/><p><strong>1.6.</strong></p></td><td align="left" valign="top"><p> + What happened to the older libg++? I need that! + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-whereis_old"/></td><td align="left" valign="top"><p> + 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. + </p><p> + More information in the <a class="link" href="manual/backwards.html" title="Backwards Compatibility">backwards compatibility documentation</a> + </p></td></tr><tr class="question" title="1.7."><td align="left" valign="top"><a id="faq.more_questions"/><a id="q-more_questions"/><p><strong>1.7.</strong></p></td><td align="left" valign="top"><p> + What if I have more questions? + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-more_questions"/></td><td align="left" valign="top"><p> + 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>. + </p><p> + If you have a question that you think should be included + here, or if you have a question <span class="emphasis"><em>about</em></span> a question/answer + here, please send email to the libstdc++ mailing list, as above. + </p></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" title="2.1."><td align="left" valign="top"><a id="faq.license.what"/><a id="q-license.what"/><p><strong>2.1.</strong></p></td><td align="left" valign="top"><p> + What are the license terms for libstdc++? + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-license.what"/></td><td align="left" valign="top"><p> + See <a class="link" href="manual/license.html" title="License">our license description</a> + for these and related questions. + </p></td></tr><tr class="question" title="2.2."><td align="left" valign="top"><a id="faq.license.any_program"/><a id="q-license.any_program"/><p><strong>2.2.</strong></p></td><td align="left" valign="top"><p> + So any program which uses libstdc++ falls under the GPL? + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-license.any_program"/></td><td align="left" valign="top"><p> + No. The special exception permits use of the library in + proprietary applications. + </p></td></tr><tr class="question" title="2.3."><td align="left" valign="top"><a id="faq.license.lgpl"/><a id="q-license.lgpl"/><p><strong>2.3.</strong></p></td><td align="left" valign="top"><p> + How is that different from the GNU {Lesser,Library} GPL? + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-license.lgpl"/></td><td align="left" valign="top"><p> + 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. + </p></td></tr><tr class="question" title="2.4."><td align="left" valign="top"><a id="faq.license.what_restrictions"/><a id="q-license.what_restrictions"/><p><strong>2.4.</strong></p></td><td align="left" valign="top"><p> + I see. So, what restrictions are there on programs that use the library? + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-license.what_restrictions"/></td><td align="left" valign="top"><p> + None. We encourage such programs to be released as open source, + but we won't punish you or sue you if you choose otherwise. + </p></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" title="3.1."><td align="left" valign="top"><a id="faq.how_to_install"/><a id="q-how_to_install"/><p><strong>3.1.</strong></p></td><td align="left" valign="top"><p>How do I install libstdc++? + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how_to_install"/></td><td align="left" valign="top"><p> + 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. + </p><p> + 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. + </p></td></tr><tr class="question" title="3.2."><td align="left" valign="top"><a id="faq.how_to_get_sources"/><a id="q-how_to_get_sources"/><p><strong>3.2.</strong></p></td><td align="left" valign="top"><p>How does one get current libstdc++ sources? + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how_to_get_sources"/></td><td align="left" valign="top"><p> + 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="link" href="http://gcc.gnu.org/mirrors.html">list of + download sites</a> is provided on the main GCC site. + </p><p> + 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 <span class="application">Subversion</span>. + </p><p> + <span class="application">Subversion</span>, 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="link" href="http://subversion.tigris.org"> Subversion + home page</a> has a better description. + </p><p> + The <span class="quote">“<span class="quote">anonymous client checkout</span>”</span> feature of SVN is + similar to anonymous FTP in that it allows anyone to retrieve + the latest libstdc++ sources. + </p><p> + For more information + see <a class="link" href="http://gcc.gnu.org/svn.html"><acronym class="acronym">SVN</acronym> + details</a>. + </p></td></tr><tr class="question" title="3.3."><td align="left" valign="top"><a id="faq.how_to_test"/><a id="q-how_to_test"/><p><strong>3.3.</strong></p></td><td align="left" valign="top"><p>How do I know if it works? + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how_to_test"/></td><td align="left" valign="top"><p> + Libstdc++ comes with its own validation testsuite, which includes + conformance testing, regression testing, ABI testing, and + performance testing. Please consult the + <a class="link" href="http://gcc.gnu.org/install/test.html">testing + documentation</a> for more details. + </p><p> + 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, + <span class="emphasis"><em>please</em></span> write up your idea and send it to the list! + </p></td></tr><tr class="question" title="3.4."><td align="left" valign="top"><a id="faq.how_to_set_paths"/><a id="q-how_to_set_paths"/><p><strong>3.4.</strong></p></td><td align="left" valign="top"><p>How do I insure that the dynamically linked library will be found? + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-how_to_set_paths"/></td><td align="left" valign="top"><p> + Depending on your platform and library version, the error message might + be similar to one of the following: + </p><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><p> + 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: + </p><pre class="screen"> + LD_LIBRARY_PATH=${prefix}/lib:$LD_LIBRARY_PATH + export LD_LIBRARY_PATH + </pre><p> + 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. + </p><p> + See the man pages for <span class="command"><strong>ld</strong></span>, <span class="command"><strong>ldd</strong></span> + and <span class="command"><strong>ldconfig</strong></span> 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>. + </p><p> + Using LD_LIBRARY_PATH is not always the best solution, <a class="link" href="manual/using_dynamic_or_shared.html#manual.intro.using.linkage.dynamic" title="Finding Dynamic or Shared Libraries">Finding Dynamic or Shared + Libraries</a> in the manual gives some alternatives. + </p></td></tr><tr class="question" title="3.5."><td align="left" valign="top"><a id="faq.what_is_libsupcxx"/><a id="q-what_is_libsupcxx"/><p><strong>3.5.</strong></p></td><td align="left" valign="top"><p> + What's libsupc++? + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-what_is_libsupcxx"/></td><td align="left" valign="top"><p> + 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="Chapter 4. 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 <span class="command"><strong>gcc</strong></span> + instead of <span class="command"><strong>g++</strong></span> 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>. + </p></td></tr><tr class="question" title="3.6."><td align="left" valign="top"><a id="faq.size"/><a id="q-size"/><p><strong>3.6.</strong></p></td><td align="left" valign="top"><p> + This library is HUGE! + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-size"/></td><td align="left" valign="top"><p> + Usually the size of libraries on disk isn't noticeable. When a + link editor (or simply <span class="quote">“<span class="quote">linker</span>”</span>) 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.) + </p><p> + 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. + </p><p> + 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. + </p></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" title="4.1."><td align="left" valign="top"><a id="faq.other_compilers"/><a id="q-other_compilers"/><p><strong>4.1.</strong></p></td><td align="left" valign="top"><p> + Can libstdc++ be used with non-GNU compilers? + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-other_compilers"/></td><td align="left" valign="top"><p> + Perhaps. + </p><p> + 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. + </p><p> + 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 to support these constructs. + </p><p> + 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. + </p></td></tr><tr class="question" title="4.2."><td align="left" valign="top"><a id="faq.solaris_long_long"/><a id="q-solaris_long_long"/><p><strong>4.2.</strong></p></td><td align="left" valign="top"><p> + No 'long long' type on Solaris? + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-solaris_long_long"/></td><td align="left" valign="top"><p> + By default we try to support the C99 <span class="type">long long</span> type. + This requires that certain functions from your C library be present. + </p><p> + Up through release 3.0.2 the platform-specific tests performed by + libstdc++ were too general, resulting in a conservative approach + to enabling the <span class="type">long long</span> code paths. The most + commonly reported platform affected was Solaris. + </p><p> + This has been fixed for libstdc++ releases greater than 3.0.3. + </p></td></tr><tr class="question" title="4.3."><td align="left" valign="top"><a id="faq.predefined"/><a id="q-predefined"/><p><strong>4.3.</strong></p></td><td align="left" valign="top"><p> + <code class="constant">_XOPEN_SOURCE</code> and <code class="constant">_GNU_SOURCE</code> are always defined? + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-predefined"/></td><td align="left" valign="top"><p>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.) + </p><p>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. + </p><p>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. + </p><p>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. + </p><p>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 + <span class="command"><strong>g++ -E -dM - < /dev/null"</strong></span> to display + a list of predefined macros for any particular installation. + </p><p>This has been discussed on the mailing lists + <a class="link" href="http://gcc.gnu.org/cgi-bin/htsearch?method=and&format=builtin-long&sort=score&words=_XOPEN_SOURCE+Solaris">quite a bit</a>. + </p><p>This method is something of a wart. We'd like to find a cleaner + solution, but nobody yet has contributed the time. + </p></td></tr><tr class="question" title="4.4."><td align="left" valign="top"><a id="faq.darwin_ctype"/><a id="q-darwin_ctype"/><p><strong>4.4.</strong></p></td><td align="left" valign="top"><p> + Mac OS X <code class="filename">ctype.h</code> is broken! How can I fix it? + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-darwin_ctype"/></td><td align="left" valign="top"><p>This is a long-standing bug in the OS X support. Fortunately, + the patch is quite simple, and well-known. + <a class="link" href="http://gcc.gnu.org/ml/gcc/2002-03/msg00817.html"> Here's a + link to the solution</a>. + </p></td></tr><tr class="question" title="4.5."><td align="left" valign="top"><a id="faq.threads_i386"/><a id="q-threads_i386"/><p><strong>4.5.</strong></p></td><td align="left" valign="top"><p> + Threading is broken on i386? + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-threads_i386"/></td><td align="left" valign="top"><p> + </p><p>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. + </p><p>This is fixed in 3.2.2. + </p></td></tr><tr class="question" title="4.6."><td align="left" valign="top"><a id="faq.atomic_mips"/><a id="q-atomic_mips"/><p><strong>4.6.</strong></p></td><td align="left" valign="top"><p> + MIPS atomic operations + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-atomic_mips"/></td><td align="left" valign="top"><p> + 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. + </p><p> + The mips*-*-linux* port continues to use the MIPS II routines, and more + work in this area is expected. + </p></td></tr><tr class="question" title="4.7."><td align="left" valign="top"><a id="faq.linux_glibc"/><a id="q-linux_glibc"/><p><strong>4.7.</strong></p></td><td align="left" valign="top"><p> + Recent GNU/Linux glibc required? + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-linux_glibc"/></td><td align="left" valign="top"><p>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 which contains necessary bugfixes. + Most GNU/Linux distros make more recent versions available now. + libstdc++ 4.6.0 and later require glibc 2.3 or later for this + localization and formatting code. + </p><p>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.) + </p></td></tr><tr class="question" title="4.8."><td align="left" valign="top"><a id="faq.freebsd_wchar"/><a id="q-freebsd_wchar"/><p><strong>4.8.</strong></p></td><td align="left" valign="top"><p> + Can't use wchar_t/wstring on FreeBSD + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-freebsd_wchar"/></td><td align="left" valign="top"><p> + 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 <span class="type">wchar_t</span> were quite strict, and not granular + enough to detect when the minimal support to + enable <span class="type">wchar_t</span> 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. + </p><p> + </p></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" title="5.1."><td align="left" valign="top"><a id="faq.what_works"/><a id="q-what_works"/><p><strong>5.1.</strong></p></td><td align="left" valign="top"><p> + What works already? + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-what_works"/></td><td align="left" valign="top"><p> + Short answer: Pretty much everything <span class="emphasis"><em>works</em></span> + 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 <span class="type">wchar_t</span> and <span class="type">long + long</span> specializations, and details of thread support. + </p><p> + Long answer: See the implementation status pages for + <a class="link" href="manual/status.html#status.iso.1998" title="C++ 1998/2003">C++98</a>, + <a class="link" href="manual/status.html#status.iso.tr1" title="C++ TR1">TR1</a>, and + <a class="link" href="manual/status.html#status.iso.200x" title="C++ 200x">C++0x</a>. + </p></td></tr><tr class="question" title="5.2."><td align="left" valign="top"><a id="faq.standard_bugs"/><a id="q-standard_bugs"/><p><strong>5.2.</strong></p></td><td align="left" valign="top"><p> + Bugs in the ISO C++ language or library specification + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-standard_bugs"/></td><td align="left" valign="top"><p> + Unfortunately, there are some. + </p><p> + 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="link" href="http://www.open-std.org/jtc1/sc22/wg21/">here</a>. + Some of these issues have resulted in code changes in libstdc++. + </p><p> + 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. + </p></td></tr><tr class="question" title="5.3."><td align="left" valign="top"><a id="faq.compiler_bugs"/><a id="q-compiler_bugs"/><p><strong>5.3.</strong></p></td><td align="left" valign="top"><p> + Bugs in the compiler (gcc/g++) and not libstdc++ + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-compiler_bugs"/></td><td align="left" valign="top"><p> + On occasion, the compiler is wrong. Please be advised that this + happens much less often than one would think, and avoid jumping to + conclusions. + </p><p> + 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. + </p><p> + Before reporting a bug, please examine the + <a class="link" href="http://gcc.gnu.org/bugs/">bugs database</a> with the + category set to <span class="quote">“<span class="quote">g++</span>”</span>. + </p></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" title="6.1."><td align="left" valign="top"><a id="faq.stream_reopening_fails"/><a id="q-stream_reopening_fails"/><p><strong>6.1.</strong></p></td><td align="left" valign="top"><p> + Reopening a stream fails + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-stream_reopening_fails"/></td><td align="left" valign="top"><p> + One of the most-reported non-bug reports. Executing a sequence like: + </p><div class="literallayout"><p><br/> + #include <fstream><br/> + ...<br/> + std::fstream fs(<span class="quote">“<span class="quote">a_file</span>”</span>);<br/> + // .<br/> + // . do things with fs...<br/> + // .<br/> + fs.close();<br/> + fs.open(<span class="quote">“<span class="quote">a_new_file</span>”</span>);<br/> + </p></div><p> + 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 <span class="emphasis"><em>not</em></span> 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. + <span class="emphasis"><em>Update:</em></span> 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! + </p></td></tr><tr class="question" title="6.2."><td align="left" valign="top"><a id="faq.wefcxx_verbose"/><a id="q-wefcxx_verbose"/><p><strong>6.2.</strong></p></td><td align="left" valign="top"><p> + -Weffc++ complains too much + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-wefcxx_verbose"/></td><td align="left" valign="top"><p> + 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. + </p><p> + 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. + </p></td></tr><tr class="question" title="6.3."><td align="left" valign="top"><a id="faq.ambiguous_overloads"/><a id="q-ambiguous_overloads"/><p><strong>6.3.</strong></p></td><td align="left" valign="top"><p> + Ambiguous overloads after including an old-style header + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-ambiguous_overloads"/></td><td align="left" valign="top"><p> + 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., <span class="quote">“<span class="quote">using</span>”</span> 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="link" href="http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html">sums + things up here</a>. The collisions with vector/string iterator + types have been fixed for 3.1. + </p></td></tr><tr class="question" title="6.4."><td align="left" valign="top"><a id="faq.v2_headers"/><a id="q-v2_headers"/><p><strong>6.4.</strong></p></td><td align="left" valign="top"><p> + The g++-3 headers are <span class="emphasis"><em>not ours</em></span> + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-v2_headers"/></td><td align="left" valign="top"><p> + If you are using headers 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. + </p><p> + 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. + </p></td></tr><tr class="question" title="6.5."><td align="left" valign="top"><a id="faq.boost_concept_checks"/><a id="q-boost_concept_checks"/><p><strong>6.5.</strong></p></td><td align="left" valign="top"><p> + Errors about <span class="emphasis"><em>*Concept</em></span> and + <span class="emphasis"><em>constraints</em></span> in the STL + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-boost_concept_checks"/></td><td align="left" valign="top"><p> + If you see compilation errors containing messages about + <span class="errortext">foo Concept </span>and something to do with a + <span class="errortext">constraints</span> 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). + </p><p> + More information, including how to optionally enable/disable the + checks, is available in the + <a class="link" href="manual/bk01pt02ch05s02.html" title="Concept Checking">Diagnostics</a>. + chapter of the manual. + </p></td></tr><tr class="question" title="6.6."><td align="left" valign="top"><a id="faq.dlopen_crash"/><a id="q-dlopen_crash"/><p><strong>6.6.</strong></p></td><td align="left" valign="top"><p> + Program crashes when using library code in a + dynamically-loaded library + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-dlopen_crash"/></td><td align="left" valign="top"><p> + If you are using the C++ library across dynamically-loaded + objects, make certain that you are passing the correct options + when compiling and linking: + </p><div class="literallayout"><p><br/> + // compile your library components<br/> + g++ -fPIC -c a.cc<br/> + g++ -fPIC -c b.cc<br/> + ...<br/> + g++ -fPIC -c z.cc<br/> +<br/> + // create your library<br/> + g++ -fPIC -shared -rdynamic -o libfoo.so a.o b.o ... z.o<br/> +<br/> + // link the executable<br/> + g++ -fPIC -rdynamic -o foo ... -L. -lfoo -ldl<br/> + </p></div></td></tr><tr class="question" title="6.7."><td align="left" valign="top"><a id="faq.memory_leaks"/><a id="q-memory_leaks"/><p><strong>6.7.</strong></p></td><td align="left" valign="top"><p> + <span class="quote">“<span class="quote">Memory leaks</span>”</span> in containers + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-memory_leaks"/></td><td align="left" valign="top"><p> + A few people have reported that the standard containers appear + to leak memory when tested with memory checkers such as + <a class="link" href="http://valgrind.org/">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. + </p></td></tr><tr class="question" title="6.8."><td align="left" valign="top"><a id="faq.list_size_on"/><a id="q-list_size_on"/><p><strong>6.8.</strong></p></td><td align="left" valign="top"><p> + list::size() is O(n)! + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-list_size_on"/></td><td align="left" valign="top"><p> + See + the <a class="link" href="manual/containers.html" title="Chapter 9. Containers">Containers</a> + chapter. + </p></td></tr><tr class="question" title="6.9."><td align="left" valign="top"><a id="faq.easy_to_fix"/><a id="q-easy_to_fix"/><p><strong>6.9.</strong></p></td><td align="left" valign="top"><p> + Aw, that's easy to fix! + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-easy_to_fix"/></td><td align="left" valign="top"><p> + 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="link" href="http://gcc.gnu.org/contribute.html">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. + </p><p> + 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. + </p></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" title="7.1."><td align="left" valign="top"><a id="faq.iterator_as_pod"/><a id="faq.iterator_as_pod_q"/><p><strong>7.1.</strong></p></td><td align="left" valign="top"><p> + string::iterator is not char*; vector<T>::iterator is not T* + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="faq.iterator_as_pod_a"/></td><td align="left" valign="top"><p> + 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. + </p><p> + 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 <span class="type">T*</span> outweighs nearly all opposing + arguments. + </p><p> + 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<>). + </p></td></tr><tr class="question" title="7.2."><td align="left" valign="top"><a id="faq.what_is_next"/><a id="q-what_is_next"/><p><strong>7.2.</strong></p></td><td align="left" valign="top"><p> + What's next after libstdc++? + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-what_is_next"/></td><td align="left" valign="top"><p> + 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 <span class="emphasis"><em>be</em></span> any + more compliance work to do. + </p><p> + 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="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf"> + The C++ Library Technical Report 1</a>. + </p></td></tr><tr class="question" title="7.3."><td align="left" valign="top"><a id="faq.sgi_stl"/><a id="q-sgi_stl"/><p><strong>7.3.</strong></p></td><td align="left" valign="top"><p> + What about the STL from SGI? + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-sgi_stl"/></td><td align="left" valign="top"><p> + The <a class="link" href="http://www.sgi.com/tech/stl/">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. + </p><p> + 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. + </p><p> + 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. + </p><p> + The FAQ for SGI's STL (one jump off of their main page) is + still recommended reading. + </p></td></tr><tr class="question" title="7.4."><td align="left" valign="top"><a id="faq.extensions_and_backwards_compat"/><a id="q-extensions_and_backwards_compat"/><p><strong>7.4.</strong></p></td><td align="left" valign="top"><p> + Extensions and Backward Compatibility + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-extensions_and_backwards_compat"/></td><td align="left" valign="top"><p> + 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. + </p></td></tr><tr class="question" title="7.5."><td align="left" valign="top"><a id="faq.tr1_support"/><a id="q-tr1_support"/><p><strong>7.5.</strong></p></td><td align="left" valign="top"><p> + Does libstdc++ support TR1? + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-tr1_support"/></td><td align="left" valign="top"><p> + Yes. + </p><p> + The C++ Standard Library Technical Report adds many new features to + the library. The latest version of this effort is described in + <a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf"> + Technical Report 1</a>. + </p><p> + The implementation status of TR1 in libstdc++ can be tracked <a class="link" href="manual/status.html#status.iso.tr1" title="C++ TR1">on the TR1 status + page</a>. + </p></td></tr><tr class="question" title="7.6."><td align="left" valign="top"><a id="faq.get_iso_cxx"/><a id="q-get_iso_cxx"/><p><strong>7.6.</strong></p></td><td align="left" valign="top"><p>How do I get a copy of the ISO C++ Standard? + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-get_iso_cxx"/></td><td align="left" valign="top"><p> + 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="link" href="http://www.ansi.org">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="link" href="http://webstore.ansi.org/RecordDetail.aspx?sku=ISO%2FIEC+14882:2003">buy the standard on-line</a>. + </p><p> + Who is your country's member body? Visit the + <a class="link" href="http://www.iso.ch/">ISO homepage</a> and find out! + </p><p> + The 2003 version of the standard (the 1998 version plus TC1) is + available in print, ISBN 0-470-84674-7. + </p></td></tr><tr class="question" title="7.7."><td align="left" valign="top"><a id="faq.what_is_abi"/><a id="q-what_is_abi"/><p><strong>7.7.</strong></p></td><td align="left" valign="top"><p> + What's an ABI and why is it so messy? + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-what_is_abi"/></td><td align="left" valign="top"><p> + <acronym class="acronym">ABI</acronym> stands for <span class="quote">“<span class="quote">Application Binary + Interface</span>”</span>. 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. + </p><p> + 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 <span class="quote">“<span class="quote">free-standing implementation</span>”</span> that doesn't include (much + of) the standard library. It is a good basis for the work to come. + </p><p> + 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. + </p><p> + 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. + </p></td></tr><tr class="question" title="7.8."><td align="left" valign="top"><a id="faq.size_equals_capacity"/><a id="q-size_equals_capacity"/><p><strong>7.8.</strong></p></td><td align="left" valign="top"><p> + How do I make std::vector<T>::capacity() == std::vector<T>::size? + </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-size_equals_capacity"/></td><td align="left" valign="top"><p> + 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> + </p><div class="literallayout"><p><br/> + std::vector<T>(v).swap(v);<br/> + </p></div><p> + The copy will take O(n) time and the swap is constant time. + </p><p> + See <a class="link" href="manual/strings.html#strings.string.shrink" title="Shrink to Fit">Shrink-to-fit + strings</a> for a similar solution for strings. + </p></td></tr></tbody></table></div></div><div class="navfooter"><hr/><table width="100%" summary="Navigation footer"><tr><td align="left"><a accesskey="p" href="bk03.html">Prev</a> </td><td align="center"><a accesskey="u" href="bk03.html">Up</a></td><td align="right"> </td></tr><tr><td align="left" valign="top"> </td><td align="center"><a accesskey="h" href="spine.html">Home</a></td><td align="right" valign="top"> </td></tr></table></div></body></html> |