| <book xmlns="http://docbook.org/ns/docbook" version="5.0"> |
| |
| <article xml:id="faq" xreflabel="Frequently Asked Questions"> |
| <?dbhtml filename="faq.html"?> |
| |
| <info><title>Frequently Asked Questions</title> |
| |
| <copyright> |
| <year> |
| 2008-2018 |
| </year> |
| <holder> |
| <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://www.fsf.org">FSF</link> |
| </holder> |
| </copyright> |
| </info> |
| |
| <!-- FAQ starts here --> |
| <qandaset xml:id="faq.faq"> |
| |
| <!-- General Information --> |
| <qandadiv xml:id="faq.info" xreflabel="General Information"> |
| |
| <qandaentry xml:id="faq.what"> |
| <question xml:id="faq.what.q"> |
| <para> |
| What is libstdc++? |
| </para> |
| </question> |
| <answer xml:id="faq.what.a"> |
| <para> |
| The GNU Standard C++ Library v3 is an ongoing project to |
| implement the ISO 14882 C++ Standard Library as described in |
| clauses 20 through 33 and annex D (prior to the 2017 standard |
| the library clauses started with 17). 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 can be cloned via |
| <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://gcc.gnu.org/git.html">Git</link>. |
| </para> |
| |
| <para> |
| N.B. The library is called libstdc++ <emphasis>not</emphasis> stdlibc++. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.why"> |
| <question xml:id="q-why"> |
| <para> |
| Why should I use libstdc++? |
| </para> |
| </question> |
| <answer xml:id="a-why"> |
| <para> |
| The completion of the initial ISO C++ standardization effort gave the C++ |
| community a powerful set of reuseable tools in the form of the C++ |
| Standard Library. However, for several years C++ implementations were |
| (as the Draft Standard used to say) <quote>incomplet and |
| incorrekt</quote>, and many suffered from limitations of the compilers |
| that used them. |
| </para> |
| <para> |
| The GNU compiler collection |
| (<command>gcc</command>, <command>g++</command>, etc) is widely |
| considered to be one of the leading compilers in the world. Its |
| development is overseen by the |
| <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://gcc.gnu.org/">GCC team</link>. All of |
| the rapid development and near-legendary |
| <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://gcc.gnu.org/buildstat.html">portability</link> |
| that are the hallmarks of an open-source project are applied to libstdc++. |
| </para> |
| <para> |
| All of the standard classes and functions from C++98/C++03, C++11 and C++14 |
| (such as <classname>string</classname>, |
| <classname>vector<></classname>, iostreams, algorithms etc.) |
| are freely available and attempt to be fully compliant. |
| Work is ongoing to complete support for the current revision of the |
| ISO C++ Standard. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.who"> |
| <question xml:id="q-who"> |
| <para> |
| Who's in charge of it? |
| </para> |
| </question> |
| <answer xml:id="a-who"> |
| <para> |
| The libstdc++ project is contributed to by several developers |
| all over the world, in the same way as GCC or the Linux kernel. |
| The current maintainers are listed in the |
| <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://gcc.gnu.org/viewcvs/gcc/trunk/MAINTAINERS?view=co"><filename>MAINTAINERS</filename></link> |
| file (look for "c++ runtime libs"). |
| </para> |
| <para> |
| 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 <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://gcc.gnu.org/lists.html">GCC mailing lists</link> page. |
| If you have questions, ideas, code, or are just curious, sign up! |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.when"> |
| <question xml:id="q-when"> |
| <para> |
| When is libstdc++ going to be finished? |
| </para> |
| </question> |
| <answer xml:id="a-when"> |
| <para> |
| Nathan Myers gave the best of all possible answers, responding to |
| a Usenet article asking this question: <emphasis>Sooner, if you |
| help.</emphasis> |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.how"> |
| <question xml:id="q-how"> |
| <para> |
| How do I contribute to the effort? |
| </para> |
| </question> |
| <answer xml:id="a-how"> |
| <para> |
| See the <link linkend="appendix.contrib">Contributing</link> section in |
| the manual. 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! |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.whereis_old"> |
| <question xml:id="q-whereis_old"> |
| <para> |
| What happened to the older libg++? I need that! |
| </para> |
| </question> |
| <answer xml:id="a-whereis_old"> |
| <para> |
| The last libg++ README states |
| <quote>This package is considered obsolete and is no longer |
| being developed.</quote> |
| It should not be used for new projects, and won't even compile with |
| recent releases of GCC (or most other C++ compilers). |
| </para> |
| <para> |
| More information can be found in the |
| <link linkend="manual.appendix.porting.backwards">Backwards |
| Compatibility</link> section of the libstdc++ manual. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.more_questions"> |
| <question xml:id="q-more_questions"> |
| <para> |
| What if I have more questions? |
| </para> |
| </question> |
| <answer xml:id="a-more_questions"> |
| <para> |
| If you have read the documentation, 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 <email>libstdc++@gcc.gnu.org</email>. |
| </para> |
| |
| <para> |
| If you have a question that you think should be included |
| here, or if you have a question <emphasis>about</emphasis> a question/answer |
| here, please send email to the libstdc++ mailing list, as above. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| </qandadiv> |
| |
| <!-- License --> |
| <qandadiv xml:id="faq.license" xreflabel="License QA"> |
| |
| |
| <qandaentry xml:id="faq.license.what"> |
| <question xml:id="q-license.what"> |
| <para> |
| What are the license terms for libstdc++? |
| </para> |
| </question> |
| <answer xml:id="a-license.what"> |
| <para> |
| See <link linkend="manual.intro.status.license">our license description</link> |
| for these and related questions. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.license.any_program"> |
| <question xml:id="q-license.any_program"> |
| <para> |
| So any program which uses libstdc++ falls under the GPL? |
| </para> |
| </question> |
| <answer xml:id="a-license.any_program"> |
| <para> |
| No. The special exception permits use of the library in |
| proprietary applications. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| |
| <qandaentry xml:id="faq.license.lgpl"> |
| <question xml:id="q-license.lgpl"> |
| <para> |
| How is that different from the GNU {Lesser,Library} GPL? |
| </para> |
| </question> |
| <answer xml:id="a-license.lgpl"> |
| <para> |
| 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. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.license.what_restrictions"> |
| <question xml:id="q-license.what_restrictions"> |
| <para> |
| I see. So, what restrictions are there on programs that use the library? |
| </para> |
| </question> |
| <answer xml:id="a-license.what_restrictions"> |
| <para> |
| None. We encourage such programs to be released as free software, |
| but we won't punish you or sue you if you choose otherwise. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| </qandadiv> |
| |
| <!-- Installation --> |
| <qandadiv xml:id="faq.installation" xreflabel="Installation"> |
| |
| |
| <qandaentry xml:id="faq.how_to_install"> |
| <question xml:id="q-how_to_install"> |
| <para>How do I install libstdc++? |
| </para> |
| </question> |
| <answer xml:id="a-how_to_install"> |
| <para> |
| Often libstdc++ comes pre-installed as an integral part of many |
| existing GNU/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. |
| </para> |
| <para> |
| To build and install from the GNU GCC sources, please consult the |
| <link linkend="manual.intro.setup">setup |
| documentation</link> for detailed |
| instructions. You may wish to browse those files ahead |
| of time to get a feel for what's required. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.how_to_get_sources"> |
| <question xml:id="q-how_to_get_sources"> |
| <para>How does one get current libstdc++ sources? |
| </para> |
| </question> |
| <answer xml:id="a-how_to_get_sources"> |
| <para> |
| Libstdc++ sources for all official releases can be obtained as |
| part of the GCC sources, available from various sites and |
| mirrors. A full <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://gcc.gnu.org/mirrors.html">list of |
| download sites</link> is provided on the main GCC site. |
| </para> |
| <para> |
| Current libstdc++ sources can always be found in the main GCC source |
| repository, available using the appropriate version control tool. |
| At this time, that tool is <application>Git</application>. |
| For more details see the documentation on |
| <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://gcc.gnu.org/git.html">using the Git repository</link>. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.how_to_test"> |
| <question xml:id="q-how_to_test"> |
| <para>How do I know if it works? |
| </para> |
| </question> |
| <answer xml:id="a-how_to_test"> |
| <para> |
| Libstdc++ comes with its own validation testsuite, which includes |
| conformance testing, regression testing, ABI testing, and |
| performance testing. Please consult the |
| <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/install/test.html">testing |
| documentation</link> for GCC and |
| <link linkend="manual.intro.setup.test">Testing</link> in the libstdc++ |
| manual for more details. |
| </para> |
| <para> |
| 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, |
| <emphasis>please</emphasis> write up your idea and send it to the list! |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.how_to_set_paths"> |
| <question xml:id="q-how_to_set_paths"> |
| <para>How do I insure that the dynamically linked library will be found? |
| </para> |
| </question> |
| <answer xml:id="a-how_to_set_paths"> |
| <para> |
| Depending on your platform and library version, the error message might |
| be similar to one of the following: |
| </para> |
| |
| <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 |
| </screen> |
| |
| <para> |
| 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. |
| </para> |
| |
| <para> |
| If you already have an older version of libstdc++ installed then the |
| error might look like one of the following instead: |
| </para> |
| |
| <screen> |
| ./a.out: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.20' not found |
| ./a.out: /usr/lib/libstdc++.so.6: version `CXXABI_1.3.8' not found |
| </screen> |
| |
| <para> |
| This means the linker found <filename>/usr/lib/libstdc++.so.6</filename> |
| but that library belongs to an older version of GCC than was used to |
| compile and link the program <filename>a.out</filename> (or some part |
| of it). The program depends on code defined in the newer libstdc++ |
| that belongs to the newer version of GCC, so the linker must be told |
| how to find the newer libstdc++ shared library. |
| </para> |
| |
| <para> |
| The simplest way to fix this is |
| to use the <envar>LD_LIBRARY_PATH</envar> environment variable, |
| which is a colon-separated list of directories in which the linker |
| will search for shared libraries: |
| </para> |
| |
| <screen><command> |
| export LD_LIBRARY_PATH=${prefix}/lib:$LD_LIBRARY_PATH |
| </command></screen> |
| |
| <para> |
| Here the shell variable <varname>${prefix}</varname> is assumed to contain |
| the directory prefix where GCC was installed to. The directory containing |
| the library might depend on whether you want the 32-bit or 64-bit copy |
| of the library, so for example would be |
| <filename class="directory">${prefix}/lib64</filename> on some systems. |
| The exact environment variable to use will depend on your |
| platform, e.g. <envar>DYLD_LIBRARY_PATH</envar> for Darwin, |
| <envar>LD_LIBRARY_PATH_32</envar>/<envar>LD_LIBRARY_PATH_64</envar> |
| for Solaris 32-/64-bit, |
| and <envar>SHLIB_PATH</envar> for HP-UX. |
| </para> |
| <para> |
| See the man pages for <command>ld</command>, <command>ldd</command> |
| and <command>ldconfig</command> for more information. The dynamic |
| linker has different names on different platforms but the man page |
| is usually called something such as <filename>ld.so</filename>, |
| <filename>rtld</filename> or <filename>dld.so</filename>. |
| </para> |
| <para> |
| Using <envar>LD_LIBRARY_PATH</envar> is not always the best solution, |
| <link linkend="manual.intro.using.linkage.dynamic">Finding Dynamic or Shared |
| Libraries</link> in the manual gives some alternatives. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.what_is_libsupcxx"> |
| <question xml:id="q-what_is_libsupcxx"> |
| <para> |
| What's libsupc++? |
| </para> |
| </question> |
| <answer xml:id="a-what_is_libsupcxx"> |
| <para> |
| If the only functions from <filename class="libraryfile">libstdc++.a</filename> |
| which you need are language support functions (those listed in |
| <link linkend="std.support">clause 18</link> of the |
| standard, e.g., <function>new</function> and |
| <function>delete</function>), then try linking against |
| <filename class="libraryfile">libsupc++.a</filename>, which is a subset of |
| <filename class="libraryfile">libstdc++.a</filename>. (Using <command>gcc</command> |
| instead of <command>g++</command> and explicitly linking in |
| <filename class="libraryfile">libsupc++.a</filename> via <option>-lsupc++</option> |
| 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 |
| <filename class="libraryfile">libstdc++.a</filename>. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.size"> |
| <question xml:id="q-size"> |
| <para> |
| This library is HUGE! |
| </para> |
| </question> |
| <answer xml:id="a-size"> |
| <para> |
| Usually the size of libraries on disk isn't noticeable. When a |
| link editor (or simply <quote>linker</quote>) 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.) |
| </para> |
| <para> |
| Some of the object files which make up |
| <filename class="libraryfile">libstdc++.a</filename> are rather large. |
| If you create a statically-linked executable with |
| <option>-static</option>, 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 <filename>.o</filename> 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. |
| </para> |
| <para> |
| 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 <filename>.o</filename> 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. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| </qandadiv> |
| |
| |
| <!-- Platform-Specific Issues --> |
| <qandadiv xml:id="faq.platform-specific" xreflabel="Platform-Specific Issues"> |
| |
| |
| <qandaentry xml:id="faq.other_compilers"> |
| <question xml:id="q-other_compilers"> |
| <para> |
| Can libstdc++ be used with non-GNU compilers? |
| </para> |
| </question> |
| <answer xml:id="a-other_compilers"> |
| <para> |
| Perhaps. |
| </para> |
| <para> |
| 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. |
| </para> |
| <para> |
| 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. |
| </para> |
| <para> |
| Recent versions of libstdc++ are known to work with the Clang compiler. |
| 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. |
| </para> |
| |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.solaris_long_long"> |
| <question xml:id="q-solaris_long_long"> |
| <para> |
| No '<type>long long</type>' type on Solaris? |
| </para> |
| </question> |
| <answer xml:id="a-solaris_long_long"> |
| <note> |
| <para>This answer is old and probably no longer be relevant.</para> |
| </note> |
| <para> |
| By default we try to support the C99 <type>long long</type> type. |
| This requires that certain functions from your C library be present. |
| </para> |
| <para> |
| Up through release 3.0.2 the platform-specific tests performed by |
| libstdc++ were too general, resulting in a conservative approach |
| to enabling the <type>long long</type> code paths. The most |
| commonly reported platform affected was Solaris. |
| </para> |
| <para> |
| This has been fixed for libstdc++ releases greater than 3.0.3. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.predefined"> |
| <question xml:id="q-predefined"> |
| <para> |
| <constant>_XOPEN_SOURCE</constant> and <constant>_GNU_SOURCE</constant> are always defined? |
| </para> |
| </question> |
| <answer xml:id="a-predefined"> |
| <para>On Solaris, <command>g++</command> (but not <command>gcc</command>) |
| always defines the preprocessor macro |
| <constant>_XOPEN_SOURCE</constant>. On GNU/Linux, the same happens |
| with <constant>_GNU_SOURCE</constant>. (This is not an exhaustive list; |
| other macros and other platforms are also affected.) |
| </para> |
| <para>These macros are typically used in C library headers, guarding new |
| versions of functions from their older versions. The C++98 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. |
| </para> |
| <para>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. |
| </para> |
| <para>Note that it's not enough to <literal>#define</literal> 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. |
| </para> |
| <para>To see which symbols are defined, look for |
| <varname>CPLUSPLUS_CPP_SPEC</varname> in |
| the gcc config headers for your target (and try changing them to |
| see what happens when building complicated code). You can also run |
| <command>g++ -E -dM - < /dev/null"</command> to display |
| a list of predefined macros for any particular installation. |
| </para> |
| <para>This has been discussed on the mailing lists |
| <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/cgi-bin/htsearch?method=and&format=builtin-long&sort=score&words=_XOPEN_SOURCE+Solaris">quite a bit</link>. |
| </para> |
| <para>This method is something of a wart. We'd like to find a cleaner |
| solution, but nobody yet has contributed the time. |
| </para> |
| |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.darwin_ctype"> |
| <question xml:id="q-darwin_ctype"> |
| <para> |
| Mac OS X <filename class="headerfile">ctype.h</filename> is broken! How can I fix it? |
| </para> |
| </question> |
| <answer xml:id="a-darwin_ctype"> |
| <note> |
| <para>This answer is old and probably no longer be relevant.</para> |
| </note> |
| <para> |
| This was a long-standing bug in the OS X support. Fortunately, the |
| <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/ml/gcc/2002-03/msg00817.html">patch</link> |
| was quite simple, and well-known. |
| </para> |
| |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.threads_i386"> |
| <question xml:id="q-threads_i386"> |
| <para> |
| Threading is broken on i386? |
| </para> |
| </question> |
| <answer xml:id="a-threads_i386"> |
| <note> |
| <para>This answer is old and probably no longer be relevant.</para> |
| </note> |
| <para>Support for atomic integer operations 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. |
| </para> |
| <para>This is fixed in 3.2.2. |
| </para> |
| |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.atomic_mips"> |
| <question xml:id="q-atomic_mips"> |
| <para> |
| MIPS atomic operations |
| </para> |
| </question> |
| <answer xml:id="a-atomic_mips"> |
| <note> |
| <para>This answer is old and probably no longer be relevant.</para> |
| </note> |
| <para> |
| 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. |
| </para> |
| <para> |
| The mips*-*-linux* port continues to use the MIPS II routines, and more |
| work in this area is expected. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.linux_glibc"> |
| <question xml:id="q-linux_glibc"> |
| <para> |
| Recent GNU/Linux glibc required? |
| </para> |
| </question> |
| <answer xml:id="a-linux_glibc"> |
| <para>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. |
| All 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. |
| </para> |
| <para>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.) |
| </para> |
| |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.freebsd_wchar"> |
| <question xml:id="q-freebsd_wchar"> |
| <para> |
| Can't use <type>wchar_t</type>/<classname>wstring</classname> on FreeBSD |
| </para> |
| </question> |
| <answer xml:id="a-freebsd_wchar"> |
| <note> |
| <para>This answer is old and probably no longer be relevant.</para> |
| </note> |
| <para> |
| 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 <type>wchar_t</type> support should be |
| disabled. In addition, the libstdc++ platform checks that |
| enabled <type>wchar_t</type> were quite strict, and not granular |
| enough to detect when the minimal support to |
| enable <type>wchar_t</type> and C++ library structures |
| like <classname>wstring</classname> were present. This impacted Solaris, |
| Darwin, and BSD variants, and is fixed in libstdc++ versions post 4.1.0. |
| </para> |
| <para> |
| </para> |
| </answer> |
| </qandaentry> |
| |
| </qandadiv> |
| |
| |
| <!-- Known Bugs --> |
| <qandadiv xml:id="faq.known_bugs" xreflabel="Known Bugs"> |
| |
| |
| <qandaentry xml:id="faq.what_works"> |
| <question xml:id="q-what_works"> |
| <para> |
| What works already? |
| </para> |
| </question> |
| <answer xml:id="a-what_works"> |
| <para> |
| Short answer: Pretty much everything <emphasis>works</emphasis> |
| except for some corner cases. Support for localization |
| in <classname>locale</classname> may be incomplete on some non-GNU |
| platforms. Also dependent on the underlying platform is support |
| for <type>wchar_t</type> and <type>long long</type> specializations, |
| and details of thread support. |
| </para> |
| <para> |
| Long answer: See the implementation status pages for |
| <link linkend="status.iso.1998">C++98</link>, |
| <link linkend="status.iso.tr1">TR1</link>, |
| <link linkend="status.iso.2011">C++11</link>, |
| <link linkend="status.iso.2014">C++14</link>, and |
| <link linkend="status.iso.2017">C++17</link>. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.standard_bugs"> |
| <question xml:id="q-standard_bugs"> |
| <para> |
| Bugs in the ISO C++ language or library specification |
| </para> |
| </question> |
| <answer xml:id="a-standard_bugs"> |
| <para> |
| Unfortunately, there are some. |
| </para> |
| <para> |
| 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 on <link xmlns:xlink="http://www.w3.org/1999/xlink" |
| xlink:href="http://www.open-std.org/jtc1/sc22/wg21/">the WG21 |
| website</link>. |
| Many of these issues have resulted in |
| <link linkend="manual.intro.status.bugs.iso">code changes in libstdc++</link>. |
| </para> |
| <para> |
| If you think you've discovered a new bug that is not listed, |
| please post a message describing your problem to the author of |
| the library issues list. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.compiler_bugs"> |
| <question xml:id="q-compiler_bugs"> |
| <para> |
| Bugs in the compiler (gcc/g++) and not libstdc++ |
| </para> |
| </question> |
| <answer xml:id="a-compiler_bugs"> |
| <para> |
| On occasion, the compiler is wrong. Please be advised that this |
| happens much less often than one would think, and avoid jumping to |
| conclusions. |
| </para> |
| <para> |
| 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. |
| </para> |
| <para> |
| Before reporting a bug, please examine the |
| <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://gcc.gnu.org/bugs/">bugs database</link>, with the |
| component set to <quote>c++</quote>. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| </qandadiv> |
| |
| <!-- Known Non-Bugs --> |
| <qandadiv xml:id="faq.known_non-bugs" xreflabel="Known Non-Bugs"> |
| |
| |
| <qandaentry xml:id="faq.stream_reopening_fails"> |
| <question xml:id="q-stream_reopening_fails"> |
| <para> |
| Reopening a stream fails |
| </para> |
| </question> |
| <answer xml:id="a-stream_reopening_fails"> |
| <note> |
| <para>This answer is old and probably no longer be relevant.</para> |
| </note> |
| <para> |
| Prior to GCC 4.0 this was one of the most-reported non-bug reports. |
| Executing a sequence like this would fail: |
| </para> |
| |
| <programlisting> |
| #include <fstream> |
| ... |
| std::fstream fs("a_file"); |
| // . |
| // . do things with fs... |
| // . |
| fs.close(); |
| fs.open("a_new_file"); |
| </programlisting> |
| |
| <para> |
| All operations on the re-opened <varname>fs</varname> would fail, or at |
| least act very strangely, especially if <varname>fs</varname> reached the |
| EOF state on the previous file. |
| The original C++98 standard did not specify behavior in this case, and |
| the <link linkend="manual.bugs.dr22">resolution of DR #22</link> was to |
| leave the state flags unchanged on a successful call to |
| <function>open()</function>. |
| You had to insert a call to <function>fs.clear()</function> between the |
| calls to <function>close()</function> and <function>open()</function>, |
| and then everything will work as expected. |
| <emphasis>Update:</emphasis> For GCC 4.0 we implemented the resolution |
| of <link linkend="manual.bugs.dr409">DR #409</link> and |
| <function>open()</function> |
| now calls <function>clear()</function> on success. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.wefcxx_verbose"> |
| <question xml:id="q-wefcxx_verbose"> |
| <para> |
| -Weffc++ complains too much |
| </para> |
| </question> |
| <answer xml:id="a-wefcxx_verbose"> |
| <para> |
| Many warnings are emitted when <option>-Weffc++</option> is used. Making |
| libstdc++ <option>-Weffc++</option>-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. The option also enforces outdated guidelines |
| from old editions of the books, and the advice isn't all relevant to |
| modern C++ (especially C++11 and later). |
| </para> |
| <para> |
| We do, however, try to have libstdc++ sources as clean as possible. If |
| you see some simple changes that pacify <option>-Weffc++</option> |
| without other drawbacks, send us a patch. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.ambiguous_overloads"> |
| <question xml:id="q-ambiguous_overloads"> |
| <para> |
| Ambiguous overloads after including an old-style header |
| </para> |
| </question> |
| <answer xml:id="a-ambiguous_overloads"> |
| <note> |
| <para>This answer is old and probably no longer be relevant.</para> |
| </note> |
| <para> |
| Another problem is the <literal>rel_ops</literal> namespace and the template |
| comparison operator functions contained therein. If they become |
| visible in the same namespace as other comparison functions |
| (e.g., <quote>using</quote> them and the |
| <filename class="headerfile"><iterator></filename> header), |
| then you will suddenly be faced with huge numbers of ambiguity |
| errors. This was discussed on the mailing list; Nathan Myers |
| <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html">sums |
| things up here</link>. The collisions with vector/string iterator |
| types have been fixed for 3.1. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.v2_headers"> |
| <question xml:id="q-v2_headers"> |
| <para> |
| The g++-3 headers are <emphasis>not ours</emphasis> |
| </para> |
| </question> |
| <answer xml:id="a-v2_headers"> |
| <note> |
| <para>This answer is old and probably no longer be relevant.</para> |
| </note> |
| <para> |
| If you are using headers in |
| <filename class="directory">${prefix}/include/g++-3</filename>, or if |
| the installed library's name looks like |
| <filename class="libraryfile">libstdc++-2.10.a</filename> or |
| <filename class="libraryfile">libstdc++-libc6-2.10.so</filename>, then |
| you are using the old libstdc++-v2 library, which is non-standard and |
| unmaintained. Do not report problems with -v2 to the -v3 |
| mailing list. |
| </para> |
| <para> |
| For GCC versions 3.0 and 3.1 the libstdc++ header files are installed in |
| <filename class="directory">${prefix}/include/g++-v3</filename> |
| (see the 'v'?). Starting with version 3.2 the headers are installed in |
| <filename class="directory">${prefix}/include/c++/${version}</filename> |
| as this prevents headers from previous versions being found by mistake. |
| </para> |
| |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.boost_concept_checks"> |
| <question xml:id="q-boost_concept_checks"> |
| <para> |
| Errors about <emphasis>*Concept</emphasis> and |
| <emphasis>constraints</emphasis> in the STL |
| </para> |
| </question> |
| <answer xml:id="a-boost_concept_checks"> |
| <para> |
| If you see compilation errors containing messages about |
| <errortext>foo Concept</errortext> and something to do with a |
| <errortext>constraints</errortext> 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). |
| </para> |
| <para> |
| More information, including how to optionally enable/disable the |
| checks, is available in the |
| <link linkend="std.diagnostics.concept_checking">Diagnostics</link>. |
| chapter of the manual. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.dlopen_crash"> |
| <question xml:id="q-dlopen_crash"> |
| <para> |
| Program crashes when using library code in a |
| dynamically-loaded library |
| </para> |
| </question> |
| <answer xml:id="a-dlopen_crash"> |
| <para> |
| If you are using the C++ library across dynamically-loaded |
| objects, make certain that you are passing the correct options |
| when compiling and linking: |
| </para> |
| |
| <literallayout class="normal"> |
| Compile your library components: |
| <command>g++ -fPIC -c a.cc</command> |
| <command>g++ -fPIC -c b.cc</command> |
| ... |
| <command>g++ -fPIC -c z.cc</command> |
| |
| Create your library: |
| <command>g++ -fPIC -shared -rdynamic -o libfoo.so a.o b.o ... z.o</command> |
| |
| Link the executable: |
| <command>g++ -fPIC -rdynamic -o foo ... -L. -lfoo -ldl</command> |
| </literallayout> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.memory_leaks"> |
| <question xml:id="q-memory_leaks"> |
| <para> |
| <quote>Memory leaks</quote> in libstdc++ |
| </para> |
| </question> |
| <answer xml:id="a-memory_leaks"> |
| <para> |
| Since GCC 5.1.0, libstdc++ automatically allocates a pool |
| of a few dozen kilobytes on startup. This pool is used to ensure it's |
| possible to throw exceptions (such as <classname>bad_alloc</classname>) |
| even when <code>malloc</code> is unable to allocate any more memory. |
| With some versions of <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://valgrind.org"><command>valgrind</command></link> |
| this pool will be shown as "still reachable" when the process exits, e.g. |
| <code>still reachable: 72,704 bytes in 1 blocks</code>. |
| This memory is not a leak, because it's still in use by libstdc++, |
| and the memory will be returned to the OS when the process exits. |
| Later versions of <command>valgrind</command> know how to free this |
| pool as the process exits, and so won't show any "still reachable" memory. |
| </para> |
| <para> |
| In the past, a few people reported that the standard containers appear |
| to leak memory when tested with memory checkers such as |
| <command>valgrind</command>. |
| Under some (non-default) configurations the library's allocators keep |
| free memory in a |
| pool for later reuse, rather than deallocating it with <code>delete</code> |
| 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 |
| <link linkend="debug.memory">Tips for memory leak hunting</link> |
| first. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.list_size_on"> |
| <question xml:id="q-list_size_on"> |
| <para> |
| <code>list::size()</code> is O(n)! |
| </para> |
| </question> |
| <answer xml:id="a-list_size_on"> |
| <para> |
| See |
| the <link linkend="std.containers">Containers</link> |
| chapter. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.easy_to_fix"> |
| <question xml:id="q-easy_to_fix"> |
| <para> |
| Aw, that's easy to fix! |
| </para> |
| </question> |
| <answer xml:id="a-easy_to_fix"> |
| <para> |
| 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 <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/contribute.html">submitting |
| patches</link> 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++ |
| <link linkend="appendix.contrib">contributors' page</link> |
| also talks about how to submit patches. |
| </para> |
| <para> |
| 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. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| </qandadiv> |
| |
| |
| <!-- Miscellaneous --> |
| <qandadiv xml:id="faq.misc" xreflabel="Miscellaneous"> |
| |
| |
| <qandaentry xml:id="faq.iterator_as_pod"> |
| <question xml:id="faq.iterator_as_pod_q"> |
| <para> |
| <classname>string::iterator</classname> is not <code>char*</code>; |
| <classname>vector<T>::iterator</classname> is not <code>T*</code> |
| </para> |
| </question> |
| <answer xml:id="faq.iterator_as_pod_a"> |
| <para> |
| 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. |
| </para> |
| <para> |
| 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 <type>T*</type> outweighs nearly all opposing |
| arguments. |
| </para> |
| <para> |
| Code which does assume that a vector/string iterator <varname>i</varname> |
| is a pointer can often be fixed by changing <varname>i</varname> in |
| certain expressions to <varname>&*i</varname>. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.what_is_next"> |
| <question xml:id="q-what_is_next"> |
| <para> |
| What's next after libstdc++? |
| </para> |
| </question> |
| <answer xml:id="a-what_is_next"> |
| <para> |
| The goal of libstdc++ is to produce a |
| fully-compliant, fully-portable Standard Library. |
| While the C++ Standard continues to evolve the libstdc++ will |
| continue to track it. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.sgi_stl"> |
| <question xml:id="q-sgi_stl"> |
| <para> |
| What about the STL from SGI? |
| </para> |
| </question> |
| <answer xml:id="a-sgi_stl"> |
| <para> |
| The STL (Standard Template Library) was the inspiration for large chunks |
| of the C++ Standard Library, but the terms are not interchangeable and |
| they don't mean the same thing. The C++ Standard Library includes lots of |
| things that didn't come from the STL, and some of them aren't even |
| templates, such as <classname>std::locale</classname> and |
| <classname>std::thread</classname>. |
| </para> |
| <para> |
| Libstdc++-v3 incorporates a lot of code from |
| <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/">the SGI STL</link> |
| (the final merge was from |
| <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/whats_new.html">release 3.3</link>). |
| The code in libstdc++ contains many fixes and changes compared to the |
| original SGI code. |
| </para> |
| <para> |
| In particular, <classname>string</classname> is not from SGI and makes no |
| use of their "rope" class (although that is included as an optional |
| extension), neither is <classname>valarray</classname> nor some others. |
| Classes like <classname>vector<></classname> were from SGI, but have |
| been extensively modified. |
| </para> |
| <para> |
| More information on the evolution of libstdc++ can be found at the |
| <link linkend="appendix.porting.api">API |
| evolution</link> |
| and <link linkend="manual.appendix.porting.backwards">backwards |
| compatibility</link> documentation. |
| </para> |
| <para> |
| The <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://web.archive.org/web/20171104092813/http://www.sgi.com/tech/stl/FAQ.html">FAQ</link> |
| for SGI's STL is still recommended reading. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.extensions_and_backwards_compat"> |
| <question xml:id="q-extensions_and_backwards_compat"> |
| <para> |
| Extensions and Backward Compatibility |
| </para> |
| </question> |
| <answer xml:id="a-extensions_and_backwards_compat"> |
| <para> |
| See the <link linkend="manual.appendix.porting.backwards">link</link> on backwards compatibility and <link linkend="appendix.porting.api">link</link> on evolution. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.tr1_support"> |
| <question xml:id="q-tr1_support"> |
| <para> |
| Does libstdc++ support TR1? |
| </para> |
| </question> |
| <answer xml:id="a-tr1_support"> |
| <para> |
| Yes. |
| </para> |
| <para> |
| The C++ Standard Library |
| <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf"> |
| Technical Report 1</link> added many new features to the library. |
| </para> |
| <para> |
| The implementation status of TR1 in libstdc++ can be tracked |
| <link linkend="status.iso.tr1">on the TR1 status page</link>. |
| </para> |
| <para> |
| New code should probably not use TR1, because almost everything in it has |
| been added to the main C++ Standard Library (usually with significant |
| improvements). |
| The TR1 implementation in libstdc++ is no longer actively maintained. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.get_iso_cxx"> |
| <question xml:id="q-get_iso_cxx"> |
| <para>How do I get a copy of the ISO C++ Standard? |
| </para> |
| </question> |
| <answer xml:id="a-get_iso_cxx"> |
| <para> |
| Please refer to the <link linkend="appendix.contrib">Contributing</link> |
| section in our manual. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.what_is_abi"> |
| <question xml:id="q-what_is_abi"> |
| <para> |
| What's an ABI and why is it so messy? |
| </para> |
| </question> |
| <answer xml:id="a-what_is_abi"> |
| <para> |
| <acronym>ABI</acronym> stands for <quote>Application Binary |
| Interface</quote>. 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. |
| </para> |
| <para> |
| 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 most CPU designers (for good reasons elaborated |
| below) have not stepped up to publish C++ ABIs. Such an ABI has been |
| defined for the Itanium architecture (see |
| <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://itanium-cxx-abi.github.io/cxx-abi/">C++ |
| ABI for Itanium</link>) and that is used by G++ and other compilers |
| as the de facto standard ABI on many common architectures (including x86). |
| G++ can also use the ARM architecture's EABI, for embedded |
| systems relying only on a <quote>free-standing implementation</quote> that |
| doesn't include (much of) the standard library, and the GNU EABI for |
| hosted implementations on ARM. Those ABIs cover low-level details |
| such as virtual function implementation, struct inheritance layout, |
| name mangling, and exception handling. |
| </para> |
| <para> |
| 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 <type>FILE</type>, <type>stat</type>, <type>jmpbuf</type>, |
| 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. |
| </para> |
| <para> |
| 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., <function>getchar</function>) 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. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| <qandaentry xml:id="faq.size_equals_capacity"> |
| <question xml:id="q-size_equals_capacity"> |
| <para> |
| How do I make <code>std::vector<T>::capacity() == std::vector<T>::size</code>? |
| </para> |
| </question> |
| <answer xml:id="a-size_equals_capacity"> |
| <para> |
| Since C++11 just call the <function>shrink_to_fit()</function> member |
| function. |
| </para> |
| <para> |
| Before C++11, the standard idiom for deallocating a |
| <classname>vector<T></classname>'s |
| unused memory was to create a temporary copy of the vector and swap their |
| contents, e.g. for <classname>vector<T> v</classname> |
| </para> |
| <literallayout class="normal"> |
| std::vector<T>(v).swap(v); |
| </literallayout> |
| <para> |
| The copy will take O(n) time and the swap is constant time. |
| </para> |
| <para> |
| See <link linkend="strings.string.shrink">Shrink-to-fit |
| strings</link> for a similar solution for strings. |
| </para> |
| </answer> |
| </qandaentry> |
| |
| </qandadiv> |
| |
| |
| <!-- FAQ ends here --> |
| </qandaset> |
| |
| </article> |
| |
| </book> |