1<book xmlns="http://docbook.org/ns/docbook" version="5.0"> 2 3<article xml:id="faq" xreflabel="Frequently Asked Questions"> 4<?dbhtml filename="faq.html"?> 5 6<info><title>Frequently Asked Questions</title> 7 8 <copyright> 9 <year> 10 2008-2018 11 </year> 12 <holder> 13 <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://www.fsf.org">FSF</link> 14 </holder> 15 </copyright> 16</info> 17 18<!-- FAQ starts here --> 19<qandaset xml:id="faq.faq"> 20 21<!-- General Information --> 22<qandadiv xml:id="faq.info" xreflabel="General Information"> 23 24<qandaentry xml:id="faq.what"> 25 <question xml:id="faq.what.q"> 26 <para> 27 What is libstdc++? 28 </para> 29 </question> 30 <answer xml:id="faq.what.a"> 31 <para> 32 The GNU Standard C++ Library v3 is an ongoing project to 33 implement the ISO 14882 C++ Standard Library as described in 34 clauses 20 through 33 and annex D (prior to the 2017 standard 35 the library clauses started with 17). For those who want to see 36 exactly how far the project has come, or just want the latest 37 bleeding-edge code, the up-to-date source can be cloned via 38 <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://gcc.gnu.org/git.html">Git</link>. 39 </para> 40 41 <para> 42 N.B. The library is called libstdc++ <emphasis>not</emphasis> stdlibc++. 43 </para> 44 </answer> 45</qandaentry> 46 47<qandaentry xml:id="faq.why"> 48 <question xml:id="q-why"> 49 <para> 50 Why should I use libstdc++? 51 </para> 52 </question> 53 <answer xml:id="a-why"> 54 <para> 55 The completion of the initial ISO C++ standardization effort gave the C++ 56 community a powerful set of reuseable tools in the form of the C++ 57 Standard Library. However, for several years C++ implementations were 58 (as the Draft Standard used to say) <quote>incomplet and 59 incorrekt</quote>, and many suffered from limitations of the compilers 60 that used them. 61 </para> 62 <para> 63 The GNU compiler collection 64 (<command>gcc</command>, <command>g++</command>, etc) is widely 65 considered to be one of the leading compilers in the world. Its 66 development is overseen by the 67 <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://gcc.gnu.org/">GCC team</link>. All of 68 the rapid development and near-legendary 69 <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://gcc.gnu.org/buildstat.html">portability</link> 70 that are the hallmarks of an open-source project are applied to libstdc++. 71 </para> 72 <para> 73 All of the standard classes and functions from C++98/C++03, C++11 and C++14 74 (such as <classname>string</classname>, 75 <classname>vector<></classname>, iostreams, algorithms etc.) 76 are freely available and attempt to be fully compliant. 77 Work is ongoing to complete support for the current revision of the 78 ISO C++ Standard. 79 </para> 80 </answer> 81</qandaentry> 82 83<qandaentry xml:id="faq.who"> 84 <question xml:id="q-who"> 85 <para> 86 Who's in charge of it? 87 </para> 88 </question> 89 <answer xml:id="a-who"> 90 <para> 91 The libstdc++ project is contributed to by several developers 92 all over the world, in the same way as GCC or the Linux kernel. 93 The current maintainers are listed in the 94 <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> 95 file (look for "c++ runtime libs"). 96 </para> 97 <para> 98 Development and discussion is held on the libstdc++ mailing 99 list. Subscribing to the list, or searching the list 100 archives, is open to everyone. You can read instructions for 101 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. 102 If you have questions, ideas, code, or are just curious, sign up! 103 </para> 104 </answer> 105</qandaentry> 106 107<qandaentry xml:id="faq.when"> 108 <question xml:id="q-when"> 109 <para> 110 When is libstdc++ going to be finished? 111 </para> 112 </question> 113 <answer xml:id="a-when"> 114 <para> 115 Nathan Myers gave the best of all possible answers, responding to 116 a Usenet article asking this question: <emphasis>Sooner, if you 117 help.</emphasis> 118 </para> 119 </answer> 120</qandaentry> 121 122<qandaentry xml:id="faq.how"> 123 <question xml:id="q-how"> 124 <para> 125 How do I contribute to the effort? 126 </para> 127 </question> 128 <answer xml:id="a-how"> 129 <para> 130 See the <link linkend="appendix.contrib">Contributing</link> section in 131 the manual. Subscribing to the mailing list (see above, or 132 the homepage) is a very good idea if you have something to 133 contribute, or if you have spare time and want to 134 help. Contributions don't have to be in the form of source code; 135 anybody who is willing to help write documentation, for example, 136 or has found a bug in code that we all thought was working and is 137 willing to provide details, is more than welcome! 138 </para> 139 </answer> 140</qandaentry> 141 142<qandaentry xml:id="faq.whereis_old"> 143 <question xml:id="q-whereis_old"> 144 <para> 145 What happened to the older libg++? I need that! 146 </para> 147 </question> 148 <answer xml:id="a-whereis_old"> 149 <para> 150 The last libg++ README states 151 <quote>This package is considered obsolete and is no longer 152 being developed.</quote> 153 It should not be used for new projects, and won't even compile with 154 recent releases of GCC (or most other C++ compilers). 155 </para> 156 <para> 157 More information can be found in the 158 <link linkend="manual.appendix.porting.backwards">Backwards 159 Compatibility</link> section of the libstdc++ manual. 160 </para> 161 </answer> 162</qandaentry> 163 164<qandaentry xml:id="faq.more_questions"> 165 <question xml:id="q-more_questions"> 166 <para> 167 What if I have more questions? 168 </para> 169 </question> 170 <answer xml:id="a-more_questions"> 171 <para> 172 If you have read the documentation, and your question remains 173 unanswered, then just ask the mailing list. At present, you do not 174 need to be subscribed to the list to send a message to it. More 175 information is available on the homepage (including how to browse 176 the list archives); to send a message to the list, 177 use <email>libstdc++@gcc.gnu.org</email>. 178 </para> 179 180 <para> 181 If you have a question that you think should be included 182 here, or if you have a question <emphasis>about</emphasis> a question/answer 183 here, please send email to the libstdc++ mailing list, as above. 184 </para> 185 </answer> 186</qandaentry> 187 188</qandadiv> 189 190<!-- License --> 191<qandadiv xml:id="faq.license" xreflabel="License QA"> 192 193 194<qandaentry xml:id="faq.license.what"> 195 <question xml:id="q-license.what"> 196 <para> 197 What are the license terms for libstdc++? 198 </para> 199 </question> 200 <answer xml:id="a-license.what"> 201 <para> 202 See <link linkend="manual.intro.status.license">our license description</link> 203 for these and related questions. 204 </para> 205 </answer> 206</qandaentry> 207 208<qandaentry xml:id="faq.license.any_program"> 209 <question xml:id="q-license.any_program"> 210 <para> 211 So any program which uses libstdc++ falls under the GPL? 212 </para> 213 </question> 214 <answer xml:id="a-license.any_program"> 215 <para> 216 No. The special exception permits use of the library in 217 proprietary applications. 218 </para> 219 </answer> 220</qandaentry> 221 222 223<qandaentry xml:id="faq.license.lgpl"> 224 <question xml:id="q-license.lgpl"> 225 <para> 226 How is that different from the GNU {Lesser,Library} GPL? 227 </para> 228 </question> 229 <answer xml:id="a-license.lgpl"> 230 <para> 231 The LGPL requires that users be able to replace the LGPL code with a 232 modified version; this is trivial if the library in question is a C 233 shared library. But there's no way to make that work with C++, where 234 much of the library consists of inline functions and templates, which 235 are expanded inside the code that uses the library. So to allow people 236 to replace the library code, someone using the library would have to 237 distribute their own source, rendering the LGPL equivalent to the GPL. 238 </para> 239 </answer> 240</qandaentry> 241 242<qandaentry xml:id="faq.license.what_restrictions"> 243 <question xml:id="q-license.what_restrictions"> 244 <para> 245 I see. So, what restrictions are there on programs that use the library? 246 </para> 247 </question> 248 <answer xml:id="a-license.what_restrictions"> 249 <para> 250 None. We encourage such programs to be released as free software, 251 but we won't punish you or sue you if you choose otherwise. 252 </para> 253 </answer> 254</qandaentry> 255 256</qandadiv> 257 258<!-- Installation --> 259<qandadiv xml:id="faq.installation" xreflabel="Installation"> 260 261 262<qandaentry xml:id="faq.how_to_install"> 263 <question xml:id="q-how_to_install"> 264 <para>How do I install libstdc++? 265 </para> 266 </question> 267 <answer xml:id="a-how_to_install"> 268 <para> 269 Often libstdc++ comes pre-installed as an integral part of many 270 existing GNU/Linux and Unix systems, as well as many embedded 271 development tools. It may be necessary to install extra 272 development packages to get the headers, or the documentation, or 273 the source: please consult your vendor for details. 274 </para> 275 <para> 276 To build and install from the GNU GCC sources, please consult the 277 <link linkend="manual.intro.setup">setup 278 documentation</link> for detailed 279 instructions. You may wish to browse those files ahead 280 of time to get a feel for what's required. 281 </para> 282 </answer> 283</qandaentry> 284 285<qandaentry xml:id="faq.how_to_get_sources"> 286 <question xml:id="q-how_to_get_sources"> 287 <para>How does one get current libstdc++ sources? 288 </para> 289 </question> 290 <answer xml:id="a-how_to_get_sources"> 291 <para> 292 Libstdc++ sources for all official releases can be obtained as 293 part of the GCC sources, available from various sites and 294 mirrors. A full <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://gcc.gnu.org/mirrors.html">list of 295 download sites</link> is provided on the main GCC site. 296 </para> 297 <para> 298 Current libstdc++ sources can always be found in the main GCC source 299 repository, available using the appropriate version control tool. 300 At this time, that tool is <application>Git</application>. 301 For more details see the documentation on 302 <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://gcc.gnu.org/git.html">using the Git repository</link>. 303 </para> 304 </answer> 305</qandaentry> 306 307<qandaentry xml:id="faq.how_to_test"> 308 <question xml:id="q-how_to_test"> 309 <para>How do I know if it works? 310 </para> 311 </question> 312 <answer xml:id="a-how_to_test"> 313 <para> 314 Libstdc++ comes with its own validation testsuite, which includes 315 conformance testing, regression testing, ABI testing, and 316 performance testing. Please consult the 317 <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/install/test.html">testing 318 documentation</link> for GCC and 319 <link linkend="manual.intro.setup.test">Testing</link> in the libstdc++ 320 manual for more details. 321 </para> 322 <para> 323 If you find bugs in the testsuite programs themselves, or if you 324 think of a new test program that should be added to the suite, 325 <emphasis>please</emphasis> write up your idea and send it to the list! 326 </para> 327 </answer> 328</qandaentry> 329 330<qandaentry xml:id="faq.how_to_set_paths"> 331 <question xml:id="q-how_to_set_paths"> 332 <para>How do I insure that the dynamically linked library will be found? 333 </para> 334 </question> 335 <answer xml:id="a-how_to_set_paths"> 336 <para> 337 Depending on your platform and library version, the error message might 338 be similar to one of the following: 339 </para> 340 341 <screen> 342 ./a.out: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory 343 344 /usr/libexec/ld-elf.so.1: Shared object "libstdc++.so.6" not found 345 </screen> 346 347 <para> 348 This doesn't mean that the shared library isn't installed, only 349 that the dynamic linker can't find it. When a dynamically-linked 350 executable is run the linker finds and loads the required shared 351 libraries by searching a pre-configured list of directories. If 352 the directory where you've installed libstdc++ is not in this list 353 then the libraries won't be found. 354 </para> 355 356 <para> 357 If you already have an older version of libstdc++ installed then the 358 error might look like one of the following instead: 359 </para> 360 361 <screen> 362 ./a.out: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.20' not found 363 ./a.out: /usr/lib/libstdc++.so.6: version `CXXABI_1.3.8' not found 364 </screen> 365 366 <para> 367 This means the linker found <filename>/usr/lib/libstdc++.so.6</filename> 368 but that library belongs to an older version of GCC than was used to 369 compile and link the program <filename>a.out</filename> (or some part 370 of it). The program depends on code defined in the newer libstdc++ 371 that belongs to the newer version of GCC, so the linker must be told 372 how to find the newer libstdc++ shared library. 373 </para> 374 375 <para> 376 The simplest way to fix this is 377 to use the <envar>LD_LIBRARY_PATH</envar> environment variable, 378 which is a colon-separated list of directories in which the linker 379 will search for shared libraries: 380 </para> 381 382 <screen><command> 383 export LD_LIBRARY_PATH=${prefix}/lib:$LD_LIBRARY_PATH 384 </command></screen> 385 386 <para> 387 Here the shell variable <varname>${prefix}</varname> is assumed to contain 388 the directory prefix where GCC was installed to. The directory containing 389 the library might depend on whether you want the 32-bit or 64-bit copy 390 of the library, so for example would be 391 <filename class="directory">${prefix}/lib64</filename> on some systems. 392 The exact environment variable to use will depend on your 393 platform, e.g. <envar>DYLD_LIBRARY_PATH</envar> for Darwin, 394 <envar>LD_LIBRARY_PATH_32</envar>/<envar>LD_LIBRARY_PATH_64</envar> 395 for Solaris 32-/64-bit, 396 and <envar>SHLIB_PATH</envar> for HP-UX. 397 </para> 398 <para> 399 See the man pages for <command>ld</command>, <command>ldd</command> 400 and <command>ldconfig</command> for more information. The dynamic 401 linker has different names on different platforms but the man page 402 is usually called something such as <filename>ld.so</filename>, 403 <filename>rtld</filename> or <filename>dld.so</filename>. 404 </para> 405 <para> 406 Using <envar>LD_LIBRARY_PATH</envar> is not always the best solution, 407 <link linkend="manual.intro.using.linkage.dynamic">Finding Dynamic or Shared 408 Libraries</link> in the manual gives some alternatives. 409 </para> 410 </answer> 411</qandaentry> 412 413<qandaentry xml:id="faq.what_is_libsupcxx"> 414 <question xml:id="q-what_is_libsupcxx"> 415 <para> 416 What's libsupc++? 417 </para> 418 </question> 419 <answer xml:id="a-what_is_libsupcxx"> 420 <para> 421 If the only functions from <filename class="libraryfile">libstdc++.a</filename> 422 which you need are language support functions (those listed in 423 <link linkend="std.support">clause 18</link> of the 424 standard, e.g., <function>new</function> and 425 <function>delete</function>), then try linking against 426 <filename class="libraryfile">libsupc++.a</filename>, which is a subset of 427 <filename class="libraryfile">libstdc++.a</filename>. (Using <command>gcc</command> 428 instead of <command>g++</command> and explicitly linking in 429 <filename class="libraryfile">libsupc++.a</filename> via <option>-lsupc++</option> 430 for the final link step will do it). This library contains only 431 those support routines, one per object file. But if you are 432 using anything from the rest of the library, such as IOStreams 433 or vectors, then you'll still need pieces from 434 <filename class="libraryfile">libstdc++.a</filename>. 435 </para> 436 </answer> 437</qandaentry> 438 439<qandaentry xml:id="faq.size"> 440 <question xml:id="q-size"> 441 <para> 442 This library is HUGE! 443 </para> 444 </question> 445 <answer xml:id="a-size"> 446 <para> 447 Usually the size of libraries on disk isn't noticeable. When a 448 link editor (or simply <quote>linker</quote>) pulls things from a 449 static archive library, only the necessary object files are copied 450 into your executable, not the entire library. Unfortunately, even 451 if you only need a single function or variable from an object file, 452 the entire object file is extracted. (There's nothing unique to C++ 453 or libstdc++ about this; it's just common behavior, given here 454 for background reasons.) 455 </para> 456 <para> 457 Some of the object files which make up 458 <filename class="libraryfile">libstdc++.a</filename> are rather large. 459 If you create a statically-linked executable with 460 <option>-static</option>, those large object files are suddenly part 461 of your executable. Historically the best way around this was to 462 only place a very few functions (often only a single one) in each 463 source/object file; then extracting a single function is the same 464 as extracting a single <filename>.o</filename> file. For libstdc++ this 465 is only possible to a certain extent; the object files in question contain 466 template classes and template functions, pre-instantiated, and 467 splitting those up causes severe maintenance headaches. 468 </para> 469 <para> 470 On supported platforms, libstdc++ takes advantage of garbage 471 collection in the GNU linker to get a result similar to separating 472 each symbol into a separate source and object files. On these platforms, 473 GNU ld can place each function and variable into its own 474 section in a <filename>.o</filename> file. The GNU linker can then perform 475 garbage collection on unused sections; this reduces the situation to only 476 copying needed functions into the executable, as before, but all 477 happens automatically. 478 </para> 479 </answer> 480</qandaentry> 481 482</qandadiv> 483 484 485<!-- Platform-Specific Issues --> 486<qandadiv xml:id="faq.platform-specific" xreflabel="Platform-Specific Issues"> 487 488 489<qandaentry xml:id="faq.other_compilers"> 490 <question xml:id="q-other_compilers"> 491 <para> 492 Can libstdc++ be used with non-GNU compilers? 493 </para> 494 </question> 495 <answer xml:id="a-other_compilers"> 496 <para> 497 Perhaps. 498 </para> 499 <para> 500 Since the goal of ISO Standardization is for all C++ 501 implementations to be able to share code, libstdc++ should be 502 usable under any ISO-compliant compiler, at least in theory. 503 </para> 504 <para> 505 However, the reality is that libstdc++ is targeted and optimized 506 for GCC/G++. This means that often libstdc++ uses specific, 507 non-standard features of G++ that are not present in older 508 versions of proprietary compilers. It may take as much as a year or two 509 after an official release of GCC that contains these features for 510 proprietary tools to support these constructs. 511 </para> 512 <para> 513 Recent versions of libstdc++ are known to work with the Clang compiler. 514 In the near past, specific released versions of libstdc++ have 515 been known to work with versions of the EDG C++ compiler, and 516 vendor-specific proprietary C++ compilers such as the Intel ICC 517 C++ compiler. 518 </para> 519 520 </answer> 521</qandaentry> 522 523<qandaentry xml:id="faq.solaris_long_long"> 524 <question xml:id="q-solaris_long_long"> 525 <para> 526 No '<type>long long</type>' type on Solaris? 527 </para> 528 </question> 529 <answer xml:id="a-solaris_long_long"> 530 <note> 531 <para>This answer is old and probably no longer be relevant.</para> 532 </note> 533 <para> 534 By default we try to support the C99 <type>long long</type> type. 535 This requires that certain functions from your C library be present. 536 </para> 537 <para> 538 Up through release 3.0.2 the platform-specific tests performed by 539 libstdc++ were too general, resulting in a conservative approach 540 to enabling the <type>long long</type> code paths. The most 541 commonly reported platform affected was Solaris. 542 </para> 543 <para> 544 This has been fixed for libstdc++ releases greater than 3.0.3. 545 </para> 546 </answer> 547</qandaentry> 548 549<qandaentry xml:id="faq.predefined"> 550 <question xml:id="q-predefined"> 551 <para> 552 <constant>_XOPEN_SOURCE</constant> and <constant>_GNU_SOURCE</constant> are always defined? 553 </para> 554 </question> 555 <answer xml:id="a-predefined"> 556 <para>On Solaris, <command>g++</command> (but not <command>gcc</command>) 557 always defines the preprocessor macro 558 <constant>_XOPEN_SOURCE</constant>. On GNU/Linux, the same happens 559 with <constant>_GNU_SOURCE</constant>. (This is not an exhaustive list; 560 other macros and other platforms are also affected.) 561 </para> 562 <para>These macros are typically used in C library headers, guarding new 563 versions of functions from their older versions. The C++98 standard 564 library includes the C standard library, but it requires the C90 565 version, which for backwards-compatibility reasons is often not the 566 default for many vendors. 567 </para> 568 <para>More to the point, the C++ standard requires behavior which is only 569 available on certain platforms after certain symbols are defined. 570 Usually the issue involves I/O-related typedefs. In order to 571 ensure correctness, the compiler simply predefines those symbols. 572 </para> 573 <para>Note that it's not enough to <literal>#define</literal> them only when the library is 574 being built (during installation). Since we don't have an 'export' 575 keyword, much of the library exists as headers, which means that 576 the symbols must also be defined as your programs are parsed and 577 compiled. 578 </para> 579 <para>To see which symbols are defined, look for 580 <varname>CPLUSPLUS_CPP_SPEC</varname> in 581 the gcc config headers for your target (and try changing them to 582 see what happens when building complicated code). You can also run 583 <command>g++ -E -dM -x c++ /dev/null</command> to display 584 a list of predefined macros for any particular installation. 585 </para> 586 <para>This has been discussed on the mailing lists 587 <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>. 588 </para> 589 <para>This method is something of a wart. We'd like to find a cleaner 590 solution, but nobody yet has contributed the time. 591 </para> 592 593 </answer> 594</qandaentry> 595 596<qandaentry xml:id="faq.darwin_ctype"> 597 <question xml:id="q-darwin_ctype"> 598 <para> 599 Mac OS X <filename class="headerfile">ctype.h</filename> is broken! How can I fix it? 600 </para> 601 </question> 602 <answer xml:id="a-darwin_ctype"> 603 <note> 604 <para>This answer is old and probably no longer be relevant.</para> 605 </note> 606 <para> 607 This was a long-standing bug in the OS X support. Fortunately, the 608 <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/ml/gcc/2002-03/msg00817.html">patch</link> 609 was quite simple, and well-known. 610 </para> 611 612 </answer> 613</qandaentry> 614 615<qandaentry xml:id="faq.threads_i386"> 616 <question xml:id="q-threads_i386"> 617 <para> 618 Threading is broken on i386? 619 </para> 620 </question> 621 <answer xml:id="a-threads_i386"> 622 <note> 623 <para>This answer is old and probably no longer be relevant.</para> 624 </note> 625 <para>Support for atomic integer operations was broken on i386 626 platforms. The assembly code accidentally used opcodes that are 627 only available on the i486 and later. So if you configured GCC 628 to target, for example, i386-linux, but actually used the programs 629 on an i686, then you would encounter no problems. Only when 630 actually running the code on a i386 will the problem appear. 631 </para> 632 <para>This is fixed in 3.2.2. 633 </para> 634 635 </answer> 636</qandaentry> 637 638<qandaentry xml:id="faq.atomic_mips"> 639 <question xml:id="q-atomic_mips"> 640 <para> 641 MIPS atomic operations 642 </para> 643 </question> 644 <answer xml:id="a-atomic_mips"> 645 <note> 646 <para>This answer is old and probably no longer be relevant.</para> 647 </note> 648 <para> 649 The atomic locking routines for MIPS targets requires MIPS II 650 and later. A patch went in just after the 3.3 release to 651 make mips* use the generic implementation instead. You can also 652 configure for mipsel-elf as a workaround. 653 </para> 654 <para> 655 The mips*-*-linux* port continues to use the MIPS II routines, and more 656 work in this area is expected. 657 </para> 658 </answer> 659</qandaentry> 660 661<qandaentry xml:id="faq.linux_glibc"> 662 <question xml:id="q-linux_glibc"> 663 <para> 664 Recent GNU/Linux glibc required? 665 </para> 666 </question> 667 <answer xml:id="a-linux_glibc"> 668 <para>When running on GNU/Linux, libstdc++ 3.2.1 (shared library version 669 5.0.1) and later uses localization and formatting code from the system 670 C library (glibc) version 2.2.5 which contains necessary bugfixes. 671 All GNU/Linux distros make more recent versions available now. 672 libstdc++ 4.6.0 and later require glibc 2.3 or later for this 673 localization and formatting code. 674 </para> 675 <para>The guideline is simple: the more recent the C++ library, the 676 more recent the C library. (This is also documented in the main 677 GCC installation instructions.) 678 </para> 679 680 </answer> 681</qandaentry> 682 683<qandaentry xml:id="faq.freebsd_wchar"> 684 <question xml:id="q-freebsd_wchar"> 685 <para> 686 Can't use <type>wchar_t</type>/<classname>wstring</classname> on FreeBSD 687 </para> 688 </question> 689 <answer xml:id="a-freebsd_wchar"> 690 <note> 691 <para>This answer is old and probably no longer be relevant.</para> 692 </note> 693 <para> 694 Older versions of FreeBSD's C library do not have sufficient 695 support for wide character functions, and as a result the 696 libstdc++ configury decides that <type>wchar_t</type> support should be 697 disabled. In addition, the libstdc++ platform checks that 698 enabled <type>wchar_t</type> were quite strict, and not granular 699 enough to detect when the minimal support to 700 enable <type>wchar_t</type> and C++ library structures 701 like <classname>wstring</classname> were present. This impacted Solaris, 702 Darwin, and BSD variants, and is fixed in libstdc++ versions post 4.1.0. 703 </para> 704 <para> 705 </para> 706 </answer> 707</qandaentry> 708 709</qandadiv> 710 711 712<!-- Known Bugs --> 713<qandadiv xml:id="faq.known_bugs" xreflabel="Known Bugs"> 714 715 716<qandaentry xml:id="faq.what_works"> 717 <question xml:id="q-what_works"> 718 <para> 719 What works already? 720 </para> 721 </question> 722 <answer xml:id="a-what_works"> 723 <para> 724 Short answer: Pretty much everything <emphasis>works</emphasis> 725 except for some corner cases. Support for localization 726 in <classname>locale</classname> may be incomplete on some non-GNU 727 platforms. Also dependent on the underlying platform is support 728 for <type>wchar_t</type> and <type>long long</type> specializations, 729 and details of thread support. 730 </para> 731 <para> 732 Long answer: See the implementation status pages for 733 <link linkend="status.iso.1998">C++98</link>, 734 <link linkend="status.iso.tr1">TR1</link>, 735 <link linkend="status.iso.2011">C++11</link>, 736 <link linkend="status.iso.2014">C++14</link>, and 737 <link linkend="status.iso.2017">C++17</link>. 738 </para> 739 </answer> 740</qandaentry> 741 742<qandaentry xml:id="faq.standard_bugs"> 743 <question xml:id="q-standard_bugs"> 744 <para> 745 Bugs in the ISO C++ language or library specification 746 </para> 747 </question> 748 <answer xml:id="a-standard_bugs"> 749 <para> 750 Unfortunately, there are some. 751 </para> 752 <para> 753 For those people who are not part of the ISO Library Group 754 (i.e., nearly all of us needing to read this page in the first 755 place), a public list of the library defects is occasionally 756 published on <link xmlns:xlink="http://www.w3.org/1999/xlink" 757 xlink:href="http://www.open-std.org/jtc1/sc22/wg21/">the WG21 758 website</link>. 759 Many of these issues have resulted in 760 <link linkend="manual.intro.status.bugs.iso">code changes in libstdc++</link>. 761 </para> 762 <para> 763 If you think you've discovered a new bug that is not listed, 764 please post a message describing your problem to the author of 765 the library issues list. 766 </para> 767 </answer> 768</qandaentry> 769 770<qandaentry xml:id="faq.compiler_bugs"> 771 <question xml:id="q-compiler_bugs"> 772 <para> 773 Bugs in the compiler (gcc/g++) and not libstdc++ 774 </para> 775 </question> 776 <answer xml:id="a-compiler_bugs"> 777 <para> 778 On occasion, the compiler is wrong. Please be advised that this 779 happens much less often than one would think, and avoid jumping to 780 conclusions. 781 </para> 782 <para> 783 First, examine the ISO C++ standard. Second, try another compiler 784 or an older version of the GNU compilers. Third, you can find more 785 information on the libstdc++ and the GCC mailing lists: search 786 these lists with terms describing your issue. 787 </para> 788 <para> 789 Before reporting a bug, please examine the 790 <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://gcc.gnu.org/bugs/">bugs database</link>, with the 791 component set to <quote>c++</quote>. 792 </para> 793 </answer> 794</qandaentry> 795 796</qandadiv> 797 798<!-- Known Non-Bugs --> 799<qandadiv xml:id="faq.known_non-bugs" xreflabel="Known Non-Bugs"> 800 801 802<qandaentry xml:id="faq.stream_reopening_fails"> 803 <question xml:id="q-stream_reopening_fails"> 804 <para> 805 Reopening a stream fails 806 </para> 807 </question> 808 <answer xml:id="a-stream_reopening_fails"> 809 <note> 810 <para>This answer is old and probably no longer be relevant.</para> 811 </note> 812 <para> 813 Prior to GCC 4.0 this was one of the most-reported non-bug reports. 814 Executing a sequence like this would fail: 815 </para> 816 817 <programlisting> 818 #include <fstream> 819 ... 820 std::fstream fs("a_file"); 821 // . 822 // . do things with fs... 823 // . 824 fs.close(); 825 fs.open("a_new_file"); 826 </programlisting> 827 828 <para> 829 All operations on the re-opened <varname>fs</varname> would fail, or at 830 least act very strangely, especially if <varname>fs</varname> reached the 831 EOF state on the previous file. 832 The original C++98 standard did not specify behavior in this case, and 833 the <link linkend="manual.bugs.dr22">resolution of DR #22</link> was to 834 leave the state flags unchanged on a successful call to 835 <function>open()</function>. 836 You had to insert a call to <function>fs.clear()</function> between the 837 calls to <function>close()</function> and <function>open()</function>, 838 and then everything will work as expected. 839 <emphasis>Update:</emphasis> For GCC 4.0 we implemented the resolution 840 of <link linkend="manual.bugs.dr409">DR #409</link> and 841 <function>open()</function> 842 now calls <function>clear()</function> on success. 843 </para> 844 </answer> 845</qandaentry> 846 847<qandaentry xml:id="faq.wefcxx_verbose"> 848 <question xml:id="q-wefcxx_verbose"> 849 <para> 850 -Weffc++ complains too much 851 </para> 852 </question> 853 <answer xml:id="a-wefcxx_verbose"> 854 <para> 855 Many warnings are emitted when <option>-Weffc++</option> is used. Making 856 libstdc++ <option>-Weffc++</option>-clean is not a goal of the project, 857 for a few reasons. Mainly, that option tries to enforce 858 object-oriented programming, while the Standard Library isn't 859 necessarily trying to be OO. The option also enforces outdated guidelines 860 from old editions of the books, and the advice isn't all relevant to 861 modern C++ (especially C++11 and later). 862 </para> 863 <para> 864 We do, however, try to have libstdc++ sources as clean as possible. If 865 you see some simple changes that pacify <option>-Weffc++</option> 866 without other drawbacks, send us a patch. 867 </para> 868 </answer> 869</qandaentry> 870 871<qandaentry xml:id="faq.ambiguous_overloads"> 872 <question xml:id="q-ambiguous_overloads"> 873 <para> 874 Ambiguous overloads after including an old-style header 875 </para> 876 </question> 877 <answer xml:id="a-ambiguous_overloads"> 878 <note> 879 <para>This answer is old and probably no longer be relevant.</para> 880 </note> 881 <para> 882 Another problem is the <literal>rel_ops</literal> namespace and the template 883 comparison operator functions contained therein. If they become 884 visible in the same namespace as other comparison functions 885 (e.g., <quote>using</quote> them and the 886 <filename class="headerfile"><iterator></filename> header), 887 then you will suddenly be faced with huge numbers of ambiguity 888 errors. This was discussed on the mailing list; Nathan Myers 889 <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html">sums 890 things up here</link>. The collisions with vector/string iterator 891 types have been fixed for 3.1. 892 </para> 893 </answer> 894</qandaentry> 895 896<qandaentry xml:id="faq.v2_headers"> 897 <question xml:id="q-v2_headers"> 898 <para> 899 The g++-3 headers are <emphasis>not ours</emphasis> 900 </para> 901 </question> 902 <answer xml:id="a-v2_headers"> 903 <note> 904 <para>This answer is old and probably no longer be relevant.</para> 905 </note> 906 <para> 907 If you are using headers in 908 <filename class="directory">${prefix}/include/g++-3</filename>, or if 909 the installed library's name looks like 910 <filename class="libraryfile">libstdc++-2.10.a</filename> or 911 <filename class="libraryfile">libstdc++-libc6-2.10.so</filename>, then 912 you are using the old libstdc++-v2 library, which is non-standard and 913 unmaintained. Do not report problems with -v2 to the -v3 914 mailing list. 915 </para> 916 <para> 917 For GCC versions 3.0 and 3.1 the libstdc++ header files are installed in 918 <filename class="directory">${prefix}/include/g++-v3</filename> 919 (see the 'v'?). Starting with version 3.2 the headers are installed in 920 <filename class="directory">${prefix}/include/c++/${version}</filename> 921 as this prevents headers from previous versions being found by mistake. 922 </para> 923 924 </answer> 925</qandaentry> 926 927<qandaentry xml:id="faq.boost_concept_checks"> 928 <question xml:id="q-boost_concept_checks"> 929 <para> 930 Errors about <emphasis>*Concept</emphasis> and 931 <emphasis>constraints</emphasis> in the STL 932 </para> 933 </question> 934 <answer xml:id="a-boost_concept_checks"> 935 <para> 936 If you see compilation errors containing messages about 937 <errortext>foo Concept</errortext> and something to do with a 938 <errortext>constraints</errortext> member function, then most 939 likely you have violated one of the requirements for types used 940 during instantiation of template containers and functions. For 941 example, EqualityComparableConcept appears if your types must be 942 comparable with == and you have not provided this capability (a 943 typo, or wrong visibility, or you just plain forgot, etc). 944 </para> 945 <para> 946 More information, including how to optionally enable/disable the 947 checks, is available in the 948 <link linkend="std.diagnostics.concept_checking">Diagnostics</link>. 949 chapter of the manual. 950 </para> 951 </answer> 952</qandaentry> 953 954<qandaentry xml:id="faq.dlopen_crash"> 955 <question xml:id="q-dlopen_crash"> 956 <para> 957 Program crashes when using library code in a 958 dynamically-loaded library 959 </para> 960 </question> 961 <answer xml:id="a-dlopen_crash"> 962 <para> 963 If you are using the C++ library across dynamically-loaded 964 objects, make certain that you are passing the correct options 965 when compiling and linking: 966 </para> 967 968 <literallayout class="normal"> 969 Compile your library components: 970 <command>g++ -fPIC -c a.cc</command> 971 <command>g++ -fPIC -c b.cc</command> 972 ... 973 <command>g++ -fPIC -c z.cc</command> 974 975 Create your library: 976 <command>g++ -fPIC -shared -rdynamic -o libfoo.so a.o b.o ... z.o</command> 977 978 Link the executable: 979 <command>g++ -fPIC -rdynamic -o foo ... -L. -lfoo -ldl</command> 980 </literallayout> 981 </answer> 982</qandaentry> 983 984<qandaentry xml:id="faq.memory_leaks"> 985 <question xml:id="q-memory_leaks"> 986 <para> 987 <quote>Memory leaks</quote> in libstdc++ 988 </para> 989 </question> 990 <answer xml:id="a-memory_leaks"> 991 <para> 992 Since GCC 5.1.0, libstdc++ automatically allocates a pool 993 of a few dozen kilobytes on startup. This pool is used to ensure it's 994 possible to throw exceptions (such as <classname>bad_alloc</classname>) 995 even when <code>malloc</code> is unable to allocate any more memory. 996 With some versions of <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://valgrind.org"><command>valgrind</command></link> 997 this pool will be shown as "still reachable" when the process exits, e.g. 998 <code>still reachable: 72,704 bytes in 1 blocks</code>. 999 This memory is not a leak, because it's still in use by libstdc++, 1000 and the memory will be returned to the OS when the process exits. 1001 Later versions of <command>valgrind</command> know how to free this 1002 pool as the process exits, and so won't show any "still reachable" memory. 1003 </para> 1004 <para> 1005 In the past, a few people reported that the standard containers appear 1006 to leak memory when tested with memory checkers such as 1007 <command>valgrind</command>. 1008 Under some (non-default) configurations the library's allocators keep 1009 free memory in a 1010 pool for later reuse, rather than deallocating it with <code>delete</code> 1011 Although this memory is always reachable by the library and is never 1012 lost, memory debugging tools can report it as a leak. If you 1013 want to test the library for memory leaks please read 1014 <link linkend="debug.memory">Tips for memory leak hunting</link> 1015 first. 1016 </para> 1017 </answer> 1018</qandaentry> 1019 1020<qandaentry xml:id="faq.list_size_on"> 1021 <question xml:id="q-list_size_on"> 1022 <para> 1023 <code>list::size()</code> is O(n)! 1024 </para> 1025 </question> 1026 <answer xml:id="a-list_size_on"> 1027 <para> 1028 See 1029 the <link linkend="std.containers">Containers</link> 1030 chapter. 1031 </para> 1032 </answer> 1033</qandaentry> 1034 1035<qandaentry xml:id="faq.easy_to_fix"> 1036 <question xml:id="q-easy_to_fix"> 1037 <para> 1038 Aw, that's easy to fix! 1039 </para> 1040 </question> 1041 <answer xml:id="a-easy_to_fix"> 1042 <para> 1043 If you have found a bug in the library and you think you have 1044 a working fix, then send it in! The main GCC site has a page 1045 on <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/contribute.html">submitting 1046 patches</link> that covers the procedure, but for libstdc++ you 1047 should also send the patch to our mailing list in addition to 1048 the GCC patches mailing list. The libstdc++ 1049 <link linkend="appendix.contrib">contributors' page</link> 1050 also talks about how to submit patches. 1051 </para> 1052 <para> 1053 In addition to the description, the patch, and the ChangeLog 1054 entry, it is a Good Thing if you can additionally create a small 1055 test program to test for the presence of the bug that your patch 1056 fixes. Bugs have a way of being reintroduced; if an old bug 1057 creeps back in, it will be caught immediately by the testsuite - 1058 but only if such a test exists. 1059 </para> 1060 </answer> 1061</qandaentry> 1062 1063</qandadiv> 1064 1065 1066<!-- Miscellaneous --> 1067<qandadiv xml:id="faq.misc" xreflabel="Miscellaneous"> 1068 1069 1070<qandaentry xml:id="faq.iterator_as_pod"> 1071 <question xml:id="faq.iterator_as_pod_q"> 1072 <para> 1073 <classname>string::iterator</classname> is not <code>char*</code>; 1074 <classname>vector<T>::iterator</classname> is not <code>T*</code> 1075 </para> 1076 </question> 1077 <answer xml:id="faq.iterator_as_pod_a"> 1078 <para> 1079 If you have code that depends on container<T> iterators 1080 being implemented as pointer-to-T, your code is broken. It's 1081 considered a feature, not a bug, that libstdc++ points this out. 1082 </para> 1083 <para> 1084 While there are arguments for iterators to be implemented in 1085 that manner, A) they aren't very good ones in the long term, 1086 and B) they were never guaranteed by the Standard anyway. The 1087 type-safety achieved by making iterators a real class rather 1088 than a typedef for <type>T*</type> outweighs nearly all opposing 1089 arguments. 1090 </para> 1091 <para> 1092 Code which does assume that a vector/string iterator <varname>i</varname> 1093 is a pointer can often be fixed by changing <varname>i</varname> in 1094 certain expressions to <varname>&*i</varname>. 1095 </para> 1096 </answer> 1097</qandaentry> 1098 1099<qandaentry xml:id="faq.what_is_next"> 1100 <question xml:id="q-what_is_next"> 1101 <para> 1102 What's next after libstdc++? 1103 </para> 1104 </question> 1105 <answer xml:id="a-what_is_next"> 1106 <para> 1107 The goal of libstdc++ is to produce a 1108 fully-compliant, fully-portable Standard Library. 1109 While the C++ Standard continues to evolve the libstdc++ will 1110 continue to track it. 1111 </para> 1112 </answer> 1113</qandaentry> 1114 1115<qandaentry xml:id="faq.sgi_stl"> 1116 <question xml:id="q-sgi_stl"> 1117 <para> 1118 What about the STL from SGI? 1119 </para> 1120 </question> 1121 <answer xml:id="a-sgi_stl"> 1122 <para> 1123 The STL (Standard Template Library) was the inspiration for large chunks 1124 of the C++ Standard Library, but the terms are not interchangeable and 1125 they don't mean the same thing. The C++ Standard Library includes lots of 1126 things that didn't come from the STL, and some of them aren't even 1127 templates, such as <classname>std::locale</classname> and 1128 <classname>std::thread</classname>. 1129 </para> 1130 <para> 1131 Libstdc++-v3 incorporates a lot of code from 1132 <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> 1133 (the final merge was from 1134 <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>). 1135 The code in libstdc++ contains many fixes and changes compared to the 1136 original SGI code. 1137 </para> 1138 <para> 1139 In particular, <classname>string</classname> is not from SGI and makes no 1140 use of their "rope" class (although that is included as an optional 1141 extension), neither is <classname>valarray</classname> nor some others. 1142 Classes like <classname>vector<></classname> were from SGI, but have 1143 been extensively modified. 1144 </para> 1145 <para> 1146 More information on the evolution of libstdc++ can be found at the 1147 <link linkend="appendix.porting.api">API 1148 evolution</link> 1149 and <link linkend="manual.appendix.porting.backwards">backwards 1150 compatibility</link> documentation. 1151 </para> 1152 <para> 1153 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> 1154 for SGI's STL is still recommended reading. 1155 </para> 1156 </answer> 1157</qandaentry> 1158 1159<qandaentry xml:id="faq.extensions_and_backwards_compat"> 1160 <question xml:id="q-extensions_and_backwards_compat"> 1161 <para> 1162 Extensions and Backward Compatibility 1163 </para> 1164 </question> 1165 <answer xml:id="a-extensions_and_backwards_compat"> 1166 <para> 1167 See the <link linkend="manual.appendix.porting.backwards">link</link> on backwards compatibility and <link linkend="appendix.porting.api">link</link> on evolution. 1168 </para> 1169 </answer> 1170</qandaentry> 1171 1172<qandaentry xml:id="faq.tr1_support"> 1173 <question xml:id="q-tr1_support"> 1174 <para> 1175 Does libstdc++ support TR1? 1176 </para> 1177 </question> 1178 <answer xml:id="a-tr1_support"> 1179 <para> 1180 Yes. 1181 </para> 1182 <para> 1183 The C++ Standard Library 1184 <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf"> 1185 Technical Report 1</link> added many new features to the library. 1186 </para> 1187 <para> 1188 The implementation status of TR1 in libstdc++ can be tracked 1189 <link linkend="status.iso.tr1">on the TR1 status page</link>. 1190 </para> 1191 <para> 1192 New code should probably not use TR1, because almost everything in it has 1193 been added to the main C++ Standard Library (usually with significant 1194 improvements). 1195 The TR1 implementation in libstdc++ is no longer actively maintained. 1196 </para> 1197 </answer> 1198</qandaentry> 1199 1200<qandaentry xml:id="faq.get_iso_cxx"> 1201 <question xml:id="q-get_iso_cxx"> 1202 <para>How do I get a copy of the ISO C++ Standard? 1203 </para> 1204 </question> 1205 <answer xml:id="a-get_iso_cxx"> 1206 <para> 1207 Please refer to the <link linkend="appendix.contrib">Contributing</link> 1208 section in our manual. 1209 </para> 1210 </answer> 1211</qandaentry> 1212 1213<qandaentry xml:id="faq.what_is_abi"> 1214 <question xml:id="q-what_is_abi"> 1215 <para> 1216 What's an ABI and why is it so messy? 1217 </para> 1218 </question> 1219 <answer xml:id="a-what_is_abi"> 1220 <para> 1221 <acronym>ABI</acronym> stands for <quote>Application Binary 1222 Interface</quote>. Conventionally, it refers to a great 1223 mass of details about how arguments are arranged on the call 1224 stack and/or in registers, and how various types are arranged 1225 and padded in structs. A single CPU design may suffer 1226 multiple ABIs designed by different development tool vendors 1227 who made different choices, or even by the same vendor for 1228 different target applications or compiler versions. In ideal 1229 circumstances the CPU designer presents one ABI and all the 1230 OSes and compilers use it. In practice every ABI omits 1231 details that compiler implementers (consciously or 1232 accidentally) must choose for themselves. 1233 </para> 1234 <para> 1235 That ABI definition suffices for compilers to generate code so a 1236 program can interact safely with an OS and its lowest-level libraries. 1237 Users usually want an ABI to encompass more detail, allowing libraries 1238 built with different compilers (or different releases of the same 1239 compiler!) to be linked together. For C++, this includes many more 1240 details than for C, and most CPU designers (for good reasons elaborated 1241 below) have not stepped up to publish C++ ABIs. Such an ABI has been 1242 defined for the Itanium architecture (see 1243 <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://itanium-cxx-abi.github.io/cxx-abi/">C++ 1244 ABI for Itanium</link>) and that is used by G++ and other compilers 1245 as the de facto standard ABI on many common architectures (including x86). 1246 G++ can also use the ARM architecture's EABI, for embedded 1247 systems relying only on a <quote>free-standing implementation</quote> that 1248 doesn't include (much of) the standard library, and the GNU EABI for 1249 hosted implementations on ARM. Those ABIs cover low-level details 1250 such as virtual function implementation, struct inheritance layout, 1251 name mangling, and exception handling. 1252 </para> 1253 <para> 1254 A useful C++ ABI must also incorporate many details of the standard 1255 library implementation. For a C ABI, the layouts of a few structs 1256 (such as <type>FILE</type>, <type>stat</type>, <type>jmpbuf</type>, 1257 and the like) and a few macros suffice. 1258 For C++, the details include the complete set of names of functions 1259 and types used, the offsets of class members and virtual functions, 1260 and the actual definitions of all inlines. C++ exposes many more 1261 library details to the caller than C does. It makes defining 1262 a complete ABI a much bigger undertaking, and requires not just 1263 documenting library implementation details, but carefully designing 1264 those details so that future bug fixes and optimizations don't 1265 force breaking the ABI. 1266 </para> 1267 <para> 1268 There are ways to help isolate library implementation details from the 1269 ABI, but they trade off against speed. Library details used in inner 1270 loops (e.g., <function>getchar</function>) must be exposed and frozen for 1271 all time, but many others may reasonably be kept hidden from user code, 1272 so they may later be changed. Deciding which, and implementing 1273 the decisions, must happen before you can reasonably document a 1274 candidate C++ ABI that encompasses the standard library. 1275 </para> 1276 </answer> 1277</qandaentry> 1278 1279<qandaentry xml:id="faq.size_equals_capacity"> 1280 <question xml:id="q-size_equals_capacity"> 1281 <para> 1282 How do I make <code>std::vector<T>::capacity() == std::vector<T>::size</code>? 1283 </para> 1284 </question> 1285 <answer xml:id="a-size_equals_capacity"> 1286 <para> 1287 Since C++11 just call the <function>shrink_to_fit()</function> member 1288 function. 1289 </para> 1290 <para> 1291 Before C++11, the standard idiom for deallocating a 1292 <classname>vector<T></classname>'s 1293 unused memory was to create a temporary copy of the vector and swap their 1294 contents, e.g. for <classname>vector<T> v</classname> 1295 </para> 1296 <literallayout class="normal"> 1297 std::vector<T>(v).swap(v); 1298 </literallayout> 1299 <para> 1300 The copy will take O(n) time and the swap is constant time. 1301 </para> 1302 <para> 1303 See <link linkend="strings.string.shrink">Shrink-to-fit 1304 strings</link> for a similar solution for strings. 1305 </para> 1306 </answer> 1307</qandaentry> 1308 1309</qandadiv> 1310 1311 1312<!-- FAQ ends here --> 1313</qandaset> 1314 1315</article> 1316 1317</book> 1318