From 2aad0282e79bee5d49dfd0f76d5c72f6c6912156 Mon Sep 17 00:00:00 2001 From: bkoz Date: Mon, 11 Feb 2008 00:01:33 +0000 Subject: 2008-02-10 Benjamin Kosnik Convert documentation to DocBook. * doc/Makefile.am (doc-doxygen-html): Changed to doc-html-doxygen. (doc-doxygen-man): Changed to doc-man-doxygen. (doc-performance): Changed to doc-html-performance. (doc-xml-doxygen): New. (doc-xml-single): New. (doc-xml-validate): New. (doc-html): New. (doc-html-single): New. (doc-fo): New. (doc-pdf): New. (doc-pdf-fop-xml): New. (doc-pdf-fop-fo): New. (doc-pdf-xmlto): New. (doc-pdf-xmlroff): New. (doc-pdf-prince): New. * doc/xml: New directory. * doc/xml/authors.xml: New. * doc/xml/images: New directory. * doc/xml/images/confdeps.png: Add. * doc/xml/images/confdeps.dot: Add. * doc/xml/faq.xml: New. * doc/xml/api.xml: New. * doc/xml/gnu: New directory. * doc/xml/gnu/gpl-3.0.xml: New. * doc/xml/gnu/fdl-1.2.xml: New. * doc/xml/gnu/gpl-2.0.xml: New. * doc/xml/manual: New directory. * doc/xml/manual/mt_allocator.xml: New. * doc/xml/manual/allocator.xml: New. * doc/xml/manual/ctype.xml: New. * doc/xml/manual/numerics.xml: New. * doc/xml/manual/codecvt.xml: New. * doc/xml/manual/concurrency.xml: New. * doc/xml/manual/backwards_compatibility.xml: New. * doc/xml/manual/intro.xml: New. * doc/xml/manual/shared_ptr.xml: New. * doc/xml/manual/abi.xml: New. * doc/xml/manual/status_cxxtr1.xml: New. * doc/xml/manual/auto_ptr.xml: New. * doc/xml/manual/build.xml: New. * doc/xml/manual/internals.xml: New. * doc/xml/manual/parallel_mode.xml: New. * doc/xml/manual/status_cxx1998.xml: New. * doc/xml/manual/containers.xml: New. * doc/xml/manual/io.xml: New. * doc/xml/manual/appendix_porting.xml: New. * doc/xml/manual/utilities.xml: New. * doc/xml/manual/bitmap_allocator.xml: New. * doc/xml/manual/support.xml: New. * doc/xml/manual/configure.xml: New. * doc/xml/manual/build_hacking.xml: New. * doc/xml/manual/evolution.xml: New. * doc/xml/manual/using.xml: New. * doc/xml/manual/debug.xml: New. * doc/xml/manual/localization.xml: New. * doc/xml/manual/strings.xml: New. * doc/xml/manual/debug_mode.xml: New. * doc/xml/manual/locale.xml: New. * doc/xml/manual/extensions.xml: New. * doc/xml/manual/appendix_contributing.xml: New. * doc/xml/manual/messages.xml: New. * doc/xml/manual/diagnostics.xml: New. * doc/xml/manual/appendix_free.xml: New. * doc/xml/manual/algorithms.xml: New. * doc/xml/manual/iterators.xml: New. * doc/xml/manual/spine.xml: New. * doc/xml/manual/test.xml: New. * doc/xml/manual/status_cxx200x.xml: New. * doc/xml/spine.xml: New. * doc/xml/book.txml: New. Template file. * doc/xml/chapter.txml: Same. * doc/xml/class.txml: Same. * doc/doxygen/guide.html: Removed, integrated into other docs. * doc/doxygen/user.cfg.in: Clean up XML generation. * doc/doxygen/run_doxygen: Move to.. * scripts/run_doxygen: ...here. * configure: Regenerate. * Makefile.in: Regenerate. * src/Makefile.in: Regenerate. * doc/Makefile.in: Regenerate. * po/Makefile.in: Regenerate. * libmath/Makefile.in: Regenerate. * include/Makefile.in: Regenerate. * libsupc++/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. * aclocal.m4: Regenerate. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@132226 138bc75d-0d04-0410-961f-82ee72b054a4 --- libstdc++-v3/doc/xml/api.xml | 94 + libstdc++-v3/doc/xml/authors.xml | 174 + libstdc++-v3/doc/xml/book.txml | 33 + libstdc++-v3/doc/xml/chapter.txml | 54 + libstdc++-v3/doc/xml/class.txml | 154 + libstdc++-v3/doc/xml/faq.xml | 1254 ++++ libstdc++-v3/doc/xml/gnu/fdl-1.2.xml | 502 ++ libstdc++-v3/doc/xml/gnu/gpl-2.0.xml | 366 ++ libstdc++-v3/doc/xml/gnu/gpl-3.0.xml | 836 +++ libstdc++-v3/doc/xml/images/confdeps.dot | 14 + libstdc++-v3/doc/xml/images/confdeps.png | Bin 0 -> 3486 bytes libstdc++-v3/doc/xml/manual/abi.xml | 1130 ++++ libstdc++-v3/doc/xml/manual/algorithms.xml | 104 + libstdc++-v3/doc/xml/manual/allocator.xml | 659 +++ .../doc/xml/manual/appendix_contributing.xml | 1847 ++++++ libstdc++-v3/doc/xml/manual/appendix_free.xml | 176 + libstdc++-v3/doc/xml/manual/appendix_porting.xml | 47 + libstdc++-v3/doc/xml/manual/auto_ptr.xml | 133 + .../doc/xml/manual/backwards_compatibility.xml | 1315 +++++ libstdc++-v3/doc/xml/manual/bitmap_allocator.xml | 559 ++ libstdc++-v3/doc/xml/manual/build.xml | 182 + libstdc++-v3/doc/xml/manual/build_hacking.xml | 354 ++ libstdc++-v3/doc/xml/manual/codecvt.xml | 730 +++ libstdc++-v3/doc/xml/manual/concurrency.xml | 334 ++ libstdc++-v3/doc/xml/manual/configure.xml | 318 + libstdc++-v3/doc/xml/manual/containers.xml | 441 ++ libstdc++-v3/doc/xml/manual/ctype.xml | 259 + libstdc++-v3/doc/xml/manual/debug.xml | 245 + libstdc++-v3/doc/xml/manual/debug_mode.xml | 888 +++ libstdc++-v3/doc/xml/manual/diagnostics.xml | 126 + libstdc++-v3/doc/xml/manual/evolution.xml | 452 ++ libstdc++-v3/doc/xml/manual/extensions.xml | 577 ++ libstdc++-v3/doc/xml/manual/internals.xml | 548 ++ libstdc++-v3/doc/xml/manual/intro.xml | 664 +++ libstdc++-v3/doc/xml/manual/io.xml | 665 +++ libstdc++-v3/doc/xml/manual/iterators.xml | 177 + libstdc++-v3/doc/xml/manual/locale.xml | 653 +++ libstdc++-v3/doc/xml/manual/localization.xml | 54 + libstdc++-v3/doc/xml/manual/messages.xml | 604 ++ libstdc++-v3/doc/xml/manual/mt_allocator.xml | 554 ++ libstdc++-v3/doc/xml/manual/numerics.xml | 143 + libstdc++-v3/doc/xml/manual/parallel_mode.xml | 674 +++ libstdc++-v3/doc/xml/manual/shared_ptr.xml | 580 ++ libstdc++-v3/doc/xml/manual/spine.xml | 111 + libstdc++-v3/doc/xml/manual/status_cxx1998.xml | 6153 ++++++++++++++++++++ libstdc++-v3/doc/xml/manual/status_cxx200x.xml | 2241 +++++++ libstdc++-v3/doc/xml/manual/status_cxxtr1.xml | 2273 ++++++++ libstdc++-v3/doc/xml/manual/strings.xml | 495 ++ libstdc++-v3/doc/xml/manual/support.xml | 448 ++ libstdc++-v3/doc/xml/manual/test.xml | 823 +++ libstdc++-v3/doc/xml/manual/using.xml | 1024 ++++ libstdc++-v3/doc/xml/manual/utilities.xml | 125 + libstdc++-v3/doc/xml/spine.xml | 47 + 53 files changed, 33413 insertions(+) create mode 100644 libstdc++-v3/doc/xml/api.xml create mode 100644 libstdc++-v3/doc/xml/authors.xml create mode 100644 libstdc++-v3/doc/xml/book.txml create mode 100644 libstdc++-v3/doc/xml/chapter.txml create mode 100644 libstdc++-v3/doc/xml/class.txml create mode 100644 libstdc++-v3/doc/xml/faq.xml create mode 100644 libstdc++-v3/doc/xml/gnu/fdl-1.2.xml create mode 100644 libstdc++-v3/doc/xml/gnu/gpl-2.0.xml create mode 100644 libstdc++-v3/doc/xml/gnu/gpl-3.0.xml create mode 100644 libstdc++-v3/doc/xml/images/confdeps.dot create mode 100644 libstdc++-v3/doc/xml/images/confdeps.png create mode 100644 libstdc++-v3/doc/xml/manual/abi.xml create mode 100644 libstdc++-v3/doc/xml/manual/algorithms.xml create mode 100644 libstdc++-v3/doc/xml/manual/allocator.xml create mode 100644 libstdc++-v3/doc/xml/manual/appendix_contributing.xml create mode 100644 libstdc++-v3/doc/xml/manual/appendix_free.xml create mode 100644 libstdc++-v3/doc/xml/manual/appendix_porting.xml create mode 100644 libstdc++-v3/doc/xml/manual/auto_ptr.xml create mode 100644 libstdc++-v3/doc/xml/manual/backwards_compatibility.xml create mode 100644 libstdc++-v3/doc/xml/manual/bitmap_allocator.xml create mode 100644 libstdc++-v3/doc/xml/manual/build.xml create mode 100644 libstdc++-v3/doc/xml/manual/build_hacking.xml create mode 100644 libstdc++-v3/doc/xml/manual/codecvt.xml create mode 100644 libstdc++-v3/doc/xml/manual/concurrency.xml create mode 100644 libstdc++-v3/doc/xml/manual/configure.xml create mode 100644 libstdc++-v3/doc/xml/manual/containers.xml create mode 100644 libstdc++-v3/doc/xml/manual/ctype.xml create mode 100644 libstdc++-v3/doc/xml/manual/debug.xml create mode 100644 libstdc++-v3/doc/xml/manual/debug_mode.xml create mode 100644 libstdc++-v3/doc/xml/manual/diagnostics.xml create mode 100644 libstdc++-v3/doc/xml/manual/evolution.xml create mode 100644 libstdc++-v3/doc/xml/manual/extensions.xml create mode 100644 libstdc++-v3/doc/xml/manual/internals.xml create mode 100644 libstdc++-v3/doc/xml/manual/intro.xml create mode 100644 libstdc++-v3/doc/xml/manual/io.xml create mode 100644 libstdc++-v3/doc/xml/manual/iterators.xml create mode 100644 libstdc++-v3/doc/xml/manual/locale.xml create mode 100644 libstdc++-v3/doc/xml/manual/localization.xml create mode 100644 libstdc++-v3/doc/xml/manual/messages.xml create mode 100644 libstdc++-v3/doc/xml/manual/mt_allocator.xml create mode 100644 libstdc++-v3/doc/xml/manual/numerics.xml create mode 100644 libstdc++-v3/doc/xml/manual/parallel_mode.xml create mode 100644 libstdc++-v3/doc/xml/manual/shared_ptr.xml create mode 100644 libstdc++-v3/doc/xml/manual/spine.xml create mode 100644 libstdc++-v3/doc/xml/manual/status_cxx1998.xml create mode 100644 libstdc++-v3/doc/xml/manual/status_cxx200x.xml create mode 100644 libstdc++-v3/doc/xml/manual/status_cxxtr1.xml create mode 100644 libstdc++-v3/doc/xml/manual/strings.xml create mode 100644 libstdc++-v3/doc/xml/manual/support.xml create mode 100644 libstdc++-v3/doc/xml/manual/test.xml create mode 100644 libstdc++-v3/doc/xml/manual/using.xml create mode 100644 libstdc++-v3/doc/xml/manual/utilities.xml create mode 100644 libstdc++-v3/doc/xml/spine.xml (limited to 'libstdc++-v3/doc/xml') diff --git a/libstdc++-v3/doc/xml/api.xml b/libstdc++-v3/doc/xml/api.xml new file mode 100644 index 00000000000..bd38e8392cc --- /dev/null +++ b/libstdc++-v3/doc/xml/api.xml @@ -0,0 +1,94 @@ + + + + + +
+ + + + API and Source Level Documentation + + + 2008 + + + FSF + + + + + + License + + + + + + +The GNU C++ library sources have been specially formatted so that with the +proper invocation of another tool (Doxygen), a set of HTML pages +are generated from the sources files themselves. The resultant +documentation is referred to as Source Level Documentation, and is +useful for examining the signatures of public member functions for +the library classes, finding out what is in a particular include +file, looking at inheritance diagrams, etc. + + + +The source-level documentation for the most recent releases can be +viewed online: + + + + + + for the 3.4 release + + + + + + for the 4.1 release + + + + + + for the 4.2 release + + + + + + "the latest collection" + + (For the main development tree; see the date on the first page.) + + + + + +This generated HTML collection, as above, is also available for download in the libstdc++ snapshots directory at + <URL:ftp://gcc.gnu.org/pub/gcc/libstdc++/doxygen/>. + You will almost certainly need to use one of the + mirror sites to download + the tarball. After unpacking, simply load libstdc++-html-*/index.html + into a browser. + + + +Documentation for older releases is available for download only, not +online viewing. + + + +In addition, an initial set of man pages are also available in the +same place as the HTML collections. Start with C++Intro(3). + + +
+ + diff --git a/libstdc++-v3/doc/xml/authors.xml b/libstdc++-v3/doc/xml/authors.xml new file mode 100644 index 00000000000..dfcdf24d1b9 --- /dev/null +++ b/libstdc++-v3/doc/xml/authors.xml @@ -0,0 +1,174 @@ + + + + + + Paolo + Carlini + + + + TR1, LWG Active, Closed, Defects lists. + + + + + + Phil + Edwards + + + + Originating author, started HOWTO and FAQ, worked on sections + Demangling, Macros, Strings, Iterators, Backwards + Compatibility, SGI Extensions, Configure, Build, Install. + + + + + + Doug + Gregor + + + + Debug Mode, TR1 function objects + + + + + + Benjamin + Kosnik + + + + Allocators, ABI, API evolution and deprecation history, + Backwards Compatibility, Thread, Debug Support, Locales, + Facets, Parallel Mode, Headers, Namespaces, Construction and + Structure, DocBook conversion and layout. + + + + + + + Dhruv + Matani + + + + bitmap_allocator + + + + + + Jason + Merrill + + + + License, __verbose_terminate_handler + + + + + + Mark + Mitchell + + + + Porting + + + + + + Nathan + Myers + + + + Referenced counted string, C++1998 implementation status. + + + + + + Felix + Natter + + + + Namespace composition, Backwards Compatibility. + + + + + + + Stefan + Olsson + + + + mt_allocator + + + + + + Johannes + Singler + + + + Parallel mode + + + + + + Ami + Tavory + + + + Policy Based Datastructures, Associative Containers, Unordered + Containers. + + + + + + Jonathan + Wakely + + + + shared_ptr, markup editing and styling + + + + + diff --git a/libstdc++-v3/doc/xml/book.txml b/libstdc++-v3/doc/xml/book.txml new file mode 100644 index 00000000000..990ca3bea20 --- /dev/null +++ b/libstdc++-v3/doc/xml/book.txml @@ -0,0 +1,33 @@ + + + + +Source Level Documentation + + + + 2007 + + FSF + + + + + + License + + + + + + + + + + + + + + diff --git a/libstdc++-v3/doc/xml/chapter.txml b/libstdc++-v3/doc/xml/chapter.txml new file mode 100644 index 00000000000..9cf5b74e855 --- /dev/null +++ b/libstdc++-v3/doc/xml/chapter.txml @@ -0,0 +1,54 @@ + + + + + + + + + ISO C++ + + + library + + + + +Introduction + + + Status + + The GNU C++ ... + + + + + Setup + + The GNU C++ ... + + + Next1 + + The GNU C++ ... + + + + Next2 + + The GNU C++ ... + + + + + + Using + + The GNU C++ ... + + + + diff --git a/libstdc++-v3/doc/xml/class.txml b/libstdc++-v3/doc/xml/class.txml new file mode 100644 index 00000000000..4e628f8c7c6 --- /dev/null +++ b/libstdc++-v3/doc/xml/class.txml @@ -0,0 +1,154 @@ + + + + + + + ISO C++ + + + allocator + + + + +allocator + + + + + +Requirements + + + + + + + + + + + + + + + + + + + +Design Issues + + + + + + + + + +Implementation + + + Interface Design + + + + + + + + + + Selecting Default Allocation Strategy + + + + + + + + + + + + + + + + + + Disabling Memory Caching + + + + + + + + + + +Using + + + + + + +Custom Allocators + + + + + + + + + +Bibliography + + + + + + + + + \ No newline at end of file diff --git a/libstdc++-v3/doc/xml/faq.xml b/libstdc++-v3/doc/xml/faq.xml new file mode 100644 index 00000000000..629d1ec12a6 --- /dev/null +++ b/libstdc++-v3/doc/xml/faq.xml @@ -0,0 +1,1254 @@ + + + + + +
+ + + + Frequently Asked Questions + + + 2008 + + + FSF + + + + + + + + + +General Information + + + + + What is libstdc++? + + + + + The GNU Standard C++ Library v3 is an ongoing project to + implement the ISO 14882 Standard C++ library as described in + chapters 17 through 27 and annex D. For those who want to see + exactly how far the project has come, or just want the latest + bleeding-edge code, the up-to-date source is available over + anonymous SVN, and can even be browsed over + the web. + + + + + + + + Why should I use libstdc++? + + + + + The completion of the ISO C++ standardization gave the C++ + community a powerful set of reuseable tools in the form of the C++ + Standard Library. However, all existing C++ implementations are + (as the Draft Standard used to say) incomplet and + incorrekt, and many suffer from limitations of the compilers + that use them. + + + The GNU compiler collection + (gcc, g++, etc) is widely + considered to be one of the leading compilers in the world. Its + development is overseen by the + GCC team. All of + the rapid development and near-legendary + portability + that are the hallmarks of an open-source project are being + applied to libstdc++. + + + That means that all of the Standard classes and functions will be + freely available and fully compliant. (Such as + string, + vector<>, iostreams, and algorithms.) + Programmers will no longer need to roll their own + nor be worried about platform-specific incompatibilities. + + + + + + + + Who's in charge of it? + + + + + The libstdc++ project is contributed to by several developers + all over the world, in the same way as GCC or Linux. + Benjamin Kosnik, Gabriel Dos Reis, Phil Edwards, Ulrich Drepper, + Loren James Rittle, and Paolo Carlini are the lead maintainers of + the SVN archive. + + + Development and discussion is held on the libstdc++ mailing + list. Subscribing to the list, or searching the list + archives, is open to everyone. You can read instructions for + doing so on the homepage. + If you have questions, ideas, code, or are just curious, sign up! + + + + + + + + When is libstdc++ going to be finished? + + + + + Nathan Myers gave the best of all possible answers, responding to + a Usenet article asking this question: Sooner, if you + help. + + + + + + + + How do I contribute to the effort? + + + + + Here is a page devoted to + this topic. Subscribing to the mailing list (see above, or + the homepage) is a very good idea if you have something to + contribute, or if you have spare time and want to + help. Contributions don't have to be in the form of source code; + anybody who is willing to help write documentation, for example, + or has found a bug in code that we all thought was working and is + willing to provide details, is more than welcome! + + + + + + + + What happened to the older libg++? I need that! + + + + + The most recent libg++ README states that libg++ is no longer + being actively maintained. It should not be used for new + projects, and is only being kicked along to support older code. + + + More information in the backwards compatibility documentation + + + + + + + + What if I have more questions? + + + + + If you have read the README file, and your question remains + unanswered, then just ask the mailing list. At present, you do not + need to be subscribed to the list to send a message to it. More + information is available on the homepage (including how to browse + the list archives); to send a message to the list, + use libstdc++@gcc.gnu.org. + + + + If you have a question that you think should be included + here, or if you have a question about a question/answer + here, please send email to the libstdc++ mailing list, as above. + + + + + + + + +License + + + + + What are the license terms for libstdc++? + + + + + See our license description + for these and related questions. + + + + + + + + So any program which uses libstdc++ falls under the GPL? + + + + + No. The special exception permits use of the library in + proprietary applications. + + + + + + + + + How is that different from the GNU {Lesser,Library} GPL? + + + + + 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. + + + + + + + + I see. So, what restrictions are there on programs that use the library? + + + + + None. We encourage such programs to be released as open source, + but we won't punish you or sue you if you choose otherwise. + + + + + + + + +Installation + + + + How do I install libstdc++? + + + + + Often libstdc++ comes pre-installed as an integral part of many + existing Linux and Unix systems, as well as many embedded + development tools. It may be necessary to install extra + development packages to get the headers, or the documentation, or + the source: please consult your vendor for details. + + + To build and install from the GNU GCC sources, please consult the + install + documentation for detailed + instructions. You may wish to browse those files ahead + of time to get a feel for what's required. + + + + + + + How does one get current libstdc++ sources? + + + + + Libstdc++ sources for all official releases can be obtained as + part of the GCC sources, available from various sites and + mirrors. A full list of + download sites is provided on the main GCC site. + + + Current libstdc++ sources can always be checked out of the main + GCC source repository using the appropriate version control + tool. At this time, that tool + is Subversion. + + + Subversion, or SVN, is + one of several revision control packages. It was selected for GNU + projects because it's free (speech), free (beer), and very high + quality. The Subversion + home page has a better description. + + + The anonymous client checkout feature of SVN is + similar to anonymous FTP in that it allows anyone to retrieve + the latest libstdc++ sources. + + + For more information + see SVN + details. + + + + + + + How do I know if it works? + + + + + Libstdc++ comes with its own validation testsuite, which includes + conformance testing, regression testing, ABI testing, and + performance testing. Please consult the + testing + documentation for more details. + + + If you find bugs in the testsuite programs themselves, or if you + think of a new test program that should be added to the suite, + please write up your idea and send it to the list! + + + + + + + How do I insure that the dynamically linked library will be found? + + + + + Depending on your platform and library version, the error message might + be similar to one of the following: + + + + ./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 + + + + This doesn't mean that the shared library isn't installed, only + that the dynamic linker can't find it. When a dynamically-linked + executable is run the linker finds and loads the required shared + libraries by searching a pre-configured list of directories. If + the directory where you've installed libstdc++ is not in this list + then the libraries won't be found. The simplest way to fix this is + to use the LD_LIBRARY_PATH environment variable, + which is a colon-separated list of directories in which the linker + will search for shared libraries: + + + + LD_LIBRARY_PATH=${prefix}/lib:$LD_LIBRARY_PATH + export LD_LIBRARY_PATH + + + + The exact environment variable to use will depend on your + platform, e.g. DYLD_LIBRARY_PATH for Darwin, + LD_LIBRARY_PATH_32/LD_LIBRARY_PATH_64 for Solaris 32-/64-bit, + LD_LIBRARYN32_PATH/LD_LIBRARY64_PATH for Irix N32/64-bit ABIs and + SHLIB_PATH for HP-UX. + + + See the man pages for ld, ldd + and ldconfig for more information. The dynamic + linker has different names on different platforms but the man page + is usually called something such as ld.so/rtld/dld.so. + + + + + + + + What's libsupc++? + + + + + If the only functions from libstdc++.a + which you need are language support functions (those listed in + clause 18 of the + standard, e.g., new and + delete), then try linking against + libsupc++.a, which is a subset of + libstdc++.a. (Using gcc + instead of g++ and explicitly linking in + libsupc++.a via -lsupc++ + for the final link step will do it). This library contains only + those support routines, one per object file. But if you are + using anything from the rest of the library, such as IOStreams + or vectors, then you'll still need pieces from + libstdc++.a. + + + + + + + + This library is HUGE! + + + + + Usually the size of libraries on disk isn't noticeable. When a + link editor (or simply linker) pulls things from a + static archive library, only the necessary object files are copied + into your executable, not the entire library. Unfortunately, even + if you only need a single function or variable from an object file, + the entire object file is extracted. (There's nothing unique to C++ + or libstdc++ about this; it's just common behavior, given here + for background reasons.) + + + Some of the object files which make up libstdc++.a are rather large. + If you create a statically-linked executable with + -static, those large object files are suddenly part + of your executable. Historically the best way around this was to + only place a very few functions (often only a single one) in each + source/object file; then extracting a single function is the same + as extracting a single .o file. For libstdc++ this is only + possible to a certain extent; the object files in question contain + template classes and template functions, pre-instantiated, and + splitting those up causes severe maintenance headaches. + + + On supported platforms, libstdc++ takes advantage of garbage + collection in the GNU linker to get a result similar to separating + each symbol into a separate source and object files. On these platforms, + GNU ld can place each function and variable into its own + section in a .o file. The GNU linker can then perform garbage + collection on unused sections; this reduces the situation to only + copying needed functions into the executable, as before, but all + happens automatically. + + + + + + + + + +Platform-Specific Issues + + + + + Can libstdc++ be used with non-GNU compilers? + + + + + Perhaps. + + + Since the goal of ISO Standardization is for all C++ + implementations to be able to share code, libstdc++ should be + usable under any ISO-compliant compiler, at least in theory. + + + However, the reality is that libstdc++ is targeted and optimized + for GCC/g++. This means that often libstdc++ uses specific, + non-standard features of g++ that are not present in older + versions of proprietary compilers. It may take as much as a year or two + after an official release of GCC that contains these features for + proprietary tools support these constructs. + + + In the near past, specific released versions of libstdc++ have + been known to work with versions of the EDG C++ compiler, and + vendor-specific proprietary C++ compilers such as the Intel ICC + C++ compiler. + + + + + + + + + No 'long long' type on Solaris? + + + + + By default we try to support the C99 long long type. + This requires that certain functions from your C library be present. + + + Up through release 3.0.2 the platform-specific tests performed by + libstdc++ were too general, resulting in a conservative approach + to enabling the long long code paths. The most + commonly reported platform affected was Solaris. + + + This has been fixed for libstdc++ releases greater than 3.0.3. + + + + + + + + _XOPEN_SOURCE and _GNU_SOURCE are always defined? + + + + On Solaris, g++ (but not gcc) always defines the preprocessor + macro _XOPEN_SOURCE. On GNU/Linux, the same happens + with _GNU_SOURCE. (This is not an exhaustive list; + other macros and other platforms are also affected.) + + These macros are typically used in C library headers, guarding new + versions of functions from their older versions. The C++ standard + library includes the C standard library, but it requires the C90 + version, which for backwards-compatibility reasons is often not the + default for many vendors. + + More to the point, the C++ standard requires behavior which is only + available on certain platforms after certain symbols are defined. + Usually the issue involves I/O-related typedefs. In order to + ensure correctness, the compiler simply predefines those symbols. + + Note that it's not enough to #define them only when the library is + being built (during installation). Since we don't have an 'export' + keyword, much of the library exists as headers, which means that + the symbols must also be defined as your programs are parsed and + compiled. + + To see which symbols are defined, look for CPLUSPLUS_CPP_SPEC in + the gcc config headers for your target (and try changing them to + see what happens when building complicated code). You can also run + g++ -E -dM - < /dev/null" to display + a list of predefined macros for any particular installation. + + This has been discussed on the mailing lists + quite a bit. + + This method is something of a wart. We'd like to find a cleaner + solution, but nobody yet has contributed the time. + + + + + + + + + Mac OS X ctype.h is broken! How can I fix it? + + + + This is a long-standing bug in the OS X support. Fortunately, + the patch is quite simple, and well-known. + Here's a + link to the solution. + + + + + + + + + Threading is broken on i386? + + + + + + Support for atomic integer operations is/was broken on i386 + platforms. The assembly code accidentally used opcodes that are + only available on the i486 and later. So if you configured GCC + to target, for example, i386-linux, but actually used the programs + on an i686, then you would encounter no problems. Only when + actually running the code on a i386 will the problem appear. + + This is fixed in 3.2.2. + + + + + + + + + MIPS atomic operations + + + + + The atomic locking routines for MIPS targets requires MIPS II + and later. A patch went in just after the 3.3 release to + make mips* use the generic implementation instead. You can also + configure for mipsel-elf as a workaround. + + + The mips*-*-linux* port continues to use the MIPS II routines, and more + work in this area is expected. + + + + + + + + Recent GNU/Linux glibc required? + + + + When running on GNU/Linux, libstdc++ 3.2.1 (shared library version + 5.0.1) and later uses localization and formatting code from the system + C library (glibc) version 2.2.5. That version of glibc is over a + year old and contains necessary bugfixes. Many GNU/Linux distros make + glibc version 2.3.x available now. + + The guideline is simple: the more recent the C++ library, the + more recent the C library. (This is also documented in the main + GCC installation instructions.) + + + + + + + + + Can't use wchar_t/wstring on FreeBSD + + + + + Older versions of FreeBSD's C library do not have sufficient + support for wide character functions, and as a result the + libstdc++ configury decides that wchar_t support should be + disabled. In addition, the libstdc++ platform checks that + enabled wchar_t were quite strict, and not granular + enough to detect when the minimal support to + enable wchar_t and C++ library structures + like wstring were present. This impacted Solaris, + Darwin, and BSD varients, and is fixed in libstdc++ versions post 4.1.0. + + + + + + + + + + + +Known Bugs + + + + + What works already? + + + + + Short answer: Pretty much everything works + except for some corner cases. Support for localization + in locale may be incomplete on non-GNU + platforms. Also dependant on the underlying platform is support + for wchar_t and long + long specializations, and details of thread support. + + + Long answer: See the implementation status pages for + C++98, + TR1, and C++0x. + + + + + + + + Bugs in the ISO C++ language or library specification + + + + + Unfortunately, there are some. + + + For those people who are not part of the ISO Library Group + (i.e., nearly all of us needing to read this page in the first + place), a public list of the library defects is occasionally + published here. + Some of these issues have resulted in code changes in libstdc++. + + + If you think you've discovered a new bug that is not listed, + please post a message describing your problem + to libstdc++@gcc.gnu.org or the Usenet group + comp.lang.c++.moderated. + + + + + + + + Bugs in the compiler (gcc/g++) and not libstdc++ + + + + + On occasion, the compiler is wrong. Please be advised that this + happens much less often than one would think, and avoid jumping to + conclusions. + + + First, examine the ISO C++ standard. Second, try another compiler + or an older version of the GNU compilers. Third, you can find more + information on the libstdc++ and the GCC mailing lists: search + these lists with terms describing your issue. + + + Before reporting a bug, please examine the + bugs database with the + category set to g++. + + + + + + + + +Known Non-Bugs + + + + + Reopening a stream fails + + + + + One of the most-reported non-bug reports. Executing a sequence like: + + + + #include <fstream> + ... + std::fstream fs(a_file); + // . + // . do things with fs... + // . + fs.close(); + fs.open(a_new_file); + + + + All operations on the re-opened fs will fail, or at + least act very strangely. Yes, they often will, especially if + fs reached the EOF state on the previous file. The + reason is that the state flags are not cleared + on a successful call to open(). The standard unfortunately did + not specify behavior in this case, and to everybody's great sorrow, + the proposed LWG resolution in + DR #22 is to leave the flags unchanged. You must insert a call + to fs.clear() between the calls to close() and open(), + and then everything will work like we all expect it to work. + Update: for GCC 4.0 we implemented the resolution + of DR #409 and open() now calls + clear() on success! + + + + + + + + -Weffc++ complains too much + + + + + Many warnings are emitted when -Weffc++ is used. Making + libstdc++ -Weffc++-clean is not a goal of the project, + for a few reasons. Mainly, that option tries to enforce + object-oriented programming, while the Standard Library isn't + necessarily trying to be OO. + + + We do, however, try to have libstdc++ sources as clean as possible. If + you see some simple changes that pacify -Weffc++ + without other drawbacks, send us a patch. + + + + + + + + Ambiguous overloads after including an old-style header + + + + + Another problem is the rel_ops namespace and the template + comparison operator functions contained therein. If they become + visible in the same namespace as other comparison functions + (e.g., using them and the <iterator> header), + then you will suddenly be faced with huge numbers of ambiguity + errors. This was discussed on the -v3 list; Nathan Myers + sums + things up here. The collisions with vector/string iterator + types have been fixed for 3.1. + + + + + + + + The g++-3 headers are not ours + + + + + If you have found an extremely broken header file which is + causing problems for you, look carefully before submitting a + "high" priority bug report (which you probably + shouldn't do anyhow; see the last paragraph of the page + describing the GCC + bug database). + + + If the headers are in ${prefix}/include/g++-3, or + if the installed library's name looks like + libstdc++-2.10.a or + libstdc++-libc6-2.10.so, then you are using the + old libstdc++-v2 library, which is nonstandard and + unmaintained. Do not report problems with -v2 to the -v3 + mailing list. + + + For GCC versions 3.0 and 3.1 the libstdc++ header files are + installed in ${prefix}/include/g++-v3 (see the + 'v'?). Starting with version 3.2 the headers are installed in + ${prefix}/include/c++/${version} as this prevents + headers from previous versions being found by mistake. + + + + + + + + + Errors about *Concept and + constraints in the STL + + + + + If you see compilation errors containing messages about + foo Concept and something to do with a + constraints member function, then most + likely you have violated one of the requirements for types used + during instantiation of template containers and functions. For + example, EqualityComparableConcept appears if your types must be + comparable with == and you have not provided this capability (a + typo, or wrong visibility, or you just plain forgot, etc). + + + More information, including how to optionally enable/disable the + checks, is available + here. + + + + + + + + Program crashes when using library code in a + dynamically-loaded library + + + + + If you are using the C++ library across dynamically-loaded + objects, make certain that you are passing the correct options + when compiling and linking: + + + + // compile your library components + g++ -fPIC -c a.cc + g++ -fPIC -c b.cc + ... + g++ -fPIC -c z.cc + + // create your library + g++ -fPIC -shared -rdynamic -o libfoo.so a.o b.o ... z.o + + // link the executable + g++ -fPIC -rdynamic -o foo ... -L. -lfoo -ldl + + + + + + + + Memory leaks in containers + + + + + A few people have reported that the standard containers appear + to leak memory when tested with memory checkers such as + valgrind. + The library's default allocators keep free memory in a pool + for later reuse, rather than returning it to the OS. Although + this memory is always reachable by the library and is never + lost, memory debugging tools can report it as a leak. If you + want to test the library for memory leaks please read + Tips for memory leak hunting + first. + + + + + + + + list::size() is O(n)! + + + + + See + the Containers + chapter. + + + + + + + + Aw, that's easy to fix! + + + + + If you have found a bug in the library and you think you have + a working fix, then send it in! The main GCC site has a page + on submitting + patches that covers the procedure, but for libstdc++ you + should also send the patch to our mailing list in addition to + the GCC patches mailing list. The libstdc++ + contributors' page + also talks about how to submit patches. + + + In addition to the description, the patch, and the ChangeLog + entry, it is a Good Thing if you can additionally create a small + test program to test for the presence of the bug that your + patch fixes. Bugs have a way of being reintroduced; if an old + bug creeps back in, it will be caught immediately by the + testsuite -- but only if such a test exists. + + + + + + + + + +Miscellaneous + + + + + string::iterator is not char*; vector<T>::iterator is not T* + + + + + If you have code that depends on container<T> iterators + being implemented as pointer-to-T, your code is broken. It's + considered a feature, not a bug, that libstdc++ points this out. + + + While there are arguments for iterators to be implemented in + that manner, A) they aren't very good ones in the long term, + and B) they were never guaranteed by the Standard anyway. The + type-safety achieved by making iterators a real class rather + than a typedef for T* outweighs nearly all opposing + arguments. + + + Code which does assume that a vector iterator i + is a pointer can often be fixed by changing i in + certain expressions to &*i. Future revisions + of the Standard are expected to bless this usage for + vector<> (but not for basic_string<>). + + + + + + + + What's next after libstdc++? + + + + + Hopefully, not much. The goal of libstdc++ is to produce a + fully-compliant, fully-portable Standard Library. After that, + we're mostly done: there won't be any + more compliance work to do. + + + There is an effort underway to add significant extensions to + the standard library specification. The latest version of + this effort is described in + + The C++ Library Technical Report 1. + + + + + + + + What about the STL from SGI? + + + + + The STL from SGI, + version 3.3, was the final merge of the STL codebase. The + code in libstdc++ contains many fixes and changes, and + the SGI code is no longer under active + development. We expect that no future merges will take place. + + + In particular, string is not from SGI and makes no + use of their "rope" class (which is included as an + optional extension), nor is valarray and some others. + Classes like vector<> are, but have been + extensively modified. + + + More information on the evolution of libstdc++ can be found at the + API + evolution + and backwards + compatibility documentation. + + + The FAQ for SGI's STL (one jump off of their main page) is + still recommended reading. + + + + + + + + Extensions and Backward Compatibility + + + + + See the link on backwards compatiblity and link on evolution. + + + + + + + + Does libstdc++ support TR1? + + + + + Yes. + + + The C++ Standard Library Technical Report adds many new features to + the library. The latest version of this effort is described in + + Technical Report 1. + + + The implementation status of TR1 in libstdc++ can be tracked on the TR1 status + page. + + + + + + + How do I get a copy of the ISO C++ Standard? + + + + + Copies of the full ISO 14882 standard are available on line via + the ISO mirror site for committee members. Non-members, or those + who have not paid for the privilege of sitting on the committee + and sustained their two-meeting commitment for voting rights, may + get a copy of the standard from their respective national + standards organization. In the USA, this national standards + organization is ANSI and their website is + right here. (And if + you've already registered with them, clicking this link will take + you to directly to the place where you can + buy the standard on-line. + + + Who is your country's member body? Visit the + ISO homepage and find out! + + + The 2003 version of the standard (the 1998 version plus TC1) is + available in print, ISBN 0-470-84674-7. + + + + + + + + What's an ABI and why is it so messy? + + + + + ABI stands for Application Binary + Interface. Conventionally, it refers to a great + mass of details about how arguments are arranged on the call + stack and/or in registers, and how various types are arranged + and padded in structs. A single CPU design may suffer + multiple ABIs designed by different development tool vendors + who made different choices, or even by the same vendor for + different target applications or compiler versions. In ideal + circumstances the CPU designer presents one ABI and all the + OSes and compilers use it. In practice every ABI omits + details that compiler implementers (consciously or + accidentally) must choose for themselves. + + + That ABI definition suffices for compilers to generate code so a + program can interact safely with an OS and its lowest-level libraries. + Users usually want an ABI to encompass more detail, allowing libraries + built with different compilers (or different releases of the same + compiler!) to be linked together. For C++, this includes many more + details than for C, and CPU designers (for good reasons elaborated + below) have not stepped up to publish C++ ABIs. The details include + virtual function implementation, struct inheritance layout, name + mangling, and exception handling. Such an ABI has been defined for + GNU C++, and is immediately useful for embedded work relying only on + a free-standing implementation that doesn't include (much + of) the standard library. It is a good basis for the work to come. + + + A useful C++ ABI must also incorporate many details of the standard + library implementation. For a C ABI, the layouts of a few structs + (such as FILE, stat, jmpbuf, and the like) and a few macros suffice. + For C++, the details include the complete set of names of functions + and types used, the offsets of class members and virtual functions, + and the actual definitions of all inlines. C++ exposes many more + library details to the caller than C does. It makes defining + a complete ABI a much bigger undertaking, and requires not just + documenting library implementation details, but carefully designing + those details so that future bug fixes and optimizations don't + force breaking the ABI. + + + There are ways to help isolate library implementation details from the + ABI, but they trade off against speed. Library details used in + inner loops (e.g., getchar) must be exposed and frozen for all + time, but many others may reasonably be kept hidden from user code, + so they may later be changed. Deciding which, and implementing + the decisions, must happen before you can reasonably document a + candidate C++ ABI that encompasses the standard library. + + + + + + + + How do I make std::vector<T>::capacity() == std::vector<T>::size? + + + + + The standard idiom for deallocating a vector<T>'s + unused memory is to create a temporary copy of the vector and swap their + contents, e.g. for vector<T> v + + + std::vector<T>(v).swap(v); + + + The copy will take O(n) time and the swap is constant time. + + + See Shrink-to-fit + strings for a similar solution for strings. + + + + + + + + + + +
+ + \ No newline at end of file diff --git a/libstdc++-v3/doc/xml/gnu/fdl-1.2.xml b/libstdc++-v3/doc/xml/gnu/fdl-1.2.xml new file mode 100644 index 00000000000..2eecfbb948a --- /dev/null +++ b/libstdc++-v3/doc/xml/gnu/fdl-1.2.xml @@ -0,0 +1,502 @@ + + GNU Free Documentation License + + Copyright (C) 2000, 2001, 2002 Free Software Foundation, + Inc. 51 Franklin St, Fifth Floor, + Boston, MA 02110-1301 USA. Everyone is permitted to copy and + distribute verbatim copies of this license document, but changing it is + not allowed. + + + 0. PREAMBLE + + + The purpose of this License is to make a manual, textbook, or other + functional and useful document "free" in the sense of freedom: to assure + everyone the effective freedom to copy and redistribute it, with or + without modifying it, either commercially or noncommercially. + Secondarily, this License preserves for the author and publisher a way to + get credit for their work, while not being considered responsible for + modifications made by others. + + + This License is a kind of "copyleft", which means that derivative works of + the document must themselves be free in the same sense. It complements + the GNU General Public License, which is a copyleft license designed for + free software. + + + We have designed this License in order to use it for manuals for free + software, because free software needs free documentation: a free program + should come with manuals providing the same freedoms that the software + does. But this License is not limited to software manuals; it can be used + for any textual work, regardless of subject matter or whether it is + published as a printed book. We recommend this License principally for + works whose purpose is instruction or reference. + + 1. APPLICABILITY AND DEFINITIONS + + + This License applies to any manual or other work, in any medium, that + contains a notice placed by the copyright holder saying it can be + distributed under the terms of this License. Such a notice grants a + world-wide, royalty-free license, unlimited in duration, to use that work + under the conditions stated herein. The "Document", below, refers to any + such manual or work. Any member of the public is a licensee, and is + addressed as "you". You accept the license if you copy, modify or + distribute the work in a way requiring permission under copyright + law. + + + A "Modified Version" of the Document means any work containing the + Document or a portion of it, either copied verbatim, or with modifications + and/or translated into another language. + + + A "Secondary Section" is a named appendix or a front-matter section of the + Document that deals exclusively with the relationship of the publishers or + authors of the Document to the Document's overall subject (or to related + matters) and contains nothing that could fall directly within that overall + subject. (Thus, if the Document is in part a textbook of mathematics, a + Secondary Section may not explain any mathematics.) The relationship + could be a matter of historical connection with the subject or with + related matters, or of legal, commercial, philosophical, ethical or + political position regarding them. + + + The "Invariant Sections" are certain Secondary Sections whose titles are + designated, as being those of Invariant Sections, in the notice that says + that the Document is released under this License. If a section does not + fit the above definition of Secondary then it is not allowed to be + designated as Invariant. The Document may contain zero Invariant + Sections. If the Document does not identify any Invariant Sections then + there are none. + + + The "Cover Texts" are certain short passages of text that are listed, as + Front-Cover Texts or Back-Cover Texts, in the notice that says that the + Document is released under this License. A Front-Cover Text may be at + most 5 words, and a Back-Cover Text may be at most 25 words. + + + A "Transparent" copy of the Document means a machine-readable copy, + represented in a format whose specification is available to the general + public, that is suitable for revising the document straightforwardly with + generic text editors or (for images composed of pixels) generic paint + programs or (for drawings) some widely available drawing editor, and that + is suitable for input to text formatters or for automatic translation to a + variety of formats suitable for input to text formatters. A copy made in + an otherwise Transparent file format whose markup, or absence of markup, + has been arranged to thwart or discourage subsequent modification by + readers is not Transparent. An image format is not Transparent if used + for any substantial amount of text. A copy that is not "Transparent" is + called "Opaque". + + + Examples of suitable formats for Transparent copies include plain ASCII + without markup, Texinfo input format, LaTeX input format, SGML or XML + using a publicly available DTD, and standard-conforming simple HTML, + PostScript or PDF designed for human modification. Examples of + transparent image formats include PNG, XCF and JPG. Opaque formats + include proprietary formats that can be read and edited only by + proprietary word processors, SGML or XML for which the DTD and/or + processing tools are not generally available, and the machine-generated + HTML, PostScript or PDF produced by some word processors for output + purposes only. + + + The "Title Page" means, for a printed book, the title page itself, plus + such following pages as are needed to hold, legibly, the material this + License requires to appear in the title page. For works in formats which + do not have any title page as such, "Title Page" means the text near the + most prominent appearance of the work's title, preceding the beginning of + the body of the text. + + + A section "Entitled XYZ" means a named subunit of the Document whose title + either is precisely XYZ or contains XYZ in parentheses following text that + translates XYZ in another language. (Here XYZ stands for a specific + section name mentioned below, such as "Acknowledgements", "Dedications", + "Endorsements", or "History".) To "Preserve the Title" of such a section + when you modify the Document means that it remains a section "Entitled + XYZ" according to this definition. + + + The Document may include Warranty Disclaimers next to the notice which + states that this License applies to the Document. These Warranty + Disclaimers are considered to be included by reference in this License, + but only as regards disclaiming warranties: any other implication that + these Warranty Disclaimers may have is void and has no effect on the + meaning of this License. + + + 2. VERBATIM COPYING + + + You may copy and distribute the Document in any medium, either + commercially or noncommercially, provided that this License, the copyright + notices, and the license notice saying this License applies to the + Document are reproduced in all copies, and that you add no other + conditions whatsoever to those of this License. You may not use technical + measures to obstruct or control the reading or further copying of the + copies you make or distribute. However, you may accept compensation in + exchange for copies. If you distribute a large enough number of copies + you must also follow the conditions in section 3. + + + You may also lend copies, under the same conditions stated above, and you + may publicly display copies. + + + 3. COPYING IN QUANTITY + + + If you publish printed copies (or copies in media that commonly have + printed covers) of the Document, numbering more than 100, and the + Document's license notice requires Cover Texts, you must enclose the + copies in covers that carry, clearly and legibly, all these Cover Texts: + Front-Cover Texts on the front cover, and Back-Cover Texts on the back + cover. Both covers must also clearly and legibly identify you as the + publisher of these copies. The front cover must present the full title + with all words of the title equally prominent and visible. You may add + other material on the covers in addition. Copying with changes limited to + the covers, as long as they preserve the title of the Document and satisfy + these conditions, can be treated as verbatim copying in other + respects. + + + If the required texts for either cover are too voluminous to fit legibly, + you should put the first ones listed (as many as fit reasonably) on the + actual cover, and continue the rest onto adjacent pages. + + + If you publish or distribute Opaque copies of the Document numbering more + than 100, you must either include a machine-readable Transparent copy + along with each Opaque copy, or state in or with each Opaque copy a + computer-network location from which the general network-using public has + access to download using public-standard network protocols a complete + Transparent copy of the Document, free of added material. If you use the + latter option, you must take reasonably prudent steps, when you begin + distribution of Opaque copies in quantity, to ensure that this Transparent + copy will remain thus accessible at the stated location until at least one + year after the last time you distribute an Opaque copy (directly or + through your agents or retailers) of that edition to the public. + + + It is requested, but not required, that you contact the authors of the + Document well before redistributing any large number of copies, to give + them a chance to provide you with an updated version of the + Document. + + + 4. MODIFICATIONS + + + You may copy and distribute a Modified Version of the Document under the + conditions of sections 2 and 3 above, provided that you release the + Modified Version under precisely this License, with the Modified Version + filling the role of the Document, thus licensing distribution and + modification of the Modified Version to whoever possesses a copy of it. + In addition, you must do these things in the Modified Version: + + + + + Use in the Title Page (and on the covers, if any) a title distinct + from that of the Document, and from those of previous versions (which + should, if there were any, be listed in the History section of the + Document). You may use the same title as a previous version if the + original publisher of that version gives permission. + + + + + List on the Title Page, as authors, one or more persons or entities + responsible for authorship of the modifications in the Modified + Version, together with at least five of the principal authors of the + Document (all of its principal authors, if it has fewer than five), + unless they release you from this requirement. + + + + + State on the Title page the name of the publisher of the Modified + Version, as the publisher. + + + + + Preserve all the copyright notices of the Document. + + + + + Add an appropriate copyright notice for your modifications adjacent to + the other copyright notices. + + + + + Include, immediately after the copyright notices, a license notice + giving the public permission to use the Modified Version under the + terms of this License, in the form shown in the Addendum below. + + + + + Preserve in that license notice the full lists of Invariant Sections + and required Cover Texts given in the Document's license notice. + + + + + Include an unaltered copy of this License. + + + + + Preserve the section Entitled "History", Preserve its Title, and add + to it an item stating at least the title, year, new authors, and + publisher of the Modified Version as given on the Title Page. If + there is no section Entitled "History" in the Document, create one + stating the title, year, authors, and publisher of the Document as + given on its Title Page, then add an item describing the Modified + Version as stated in the previous sentence. + + + + + Preserve the network location, if any, given in the Document for + public access to a Transparent copy of the Document, and likewise the + network locations given in the Document for previous versions it was + based on. These may be placed in the "History" section. You may omit + a network location for a work that was published at least four years + before the Document itself, or if the original publisher of the + version it refers to gives permission. + + + + + For any section Entitled "Acknowledgements" or "Dedications", Preserve + the Title of the section, and preserve in the section all the + substance and tone of each of the contributor acknowledgements and/or + dedications given therein. + + + + + Preserve all the Invariant Sections of the Document, unaltered in + their text and in their titles. Section numbers or the equivalent are + not considered part of the section titles. + + + + + Delete any section Entitled "Endorsements". Such a section may not be + included in the Modified Version. + + + + + Do not retitle any existing section to be Entitled "Endorsements" or + to conflict in title with any Invariant Section. + + + + + Preserve any Warranty Disclaimers. + + + + + If the Modified Version includes new front-matter sections or appendices + that qualify as Secondary Sections and contain no material copied from the + Document, you may at your option designate some or all of these sections + as invariant. To do this, add their titles to the list of Invariant + Sections in the Modified Version's license notice. These titles must be + distinct from any other section titles. + + + You may add a section Entitled "Endorsements", provided it contains + nothing but endorsements of your Modified Version by various parties--for + example, statements of peer review or that the text has been approved by + an organization as the authoritative definition of a standard. + + + You may add a passage of up to five words as a Front-Cover Text, and a + passage of up to 25 words as a Back-Cover Text, to the end of the list of + Cover Texts in the Modified Version. Only one passage of Front-Cover Text + and one of Back-Cover Text may be added by (or through arrangements made + by) any one entity. If the Document already includes a cover text for the + same cover, previously added by you or by arrangement made by the same + entity you are acting on behalf of, you may not add another; but you may + replace the old one, on explicit permission from the previous publisher + that added the old one. + + + The author(s) and publisher(s) of the Document do not by this License give + permission to use their names for publicity for or to assert or imply + endorsement of any Modified Version. + + + 5. COMBINING DOCUMENTS + + + You may combine the Document with other documents released under this + License, under the terms defined in section 4 above for modified versions, + provided that you include in the combination all of the Invariant Sections + of all of the original documents, unmodified, and list them all as + Invariant Sections of your combined work in its license notice, and that + you preserve all their Warranty Disclaimers. + + + The combined work need only contain one copy of this License, and multiple + identical Invariant Sections may be replaced with a single copy. If there + are multiple Invariant Sections with the same name but different contents, + make the title of each such section unique by adding at the end of it, in + parentheses, the name of the original author or publisher of that section + if known, or else a unique number. Make the same adjustment to the + section titles in the list of Invariant Sections in the license notice of + the combined work. + + + In the combination, you must combine any sections Entitled "History" in + the various original documents, forming one section Entitled "History"; + likewise combine any sections Entitled "Acknowledgements", and any + sections Entitled "Dedications". You must delete all sections Entitled + "Endorsements". + + + 6. COLLECTIONS OF DOCUMENTS + + + You may make a collection consisting of the Document and other documents + released under this License, and replace the individual copies of this + License in the various documents with a single copy that is included in + the collection, provided that you follow the rules of this License for + verbatim copying of each of the documents in all other respects. + + + You may extract a single document from such a collection, and distribute + it individually under this License, provided you insert a copy of this + License into the extracted document, and follow this License in all other + respects regarding verbatim copying of that document. + + + 7. AGGREGATION WITH INDEPENDENT WORKS + + + A compilation of the Document or its derivatives with other separate and + independent documents or works, in or on a volume of a storage or + distribution medium, is called an "aggregate" if the copyright resulting + from the compilation is not used to limit the legal rights of the + compilation's users beyond what the individual works permit. When the + Document is included in an aggregate, this License does not apply to the + other works in the aggregate which are not themselves derivative works of + the Document. + + + If the Cover Text requirement of section 3 is applicable to these copies + of the Document, then if the Document is less than one half of the entire + aggregate, the Document's Cover Texts may be placed on covers that bracket + the Document within the aggregate, or the electronic equivalent of covers + if the Document is in electronic form. Otherwise they must appear on + printed covers that bracket the whole aggregate. + + + 8. TRANSLATION + + + Translation is considered a kind of modification, so you may distribute + translations of the Document under the terms of section 4. Replacing + Invariant Sections with translations requires special permission from + their copyright holders, but you may include translations of some or all + Invariant Sections in addition to the original versions of these Invariant + Sections. You may include a translation of this License, and all the + license notices in the Document, and any Warranty Disclaimers, provided + that you also include the original English version of this License and the + original versions of those notices and disclaimers. In case of a + disagreement between the translation and the original version of this + License or a notice or disclaimer, the original version will prevail. + + + If a section in the Document is Entitled "Acknowledgements", + "Dedications", or "History", the requirement (section 4) to Preserve its + Title (section 1) will typically require changing the actual title. + + + 9. TERMINATION + + + You may not copy, modify, sublicense, or distribute the Document except as + expressly provided for under this License. Any other attempt to copy, + modify, sublicense or distribute the Document is void, and will + automatically terminate your rights under this License. However, parties + who have received copies, or rights, from you under this License will not + have their licenses terminated so long as such parties remain in full + compliance. + + + 10. FUTURE REVISIONS OF THIS LICENSE + + + The Free Software Foundation may publish new, revised versions of the GNU + Free Documentation License from time to time. Such new versions will be + similar in spirit to the present version, but may differ in detail to + address new problems or concerns. See http://www.gnu.org/copyleft/. + + + Each version of the License is given a distinguishing version number. If + the Document specifies that a particular numbered version of this License + "or any later version" applies to it, you have the option of following the + terms and conditions either of that specified version or of any later + version that has been published (not as a draft) by the Free Software + Foundation. If the Document does not specify a version number of this + License, you may choose any version ever published (not as a draft) by the + Free Software Foundation. + + + ADDENDUM: How to use this License for your documents + + + To use this License in a document you have written, include a copy of the + License in the document and put the following copyright and license + notices just after the title page: + +
+ + Copyright (C) YEAR YOUR NAME. + + + Permission is granted to copy, distribute and/or modify this document + under the terms of the GNU Free Documentation License, Version 1.2 or + any later version published by the Free Software Foundation; with no + Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A + copy of the license is included in the section entitled "GNU Free + Documentation License". + +
+ + If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, + replace the "with...Texts." line with this: + +
+ + with the Invariant Sections being LIST THEIR TITLES, with the + Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. + +
+ + If you have Invariant Sections without Cover Texts, or some other + combination of the three, merge those two alternatives to suit the + situation. + + + If your document contains nontrivial examples of program code, we + recommend releasing these examples in parallel under your choice of free + software license, such as the GNU General Public License, to permit their + use in free software. + + diff --git a/libstdc++-v3/doc/xml/gnu/gpl-2.0.xml b/libstdc++-v3/doc/xml/gnu/gpl-2.0.xml new file mode 100644 index 00000000000..151a9523f07 --- /dev/null +++ b/libstdc++-v3/doc/xml/gnu/gpl-2.0.xml @@ -0,0 +1,366 @@ + + + + + GNU General Public License + Version 2, June 1991 + + 1989, 1991 + Free Software Foundation, Inc. + + + +
Free Software Foundation, Inc. + 51 Franklin Street, Fifth Floor, + Boston, MA 02110-1301 + USA +
+ + Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. + + Version 2, June 1991 + + GNU General Public License +
+ Preamble + The licenses for most software are designed to take away your + freedom to share and change it. By contrast, the GNU General Public License is + intended to guarantee your freedom to share and change + free software - to make sure the software is free for all its users. + This General Public License applies to most of the Free Software + Foundation's software and to any other program whose authors commit + to using it. (Some other Free Software Foundation software is covered + by the GNU Library General Public License instead.) You can apply it + to your programs, too. + + When we speak of free software, we are referring to freedom, not price. + Our General Public Licenses are designed to make sure that you have the + freedom to distribute copies of free software (and charge for this + service if you wish), that you receive source code or can get it if you + want it, that you can change the software or use pieces of it in new free + programs; and that you know you can do these things. + + To protect your rights, we need to make restrictions that forbid anyone + to deny you these rights or to ask you to surrender the rights. These + restrictions translate to certain responsibilities for you if you distribute + copies of the software, or if you modify it. + + For example, if you distribute copies of such a program, whether gratis or + for a fee, you must give the recipients all the rights that you have. You + must make sure that they, too, receive or can get the source code. And you + must show them these terms so they know their rights. + + We protect your rights with two steps: + + + copyright the software, and + + + offer you this license which gives you legal permission to copy, + distribute and/or modify the software. + + + + + Also, for each author's protection and ours, we want to make certain that + everyone understands that there is no warranty for this free software. If + the software is modified by someone else and passed on, we want its + recipients to know that what they have is not the original, so that any + problems introduced by others will not reflect on the original authors' + reputations. + + Finally, any free program is threatened constantly by software patents. + We wish to avoid the danger that redistributors of a free program will + individually obtain patent licenses, in effect making the program + proprietary. To prevent this, we have made it clear that any patent must be + licensed for everyone's free use or not licensed at all. + + The precise terms and conditions for copying, distribution and modification + follow. +
+
+ TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION +
+ Section 0 + This License applies to any program or other work which contains a notice + placed by the copyright holder saying it may be distributed under the terms + of this General Public License. The Program, below, refers to any such + program or work, and a + work based on the Program means either + the Program or any derivative work under copyright law: that is to say, a + work containing the Program or a portion of it, either verbatim or with + modifications and/or translated into another language. (Hereinafter, translation + is included without limitation in the term + modification.) Each licensee is addressed as you. + + Activities other than copying, distribution and modification are not covered by + this License; they are outside its scope. The act of running the Program is not + restricted, and the output from the Program is covered only if its contents + constitute a work based on the Program (independent of having been made by running + the Program). Whether that is true depends on what the Program does. +
+
+ Section 1 + You may copy and distribute verbatim copies of the Program's source code as you + receive it, in any medium, provided that you conspicuously and appropriately + publish on each copy an appropriate copyright notice and disclaimer of warranty; + keep intact all the notices that refer to this License and to the absence of any + warranty; and give any other recipients of the Program a copy of this License + along with the Program. + + You may charge a fee for the physical act of transferring a copy, and you may at + your option offer warranty protection in exchange for a fee. +
+
+ Section 2 + You may modify your copy or copies of the Program or any portion of it, thus + forming a work based on the Program, and copy and distribute such modifications + or work under the terms of + Section 1 above, provided + that you also meet all of these conditions: + + + You must cause the modified files to carry prominent notices stating that + you changed the files and the date of any change. + + + You must cause any work that you distribute or publish, that in whole or + in part contains or is derived from the Program or any part thereof, to be + licensed as a whole at no charge to all third parties under the terms of + this License. + + + If the modified program normally reads commands interactively when run, you + must cause it, when started running for such interactive use in the most + ordinary way, to print or display an announcement including an appropriate + copyright notice and a notice that there is no warranty (or else, saying + that you provide a warranty) and that users may redistribute the program + under these conditions, and telling the user how to view a copy of this + License. (Exception: If the Program itself is interactive but does not + normally print such an announcement, your work based on the Program is not + required to print an announcement.) + + + + + These requirements apply to the modified work as a whole. If identifiable sections + of that work are not derived from the Program, and can be reasonably considered + independent and separate works in themselves, then this License, and its terms, + do not apply to those sections when you distribute them as separate works. But when + you distribute the same sections as part of a whole which is a work based on the + Program, the distribution of the whole must be on the terms of this License, whose + permissions for other licensees extend to the entire whole, and thus to each and + every part regardless of who wrote it. + + Thus, it is not the intent of this section to claim rights or contest your rights + to work written entirely by you; rather, the intent is to exercise the right to control + the distribution of derivative or collective works based on the Program. + + In addition, mere aggregation of another work not based on the Program with the Program + (or with a work based on the Program) on a volume of a storage or distribution medium + does not bring the other work under the scope of this License. +
+
+ Section 3 + You may copy and distribute the Program (or a work based on it, under + Section 2 in object code or executable form under the terms of + Sections 1 and + 2 above provided that you also do one of the following: + + + Accompany it with the complete corresponding machine-readable source code, which + must be distributed under the terms of Sections 1 and 2 above on a medium + customarily used for software interchange; or, + + + Accompany it with a written offer, valid for at least three years, to give any + third party, for a charge no more than your cost of physically performing source + distribution, a complete machine-readable copy of the corresponding source code, + to be distributed under the terms of Sections 1 and 2 above on a medium customarily + used for software interchange; or, + + + Accompany it with the information you received as to the offer to distribute + corresponding source code. (This alternative is allowed only for noncommercial + distribution and only if you received the program in object code or executable form + with such an offer, in accord with Subsection b above.) + + + + + The source code for a work means the preferred form of the work for making modifications + to it. For an executable work, complete source code means all the source code for all modules + it contains, plus any associated interface definition files, plus the scripts used to control + compilation and installation of the executable. However, as a special exception, the source + code distributed need not include anything that is normally distributed (in either source or + binary form) with the major components (compiler, kernel, and so on) of the operating system + on which the executable runs, unless that component itself accompanies the executable. + + If distribution of executable or object code is made by offering access to copy from a + designated place, then offering equivalent access to copy the source code from the same place + counts as distribution of the source code, even though third parties are not compelled to + copy the source along with the object code. +
+
+ Section 4 + You may not copy, modify, sublicense, or distribute the Program except as expressly provided + under this License. Any attempt otherwise to copy, modify, sublicense or distribute the + Program is void, and will automatically terminate your rights under this License. However, + parties who have received copies, or rights, from you under this License will not have their + licenses terminated so long as such parties remain in full compliance. +
+
+ Section 5 + You are not required to accept this License, since you have not signed it. However, nothing + else grants you permission to modify or distribute the Program or its derivative works. + These actions are prohibited by law if you do not accept this License. Therefore, by modifying + or distributing the Program (or any work based on the Program), you indicate your acceptance + of this License to do so, and all its terms and conditions for copying, distributing or + modifying the Program or works based on it. +
+
+ Section 6 + Each time you redistribute the Program (or any work based on the Program), the recipient + automatically receives a license from the original licensor to copy, distribute or modify + the Program subject to these terms and conditions. You may not impose any further restrictions + on the recipients' exercise of the rights granted herein. You are not responsible for enforcing + compliance by third parties to this License. +
+
+ Section 7 + If, as a consequence of a court judgment or allegation of patent infringement or for any other + reason (not limited to patent issues), conditions are imposed on you (whether by court order, + agreement or otherwise) that contradict the conditions of this License, they do not excuse you + from the conditions of this License. If you cannot distribute so as to satisfy simultaneously + your obligations under this License and any other pertinent obligations, then as a consequence + you may not distribute the Program at all. For example, if a patent license would not permit + royalty-free redistribution of the Program by all those who receive copies directly or + indirectly through you, then the only way you could satisfy both it and this License would be + to refrain entirely from distribution of the Program. + + If any portion of this section is held invalid or unenforceable under any particular circumstance, + the balance of the section is intended to apply and the section as a whole is intended to apply + in other circumstances. + + It is not the purpose of this section to induce you to infringe any patents or other property + right claims or to contest validity of any such claims; this section has the sole purpose of + protecting the integrity of the free software distribution system, which is implemented by public + license practices. Many people have made generous contributions to the wide range of software + distributed through that system in reliance on consistent application of that system; it is up + to the author/donor to decide if he or she is willing to distribute software through any other + system and a licensee cannot impose that choice. + + This section is intended to make thoroughly clear what is believed to be a consequence of the + rest of this License. +
+
+ Section 8 + If the distribution and/or use of the Program is restricted in certain countries either by patents + or by copyrighted interfaces, the original copyright holder who places the Program under this License + may add an explicit geographical distribution limitation excluding those countries, so that + distribution is permitted only in or among countries not thus excluded. In such case, this License + incorporates the limitation as if written in the body of this License. +
+
+ Section 9 + The Free Software Foundation may publish revised and/or new versions of the General Public License + from time to time. Such new versions will be similar in spirit to the present version, but may differ + in detail to address new problems or concerns. + + Each version is given a distinguishing version number. If the Program specifies a version number of + this License which applies to it and any later version, you have the option of following the terms + and conditions either of that version or of any later version published by the Free Software + Foundation. If the Program does not specify a version number of this License, you may choose any + version ever published by the Free Software Foundation. +
+
+ Section 10 + If you wish to incorporate parts of the Program into other free programs whose distribution + conditions are different, write to the author to ask for permission. For software which is copyrighted + by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions + for this. Our decision will be guided by the two goals of preserving the free status of all + derivatives of our free software and of promoting the sharing and reuse of software generally. +
+
+ NO WARRANTY Section 11 + BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT + PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR + OTHER PARTIES PROVIDE THE PROGRAM AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, + INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR + PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE + PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. +
+
+ Section 12 + IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR + ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU + FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE + USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED + INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH + ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH + DAMAGES. + + END OF TERMS AND CONDITIONS +
+
+
+ How to Apply These Terms to Your New Programs + If you develop a new program, and you want it to be of the greatest + possible use to the public, the best way to achieve this is to make it + free software which everyone can redistribute and change under these terms. + + To do so, attach the following notices to the program. It is safest + to attach them to the start of each source file to most effectively + convey the exclusion of warranty; and each file should have at least + the copyright line and a pointer to where the full notice is found. + + <one line to give the program's name and a brief idea of what it does.> + Copyright (C) <year> <name of author> + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + + Also add information on how to contact you by electronic and paper mail. + + If the program is interactive, make it output a short notice like this + when it starts in an interactive mode: + + Gnomovision version 69, Copyright (C) year name of author + Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type show w. + This is free software, and you are welcome to redistribute it + under certain conditions; type show c for details. + + The hypothetical commands show w and show c should + show the appropriate parts of the General Public License. Of course, the commands you + use may be called something other than show w and show c; + they could even be mouse-clicks or menu items--whatever suits your program. + + You should also get your employer (if you work as a programmer) or your + school, if any, to sign a copyright disclaimer for the program, if + necessary. Here is a sample; alter the names: + + Yoyodyne, Inc., hereby disclaims all copyright interest in the program + Gnomovision (which makes passes at compilers) written by James Hacker. + + <signature of Ty Coon>, 1 April 1989 + Ty Coon, President of Vice + + This General Public License does not permit incorporating your program into + proprietary programs. If your program is a subroutine library, you may + consider it more useful to permit linking proprietary applications with the + library. If this is what you want to do, use the GNU Library General + Public License instead of this License. +
+ diff --git a/libstdc++-v3/doc/xml/gnu/gpl-3.0.xml b/libstdc++-v3/doc/xml/gnu/gpl-3.0.xml new file mode 100644 index 00000000000..317b8559617 --- /dev/null +++ b/libstdc++-v3/doc/xml/gnu/gpl-3.0.xml @@ -0,0 +1,836 @@ + + + + + <acronym>GNU</acronym> General Public License version 3 + + + Version 3, 29 June 2007 + + + Copyright © 2007 Free Software Foundation, Inc. + http://fsf.org/ + + + Everyone is permitted to copy and distribute verbatim copies of this license + document, but changing it is not allowed. + + + Preamble + + + The GNU General Public License is a free, copyleft + license for software and other kinds of works. + + + The licenses for most software and other practical works are designed to + take away your freedom to share and change the works. By contrast, the + GNU General Public License is intended to guarantee your + freedom to share and change all versions of a program—to make sure it + remains free software for all its users. We, the Free Software Foundation, + use the GNU General Public License for most of our + software; it applies also to any other work released this way by its + authors. You can apply it to your programs, too. + + + When we speak of free software, we are referring to freedom, not price. Our + General Public Licenses are designed to make sure that you have the freedom + to distribute copies of free software (and charge for them if you wish), + that you receive source code or can get it if you want it, that you can + change the software or use pieces of it in new free programs, and that you + know you can do these things. + + + To protect your rights, we need to prevent others from denying you these + rights or asking you to surrender the rights. Therefore, you have certain + responsibilities if you distribute copies of the software, or if you modify + it: responsibilities to respect the freedom of others. + + + For example, if you distribute copies of such a program, whether gratis or + for a fee, you must pass on to the recipients the same freedoms that you + received. You must make sure that they, too, receive or can get the source + code. And you must show them these terms so they know their rights. + + + Developers that use the GNU GPL + protect your rights with two steps: (1) assert copyright on the software, + and (2) offer you this License giving you legal permission to copy, + distribute and/or modify it. + + + For the developers’ and authors’ protection, the + GPL clearly explains that there is no warranty for this + free software. For both users’ and authors’ sake, the + GPL requires that modified versions be marked as changed, + so that their problems will not be attributed erroneously to authors of + previous versions. + + + Some devices are designed to deny users access to install or run modified + versions of the software inside them, although the manufacturer can do so. + This is fundamentally incompatible with the aim of protecting users’ + freedom to change the software. The systematic pattern of such abuse occurs + in the area of products for individuals to use, which is precisely where it + is most unacceptable. Therefore, we have designed this version of the + GPL to prohibit the practice for those products. If such + problems arise substantially in other domains, we stand ready to extend this + provision to those domains in future versions of the GPL, + as needed to protect the freedom of users. + + + Finally, every program is threatened constantly by software patents. States + should not allow patents to restrict development and use of software on + general-purpose computers, but in those that do, we wish to avoid the + special danger that patents applied to a free program could make it + effectively proprietary. To prevent this, the GPL + assures that patents cannot be used to render the program non-free. + + + The precise terms and conditions for copying, distribution and modification + follow. + + + TERMS AND CONDITIONS + + + 0. Definitions. + + + “This License” refers to version 3 of the GNU + General Public License. + + + “Copyright” also means copyright-like laws that apply to other + kinds of works, such as semiconductor masks. + + + “The Program” refers to any copyrightable work licensed under + this License. Each licensee is addressed as “you”. + “Licensees” and “recipients” may be individuals or + organizations. + + + To “modify” a work means to copy from or adapt all or part of + the work in a fashion requiring copyright permission, other than the making + of an exact copy. The resulting work is called a “modified + version” of the earlier work or a work “based on” the + earlier work. + + + A “covered work” means either the unmodified Program or a work + based on the Program. + + + To “propagate” a work means to do anything with it that, without + permission, would make you directly or secondarily liable for infringement + under applicable copyright law, except executing it on a computer or + modifying a private copy. Propagation includes copying, distribution (with + or without modification), making available to the public, and in some + countries other activities as well. + + + To “convey” a work means any kind of propagation that enables + other parties to make or receive copies. Mere interaction with a user + through a computer network, with no transfer of a copy, is not conveying. + + + An interactive user interface displays “Appropriate Legal + Notices” to the extent that it includes a convenient and prominently + visible feature that (1) displays an appropriate copyright notice, and (2) + tells the user that there is no warranty for the work (except to the extent + that warranties are provided), that licensees may convey the work under this + License, and how to view a copy of this License. If the interface presents + a list of user commands or options, such as a menu, a prominent item in the + list meets this criterion. + + + 1. Source Code. + + + The “source code” for a work means the preferred form of the + work for making modifications to it. “Object code” means any + non-source form of a work. + + + A “Standard Interface” means an interface that either is an + official standard defined by a recognized standards body, or, in the case of + interfaces specified for a particular programming language, one that is + widely used among developers working in that language. + + + The “System Libraries” of an executable work include anything, + other than the work as a whole, that (a) is included in the normal form of + packaging a Major Component, but which is not part of that Major Component, + and (b) serves only to enable use of the work with that Major Component, or + to implement a Standard Interface for which an implementation is available + to the public in source code form. A “Major Component”, in this + context, means a major essential component (kernel, window system, and so + on) of the specific operating system (if any) on which the executable work + runs, or a compiler used to produce the work, or an object code interpreter + used to run it. + + + The “Corresponding Source” for a work in object code form means + all the source code needed to generate, install, and (for an executable + work) run the object code and to modify the work, including scripts to + control those activities. However, it does not include the work’s + System Libraries, or general-purpose tools or generally available free + programs which are used unmodified in performing those activities but which + are not part of the work. For example, Corresponding Source includes + interface definition files associated with source files for the work, and + the source code for shared libraries and dynamically linked subprograms that + the work is specifically designed to require, such as by intimate data + communication or control flow between those subprograms and other parts of + the work. + + + The Corresponding Source need not include anything that users can regenerate + automatically from other parts of the Corresponding Source. + + + The Corresponding Source for a work in source code form is that same work. + + + 2. Basic Permissions. + + + All rights granted under this License are granted for the term of copyright + on the Program, and are irrevocable provided the stated conditions are met. + This License explicitly affirms your unlimited permission to run the + unmodified Program. The output from running a covered work is covered by + this License only if the output, given its content, constitutes a covered + work. This License acknowledges your rights of fair use or other + equivalent, as provided by copyright law. + + + You may make, run and propagate covered works that you do not convey, + without conditions so long as your license otherwise remains in force. You + may convey covered works to others for the sole purpose of having them make + modifications exclusively for you, or provide you with facilities for + running those works, provided that you comply with the terms of this License + in conveying all material for which you do not control copyright. Those + thus making or running the covered works for you must do so exclusively on + your behalf, under your direction and control, on terms that prohibit them + from making any copies of your copyrighted material outside their + relationship with you. + + + Conveying under any other circumstances is permitted solely under the + conditions stated below. Sublicensing is not allowed; section 10 makes it + unnecessary. + + + 3. Protecting Users’ Legal Rights From Anti-Circumvention Law. + + + No covered work shall be deemed part of an effective technological measure + under any applicable law fulfilling obligations under article 11 of the WIPO + copyright treaty adopted on 20 December 1996, or similar laws prohibiting or + restricting circumvention of such measures. + + + When you convey a covered work, you waive any legal power to forbid + circumvention of technological measures to the extent such circumvention is + effected by exercising rights under this License with respect to the covered + work, and you disclaim any intention to limit operation or modification of + the work as a means of enforcing, against the work’s users, your or + third parties’ legal rights to forbid circumvention of technological + measures. + + + 4. Conveying Verbatim Copies. + + + You may convey verbatim copies of the Program’s source code as you + receive it, in any medium, provided that you conspicuously and appropriately + publish on each copy an appropriate copyright notice; keep intact all + notices stating that this License and any non-permissive terms added in + accord with section 7 apply to the code; keep intact all notices of the + absence of any warranty; and give all recipients a copy of this License + along with the Program. + + + You may charge any price or no price for each copy that you convey, and you + may offer support or warranty protection for a fee. + + + 5. Conveying Modified Source Versions. + + + You may convey a work based on the Program, or the modifications to produce + it from the Program, in the form of source code under the terms of section + 4, provided that you also meet all of these conditions: + + + + + The work must carry prominent notices stating that you modified it, and + giving a relevant date. + + + + + The work must carry prominent notices stating that it is released under + this License and any conditions added under section 7. This requirement + modifies the requirement in section 4 to “keep intact all + notices”. + + + + + You must license the entire work, as a whole, under this License to + anyone who comes into possession of a copy. This License will therefore + apply, along with any applicable section 7 additional terms, to the + whole of the work, and all its parts, regardless of how they are + packaged. This License gives no permission to license the work in any + other way, but it does not invalidate such permission if you have + separately received it. + + + + + If the work has interactive user interfaces, each must display + Appropriate Legal Notices; however, if the Program has interactive + interfaces that do not display Appropriate Legal Notices, your work need + not make them do so. + + + + + A compilation of a covered work with other separate and independent works, + which are not by their nature extensions of the covered work, and which are + not combined with it such as to form a larger program, in or on a volume of + a storage or distribution medium, is called an “aggregate” if + the compilation and its resulting copyright are not used to limit the access + or legal rights of the compilation’s users beyond what the individual works + permit. Inclusion of a covered work in an aggregate does not cause + this License to apply to the other parts of the aggregate. + + + 6. Conveying Non-Source Forms. + + + You may convey a covered work in object code form under the terms of + sections 4 and 5, provided that you also convey the machine-readable + Corresponding Source under the terms of this License, in one of these ways: + + + + + Convey the object code in, or embodied in, a physical product (including + a physical distribution medium), accompanied by the Corresponding Source + fixed on a durable physical medium customarily used for software + interchange. + + + + + Convey the object code in, or embodied in, a physical product (including + a physical distribution medium), accompanied by a written offer, valid + for at least three years and valid for as long as you offer spare parts + or customer support for that product model, to give anyone who possesses + the object code either (1) a copy of the Corresponding Source for all + the software in the product that is covered by this License, on a + durable physical medium customarily used for software interchange, for a + price no more than your reasonable cost of physically performing this + conveying of source, or (2) access to copy the Corresponding Source from + a network server at no charge. + + + + + Convey individual copies of the object code with a copy of the written + offer to provide the Corresponding Source. This alternative is allowed + only occasionally and noncommercially, and only if you received the + object code with such an offer, in accord with subsection 6b. + + + + + Convey the object code by offering access from a designated place + (gratis or for a charge), and offer equivalent access to the + Corresponding Source in the same way through the same place at no + further charge. You need not require recipients to copy the + Corresponding Source along with the object code. If the place to copy + the object code is a network server, the Corresponding Source may be on + a different server (operated by you or a third party) that supports + equivalent copying facilities, provided you maintain clear directions + next to the object code saying where to find the Corresponding Source. + Regardless of what server hosts the Corresponding Source, you remain + obligated to ensure that it is available for as long as needed to + satisfy these requirements. + + + + + Convey the object code using peer-to-peer transmission, provided you + inform other peers where the object code and Corresponding Source of the + work are being offered to the general public at no charge under + subsection 6d. + + + + + A separable portion of the object code, whose source code is excluded from + the Corresponding Source as a System Library, need not be included in + conveying the object code work. + + + A “User Product” is either (1) a “consumer product”, + which means any tangible personal property which is normally used for + personal, family, or household purposes, or (2) anything designed or sold + for incorporation into a dwelling. In determining whether a product is a + consumer product, doubtful cases shall be resolved in favor of coverage. + For a particular product received by a particular user, “normally + used” refers to a typical or common use of that class of product, + regardless of the status of the particular user or of the way in which the + particular user actually uses, or expects or is expected to use, the + product. A product is a consumer product regardless of whether the product + has substantial commercial, industrial or non-consumer uses, unless such + uses represent the only significant mode of use of the product. + + + “Installation Information” for a User Product means any methods, + procedures, authorization keys, or other information required to install and + execute modified versions of a covered work in that User Product from a + modified version of its Corresponding Source. The information must suffice + to ensure that the continued functioning of the modified object code is in + no case prevented or interfered with solely because modification has been + made. + + + If you convey an object code work under this section in, or with, or + specifically for use in, a User Product, and the conveying occurs as part of + a transaction in which the right of possession and use of the User Product + is transferred to the recipient in perpetuity or for a fixed term + (regardless of how the transaction is characterized), the Corresponding + Source conveyed under this section must be accompanied by the Installation + Information. But this requirement does not apply if neither you nor any + third party retains the ability to install modified object code on the User + Product (for example, the work has been installed in + ROM). + + + The requirement to provide Installation Information does not include a + requirement to continue to provide support service, warranty, or updates for + a work that has been modified or installed by the recipient, or for the User + Product in which it has been modified or installed. Access to a network may + be denied when the modification itself materially and adversely affects the + operation of the network or violates the rules and protocols for + communication across the network. + + + Corresponding Source conveyed, and Installation Information provided, in + accord with this section must be in a format that is publicly documented + (and with an implementation available to the public in source code form), + and must require no special password or key for unpacking, reading or + copying. + + + 7. Additional Terms. + + + “Additional permissions” are terms that supplement the terms of + this License by making exceptions from one or more of its conditions. + Additional permissions that are applicable to the entire Program shall be + treated as though they were included in this License, to the extent that + they are valid under applicable law. If additional permissions apply only + to part of the Program, that part may be used separately under those + permissions, but the entire Program remains governed by this License + without regard to the additional permissions. + + + When you convey a copy of a covered work, you may at your option remove any + additional permissions from that copy, or from any part of it. (Additional + permissions may be written to require their own removal in certain cases + when you modify the work.) You may place additional permissions on + material, added by you to a covered work, for which you have or can give + appropriate copyright permission. + + + Notwithstanding any other provision of this License, for material you add + to a covered work, you may (if authorized by the copyright holders of that + material) supplement the terms of this License with terms: + + + + + Disclaiming warranty or limiting liability differently from the terms + of sections 15 and 16 of this License; or + + + + + Requiring preservation of specified reasonable legal notices or author + attributions in that material or in the Appropriate Legal Notices + displayed by works containing it; or + + + + + Prohibiting misrepresentation of the origin of that material, or + requiring that modified versions of such material be marked in + reasonable ways as different from the original version; or + + + + + Limiting the use for publicity purposes of names of licensors or + authors of the material; or + + + + + Declining to grant rights under trademark law for use of some trade + names, trademarks, or service marks; or + + + + + Requiring indemnification of licensors and authors of that material by + anyone who conveys the material (or modified versions of it) with + contractual assumptions of liability to the recipient, for any + liability that these contractual assumptions directly impose on those + licensors and authors. + + + + + All other non-permissive additional terms are considered “further + restrictions” within the meaning of section 10. If the Program as + you received it, or any part of it, contains a notice stating that it is + governed by this License along with a term that is a further restriction, + you may remove that term. If a license document contains a further + restriction but permits relicensing or conveying under this License, you + may add to a covered work material governed by the terms of that license + document, provided that the further restriction does not survive such + relicensing or conveying. + + + If you add terms to a covered work in accord with this section, you must + place, in the relevant source files, a statement of the additional terms + that apply to those files, or a notice indicating where to find the + applicable terms. + + + Additional terms, permissive or non-permissive, may be stated in the form + of a separately written license, or stated as exceptions; the above + requirements apply either way. + + + 8. Termination. + + + You may not propagate or modify a covered work except as expressly provided + under this License. Any attempt otherwise to propagate or modify it is + void, and will automatically terminate your rights under this License + (including any patent licenses granted under the third paragraph of section + 11). + + + However, if you cease all violation of this License, then your license from + a particular copyright holder is reinstated (a) provisionally, unless and + until the copyright holder explicitly and finally terminates your license, + and (b) permanently, if the copyright holder fails to notify you of the + violation by some reasonable means prior to 60 days after the cessation. + + + Moreover, your license from a particular copyright holder is reinstated + permanently if the copyright holder notifies you of the violation by some + reasonable means, this is the first time you have received notice of + violation of this License (for any work) from that copyright holder, and + you cure the violation prior to 30 days after your receipt of the notice. + + + Termination of your rights under this section does not terminate the + licenses of parties who have received copies or rights from you under this + License. If your rights have been terminated and not permanently + reinstated, you do not qualify to receive new licenses for the same + material under section 10. + + + 9. Acceptance Not Required for Having Copies. + + + You are not required to accept this License in order to receive or run a + copy of the Program. Ancillary propagation of a covered work occurring + solely as a consequence of using peer-to-peer transmission to receive a + copy likewise does not require acceptance. However, nothing other than + this License grants you permission to propagate or modify any covered work. + These actions infringe copyright if you do not accept this License. + Therefore, by modifying or propagating a covered work, you indicate your + acceptance of this License to do so. + + + 10. Automatic Licensing of Downstream Recipients. + + + Each time you convey a covered work, the recipient automatically receives a + license from the original licensors, to run, modify and propagate that + work, subject to this License. You are not responsible for enforcing + compliance by third parties with this License. + + + An “entity transaction” is a transaction transferring control + of an organization, or substantially all assets of one, or subdividing an + organization, or merging organizations. If propagation of a covered work + results from an entity transaction, each party to that transaction who + receives a copy of the work also receives whatever licenses to the work the + party’s predecessor in interest had or could give under the previous + paragraph, plus a right to possession of the Corresponding Source of the + work from the predecessor in interest, if the predecessor has it or can get + it with reasonable efforts. + + + You may not impose any further restrictions on the exercise of the rights + granted or affirmed under this License. For example, you may not impose a + license fee, royalty, or other charge for exercise of rights granted under + this License, and you may not initiate litigation (including a cross-claim + or counterclaim in a lawsuit) alleging that any patent claim is infringed + by making, using, selling, offering for sale, or importing the Program or + any portion of it. + + + 11. Patents. + + + A “contributor” is a copyright holder who authorizes use under + this License of the Program or a work on which the Program is based. The + work thus licensed is called the contributor’s “contributor + version”. + + + A contributor’s “essential patent claims” are all patent + claims owned or controlled by the contributor, whether already acquired or + hereafter acquired, that would be infringed by some manner, permitted by + this License, of making, using, or selling its contributor version, but do + not include claims that would be infringed only as a consequence of further + modification of the contributor version. For purposes of this definition, + “control” includes the right to grant patent sublicenses in a + manner consistent with the requirements of this License. + + + Each contributor grants you a non-exclusive, worldwide, royalty-free patent + license under the contributor’s essential patent claims, to make, use, + sell, offer for sale, import and otherwise run, modify and propagate the + contents of its contributor version. + + + In the following three paragraphs, a “patent license” is any + express agreement or commitment, however denominated, not to enforce a + patent (such as an express permission to practice a patent or covenant not + to sue for patent infringement). To “grant” such a patent + license to a party means to make such an agreement or commitment not to + enforce a patent against the party. + + + If you convey a covered work, knowingly relying on a patent license, and the + Corresponding Source of the work is not available for anyone to copy, free + of charge and under the terms of this License, through a publicly available + network server or other readily accessible means, then you must either (1) + cause the Corresponding Source to be so available, or (2) arrange to deprive + yourself of the benefit of the patent license for this particular work, or + (3) arrange, in a manner consistent with the requirements of this License, + to extend the patent license to downstream recipients. “Knowingly + relying” means you have actual knowledge that, but for the patent + license, your conveying the covered work in a country, or your + recipient’s use of the covered work in a country, would infringe one + or more identifiable patents in that country that you have reason to believe + are valid. + + + If, pursuant to or in connection with a single transaction or arrangement, + you convey, or propagate by procuring conveyance of, a covered work, and + grant a patent license to some of the parties receiving the covered work + authorizing them to use, propagate, modify or convey a specific copy of the + covered work, then the patent license you grant is automatically extended to + all recipients of the covered work and works based on it. + + + A patent license is “discriminatory” if it does not include + within the scope of its coverage, prohibits the exercise of, or is + conditioned on the non-exercise of one or more of the rights that are + specifically granted under this License. You may not convey a covered work + if you are a party to an arrangement with a third party that is in the + business of distributing software, under which you make payment to the third + party based on the extent of your activity of conveying the work, and under + which the third party grants, to any of the parties who would receive the + covered work from you, a discriminatory patent license (a) in connection + with copies of the covered work conveyed by you (or copies made from those + copies), or (b) primarily for and in connection with specific products or + compilations that contain the covered work, unless you entered into that + arrangement, or that patent license was granted, prior to 28 March 2007. + + + Nothing in this License shall be construed as excluding or limiting any + implied license or other defenses to infringement that may otherwise be + available to you under applicable patent law. + + + 12. No Surrender of Others’ Freedom. + + + If conditions are imposed on you (whether by court order, agreement or + otherwise) that contradict the conditions of this License, they do not + excuse you from the conditions of this License. If you cannot convey a + covered work so as to satisfy simultaneously your obligations under this + License and any other pertinent obligations, then as a consequence you may + not convey it at all. For example, if you agree to terms that obligate you + to collect a royalty for further conveying from those to whom you convey the + Program, the only way you could satisfy both those terms and this License + would be to refrain entirely from conveying the Program. + + + 13. Use with the GNU Affero General Public License. + + + Notwithstanding any other provision of this License, you have permission to + link or combine any covered work with a work licensed under version 3 of the + GNU Affero General Public License into a single combined + work, and to convey the resulting work. The terms of this License will + continue to apply to the part which is the covered work, but the special + requirements of the GNU Affero General Public License, + section 13, concerning interaction through a network will apply to the + combination as such. + + + 14. Revised Versions of this License. + + + The Free Software Foundation may publish revised and/or new versions of the + GNU General Public License from time to time. Such new + versions will be similar in spirit to the present version, but may differ in + detail to address new problems or concerns. + + + Each version is given a distinguishing version number. If the Program + specifies that a certain numbered version of the GNU + General Public License “or any later version” applies to it, you + have the option of following the terms and conditions either of that + numbered version or of any later version published by the Free Software + Foundation. If the Program does not specify a version number of the + GNU General Public License, you may choose any version + ever published by the Free Software Foundation. + + + If the Program specifies that a proxy can decide which future versions of + the GNU General Public License can be used, that + proxy’s public statement of acceptance of a version permanently + authorizes you to choose that version for the Program. + + + Later license versions may give you additional or different permissions. + However, no additional obligations are imposed on any author or copyright + holder as a result of your choosing to follow a later version. + + + 15. Disclaimer of Warranty. + + + THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE + LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR + OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF + ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE + IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. + THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH + YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL + NECESSARY SERVICING, REPAIR OR CORRECTION. + + + 16. Limitation of Liability. + + + IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL + ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE + PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY + GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE + OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA + OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD + PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), + EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF + SUCH DAMAGES. + + + 17. Interpretation of Sections 15 and 16. + + + If the disclaimer of warranty and limitation of liability provided above + cannot be given local legal effect according to their terms, reviewing + courts shall apply local law that most closely approximates an absolute + waiver of all civil liability in connection with the Program, unless a + warranty or assumption of liability accompanies a copy of the Program in + return for a fee. + + + END OF TERMS AND CONDITIONS + + + How to Apply These Terms to Your New Programs + + + If you develop a new program, and you want it to be of the greatest possible + use to the public, the best way to achieve this is to make it free software + which everyone can redistribute and change under these terms. + + + To do so, attach the following notices to the program. It is safest to + attach them to the start of each source file to most effectively state the + exclusion of warranty; and each file should have at least the + “copyright” line and a pointer to where the full notice is + found. + + +one line to give the program’s name and a brief idea of what it does. +Copyright (C) year name of author + +This program is free software: you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation, either version 3 of the License, or +(at your option) any later version. + +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program. If not, see http://www.gnu.org/licenses/. + + + Also add information on how to contact you by electronic and paper mail. + + + If the program does terminal interaction, make it output a short notice like + this when it starts in an interactive mode: + + +program Copyright (C) year name of author +This program comes with ABSOLUTELY NO WARRANTY; for details type ‘show w’. +This is free software, and you are welcome to redistribute it +under certain conditions; type ‘show c’ for details. + + + The hypothetical commands ‘show w’ and + ‘show c’ should show the appropriate parts of + the General Public License. Of course, your program’s commands might be + different; for a GUI interface, you would use an “about box”. + + + You should also get your employer (if you work as a programmer) or school, + if any, to sign a “copyright disclaimer” for the program, if + necessary. For more information on this, and how to apply and follow the + GNU GPL, see + http://www.gnu.org/licenses/. + + + The GNU General Public License does not permit + incorporating your program into proprietary programs. If your program is a + subroutine library, you may consider it more useful to permit linking + proprietary applications with the library. If this is what you want to do, + use the GNU Lesser General Public License instead of this + License. But first, please read http://www.gnu.org/philosophy/why-not-lgpl.html. + + diff --git a/libstdc++-v3/doc/xml/images/confdeps.dot b/libstdc++-v3/doc/xml/images/confdeps.dot new file mode 100644 index 00000000000..a62d28ce9dd --- /dev/null +++ b/libstdc++-v3/doc/xml/images/confdeps.dot @@ -0,0 +1,14 @@ +# Blatantly ripped out of the graphviz examples and modified. -pme +digraph v3conf { + size="6,6"; + node [color=lightblue2, style=filled]; + "aclocal.m4" -> "acinclude.m4"; + "configure" -> "aclocal.m4"; + "configure" -> "configure.ac"; + "configure" -> "crossconfig.m4"; + "configure" -> "linkage.m4"; + "[*/]Makefile.in" -> "Makefile.am"; + "[*/]Makefile.in" -> "configure.ac"; + "config.h.in" -> "acconfig.h"; + "config.h.in" -> "configure.ac"; +} diff --git a/libstdc++-v3/doc/xml/images/confdeps.png b/libstdc++-v3/doc/xml/images/confdeps.png new file mode 100644 index 00000000000..5075aa869b1 Binary files /dev/null and b/libstdc++-v3/doc/xml/images/confdeps.png differ diff --git a/libstdc++-v3/doc/xml/manual/abi.xml b/libstdc++-v3/doc/xml/manual/abi.xml new file mode 100644 index 00000000000..c11da9507db --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/abi.xml @@ -0,0 +1,1130 @@ + + + + + + + C++ + + + ABI + + + version + + + dynamic + + + shared + + + + +ABI Policy and Guidelines + + + + + +The C++ Interface + + + C++ applications often dependent on specific language support + routines, say for throwing exceptions, or catching exceptions, and + perhaps also dependent on features in the C++ Standard Library. + + + + The C++ Standard Library has many include files, types defined in + those include files, specific named functions, and other + behavior. The text of these behaviors, as written in source include + files, is called the Application Programing Interface, or API. + + + + Furthermore, C++ source that is compiled into object files is + transformed by the compiler: it arranges objects with specific + alignment and in a particular layout, mangling names according to a + well-defined algorithm, has specific arrangements for the support of + virtual functions, etc. These details are defined as the compiler + Application Binary Interface, or ABI. The GNU C++ compiler uses an + industry-standard C++ ABI starting with version 3. Details can be + found in the ABI + specification. + + + + The GNU C++ compiler, g++, has a compiler command line option to + switch between various different C++ ABIs. This explicit version + switch is the flag -fabi-version. In addition, some + g++ command line options may change the ABI as a side-effect of + use. Such flags include -fpack-struct and + -fno-exceptions, but include others: see the complete + list in the GCC manual under the heading Options + for Code Generation Conventions. + + + + The configure options used when building a specific libstdc++ + version may also impact the resulting library ABI. The available + configure options, and their impact on the library ABI, are + documented + +here. + + + Putting all of these ideas together results in the C++ Standard +library ABI, which is the compilation of a given library API by a +given compiler ABI. In a nutshell: + + + + + library API + compiler ABI = library ABI + + + + + The library ABI is mostly of interest for end-users who have + unresolved symbols and are linking dynamically to the C++ Standard + library, and who thus must be careful to compile their application + with a compiler that is compatible with the available C++ Standard + library binary. In this case, compatible is defined with the equation + above: given an application compiled with a given compiler ABI and + library API, it will work correctly with a Standard C++ Library + created with the same constraints. + + + + To use a specific version of the C++ ABI, one must use a + corresponding GNU C++ toolchain (Ie, g++ and libstdc++) that + implements the C++ ABI in question. + + + + + +Versioning + + The C++ interface has evolved throughout the history of the GNU +C++ toolchain. With each release, various details have been changed so +as to give distinct versions to the C++ interface. + + + + Goals + +Extending existing, stable ABIs. Versioning gives subsequent stable +releases series libraries the ability to add new symbols and add +functionality, all the while retaining backwards compatibility with +the previous releases in the series. Note: the reverse is not true. It +is not possible to take binaries linked with the latest version of a +release series (if symbols have been added) and expect the initial +release of the series to remain link compatible. + + +Allows multiple, incompatible ABIs to coexist at the same time. + + + + + History + + + How can this complexity be managed? What does C++ versioning mean? + Because library and compiler changes often make binaries compiled + with one version of the GNU tools incompatible with binaries + compiled with other (either newer or older) versions of the same GNU + tools, specific techniques are used to make managing this complexity + easier. + + + + The following techniques are used: + + + + + Release versioning on the libgcc_s.so binary. + + This is implemented via file names and the ELF DT_SONAME + mechanism (at least on ELF systems). It is versioned as follows: + + + + gcc-3.0.0: libgcc_s.so.1 + gcc-3.0.1: libgcc_s.so.1 + gcc-3.0.2: libgcc_s.so.1 + gcc-3.0.3: libgcc_s.so.1 + gcc-3.0.4: libgcc_s.so.1 + gcc-3.1.0: libgcc_s.so.1 + gcc-3.1.1: libgcc_s.so.1 + gcc-3.2.0: libgcc_s.so.1 + gcc-3.2.1: libgcc_s.so.1 + gcc-3.2.2: libgcc_s.so.1 + gcc-3.2.3: libgcc_s.so.1 + gcc-3.3.0: libgcc_s.so.1 + gcc-3.3.1: libgcc_s.so.1 + gcc-3.3.2: libgcc_s.so.1 + gcc-3.3.3: libgcc_s.so.1 + gcc-3.4.x, gcc-4.0.x, gcc-4.1.x, gcc-4.2.x: on m68k-linux and + hppa-linux this is either libgcc_s.so.1 (when configuring + --with-sjlj-exceptions) or libgcc_s.so.2. For all + others, this is libgcc_s.so.1. + + + + + + Symbol versioning on the libgcc_s.so binary. + + It is versioned with the following labels and version + definitions, where the version definition is the maximum for a + particular release. Labels are cumulative. If a particular release + is not listed, it has the same version labels as the preceeding + release. + + This corresponds to the mapfile: gcc/libgcc-std.ver + + gcc-3.0.0: GCC_3.0 + gcc-3.3.0: GCC_3.3 + gcc-3.3.1: GCC_3.3.1 + gcc-3.3.2: GCC_3.3.2 + gcc-3.3.4: GCC_3.3.4 + gcc-3.4.0: GCC_3.4 + gcc-3.4.2: GCC_3.4.2 + gcc-3.4.4: GCC_3.4.4 + gcc-4.0.0: GCC_4.0.0 + gcc-4.1.0: GCC_4.1.0 + gcc-4.2.0: GCC_4.2.0 + + + + Release versioning on the libstdc++.so binary, implemented in the same was as the libgcc_s.so binary, above. + + It is versioned as follows: + + + gcc-3.0.0: libstdc++.so.3.0.0 + gcc-3.0.1: libstdc++.so.3.0.1 + gcc-3.0.2: libstdc++.so.3.0.2 + gcc-3.0.3: libstdc++.so.3.0.2 (Error should be libstdc++.so.3.0.3) + gcc-3.0.4: libstdc++.so.3.0.4 + gcc-3.1.0: libstdc++.so.4.0.0 + gcc-3.1.1: libstdc++.so.4.0.1 + gcc-3.2.0: libstdc++.so.5.0.0 + gcc-3.2.1: libstdc++.so.5.0.1 + gcc-3.2.2: libstdc++.so.5.0.2 + gcc-3.2.3: libstdc++.so.5.0.3 (Not strictly required) + gcc-3.3.0: libstdc++.so.5.0.4 + gcc-3.3.1: libstdc++.so.5.0.5 + gcc-3.3.2: libstdc++.so.5.0.5 + gcc-3.3.3: libstdc++.so.5.0.5 + gcc-3.4.0: libstdc++.so.6.0.0 + gcc-3.4.1: libstdc++.so.6.0.1 + gcc-3.4.2: libstdc++.so.6.0.2 + gcc-3.4.3: libstdc++.so.6.0.3 + gcc-3.4.4: libstdc++.so.6.0.3 + gcc-3.4.5: libstdc++.so.6.0.3 + gcc-3.4.6: libstdc++.so.6.0.3 + gcc-4.0.0: libstdc++.so.6.0.4 + gcc-4.0.1: libstdc++.so.6.0.5 + gcc-4.0.2: libstdc++.so.6.0.6 + gcc-4.0.3: libstdc++.so.6.0.7 + gcc-4.1.0: libstdc++.so.6.0.7 + gcc-4.1.1: libstdc++.so.6.0.8 + gcc-4.1.2: libstdc++.so.6.0.8 + gcc-4.2.0: libstdc++.so.6.0.9 + + + + Symbol versioning on the libstdc++.so binary. + + mapfile: libstdc++/config/linker-map.gnu + It is versioned with the following labels and version + definitions, where the version definition is the maximum for a + particular release. Note, only symbol which are newly introduced + will use the maximum version definition. Thus, for release series + with the same label, but incremented version definitions, the later + release has both versions. (An example of this would be the + gcc-3.2.1 release, which has GLIBCPP_3.2.1 for new symbols and + GLIBCPP_3.2 for symbols that were introduced in the gcc-3.2.0 + release.) If a particular release is not listed, it has the same + version labels as the preceeding release. + + + gcc-3.0.0: (Error, not versioned) + gcc-3.0.1: (Error, not versioned) + gcc-3.0.2: (Error, not versioned) + gcc-3.0.3: (Error, not versioned) + gcc-3.0.4: (Error, not versioned) + gcc-3.1.0: GLIBCPP_3.1, CXXABI_1 + gcc-3.1.1: GLIBCPP_3.1, CXXABI_1 + gcc-3.2.0: GLIBCPP_3.2, CXXABI_1.2 + gcc-3.2.1: GLIBCPP_3.2.1, CXXABI_1.2 + gcc-3.2.2: GLIBCPP_3.2.2, CXXABI_1.2 + gcc-3.2.3: GLIBCPP_3.2.2, CXXABI_1.2 + gcc-3.3.0: GLIBCPP_3.2.2, CXXABI_1.2.1 + gcc-3.3.1: GLIBCPP_3.2.3, CXXABI_1.2.1 + gcc-3.3.2: GLIBCPP_3.2.3, CXXABI_1.2.1 + gcc-3.3.3: GLIBCPP_3.2.3, CXXABI_1.2.1 + gcc-3.4.0: GLIBCXX_3.4, CXXABI_1.3 + gcc-3.4.1: GLIBCXX_3.4.1, CXXABI_1.3 + gcc-3.4.2: GLIBCXX_3.4.2 + gcc-3.4.3: GLIBCXX_3.4.3 + gcc-4.0.0: GLIBCXX_3.4.4, CXXABI_1.3.1 + gcc-4.0.1: GLIBCXX_3.4.5 + gcc-4.0.2: GLIBCXX_3.4.6 + gcc-4.0.3: GLIBCXX_3.4.7 + gcc-4.1.1: GLIBCXX_3.4.8 + gcc-4.2.0: GLIBCXX_3.4.9 + + + + + Incremental bumping of a compiler pre-defined macro, + __GXX_ABI_VERSION. This macro is defined as the version of the + compiler v3 ABI, with g++ 3.0.x being version 100. This macro will + be automatically defined whenever g++ is used (the curious can + test this by invoking g++ with the '-v' flag.) + + + + This macro was defined in the file "lang-specs.h" in the gcc/cp directory. + Later versions defined it in "c-common.c" in the gcc directory, and from + G++ 3.4 it is defined in c-cppbuiltin.c and its value determined by the + '-fabi-version' command line option. + + + + It is versioned as follows, where 'n' is given by '-fabi-version=n': + + + gcc-3.0.x: 100 + gcc-3.1.x: 100 (Error, should be 101) + gcc-3.2.x: 102 + gcc-3.3.x: 102 + gcc-3.4.x, gcc-4.0.x, gcc-4.1.x, gcc-4.2.x: 102 (when n=1) + gcc-3.4.x, gcc-4.0.x, gcc-4.1.x, gcc-4.2.x: 1000 + n (when n>1) + gcc-3.4.x, gcc-4.0.x, gcc-4.1.x, gcc-4.2.x: 999999 (when n=0) + + + + + + Changes to the default compiler option for + -fabi-version. + + + It is versioned as follows: + + + gcc-3.0.x: (Error, not versioned) + gcc-3.1.x: (Error, not versioned) + gcc-3.2.x: -fabi-version=1 + gcc-3.3.x: -fabi-version=1 + gcc-3.4.x, gcc-4.0.x, gcc-4.1.x, gcc-4.2.x: -fabi-version=2 + + + + + + Incremental bumping of a library pre-defined macro. For releases + before 3.4.0, the macro is __GLIBCPP__. For later releases, it's + __GLIBCXX__. (The libstdc++ project generously changed from CPP to + CXX throughout its source to allow the "C" pre-processor the CPP + macro namespace.) These macros are defined as the date the library + was released, in compressed ISO date format, as an unsigned long. + + + + This macro is defined in the file "c++config" in the + "libstdc++/include/bits" directory. (Up to gcc-4.1.0, it was + changed every night by an automated script. Since gcc-4.1.0, it is + the same value as gcc/DATESTAMP.) + + + It is versioned as follows: + + + gcc-3.0.0: 20010615 + gcc-3.0.1: 20010819 + gcc-3.0.2: 20011023 + gcc-3.0.3: 20011220 + gcc-3.0.4: 20020220 + gcc-3.1.0: 20020514 + gcc-3.1.1: 20020725 + gcc-3.2.0: 20020814 + gcc-3.2.1: 20021119 + gcc-3.2.2: 20030205 + gcc-3.2.3: 20030422 + gcc-3.3.0: 20030513 + gcc-3.3.1: 20030804 + gcc-3.3.2: 20031016 + gcc-3.3.3: 20040214 + gcc-3.4.0: 20040419 + gcc-3.4.1: 20040701 + gcc-3.4.2: 20040906 + gcc-3.4.3: 20041105 + gcc-3.4.4: 20050519 + gcc-3.4.5: 20051201 + gcc-3.4.6: 20060306 + gcc-4.0.0: 20050421 + gcc-4.0.1: 20050707 + gcc-4.0.2: 20050921 + gcc-4.0.3: 20060309 + gcc-4.1.0: 20060228 + gcc-4.1.1: 20060524 + gcc-4.1.2: 20070214 + gcc-4.2.0: 20070514 + + + + + + + Incremental bumping of a library pre-defined macro, + _GLIBCPP_VERSION. This macro is defined as the released version of + the library, as a string literal. This is only implemented in + gcc-3.1.0 releases and higher, and is deprecated in 3.4 (where it + is called _GLIBCXX_VERSION). + + + + This macro is defined in the file "c++config" in the + "libstdc++/include/bits" directory and is generated + automatically by autoconf as part of the configure-time generation + of config.h. + + + + It is versioned as follows: + + + gcc-3.0.0: "3.0.0" + gcc-3.0.1: "3.0.0" (Error, should be "3.0.1") + gcc-3.0.2: "3.0.0" (Error, should be "3.0.2") + gcc-3.0.3: "3.0.0" (Error, should be "3.0.3") + gcc-3.0.4: "3.0.0" (Error, should be "3.0.4") + gcc-3.1.0: "3.1.0" + gcc-3.1.1: "3.1.1" + gcc-3.2.0: "3.2" + gcc-3.2.1: "3.2.1" + gcc-3.2.2: "3.2.2" + gcc-3.2.3: "3.2.3" + gcc-3.3.0: "3.3" + gcc-3.3.1: "3.3.1" + gcc-3.3.2: "3.3.2" + gcc-3.3.3: "3.3.3" + gcc-3.4.x: "version-unused" + gcc-4.0.x: "version-unused" + gcc-4.1.x: "version-unused" + gcc-4.2.x: "version-unused" + + + + + + + Matching each specific C++ compiler release to a specific set of + C++ include files. This is only implemented in gcc-3.1.1 releases + and higher. + + + All C++ includes are installed in include/c++, then nest in a + directory hierarchy corresponding to the C++ compiler's released + version. This version corresponds to the variable "gcc_version" in + "libstdc++/acinclude.m4," and more details can be found in that + file's macro GLIBCXX_CONFIGURE (GLIBCPP_CONFIGURE before gcc-3.4.0). + + + C++ includes are versioned as follows: + + + gcc-3.0.0: include/g++-v3 + gcc-3.0.1: include/g++-v3 + gcc-3.0.2: include/g++-v3 + gcc-3.0.3: include/g++-v3 + gcc-3.0.4: include/g++-v3 + gcc-3.1.0: include/g++-v3 + gcc-3.1.1: include/c++/3.1.1 + gcc-3.2.0: include/c++/3.2 + gcc-3.2.1: include/c++/3.2.1 + gcc-3.2.2: include/c++/3.2.2 + gcc-3.2.3: include/c++/3.2.3 + gcc-3.3.0: include/c++/3.3 + gcc-3.3.1: include/c++/3.3.1 + gcc-3.3.2: include/c++/3.3.2 + gcc-3.3.3: include/c++/3.3.3 + gcc-3.4.0: include/c++/3.4.0 + gcc-3.4.1: include/c++/3.4.1 + gcc-3.4.2: include/c++/3.4.2 + gcc-3.4.3: include/c++/3.4.3 + gcc-3.4.4: include/c++/3.4.4 + gcc-3.4.5: include/c++/3.4.5 + gcc-3.4.6: include/c++/3.4.6 + gcc-4.0.0: include/c++/4.0.0 + gcc-4.0.1: include/c++/4.0.1 + gcc-4.0.2: include/c++/4.0.2 + gcc-4.0.3: include/c++/4.0.3 + gcc-4.1.0: include/c++/4.1.0 + gcc-4.1.1: include/c++/4.1.1 + gcc-4.1.2: include/c++/4.1.2 + gcc-4.2.0: include/c++/4.2.0 + + + + + + + Taken together, these techniques can accurately specify interface + and implementation changes in the GNU C++ tools themselves. Used + properly, they allow both the GNU C++ tools implementation, and + programs using them, an evolving yet controlled development that + maintains backward compatibility. + + + + + + + Prerequisites + + Minimum environment that supports a versioned ABI: A supported + dynamic linker, a GNU linker of sufficient vintage to understand + demangled C++ name globbing (ld), a shared executable compiled + with g++, and shared libraries (libgcc_s, libstdc++) compiled by + a compiler (g++) with a compatible ABI. Phew. + + + + On top of all that, an additional constraint: libstdc++ did not + attempt to version symbols (or age gracefully, really) until + version 3.1.0. + + + + Most modern Linux and BSD versions, particularly ones using + gcc-3.1.x tools and more recent vintages, will meet the + requirements above. + + + + + Configuring + + + It turns out that most of the configure options that change + default behavior will impact the mangled names of exported + symbols, and thus impact versioning and compatibility. + + + + For more information on configure options, including ABI + impacts, see: + http://gcc.gnu.org/onlinedocs/libstdc++/configopts.html + + + + There is one flag that explicitly deals with symbol versioning: + --enable-symvers. + + + + In particular, libstdc++/acinclude.m4 has a macro called + GLIBCXX_ENABLE_SYMVERS that defaults to yes (or the argument + passed in via --enable-symvers=foo). At that point, the macro + attempts to make sure that all the requirement for symbol + versioning are in place. For more information, please consult + acinclude.m4. + + + + + Checking Active + + + When the GNU C++ library is being built with symbol versioning + on, you should see the following at configure time for + libstdc++: + + + + + checking versioning on shared library symbols... gnu + + + + + If you don't see this line in the configure output, or if this line + appears but the last word is 'no', then you are out of luck. + + + + If the compiler is pre-installed, a quick way to test is to compile + the following (or any) simple C++ file and link it to the shared + libstdc++ library: + + + +#include <iostream> + +int main() +{ std::cout << "hello" << std::endl; return 0; } + +%g++ hello.cc -o hello.out + +%ldd hello.out + libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x00764000) + libm.so.6 => /lib/tls/libm.so.6 (0x004a8000) + libgcc_s.so.1 => /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x40016000) + libc.so.6 => /lib/tls/libc.so.6 (0x0036d000) + /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00355000) + +%nm hello.out + + + +If you see symbols in the resulting output with "GLIBCXX_3" as part +of the name, then the executable is versioned. Here's an example: + + + + U _ZNSt8ios_base4InitC1Ev@@GLIBCXX_3.4 + + + + + + +Allowed Changes + + +The following will cause the library minor version number to +increase, say from "libstdc++.so.3.0.4" to "libstdc++.so.3.0.5". + + + Adding an exported global or static data member + Adding an exported function, static or non-virtual member function + Adding an exported symbol or symbols by additional instantiations + + +Other allowed changes are possible. + + + + + +Prohibited Changes + + +The following non-exhaustive list will cause the library major version +number to increase, say from "libstdc++.so.3.0.4" to +"libstdc++.so.4.0.0". + + + + Changes in the gcc/g++ compiler ABI +Changing size of an exported symbol +Changing alignment of an exported symbol +Changing the layout of an exported symbol +Changing mangling on an exported symbol +Deleting an exported symbol +Changing the inheritance properties of a type by adding or removing + base classes + + Changing the size, alignment, or layout of types + specified in the C++ standard. These may not necessarily be + instantiated or otherwise exported in the library binary, and + include all the required locale facets, as well as things like + std::basic_streambuf, et al. + + + Adding an explicit copy constructor or destructor to a +class that would otherwise have implicit versions. This will change +the way the compiler deals with this class in by-value return +statements or parameters: instead of being passing instances of this +class in registers, the compiler will be forced to use memory. See this part + of the C++ ABI documentation for further details. + + + + + + + + + +Implementation + + + + + Separation of interface and implementation + + + This is accomplished by two techniques that separate the API from + the ABI: forcing undefined references to link against a library + binary for definitions. + + + + + Include files have declarations, source files have defines + + + + For non-templatized types, such as much of class + locale, the appropriate standard C++ include, say + locale, can contain full declarations, while + various source files (say locale.cc, locale_init.cc, + localename.cc) contain definitions. + + + + + + Extern template on required types + + + + For parts of the standard that have an explicit list of + required instantiations, the GNU extension syntax extern + template can be used to control where template + definitions reside. By marking required instantiations as + extern template in include files, and providing + explicit instantiations in the appropriate instantiation files, + non-inlined template functions can be versioned. This technique + is mostly used on parts of the standard that require + char and wchar_t instantiations, and + includes basic_string, the locale facets, and the + types in iostreams. + + + + + + + + In addition, these techniques have the additional benefit that they + reduce binary size, which can increase runtime performance. + + + + + + Namespaces linking symbol definitions to export mapfiles + + + All symbols in the shared library binary are processed by a + linker script at build time that either allows or disallows + external linkage. Because of this, some symbols, regardless of + normal C/C++ linkage, are not visible. Symbols that are internal + have several appealing characteristics: by not exporting the + symbols, there are no relocations when the shared library is + started and thus this makes for faster runtime loading + performance by the underlying dynamic loading mechanism. In + addition, they have the possibility of changing without impacting + ABI compatibility. + + +The following namespaces are transformed by the mapfile: + + + + +namespace std + Defaults to exporting all symbols in label +GLIBCXX that do not begin with an underscore, ie +__test_func would not be exported by default. Select +exceptional symbols are allowed to be visible. + + + +namespace __gnu_cxx + Defaults to not exporting any symbols in label +GLIBCXX, select items are allowed to be visible. + + + +namespace __gnu_internal + Defaults to not exported, no items are allowed to be visible. + + + +namespace __cxxabiv1, aliased to namespace abi + Defaults to not exporting any symbols in label +CXXABI, select items are allowed to be visible. + + + + + + + + Freezing the API + Disallowed changes, as above, are not made on a stable release +branch. Enforcement tends to be less strict with GNU extensions that +standard includes. + + + + + + +Testing + + + Single ABI Testing + + + Testing for GNU C++ ABI changes is composed of two distinct + areas: testing the C++ compiler (g++) for compiler changes, and + testing the C++ library (libstdc++) for library changes. + + + + Testing the C++ compiler ABI can be done various ways. + + + + One. Intel ABI checker. More information can be obtained here. + + + +Two. +The second is yet unreleased, but has been announced on the gcc +mailing list. It is yet unspecified if these tools will be freely +available, and able to be included in a GNU project. Please contact +Mark Mitchell (mark@codesourcery.com) for more details, and current +status. + + + +Three. +Involves using the vlad.consistency test framework. This has also been +discussed on the gcc mailing lists. + + + +Testing the C++ library ABI can also be done various ways. + + + +One. +(Brendan Kehoe, Jeff Law suggestion to run 'make check-c++' two ways, +one with a new compiler and an old library, and the other with an old +compiler and a new library, and look for testsuite regressions) + + + +Details on how to set this kind of test up can be found here: +http://gcc.gnu.org/ml/gcc/2002-08/msg00142.html + + + +Two. +Use the 'make check-abi' rule in the libstdc++ Makefile. + + + +This is a proactive check the library ABI. Currently, exported symbol +names that are either weak or defined are checked against a last known +good baseline. Currently, this baseline is keyed off of 3.4.0 +binaries, as this was the last time the .so number was incremented. In +addition, all exported names are demangled, and the exported objects +are checked to make sure they are the same size as the same object in +the baseline. + +Notice that each baseline is relative to a default +configured library and compiler: in particular, if options such as +--enable-clocale, or --with-cpu, in case of multilibs, are used at +configure time, the check may fail, either because of substantive +differences or because of limitations of the current checking +machinery. + + + +This dataset is insufficient, yet a start. Also needed is a +comprehensive check for all user-visible types part of the standard +library for sizeof() and alignof() changes. + + + +Verifying compatible layouts of objects is not even attempted. It +should be possible to use sizeof, alignof, and offsetof to compute +offsets for each structure and type in the standard library, saving to +another datafile. Then, compute this in a similar way for new +binaries, and look for differences. + + + +Another approach might be to use the -fdump-class-hierarchy flag to +get information. However, currently this approach gives insufficient +data for use in library testing, as class data members, their offsets, +and other detailed data is not displayed with this flag. +(See g++/7470 on how this was used to find bugs.) + + + +Perhaps there are other C++ ABI checkers. If so, please notify +us. We'd like to know about them! + + + + + Multiple ABI Testing + +A "C" application, dynamically linked to two shared libraries, liba, +libb. The dependent library liba is C++ shared library compiled with +gcc-3.3.x, and uses io, exceptions, locale, etc. The dependent library +libb is a C++ shared library compiled with gcc-3.4.x, and also uses io, +exceptions, locale, etc. + + + As above, libone is constructed as follows: + +%$bld/H-x86-gcc-3.4.0/bin/g++ -fPIC -DPIC -c a.cc + +%$bld/H-x86-gcc-3.4.0/bin/g++ -shared -Wl,-soname -Wl,libone.so.1 -Wl,-O1 -Wl,-z,defs a.o -o libone.so.1.0.0 + +%ln -s libone.so.1.0.0 libone.so + +%$bld/H-x86-gcc-3.4.0/bin/g++ -c a.cc + +%ar cru libone.a a.o + + + And, libtwo is constructed as follows: + + +%$bld/H-x86-gcc-3.3.3/bin/g++ -fPIC -DPIC -c b.cc + +%$bld/H-x86-gcc-3.3.3/bin/g++ -shared -Wl,-soname -Wl,libtwo.so.1 -Wl,-O1 -Wl,-z,defs b.o -o libtwo.so.1.0.0 + +%ln -s libtwo.so.1.0.0 libtwo.so + +%$bld/H-x86-gcc-3.3.3/bin/g++ -c b.cc + +%ar cru libtwo.a b.o + + + ...with the resulting libraries looking like + + + +%ldd libone.so.1.0.0 + libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x40016000) + libm.so.6 => /lib/tls/libm.so.6 (0x400fa000) + libgcc_s.so.1 => /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x4011c000) + libc.so.6 => /lib/tls/libc.so.6 (0x40125000) + /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00355000) + +%ldd libtwo.so.1.0.0 + libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40027000) + libm.so.6 => /lib/tls/libm.so.6 (0x400e1000) + libgcc_s.so.1 => /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x40103000) + libc.so.6 => /lib/tls/libc.so.6 (0x4010c000) + /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00355000) + + + + + Then, the "C" compiler is used to compile a source file that uses + functions from each library. + + +gcc test.c -g -O2 -L. -lone -ltwo /usr/lib/libstdc++.so.5 /usr/lib/libstdc++.so.6 + + + + Which gives the expected: + + + + +%ldd a.out + libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x00764000) + libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x40015000) + libc.so.6 => /lib/tls/libc.so.6 (0x0036d000) + libm.so.6 => /lib/tls/libm.so.6 (0x004a8000) + libgcc_s.so.1 => /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x400e5000) + /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00355000) + + + + + This resulting binary, when executed, will be able to safely use + code from both liba, and the dependent libstdc++.so.6, and libb, + with the dependent libstdc++.so.5. + + + + + +Outstanding Issues + + + Some features in the C++ language make versioning especially + difficult. In particular, compiler generated constructs such as + implicit instantiations for templates, typeinfo information, and + virtual tables all may cause ABI leakage across shared library + boundaries. Because of this, mixing C++ ABI's is not recommended at + this time. + + + + For more background on this issue, see these bugzilla entries: + + + +24660: versioning weak symbols in libstdc++ + + + +19664: libstdc++ headers should have pop/push of the visibility around the declarations + + + + + +Bibliography + + + + ABIcheck, a vague idea of checking ABI compatibility + + + + + + + + + + + C++ ABI Reference + + + + + + + + + + + Intel® Compilers for Linux* -Compatibility with the GNU Compilers + + + + + + + + + + + Intel® Compilers for Linux* -Compatibility with the GNU Compilers + + + + + + + + + + + Sun Solaris 2.9 : Linker and Libraries Guide (document 816-1386) + + + + + + + + + + + + Sun Solaris 2.9 : C++ Migration Guide (document 816-2459) + + + + + + + + + + + ELF Symbol Versioning + + + + Ulrich + Drepper + + + + + + + + + + + C++ ABI for the ARM Architecture + + + + + + + + + + + Dynamic Shared Objects: Survey and Issues + + + ISO C++ J16/06-0046 + + + + Benjamin + Kosnik + + + + + + + + + + + Versioning With Namespaces + + + ISO C++ J16/06-0083 + + + + Benjamin + Kosnik + + + + + + + + + + + \ No newline at end of file diff --git a/libstdc++-v3/doc/xml/manual/algorithms.xml b/libstdc++-v3/doc/xml/manual/algorithms.xml new file mode 100644 index 00000000000..6f1a16af24f --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/algorithms.xml @@ -0,0 +1,104 @@ + + + + + + + + + + ISO C++ + + + library + + + algorithm + + + + +Algorithms + + + + + The neatest accomplishment of the algorithms chapter is that all the + work is done via iterators, not containers directly. This means two + important things: + + + + + Anything that behaves like an iterator can be used in one of + these algorithms. Raw pointers make great candidates, thus + built-in arrays are fine containers, as well as your own iterators. + + + + + The algorithms do not (and cannot) affect the container as a + whole; only the things between the two iterator endpoints. If + you pass a range of iterators only enclosing the middle third of + a container, then anything outside that range is inviolate. + + + + + Even strings can be fed through the algorithms here, although the + string class has specialized versions of many of these functions + (for example, string::find()). Most of the examples + on this page will use simple arrays of integers as a playground + for algorithms, just to keep things simple. The use of + N as a size in the examples is to keep + things easy to read but probably won't be valid code. You can + use wrappers such as those described in the containers chapter to + keep real code readable. + + + The single thing that trips people up the most is the definition + of range used with iterators; the famous + "past-the-end" rule that everybody loves to hate. The + iterators + chapter of this document has a complete explanation of + this simple rule that seems to cause so much confusion. Once you + get range into your head (it's not that + hard, honest!), then the algorithms are a cakewalk. + + + + + + + + Mutating + + + <function>swap</function> + + + Specializations + + If you call std::swap(x,y); where x and y are standard + containers, then the call will automatically be replaced by a call to + x.swap(y); instead. + + This allows member functions of each container class to take over, and + containers' swap functions should have O(1) complexity according to + the standard. (And while "should" allows implementations to + behave otherwise and remain compliant, this implementation does in + fact use constant-time swaps.) This should not be surprising, since + for two containers of the same type to swap contents, only some + internal pointers to storage need to be exchanged. + + + + + + + + + diff --git a/libstdc++-v3/doc/xml/manual/allocator.xml b/libstdc++-v3/doc/xml/manual/allocator.xml new file mode 100644 index 00000000000..213d82b7e59 --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/allocator.xml @@ -0,0 +1,659 @@ + + + + + + + ISO C++ + + + allocator + + + + +Allocators + + + Memory management for Standard Library entities is encapsulated in a + class template called allocator. The + allocator abstraction is used throughout the + library in string, container classes, + algorithnms, and parts of iostreams. This class, and base classes of + it, are the superset of available free store (heap) + management classes. + + + +Requirements + + + The C++ standard only gives a few directives in this area: + + + + + When you add elements to a container, and the container must + allocate more memory to hold them, the container makes the + request via its Allocator template + parameter, which is usually aliased to + allocator_type. This includes adding chars + to the string class, which acts as a regular STL container in + this respect. + + + + + The default Allocator argument of every + container-of-T is allocator<T>. + + + + + The interface of the allocator<T> class is + extremely simple. It has about 20 public declarations (nested + typedefs, member functions, etc), but the two which concern us most + are: + + + T* allocate (size_type n, const void* hint = 0); + void deallocate (T* p, size_type n); + + + + The n arguments in both those + functions is a count of the number of + T's to allocate space for, not their + total size. + (This is a simplification; the real signatures use nested typedefs.) + + + + + The storage is obtained by calling ::operator + new, but it is unspecified when or how + often this function is called. The use of the + hint is unspecified, but intended as an + aid to locality if an implementation so + desires. [20.4.1.1]/6 + + + + + + Complete details cam be found in the C++ standard, look in + [20.4 Memory]. + + + + + +Design Issues + + + The easiest way of fulfilling the requirements is to call + operator new each time a container needs + memory, and to call operator delete each time + the container releases memory. This method may be slower + than caching the allocations and re-using previously-allocated + memory, but has the advantage of working correctly across a wide + variety of hardware and operating systems, including large + clusters. The __gnu_cxx::new_allocator + implements the simple operator new and operator delete semantics, + while __gnu_cxx::malloc_allocator + implements much the same thing, only with the C language functions + std::malloc and free. + + + + Another approach is to use intelligence within the allocator + class to cache allocations. This extra machinery can take a variety + of forms: a bitmap index, an index into an exponentially increasing + power-of-two-sized buckets, or simpler fixed-size pooling cache. + The cache is shared among all the containers in the program: when + your program's std::vector<int> gets + cut in half and frees a bunch of its storage, that memory can be + reused by the private + std::list<WonkyWidget> brought in from + a KDE library that you linked against. And operators + new and delete are not + always called to pass the memory on, either, which is a speed + bonus. Examples of allocators that use these techniques are + __gnu_cxx::bitmap_allocator, + __gnu_cxx::pool_allocator, and + __gnu_cxx::__mt_alloc. + + + + Depending on the implementation techniques used, the underlying + operating system, and compilation environment, scaling caching + allocators can be tricky. In particular, order-of-destruction and + order-of-creation for memory pools may be difficult to pin down + with certainty, which may create problems when used with plugins + or loading and unloading shared objects in memory. As such, using + caching allocators on systems that do not support + abi::__cxa_atexit is not recommended. + + + + + +Implementation + + + Interface Design + + + The only allocator interface that + is support is the standard C++ interface. As such, all STL + containers have been adjusted, and all external allocators have + been modified to support this change. + + + + The class allocator just has typedef, + constructor, and rebind members. It inherits from one of the + high-speed extension allocators, covered below. Thus, all + allocation and deallocation depends on the base class. + + + + The base class that allocator is derived from + may not be user-configurable. + + + + + + Selecting Default Allocation Policy + + + It's difficult to pick an allocation strategy that will provide + maximum utility, without excessively penalizing some behavior. In + fact, it's difficult just deciding which typical actions to measure + for speed. + + + + Three synthetic benchmarks have been created that provide data + that is used to compare different C++ allocators. These tests are: + + + + + + Insertion. + + + Over multiple iterations, various STL container + objects have elements inserted to some maximum amount. A variety + of allocators are tested. + Test source for sequence + and associative + containers. + + + + + + + Insertion and erasure in a multi-threaded environment. + + + This test shows the ability of the allocator to reclaim memory + on a pre-thread basis, as well as measuring thread contention + for memory resources. + Test source + here. + + + + + + A threaded producer/consumer model. + + + Test source for + sequence + and + associative + containers. + + + + + + The current default choice for + allocator is + __gnu_cxx::new_allocator. + + + + + + Disabling Memory Caching + + + In use, allocator may allocate and + deallocate using implementation-specified strategies and + heuristics. Because of this, every call to an allocator object's + allocate member function may not actually + call the global operator new. This situation is also duplicated + for calls to the deallocate member + function. + + + + This can be confusing. + + + + In particular, this can make debugging memory errors more + difficult, especially when using third party tools like valgrind or + debug versions of new. + + + + There are various ways to solve this problem. One would be to use + a custom allocator that just called operators + new and delete + directly, for every allocation. (See + include/ext/new_allocator.h, for instance.) + However, that option would involve changing source code to use + the a non-default allocator. Another option is to force the + default allocator to remove caching and pools, and to directly + allocate with every call of allocate and + directly deallocate with every call of + deallocate, regardless of efficiency. As it + turns out, this last option is also available. + + + + + To globally disable memory caching within the library for the + default allocator, merely set + GLIBCXX_FORCE_NEW (with any value) in the + system's environment before running the program. If your program + crashes with GLIBCXX_FORCE_NEW in the + environment, it likely means that you linked against objects + built against the older library (objects which might still using the + cached allocations...). + + + + + + + +Using a Specific Allocator + + + You can specify different memory management schemes on a + per-container basis, by overriding the default + Allocator template parameter. For example, an easy + (but non-portable) method of specifying that only malloc or free + should be used instead of the default node allocator is: + + + std::list <int, __gnu_cxx::malloc_allocator<int> > malloc_list; + + Likewise, a debugging form of whichever allocator is currently in use: + + + std::deque <int, __gnu_cxx::debug_allocator<std::allocator<int> > > debug_deque; + + + + +Custom Allocators + + + Writing a portable C++ allocator would dictate that the interface + would look much like the one specified for + allocator. Additional member functions, but + not subtractions, would be permissible. + + + + Probably the best place to start would be to copy one of the + extension allocators: say a simple one like + new_allocator. + + + + + +Extension Allocators + + + Several other allocators are provided as part of this + implementation. The location of the extension allocators and their + names have changed, but in all cases, functionality is + equivalent. Starting with gcc-3.4, all extension allocators are + standard style. Before this point, SGI style was the norm. Because of + this, the number of template arguments also changed. Here's a simple + chart to track the changes. + + + + More details on each of these extension allocators follows. + + + + + new_allocator + + + Simply wraps ::operator new + and ::operator delete. + + + + + malloc_allocator + + + Simply wraps malloc and + free. There is also a hook for an + out-of-memory handler (for + new/delete this is + taken care of elsewhere). + + + + + array_allocator + + + Allows allocations of known and fixed sizes using existing + global or external storage allocated via construction of + std::tr1::array objects. By using this + allocator, fixed size containers (including + std::string) can be used without + instances calling ::operator new and + ::operator delete. This capability + allows the use of STL abstractions without runtime + complications or overhead, even in situations such as program + startup. For usage examples, please consult the testsuite. + + + + + debug_allocator + + + A wrapper around an arbitrary allocator A. It passes on + slightly increased size requests to A, and uses the extra + memory to store size information. When a pointer is passed + to deallocate(), the stored size is + checked, and assert() is used to + guarantee they match. + + + + + throw_allocator + + + Includes memory tracking and marking abilities as well as hooks for + throwing exceptinos at configurable intervals (including random, + all, none). + + + + + __pool_alloc + + + A high-performance, single pool allocator. The reusable + memory is shared among identical instantiations of this type. + It calls through ::operator new to + obtain new memory when its lists run out. If a client + container requests a block larger than a certain threshold + size, then the pool is bypassed, and the allocate/deallocate + request is passed to ::operator new + directly. + + + + Older versions of this class take a boolean template + parameter, called thr, and an integer template + parameter, called inst. + + + + The inst number is used to track additional memory + pools. The point of the number is to allow multiple + instantiations of the classes without changing the semantics at + all. All three of + + + + typedef __pool_alloc<true,0> normal; + typedef __pool_alloc<true,1> private; + typedef __pool_alloc<true,42> also_private; + + + behave exactly the same way. However, the memory pool for each type + (and remember that different instantiations result in different types) + remains separate. + + + The library uses 0 in all its instantiations. If you + wish to keep separate free lists for a particular purpose, use a + different number. + + The thr boolean determines whether the + pool should be manipulated atomically or not. When + thr = true, the allocator + is is threadsafe, while thr = + false, and is slightly faster but unsafe for + multiple threads. + + + + For thread-enabled configurations, the pool is locked with a + single big lock. In some situations, this implementation detail + may result in severe performance degredation. + + + + (Note that the GCC thread abstraction layer allows us to provide + safe zero-overhead stubs for the threading routines, if threads + were disabled at configuration time.) + + + + + + __mt_alloc + + + A high-performance fixed-size allocator with + exponentially-increasing allocations. It has its own + documentation, found here. + + + + + + bitmap_allocator + + + A high-performance allocator that uses a bit-map to keep track + of the used and unused memory locations. It has its own + documentation, found here. + + + + + + + +Bibliography + + + + ISO/IEC 14882:1998 Programming languages - C++ + + + + isoc++_1998 + + 20.4 Memory + + + + The Standard Librarian: What Are Allocators Good + + + + austernm + + + + Matt + Austern + + + + + C/C++ Users Journal + + + + + + + + + + + The Hoard Memory Allocator + + + emeryb + + + + Emery + Berger + + + + + + + + + + Reconsidering Custom Memory Allocation + + + bergerzorn + + + + Emery + Berger + + + Ben + Zorn + + + Kathryn + McKinley + + + + 2002 + OOPSLA + + + + + + + + + + + Allocator Types + + + kreftlanger + + + + Klaus + Kreft + + + Angelika + Langer + + + + + C/C++ Users Journal + + + + + + + + + + + The C++ Programming Language + + + tcpl + + + + Bjarne + Stroustrup + + + 2000 + + + 19.4 Allocators + + + + Addison Wesley + + + + + + Yalloc: A Recycling C++ Allocator + + + yenf + + + + Felix + Yen + + + + + + + + + + + + + + diff --git a/libstdc++-v3/doc/xml/manual/appendix_contributing.xml b/libstdc++-v3/doc/xml/manual/appendix_contributing.xml new file mode 100644 index 00000000000..033bd7dbbef --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/appendix_contributing.xml @@ -0,0 +1,1847 @@ + + + + + + + + + + ISO C++ + + + library + + + + +Contributing + + + The GNU C++ Library follows an open development model. Active + contributors are assigned maintainer-ship responsibility, and given + write access to the source repository. First time contributors + should follow this procedure: + + + + Contributor Checklist + + + Reading + + + Get and read the relevant sections of the C++ language +specification. Copies of the full ISO 14882 standard are available on +line via the ISO mirror site for committee members. Non-members, or +those who have not paid for the privilege of sitting on the committee +and sustained their two meeting commitment for voting rights, may get +a copy of the standard from their respective national standards +organization. In the USA, this national standards organization is ANSI +and their web-site is right + + here. +(And if you've already registered with them, clicking this link will take you to directly to the place where you can +buy the standard on-line.) + + + The library working group bugs, and known defects, can be obtained here: + http://www.open-std.org/jtc1/sc22/wg21 + + + The newsgroup dedicated to standardization issues is comp.std.c++: this FAQ for this group is quite useful and can be found here . + + + Peruse the GNU Coding Standards, and chuckle when you hit the part about "Using Languages Other Than C." + + + Be familiar with the extensions that preceded these general GNU rules. These style issues for libstdc++ can be found in the file C++STYLE, located in the root level of the distribution, or here. + + + And last but certainly not least, read the library-specific information found here. + + + + + + + Assignment + +Small changes can be accepted without a copyright assignment form on +file. New code and additions to the library need completed copyright +assignment form on file at the FSF. Note: your employer may be required +to fill out appropriate disclaimer forms as well. + + + + Historically, the libstdc++ assignment form added the following + question: + + + + + Which Belgian comic book character is better, Tintin or Asterix, and + why? + + + + +While not strictly necessary, humoring the maintainers and answering +this question would be appreciated. + + + +For more information about getting a copyright assignment, please see +Legal +Matters. + + + +Please contact Benjamin Kosnik at +bkoz+assign@redhat.com if you are confused +about the assignment or have general licensing questions. When +requesting an assignment form from +mailto:assign@gnu.org, please cc the libstdc++ +maintainer above so that progress can be monitored. + + + + + Getting Sources + + Getting write access + (look for "Write after approval") + + + + + Submitting Patches + + + +Every patch must have several pieces of information before it can be +properly evaluated. Ideally (and to ensure the fastest possible +response from the maintainers) it would have all of these pieces: + + + + + A description of the bug and how your patch fixes this bug. For + new features a description of the feature and your implementation. + + A ChangeLog entry as plain text; see the various ChangeLog files + for format and content. If using you are using emacs as your editor, + simply position the insertion point at the beginning of your change + and hit CX-4a to bring up the appropriate ChangeLog + entry. See--magic! Similar functionality also exists for vi. + + A testsuite submission or sample program that will easily and + simply show the existing error or test new functionality. + + The patch itself. If you are accessing the SVN repository + use "svn update; svn diff NEW"; else, use "diff -cp OLD NEW" + ... If your version of diff does not support these options, then + get the latest version of GNU diff. The SVN Tricks wiki page + has information on customising the output of svn diff. + + When you have all these pieces, bundle them up in a mail message +and send it to libstdc++@gcc.gnu.org. All patches and related +discussion should be sent to the libstdc++ mailing list. + + + + + + + + + Coding Style + + + + Bad Itentifiers + +Identifiers that conflict and should be avoided. + + + + +This is the list of names "reserved to the implementation" that +have been claimed by certain compilers and system headers of interest, +and should not be used in the library. It will grow, of course. +We generally are interested in names that are not all-caps, except +for those like "_T" + +For Solarix: +_B +_C +_L +_N +_P +_S +_U +_X +_E1 +.. +_E24 + +Irix adds: +_A +_G + +MS adds: +_T + +BSD adds: +__used +__unused +__inline +_Complex +__istype +__maskrune +__tolower +__toupper +__wchar_t +__wint_t +_res +_res_ext +__tg_* + +For GCC: + + [Note that this list is out of date. It applies to the old + name-mangling; in G++ 3.0 and higher a different name-mangling is + used. In addition, many of the bugs relating to G++ interpreting + these names as operators have been fixed.] + + The full set of __* identifiers (combined from gcc/cp/lex.c and + gcc/cplus-dem.c) that are either old or new, but are definitely + recognized by the demangler, is: + +__aa +__aad +__ad +__addr +__adv +__aer +__als +__alshift +__amd +__ami +__aml +__amu +__aor +__apl +__array +__ars +__arshift +__as +__bit_and +__bit_ior +__bit_not +__bit_xor +__call +__cl +__cm +__cn +__co +__component +__compound +__cond +__convert +__delete +__dl +__dv +__eq +__er +__ge +__gt +__indirect +__le +__ls +__lt +__max +__md +__method_call +__mi +__min +__minus +__ml +__mm +__mn +__mult +__mx +__ne +__negate +__new +__nop +__nt +__nw +__oo +__op +__or +__pl +__plus +__postdecrement +__postincrement +__pp +__pt +__rf +__rm +__rs +__sz +__trunc_div +__trunc_mod +__truth_andif +__truth_not +__truth_orif +__vc +__vd +__vn + +SGI badnames: +__builtin_alloca +__builtin_fsqrt +__builtin_sqrt +__builtin_fabs +__builtin_dabs +__builtin_cast_f2i +__builtin_cast_i2f +__builtin_cast_d2ll +__builtin_cast_ll2d +__builtin_copy_dhi2i +__builtin_copy_i2dhi +__builtin_copy_dlo2i +__builtin_copy_i2dlo +__add_and_fetch +__sub_and_fetch +__or_and_fetch +__xor_and_fetch +__and_and_fetch +__nand_and_fetch +__mpy_and_fetch +__min_and_fetch +__max_and_fetch +__fetch_and_add +__fetch_and_sub +__fetch_and_or +__fetch_and_xor +__fetch_and_and +__fetch_and_nand +__fetch_and_mpy +__fetch_and_min +__fetch_and_max +__lock_test_and_set +__lock_release +__lock_acquire +__compare_and_swap +__synchronize +__high_multiply +__unix +__sgi +__linux__ +__i386__ +__i486__ +__cplusplus +__embedded_cplusplus +// long double conversion members mangled as __opr +// http://gcc.gnu.org/ml/libstdc++/1999-q4/msg00060.html +_opr + + + + + By Example + + +This library is written to appropriate C++ coding standards. As such, +it is intended to precede the recommendations of the GNU Coding +Standard, which can be referenced in full here: + +http://www.gnu.org/prep/standards/standards.html#Formatting + +The rest of this is also interesting reading, but skip the "Design +Advice" part. + +The GCC coding conventions are here, and are also useful: +http://gcc.gnu.org/codingconventions.html + +In addition, because it doesn't seem to be stated explicitly anywhere +else, there is an 80 column source limit. + +ChangeLog entries for member functions should use the +classname::member function name syntax as follows: + +1999-04-15 Dennis Ritchie <dr@att.com> + + * src/basic_file.cc (__basic_file::open): Fix thinko in + _G_HAVE_IO_FILE_OPEN bits. + +Notable areas of divergence from what may be previous local practice +(particularly for GNU C) include: + +01. Pointers and references + char* p = "flop"; + char& c = *p; + -NOT- + char *p = "flop"; // wrong + char &c = *p; // wrong + + Reason: In C++, definitions are mixed with executable code. Here, + p is being initialized, not *p. This is near-universal + practice among C++ programmers; it is normal for C hackers + to switch spontaneously as they gain experience. + +02. Operator names and parentheses + operator==(type) + -NOT- + operator == (type) // wrong + + Reason: The == is part of the function name. Separating + it makes the declaration look like an expression. + +03. Function names and parentheses + void mangle() + -NOT- + void mangle () // wrong + + Reason: no space before parentheses (except after a control-flow + keyword) is near-universal practice for C++. It identifies the + parentheses as the function-call operator or declarator, as + opposed to an expression or other overloaded use of parentheses. + +04. Template function indentation + template<typename T> + void + template_function(args) + { } + -NOT- + template<class T> + void template_function(args) {}; + + Reason: In class definitions, without indentation whitespace is + needed both above and below the declaration to distinguish + it visually from other members. (Also, re: "typename" + rather than "class".) T often could be int, which is + not a class. ("class", here, is an anachronism.) + +05. Template class indentation + template<typename _CharT, typename _Traits> + class basic_ios : public ios_base + { + public: + // Types: + }; + -NOT- + template<class _CharT, class _Traits> + class basic_ios : public ios_base + { + public: + // Types: + }; + -NOT- + template<class _CharT, class _Traits> + class basic_ios : public ios_base + { + public: + // Types: + }; + +06. Enumerators + enum + { + space = _ISspace, + print = _ISprint, + cntrl = _IScntrl + }; + -NOT- + enum { space = _ISspace, print = _ISprint, cntrl = _IScntrl }; + +07. Member initialization lists + All one line, separate from class name. + + gribble::gribble() + : _M_private_data(0), _M_more_stuff(0), _M_helper(0); + { } + -NOT- + gribble::gribble() : _M_private_data(0), _M_more_stuff(0), _M_helper(0); + { } + +08. Try/Catch blocks + try + { + // + } + catch (...) + { + // + } + -NOT- + try { + // + } catch(...) { + // + } + +09. Member functions declarations and definitions + Keywords such as extern, static, export, explicit, inline, etc + go on the line above the function name. Thus + + virtual int + foo() + -NOT- + virtual int foo() + + Reason: GNU coding conventions dictate return types for functions + are on a separate line than the function name and parameter list + for definitions. For C++, where we have member functions that can + be either inline definitions or declarations, keeping to this + standard allows all member function names for a given class to be + aligned to the same margin, increasing readibility. + + +10. Invocation of member functions with "this->" + For non-uglified names, use this->name to call the function. + + this->sync() + -NOT- + sync() + + Reason: Koenig lookup. + +11. Namespaces + namespace std + { + blah blah blah; + } // namespace std + + -NOT- + + namespace std { + blah blah blah; + } // namespace std + +12. Spacing under protected and private in class declarations: + space above, none below + ie + + public: + int foo; + + -NOT- + public: + + int foo; + +13. Spacing WRT return statements. + no extra spacing before returns, no parenthesis + ie + + } + return __ret; + + -NOT- + } + + return __ret; + + -NOT- + + } + return (__ret); + + +14. Location of global variables. + All global variables of class type, whether in the "user visable" + space (e.g., cin) or the implementation namespace, must be defined + as a character array with the appropriate alignment and then later + re-initialized to the correct value. + + This is due to startup issues on certain platforms, such as AIX. + For more explanation and examples, see src/globals.cc. All such + variables should be contained in that file, for simplicity. + +15. Exception abstractions + Use the exception abstractions found in functexcept.h, which allow + C++ programmers to use this library with -fno-exceptions. (Even if + that is rarely advisable, it's a necessary evil for backwards + compatibility.) + +16. Exception error messages + All start with the name of the function where the exception is + thrown, and then (optional) descriptive text is added. Example: + + __throw_logic_error(__N("basic_string::_S_construct NULL not valid")); + + Reason: The verbose terminate handler prints out exception::what(), + as well as the typeinfo for the thrown exception. As this is the + default terminate handler, by putting location info into the + exception string, a very useful error message is printed out for + uncaught exceptions. So useful, in fact, that non-programmers can + give useful error messages, and programmers can intelligently + speculate what went wrong without even using a debugger. + +17. The doxygen style guide to comments is a separate document, + see index. + +The library currently has a mixture of GNU-C and modern C++ coding +styles. The GNU C usages will be combed out gradually. + +Name patterns: + +For nonstandard names appearing in Standard headers, we are constrained +to use names that begin with underscores. This is called "uglification". +The convention is: + + Local and argument names: __[a-z].* + + Examples: __count __ix __s1 + + Type names and template formal-argument names: _[A-Z][^_].* + + Examples: _Helper _CharT _N + + Member data and function names: _M_.* + + Examples: _M_num_elements _M_initialize () + + Static data members, constants, and enumerations: _S_.* + + Examples: _S_max_elements _S_default_value + +Don't use names in the same scope that differ only in the prefix, +e.g. _S_top and _M_top. See BADNAMES for a list of forbidden names. +(The most tempting of these seem to be and "_T" and "__sz".) + +Names must never have "__" internally; it would confuse name +unmanglers on some targets. Also, never use "__[0-9]", same reason. + +-------------------------- + +[BY EXAMPLE] + +#ifndef _HEADER_ +#define _HEADER_ 1 + +namespace std +{ + class gribble + { + public: + gribble() throw(); + + gribble(const gribble&); + + explicit + gribble(int __howmany); + + gribble& + operator=(const gribble&); + + virtual + ~gribble() throw (); + + // Start with a capital letter, end with a period. + inline void + public_member(const char* __arg) const; + + // In-class function definitions should be restricted to one-liners. + int + one_line() { return 0 } + + int + two_lines(const char* arg) + { return strchr(arg, 'a'); } + + inline int + three_lines(); // inline, but defined below. + + // Note indentation. + template<typename _Formal_argument> + void + public_template() const throw(); + + template<typename _Iterator> + void + other_template(); + + private: + class _Helper; + + int _M_private_data; + int _M_more_stuff; + _Helper* _M_helper; + int _M_private_function(); + + enum _Enum + { + _S_one, + _S_two + }; + + static void + _S_initialize_library(); + }; + +// More-or-less-standard language features described by lack, not presence. +# ifndef _G_NO_LONGLONG + extern long long _G_global_with_a_good_long_name; // avoid globals! +# endif + + // Avoid in-class inline definitions, define separately; + // likewise for member class definitions: + inline int + gribble::public_member() const + { int __local = 0; return __local; } + + class gribble::_Helper + { + int _M_stuff; + + friend class gribble; + }; +} + +// Names beginning with "__": only for arguments and +// local variables; never use "__" in a type name, or +// within any name; never use "__[0-9]". + +#endif /* _HEADER_ */ + + +namespace std +{ + template<typename T> // notice: "typename", not "class", no space + long_return_value_type<with_many, args> + function_name(char* pointer, // "char *pointer" is wrong. + char* argument, + const Reference& ref) + { + // int a_local; /* wrong; see below. */ + if (test) + { + nested code + } + + int a_local = 0; // declare variable at first use. + + // char a, b, *p; /* wrong */ + char a = 'a'; + char b = a + 1; + char* c = "abc"; // each variable goes on its own line, always. + + // except maybe here... + for (unsigned i = 0, mask = 1; mask; ++i, mask <<= 1) { + // ... + } + } + + gribble::gribble() + : _M_private_data(0), _M_more_stuff(0), _M_helper(0); + { } + + inline int + gribble::three_lines() + { + // doesn't fit in one line. + } +} // namespace std + + + + + + + + Documentation Style + + + + Doxygen + + Generating the Doxygen Files + +The Makefile rules 'make doc-doxygen-html', + and 'make doc-doxygen-man' in the libstdc++ build + directory generate the HTML docs, the and the man pages, + respectively. Prerequisite tools are Bash 2.x, + Doxygen, a working version of g++ somewhere in the PATH, and + the GNU coreutils. + + In addition, to generate the pretty pictures and hierarchy graphs, the + Graphviz + package will need to be installed. + (g++ is used to build a program which manipulates man pages. GNU versions + of find, xargs, and possibly sed and grep are used, just because the GNU + versions make things very easy.) + + +Careful observers will see that the Makefile rules simply call a script + from the source tree, run_doxygen, which does the actual work + of running Doxygen and then (most importantly) massaging the output files. + If for some reason you prefer to not go through the Makefile, you can call + this script directly. (Start by passing '--help'.) + + +If you wish to tweak the Doxygen settings, do so by editing + docs/doxygen/user.cfg.in. Notes to v3-hackers are written in + triple-# comments. + + + + + + Markup + +In general, libstdc++ files should be formatted according to the GNU + C++ Coding Standard rules found in the file + C++STYLE. + Before any doxygen-specific formatting tweaks are made, please try to make + sure that the initial formatting is sound. + + +Adding Doxygen markup to a file (informally called "doxygenating") is very + simple. The Doxygen manual can be found + here. + We try to use a very-recent version of Doxygen. + + +For classes, use deque/vector/list and std::pair as examples. For + functions, see their member functions, and the free functions in + stl_algobase.h. Member functions of other container-like + types should read similarly to these member functions. + + +These points accompany the first list in section 3.1 of the Doxygen manual: + + + Use the Javadoc style... + ...not the Qt style. The intermediate *'s are preferred. + Use the triple-slash style only for one-line comments (the "brief" mode). + Very recent versions of Doxygen permit full-mode comments in triple-slash + blocks, but the formatting still comes out wonky. + This is disgusting. Don't do this. + + +Use the @-style of commands, not the !-style. Please be careful about + whitespace in your markup comments. Most of the time it doesn't matter; + doxygen absorbs most whitespace, and both HTML and *roff are agnostic about + whitespace. However, in <pre> blocks and @code/@endcode sections, + spacing can have "interesting" effects. + + +Use either kind of grouping, as appropriate. doxygroups.cc + exists for this purpose. See stl_iterator.h for a good + example of the "other" kind of grouping. + + +Please use markup tags like @p and @a when referring to things such as the + names of function parameters. Use @e for emphasis when necessary. Use @c + to refer to other standard names. (Examples of all these abound in the + present code.) + + + + + + + + Docbook + + + +Which files are important: + +Main page +spine.xml - index to documentation set + +manual/spine.xml - index to manual +manual/*.xml - chapters and sections of the manual + +faq.xml - index to FAQ +api.xml - index to source level / API + +All *.txml files are template xml files, ie otherwise empty files with +the correct structure, suitable for filling in. + + +Cannonical Writing Style + +class template +function template +member function template +(via C++ Templates, Vandevoorde) + +class in namespace std: allocator, not std::allocator + +header file: iostream, not <iostream> + + +Translation + +HTML to XML rough equivalents + +<p> <para> + +<pre> <computeroutput> +<pre> <programlisting> +<pre> <literallayout> + +<ul> <itemizedlist> +<ol> <orderedlist> +<il> <listitem> + +<dl> <variablelist> + + <varlistentry> +<dt> <term> +</dt> </term> +<dd> <listitem> +</dt> </listitem> + </varlistentry> + +<a href <ulink url +<code> <literal> +<code> <programlisting> + +<strong> <emphasis> +<em> <emphasis> +" <quote> + +ctype.h <filename class="headerfile"></filename> + + +build_dir <filename class="directory">path_to_build_dir</filename> + +Finer gradations of <code> + +<classname> <classname>string</classname> + <classname>vector<></classname> + <function>fs.clear()</function> + +<structname> + +<function> <function>clear()</function> + +<type> <type>long long</type> + +<varname> <varname>fs</varname> + +<literal> <literal>-Weffc++</literal> + <literal>rel_ops</literal> + +<constant> <constant>_GNU_SOURCE</constant> + <constant>3.0</constant> + +<filename> + +<command> <command>g++</command> + +<errortext> <errortext>foo Concept </errortext> + + +General structure + +<set> + <book> + </book> + + <book> + <chapter> + </chapter> + </book> + + + <book> + <part> + <chapter> + <section> + </section> + + <sect1> + </sect1> + + <sect1> + <sect2> + </sect2> + </sect1> + </chapter> + + <chapter> + </chapter> + </part> + </book> + + +</set> + + + + + + + + Design Notes + + + + + +The Library +----------- + +This paper is covers two major areas: + + - Features and policies not mentioned in the standard that + the quality of the library implementation depends on, including + extensions and "implementation-defined" features; + + - Plans for required but unimplemented library features and + optimizations to them. + +Overhead +-------- + +The standard defines a large library, much larger than the standard +C library. A naive implementation would suffer substantial overhead +in compile time, executable size, and speed, rendering it unusable +in many (particularly embedded) applications. The alternative demands +care in construction, and some compiler support, but there is no +need for library subsets. + +What are the sources of this overhead? There are four main causes: + + - The library is specified almost entirely as templates, which + with current compilers must be included in-line, resulting in + very slow builds as tens or hundreds of thousands of lines + of function definitions are read for each user source file. + Indeed, the entire SGI STL, as well as the dos Reis valarray, + are provided purely as header files, largely for simplicity in + porting. Iostream/locale is (or will be) as large again. + + - The library is very flexible, specifying a multitude of hooks + where users can insert their own code in place of defaults. + When these hooks are not used, any time and code expended to + support that flexibility is wasted. + + - Templates are often described as causing to "code bloat". In + practice, this refers (when it refers to anything real) to several + independent processes. First, when a class template is manually + instantiated in its entirely, current compilers place the definitions + for all members in a single object file, so that a program linking + to one member gets definitions of all. Second, template functions + which do not actually depend on the template argument are, under + current compilers, generated anew for each instantiation, rather + than being shared with other instantiations. Third, some of the + flexibility mentioned above comes from virtual functions (both in + regular classes and template classes) which current linkers add + to the executable file even when they manifestly cannot be called. + + - The library is specified to use a language feature, exceptions, + which in the current gcc compiler ABI imposes a run time and + code space cost to handle the possibility of exceptions even when + they are not used. Under the new ABI (accessed with -fnew-abi), + there is a space overhead and a small reduction in code efficiency + resulting from lost optimization opportunities associated with + non-local branches associated with exceptions. + +What can be done to eliminate this overhead? A variety of coding +techniques, and compiler, linker and library improvements and +extensions may be used, as covered below. Most are not difficult, +and some are already implemented in varying degrees. + +Overhead: Compilation Time +-------------------------- + +Providing "ready-instantiated" template code in object code archives +allows us to avoid generating and optimizing template instantiations +in each compilation unit which uses them. However, the number of such +instantiations that are useful to provide is limited, and anyway this +is not enough, by itself, to minimize compilation time. In particular, +it does not reduce time spent parsing conforming headers. + +Quicker header parsing will depend on library extensions and compiler +improvements. One approach is some variation on the techniques +previously marketed as "pre-compiled headers", now standardized as +support for the "export" keyword. "Exported" template definitions +can be placed (once) in a "repository" -- really just a library, but +of template definitions rather than object code -- to be drawn upon +at link time when an instantiation is needed, rather than placed in +header files to be parsed along with every compilation unit. + +Until "export" is implemented we can put some of the lengthy template +definitions in #if guards or alternative headers so that users can skip +over the the full definitions when they need only the ready-instantiated +specializations. + +To be precise, this means that certain headers which define +templates which users normally use only for certain arguments +can be instrumented to avoid exposing the template definitions +to the compiler unless a macro is defined. For example, in +<string>, we might have: + + template <class _CharT, ... > class basic_string { + ... // member declarations + }; + ... // operator declarations + + #ifdef _STRICT_ISO_ + # if _G_NO_TEMPLATE_EXPORT + # include <bits/std_locale.h> // headers needed by definitions + # ... + # include <bits/string.tcc> // member and global template definitions. + # endif + #endif + +Users who compile without specifying a strict-ISO-conforming flag +would not see many of the template definitions they now see, and rely +instead on ready-instantiated specializations in the library. This +technique would be useful for the following substantial components: +string, locale/iostreams, valarray. It would *not* be useful or +usable with the following: containers, algorithms, iterators, +allocator. Since these constitute a large (though decreasing) +fraction of the library, the benefit the technique offers is +limited. + +The language specifies the semantics of the "export" keyword, but +the gcc compiler does not yet support it. When it does, problems +with large template inclusions can largely disappear, given some +minor library reorganization, along with the need for the apparatus +described above. + +Overhead: Flexibility Cost +-------------------------- + +The library offers many places where users can specify operations +to be performed by the library in place of defaults. Sometimes +this seems to require that the library use a more-roundabout, and +possibly slower, way to accomplish the default requirements than +would be used otherwise. + +The primary protection against this overhead is thorough compiler +optimization, to crush out layers of inline function interfaces. +Kuck & Associates has demonstrated the practicality of this kind +of optimization. + +The second line of defense against this overhead is explicit +specialization. By defining helper function templates, and writing +specialized code for the default case, overhead can be eliminated +for that case without sacrificing flexibility. This takes full +advantage of any ability of the optimizer to crush out degenerate +code. + +The library specifies many virtual functions which current linkers +load even when they cannot be called. Some minor improvements to the +compiler and to ld would eliminate any such overhead by simply +omitting virtual functions that the complete program does not call. +A prototype of this work has already been done. For targets where +GNU ld is not used, a "pre-linker" could do the same job. + +The main areas in the standard interface where user flexibility +can result in overhead are: + + - Allocators: Containers are specified to use user-definable + allocator types and objects, making tuning for the container + characteristics tricky. + + - Locales: the standard specifies locale objects used to implement + iostream operations, involving many virtual functions which use + streambuf iterators. + + - Algorithms and containers: these may be instantiated on any type, + frequently duplicating code for identical operations. + + - Iostreams and strings: users are permitted to use these on their + own types, and specify the operations the stream must use on these + types. + +Note that these sources of overhead are _avoidable_. The techniques +to avoid them are covered below. + +Code Bloat +---------- + +In the SGI STL, and in some other headers, many of the templates +are defined "inline" -- either explicitly or by their placement +in class definitions -- which should not be inline. This is a +source of code bloat. Matt had remarked that he was relying on +the compiler to recognize what was too big to benefit from inlining, +and generate it out-of-line automatically. However, this also can +result in code bloat except where the linker can eliminate the extra +copies. + +Fixing these cases will require an audit of all inline functions +defined in the library to determine which merit inlining, and moving +the rest out of line. This is an issue mainly in chapters 23, 25, and +27. Of course it can be done incrementally, and we should generally +accept patches that move large functions out of line and into ".tcc" +files, which can later be pulled into a repository. Compiler/linker +improvements to recognize very large inline functions and move them +out-of-line, but shared among compilation units, could make this +work unnecessary. + +Pre-instantiating template specializations currently produces large +amounts of dead code which bloats statically linked programs. The +current state of the static library, libstdc++.a, is intolerable on +this account, and will fuel further confused speculation about a need +for a library "subset". A compiler improvement that treats each +instantiated function as a separate object file, for linking purposes, +would be one solution to this problem. An alternative would be to +split up the manual instantiation files into dozens upon dozens of +little files, each compiled separately, but an abortive attempt at +this was done for <string> and, though it is far from complete, it +is already a nuisance. A better interim solution (just until we have +"export") is badly needed. + +When building a shared library, the current compiler/linker cannot +automatically generate the instantiatiations needed. This creates a +miserable situation; it means any time something is changed in the +library, before a shared library can be built someone must manually +copy the declarations of all templates that are needed by other parts +of the library to an "instantiation" file, and add it to the build +system to be compiled and linked to the library. This process is +readily automated, and should be automated as soon as possible. +Users building their own shared libraries experience identical +frustrations. + +Sharing common aspects of template definitions among instantiations +can radically reduce code bloat. The compiler could help a great +deal here by recognizing when a function depends on nothing about +a template parameter, or only on its size, and giving the resulting +function a link-name "equate" that allows it to be shared with other +instantiations. Implementation code could take advantage of the +capability by factoring out code that does not depend on the template +argument into separate functions to be merged by the compiler. + +Until such a compiler optimization is implemented, much can be done +manually (if tediously) in this direction. One such optimization is +to derive class templates from non-template classes, and move as much +implementation as possible into the base class. Another is to partial- +specialize certain common instantiations, such as vector<T*>, to share +code for instantiations on all types T. While these techniques work, +they are far from the complete solution that a compiler improvement +would afford. + +Overhead: Expensive Language Features +------------------------------------- + +The main "expensive" language feature used in the standard library +is exception support, which requires compiling in cleanup code with +static table data to locate it, and linking in library code to use +the table. For small embedded programs the amount of such library +code and table data is assumed by some to be excessive. Under the +"new" ABI this perception is generally exaggerated, although in some +cases it may actually be excessive. + +To implement a library which does not use exceptions directly is +not difficult given minor compiler support (to "turn off" exceptions +and ignore exception constructs), and results in no great library +maintenance difficulties. To be precise, given "-fno-exceptions", +the compiler should treat "try" blocks as ordinary blocks, and +"catch" blocks as dead code to ignore or eliminate. Compiler +support is not strictly necessary, except in the case of "function +try blocks"; otherwise the following macros almost suffice: + + #define throw(X) + #define try if (true) + #define catch(X) else if (false) + +However, there may be a need to use function try blocks in the +library implementation, and use of macros in this way can make +correct diagnostics impossible. Furthermore, use of this scheme +would require the library to call a function to re-throw exceptions +from a try block. Implementing the above semantics in the compiler +is preferable. + +Given the support above (however implemented) it only remains to +replace code that "throws" with a call to a well-documented "handler" +function in a separate compilation unit which may be replaced by +the user. The main source of exceptions that would be difficult +for users to avoid is memory allocation failures, but users can +define their own memory allocation primitives that never throw. +Otherwise, the complete list of such handlers, and which library +functions may call them, would be needed for users to be able to +implement the necessary substitutes. (Fortunately, they have the +source code.) + +Opportunities +------------- + +The template capabilities of C++ offer enormous opportunities for +optimizing common library operations, well beyond what would be +considered "eliminating overhead". In particular, many operations +done in Glibc with macros that depend on proprietary language +extensions can be implemented in pristine Standard C++. For example, +the chapter 25 algorithms, and even C library functions such as strchr, +can be specialized for the case of static arrays of known (small) size. + +Detailed optimization opportunities are identified below where +the component where they would appear is discussed. Of course new +opportunities will be identified during implementation. + +Unimplemented Required Library Features +--------------------------------------- + +The standard specifies hundreds of components, grouped broadly by +chapter. These are listed in excruciating detail in the CHECKLIST +file. + + 17 general + 18 support + 19 diagnostics + 20 utilities + 21 string + 22 locale + 23 containers + 24 iterators + 25 algorithms + 26 numerics + 27 iostreams + Annex D backward compatibility + +Anyone participating in implementation of the library should obtain +a copy of the standard, ISO 14882. People in the U.S. can obtain an +electronic copy for US$18 from ANSI's web site. Those from other +countries should visit http://www.iso.ch/ to find out the location +of their country's representation in ISO, in order to know who can +sell them a copy. + +The emphasis in the following sections is on unimplemented features +and optimization opportunities. + +Chapter 17 General +------------------- + +Chapter 17 concerns overall library requirements. + +The standard doesn't mention threads. A multi-thread (MT) extension +primarily affects operators new and delete (18), allocator (20), +string (21), locale (22), and iostreams (27). The common underlying +support needed for this is discussed under chapter 20. + +The standard requirements on names from the C headers create a +lot of work, mostly done. Names in the C headers must be visible +in the std:: and sometimes the global namespace; the names in the +two scopes must refer to the same object. More stringent is that +Koenig lookup implies that any types specified as defined in std:: +really are defined in std::. Names optionally implemented as +macros in C cannot be macros in C++. (An overview may be read at +<http://www.cantrip.org/cheaders.html>). The scripts "inclosure" +and "mkcshadow", and the directories shadow/ and cshadow/, are the +beginning of an effort to conform in this area. + +A correct conforming definition of C header names based on underlying +C library headers, and practical linking of conforming namespaced +customer code with third-party C libraries depends ultimately on +an ABI change, allowing namespaced C type names to be mangled into +type names as if they were global, somewhat as C function names in a +namespace, or C++ global variable names, are left unmangled. Perhaps +another "extern" mode, such as 'extern "C-global"' would be an +appropriate place for such type definitions. Such a type would +affect mangling as follows: + + namespace A { + struct X {}; + extern "C-global" { // or maybe just 'extern "C"' + struct Y {}; + }; + } + void f(A::X*); // mangles to f__FPQ21A1X + void f(A::Y*); // mangles to f__FP1Y + +(It may be that this is really the appropriate semantics for regular +'extern "C"', and 'extern "C-global"', as an extension, would not be +necessary.) This would allow functions declared in non-standard C headers +(and thus fixable by neither us nor users) to link properly with functions +declared using C types defined in properly-namespaced headers. The +problem this solves is that C headers (which C++ programmers do persist +in using) frequently forward-declare C struct tags without including +the header where the type is defined, as in + + struct tm; + void munge(tm*); + +Without some compiler accommodation, munge cannot be called by correct +C++ code using a pointer to a correctly-scoped tm* value. + +The current C headers use the preprocessor extension "#include_next", +which the compiler complains about when run "-pedantic". +(Incidentally, it appears that "-fpedantic" is currently ignored, +probably a bug.) The solution in the C compiler is to use +"-isystem" rather than "-I", but unfortunately in g++ this seems +also to wrap the whole header in an 'extern "C"' block, so it's +unusable for C++ headers. The correct solution appears to be to +allow the various special include-directory options, if not given +an argument, to affect subsequent include-directory options additively, +so that if one said + + -pedantic -iprefix $(prefix) \ + -idirafter -ino-pedantic -ino-extern-c -iwithprefix -I g++-v3 \ + -iwithprefix -I g++-v3/ext + +the compiler would search $(prefix)/g++-v3 and not report +pedantic warnings for files found there, but treat files in +$(prefix)/g++-v3/ext pedantically. (The undocumented semantics +of "-isystem" in g++ stink. Can they be rescinded? If not it +must be replaced with something more rationally behaved.) + +All the C headers need the treatment above; in the standard these +headers are mentioned in various chapters. Below, I have only +mentioned those that present interesting implementation issues. + +The components identified as "mostly complete", below, have not been +audited for conformance. In many cases where the library passes +conformance tests we have non-conforming extensions that must be +wrapped in #if guards for "pedantic" use, and in some cases renamed +in a conforming way for continued use in the implementation regardless +of conformance flags. + +The STL portion of the library still depends on a header +stl/bits/stl_config.h full of #ifdef clauses. This apparatus +should be replaced with autoconf/automake machinery. + +The SGI STL defines a type_traits<> template, specialized for +many types in their code including the built-in numeric and +pointer types and some library types, to direct optimizations of +standard functions. The SGI compiler has been extended to generate +specializations of this template automatically for user types, +so that use of STL templates on user types can take advantage of +these optimizations. Specializations for other, non-STL, types +would make more optimizations possible, but extending the gcc +compiler in the same way would be much better. Probably the next +round of standardization will ratify this, but probably with +changes, so it probably should be renamed to place it in the +implementation namespace. + +The SGI STL also defines a large number of extensions visible in +standard headers. (Other extensions that appear in separate headers +have been sequestered in subdirectories ext/ and backward/.) All +these extensions should be moved to other headers where possible, +and in any case wrapped in a namespace (not std!), and (where kept +in a standard header) girded about with macro guards. Some cannot be +moved out of standard headers because they are used to implement +standard features. The canonical method for accommodating these +is to use a protected name, aliased in macro guards to a user-space +name. Unfortunately C++ offers no satisfactory template typedef +mechanism, so very ad-hoc and unsatisfactory aliasing must be used +instead. + +Implementation of a template typedef mechanism should have the highest +priority among possible extensions, on the same level as implementation +of the template "export" feature. + +Chapter 18 Language support +---------------------------- + +Headers: <limits> <new> <typeinfo> <exception> +C headers: <cstddef> <climits> <cfloat> <cstdarg> <csetjmp> + <ctime> <csignal> <cstdlib> (also 21, 25, 26) + +This defines the built-in exceptions, rtti, numeric_limits<>, +operator new and delete. Much of this is provided by the +compiler in its static runtime library. + +Work to do includes defining numeric_limits<> specializations in +separate files for all target architectures. Values for integer types +except for bool and wchar_t are readily obtained from the C header +<limits.h>, but values for the remaining numeric types (bool, wchar_t, +float, double, long double) must be entered manually. This is +largely dog work except for those members whose values are not +easily deduced from available documentation. Also, this involves +some work in target configuration to identify the correct choice of +file to build against and to install. + +The definitions of the various operators new and delete must be +made thread-safe, which depends on a portable exclusion mechanism, +discussed under chapter 20. Of course there is always plenty of +room for improvements to the speed of operators new and delete. + +<cstdarg>, in Glibc, defines some macros that gcc does not allow to +be wrapped into an inline function. Probably this header will demand +attention whenever a new target is chosen. The functions atexit(), +exit(), and abort() in cstdlib have different semantics in C++, so +must be re-implemented for C++. + +Chapter 19 Diagnostics +----------------------- + +Headers: <stdexcept> +C headers: <cassert> <cerrno> + +This defines the standard exception objects, which are "mostly complete". +Cygnus has a version, and now SGI provides a slightly different one. +It makes little difference which we use. + +The C global name "errno", which C allows to be a variable or a macro, +is required in C++ to be a macro. For MT it must typically result in +a function call. + +Chapter 20 Utilities +--------------------- +Headers: <utility> <functional> <memory> +C header: <ctime> (also in 18) + +SGI STL provides "mostly complete" versions of all the components +defined in this chapter. However, the auto_ptr<> implementation +is known to be wrong. Furthermore, the standard definition of it +is known to be unimplementable as written. A minor change to the +standard would fix it, and auto_ptr<> should be adjusted to match. + +Multi-threading affects the allocator implementation, and there must +be configuration/installation choices for different users' MT +requirements. Anyway, users will want to tune allocator options +to support different target conditions, MT or no. + +The primitives used for MT implementation should be exposed, as an +extension, for users' own work. We need cross-CPU "mutex" support, +multi-processor shared-memory atomic integer operations, and single- +processor uninterruptible integer operations, and all three configurable +to be stubbed out for non-MT use, or to use an appropriately-loaded +dynamic library for the actual runtime environment, or statically +compiled in for cases where the target architecture is known. + +Chapter 21 String +------------------ +Headers: <string> +C headers: <cctype> <cwctype> <cstring> <cwchar> (also in 27) + <cstdlib> (also in 18, 25, 26) + +We have "mostly-complete" char_traits<> implementations. Many of the +char_traits<char> operations might be optimized further using existing +proprietary language extensions. + +We have a "mostly-complete" basic_string<> implementation. The work +to manually instantiate char and wchar_t specializations in object +files to improve link-time behavior is extremely unsatisfactory, +literally tripling library-build time with no commensurate improvement +in static program link sizes. It must be redone. (Similar work is +needed for some components in chapters 22 and 27.) + +Other work needed for strings is MT-safety, as discussed under the +chapter 20 heading. + +The standard C type mbstate_t from <cwchar> and used in char_traits<> +must be different in C++ than in C, because in C++ the default constructor +value mbstate_t() must be the "base" or "ground" sequence state. +(According to the likely resolution of a recently raised Core issue, +this may become unnecessary. However, there are other reasons to +use a state type not as limited as whatever the C library provides.) +If we might want to provide conversions from (e.g.) internally- +represented EUC-wide to externally-represented Unicode, or vice- +versa, the mbstate_t we choose will need to be more accommodating +than what might be provided by an underlying C library. + +There remain some basic_string template-member functions which do +not overload properly with their non-template brethren. The infamous +hack akin to what was done in vector<> is needed, to conform to +23.1.1 para 10. The CHECKLIST items for basic_string marked 'X', +or incomplete, are so marked for this reason. + +Replacing the string iterators, which currently are simple character +pointers, with class objects would greatly increase the safety of the +client interface, and also permit a "debug" mode in which range, +ownership, and validity are rigorously checked. The current use of +raw pointers as string iterators is evil. vector<> iterators need the +same treatment. Note that the current implementation freely mixes +pointers and iterators, and that must be fixed before safer iterators +can be introduced. + +Some of the functions in <cstring> are different from the C version. +generally overloaded on const and non-const argument pointers. For +example, in <cstring> strchr is overloaded. The functions isupper +etc. in <cctype> typically implemented as macros in C are functions +in C++, because they are overloaded with others of the same name +defined in <locale>. + +Many of the functions required in <cwctype> and <cwchar> cannot be +implemented using underlying C facilities on intended targets because +such facilities only partly exist. + +Chapter 22 Locale +------------------ +Headers: <locale> +C headers: <clocale> + +We have a "mostly complete" class locale, with the exception of +code for constructing, and handling the names of, named locales. +The ways that locales are named (particularly when categories +(e.g. LC_TIME, LC_COLLATE) are different) varies among all target +environments. This code must be written in various versions and +chosen by configuration parameters. + +Members of many of the facets defined in <locale> are stubs. Generally, +there are two sets of facets: the base class facets (which are supposed +to implement the "C" locale) and the "byname" facets, which are supposed +to read files to determine their behavior. The base ctype<>, collate<>, +and numpunct<> facets are "mostly complete", except that the table of +bitmask values used for "is" operations, and corresponding mask values, +are still defined in libio and just included/linked. (We will need to +implement these tables independently, soon, but should take advantage +of libio where possible.) The num_put<>::put members for integer types +are "mostly complete". + +A complete list of what has and has not been implemented may be +found in CHECKLIST. However, note that the current definition of +codecvt<wchar_t,char,mbstate_t> is wrong. It should simply write +out the raw bytes representing the wide characters, rather than +trying to convert each to a corresponding single "char" value. + +Some of the facets are more important than others. Specifically, +the members of ctype<>, numpunct<>, num_put<>, and num_get<> facets +are used by other library facilities defined in <string>, <istream>, +and <ostream>, and the codecvt<> facet is used by basic_filebuf<> +in <fstream>, so a conforming iostream implementation depends on +these. + +The "long long" type eventually must be supported, but code mentioning +it should be wrapped in #if guards to allow pedantic-mode compiling. + +Performance of num_put<> and num_get<> depend critically on +caching computed values in ios_base objects, and on extensions +to the interface with streambufs. + +Specifically: retrieving a copy of the locale object, extracting +the needed facets, and gathering data from them, for each call to +(e.g.) operator<< would be prohibitively slow. To cache format +data for use by num_put<> and num_get<> we have a _Format_cache<> +object stored in the ios_base::pword() array. This is constructed +and initialized lazily, and is organized purely for utility. It +is discarded when a new locale with different facets is imbued. + +Using only the public interfaces of the iterator arguments to the +facet functions would limit performance by forbidding "vector-style" +character operations. The streambuf iterator optimizations are +described under chapter 24, but facets can also bypass the streambuf +iterators via explicit specializations and operate directly on the +streambufs, and use extended interfaces to get direct access to the +streambuf internal buffer arrays. These extensions are mentioned +under chapter 27. These optimizations are particularly important +for input parsing. + +Unused virtual members of locale facets can be omitted, as mentioned +above, by a smart linker. + +Chapter 23 Containers +---------------------- +Headers: <deque> <list> <queue> <stack> <vector> <map> <set> <bitset> + +All the components in chapter 23 are implemented in the SGI STL. +They are "mostly complete"; they include a large number of +nonconforming extensions which must be wrapped. Some of these +are used internally and must be renamed or duplicated. + +The SGI components are optimized for large-memory environments. For +embedded targets, different criteria might be more appropriate. Users +will want to be able to tune this behavior. We should provide +ways for users to compile the library with different memory usage +characteristics. + +A lot more work is needed on factoring out common code from different +specializations to reduce code size here and in chapter 25. The +easiest fix for this would be a compiler/ABI improvement that allows +the compiler to recognize when a specialization depends only on the +size (or other gross quality) of a template argument, and allow the +linker to share the code with similar specializations. In its +absence, many of the algorithms and containers can be partial- +specialized, at least for the case of pointers, but this only solves +a small part of the problem. Use of a type_traits-style template +allows a few more optimization opportunities, more if the compiler +can generate the specializations automatically. + +As an optimization, containers can specialize on the default allocator +and bypass it, or take advantage of details of its implementation +after it has been improved upon. + +Replacing the vector iterators, which currently are simple element +pointers, with class objects would greatly increase the safety of the +client interface, and also permit a "debug" mode in which range, +ownership, and validity are rigorously checked. The current use of +pointers for iterators is evil. + +As mentioned for chapter 24, the deque iterator is a good example of +an opportunity to implement a "staged" iterator that would benefit +from specializations of some algorithms. + +Chapter 24 Iterators +--------------------- +Headers: <iterator> + +Standard iterators are "mostly complete", with the exception of +the stream iterators, which are not yet templatized on the +stream type. Also, the base class template iterator<> appears +to be wrong, so everything derived from it must also be wrong, +currently. + +The streambuf iterators (currently located in stl/bits/std_iterator.h, +but should be under bits/) can be rewritten to take advantage of +friendship with the streambuf implementation. + +Matt Austern has identified opportunities where certain iterator +types, particularly including streambuf iterators and deque +iterators, have a "two-stage" quality, such that an intermediate +limit can be checked much more quickly than the true limit on +range operations. If identified with a member of iterator_traits, +algorithms may be specialized for this case. Of course the +iterators that have this quality can be identified by specializing +a traits class. + +Many of the algorithms must be specialized for the streambuf +iterators, to take advantage of block-mode operations, in order +to allow iostream/locale operations' performance not to suffer. +It may be that they could be treated as staged iterators and +take advantage of those optimizations. + +Chapter 25 Algorithms +---------------------- +Headers: <algorithm> +C headers: <cstdlib> (also in 18, 21, 26)) + +The algorithms are "mostly complete". As mentioned above, they +are optimized for speed at the expense of code and data size. + +Specializations of many of the algorithms for non-STL types would +give performance improvements, but we must use great care not to +interfere with fragile template overloading semantics for the +standard interfaces. Conventionally the standard function template +interface is an inline which delegates to a non-standard function +which is then overloaded (this is already done in many places in +the library). Particularly appealing opportunities for the sake of +iostream performance are for copy and find applied to streambuf +iterators or (as noted elsewhere) for staged iterators, of which +the streambuf iterators are a good example. + +The bsearch and qsort functions cannot be overloaded properly as +required by the standard because gcc does not yet allow overloading +on the extern-"C"-ness of a function pointer. + +Chapter 26 Numerics +-------------------- +Headers: <complex> <valarray> <numeric> +C headers: <cmath>, <cstdlib> (also 18, 21, 25) + +Numeric components: Gabriel dos Reis's valarray, Drepper's complex, +and the few algorithms from the STL are "mostly done". Of course +optimization opportunities abound for the numerically literate. It +is not clear whether the valarray implementation really conforms +fully, in the assumptions it makes about aliasing (and lack thereof) +in its arguments. + +The C div() and ldiv() functions are interesting, because they are the +only case where a C library function returns a class object by value. +Since the C++ type div_t must be different from the underlying C type +(which is in the wrong namespace) the underlying functions div() and +ldiv() cannot be re-used efficiently. Fortunately they are trivial to +re-implement. + +Chapter 27 Iostreams +--------------------- +Headers: <iosfwd> <streambuf> <ios> <ostream> <istream> <iostream> + <iomanip> <sstream> <fstream> +C headers: <cstdio> <cwchar> (also in 21) + +Iostream is currently in a very incomplete state. <iosfwd>, <iomanip>, +ios_base, and basic_ios<> are "mostly complete". basic_streambuf<> and +basic_ostream<> are well along, but basic_istream<> has had little work +done. The standard stream objects, <sstream> and <fstream> have been +started; basic_filebuf<> "write" functions have been implemented just +enough to do "hello, world". + +Most of the istream and ostream operators << and >> (with the exception +of the op<<(integer) ones) have not been changed to use locale primitives, +sentry objects, or char_traits members. + +All these templates should be manually instantiated for char and +wchar_t in a way that links only used members into user programs. + +Streambuf is fertile ground for optimization extensions. An extended +interface giving iterator access to its internal buffer would be very +useful for other library components. + +Iostream operations (primarily operators << and >>) can take advantage +of the case where user code has not specified a locale, and bypass locale +operations entirely. The current implementation of op<</num_put<>::put, +for the integer types, demonstrates how they can cache encoding details +from the locale on each operation. There is lots more room for +optimization in this area. + +The definition of the relationship between the standard streams +cout et al. and stdout et al. requires something like a "stdiobuf". +The SGI solution of using double-indirection to actually use a +stdio FILE object for buffering is unsatisfactory, because it +interferes with peephole loop optimizations. + +The <sstream> header work has begun. stringbuf can benefit from +friendship with basic_string<> and basic_string<>::_Rep to use +those objects directly as buffers, and avoid allocating and making +copies. + +The basic_filebuf<> template is a complex beast. It is specified to +use the locale facet codecvt<> to translate characters between native +files and the locale character encoding. In general this involves +two buffers, one of "char" representing the file and another of +"char_type", for the stream, with codecvt<> translating. The process +is complicated by the variable-length nature of the translation, and +the need to seek to corresponding places in the two representations. +For the case of basic_filebuf<char>, when no translation is needed, +a single buffer suffices. A specialized filebuf can be used to reduce +code space overhead when no locale has been imbued. Matt Austern's +work at SGI will be useful, perhaps directly as a source of code, or +at least as an example to draw on. + +Filebuf, almost uniquely (cf. operator new), depends heavily on +underlying environmental facilities. In current releases iostream +depends fairly heavily on libio constant definitions, but it should +be made independent. It also depends on operating system primitives +for file operations. There is immense room for optimizations using +(e.g.) mmap for reading. The shadow/ directory wraps, besides the +standard C headers, the libio.h and unistd.h headers, for use mainly +by filebuf. These wrappings have not been completed, though there +is scaffolding in place. + +The encapulation of certain C header <cstdio> names presents an +interesting problem. It is possible to define an inline std::fprintf() +implemented in terms of the 'extern "C"' vfprintf(), but there is no +standard vfscanf() to use to implement std::fscanf(). It appears that +vfscanf but be re-implemented in C++ for targets where no vfscanf +extension has been defined. This is interesting in that it seems +to be the only significant case in the C library where this kind of +rewriting is necessary. (Of course Glibc provides the vfscanf() +extension.) (The functions related to exit() must be rewritten +for other reasons.) + + +Annex D +------- +Headers: <strstream> + +Annex D defines many non-library features, and many minor +modifications to various headers, and a complete header. +It is "mostly done", except that the libstdc++-2 <strstream> +header has not been adopted into the library, or checked to +verify that it matches the draft in those details that were +clarified by the committee. Certainly it must at least be +moved into the std namespace. + +We still need to wrap all the deprecated features in #if guards +so that pedantic compile modes can detect their use. + +Nonstandard Extensions +---------------------- +Headers: <iostream.h> <strstream.h> <hash> <rbtree> + <pthread_alloc> <stdiobuf> (etc.) + +User code has come to depend on a variety of nonstandard components +that we must not omit. Much of this code can be adopted from +libstdc++-v2 or from the SGI STL. This particularly includes +<iostream.h>, <strstream.h>, and various SGI extensions such +as <hash_map.h>. Many of these are already placed in the +subdirectories ext/ and backward/. (Note that it is better to +include them via "<backward/hash_map.h>" or "<ext/hash_map>" than +to search the subdirectory itself via a "-I" directive. + + + + diff --git a/libstdc++-v3/doc/xml/manual/appendix_free.xml b/libstdc++-v3/doc/xml/manual/appendix_free.xml new file mode 100644 index 00000000000..038d4558e6e --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/appendix_free.xml @@ -0,0 +1,176 @@ + + + + + + + + + + ISO C++ + + + library + + + + +Free Software Needs Free Documentation + + +The biggest deficiency in free operating systems is not in the +software--it is the lack of good free manuals that we can include in +these systems. Many of our most important programs do not come with +full manuals. Documentation is an essential part of any software +package; when an important free software package does not come with a +free manual, that is a major gap. We have many such gaps today. + + + +Once upon a time, many years ago, I thought I would learn Perl. I got +a copy of a free manual, but I found it hard to read. When I asked +Perl users about alternatives, they told me that there were better +introductory manuals--but those were not free. + + + +Why was this? The authors of the good manuals had written them for +O'Reilly Associates, which published them with restrictive terms--no +copying, no modification, source files not available--which exclude +them from the free software community. + + + +That wasn't the first time this sort of thing has happened, and (to +our community's great loss) it was far from the last. Proprietary +manual publishers have enticed a great many authors to restrict their +manuals since then. Many times I have heard a GNU user eagerly tell +me about a manual that he is writing, with which he expects to help +the GNU project--and then had my hopes dashed, as he proceeded to +explain that he had signed a contract with a publisher that would +restrict it so that we cannot use it. + + + +Given that writing good English is a rare skill among programmers, we +can ill afford to lose manuals this way. + + + + Free documentation, like free software, is a matter of freedom, +not price. The problem with these manuals was not that O'Reilly +Associates charged a price for printed copies--that in itself is fine. +(The Free Software Foundation sells printed copies of +free GNU manuals, too.) But GNU manuals are available in source code +form, while these manuals are available only on paper. GNU manuals +come with permission to copy and modify; the Perl manuals do not. +These restrictions are the problems. + + + +The criterion for a free manual is pretty much the same as for free +software: it is a matter of giving all users certain freedoms. +Redistribution (including commercial redistribution) must be +permitted, so that the manual can accompany every copy of the program, +on-line or on paper. Permission for modification is crucial too. + + + +As a general rule, I don't believe that it is essential for people to +have permission to modify all sorts of articles and books. The issues +for writings are not necessarily the same as those for software. For +example, I don't think you or I are obliged to give permission to +modify articles like this one, which describe our actions and our +views. + + + +But there is a particular reason why the freedom to modify is crucial +for documentation for free software. When people exercise their right +to modify the software, and add or change its features, if they are +conscientious they will change the manual too--so they can provide +accurate and usable documentation with the modified program. A manual +which forbids programmers to be conscientious and finish the job, or +more precisely requires them to write a new manual from scratch if +they change the program, does not fill our community's needs. + + + +While a blanket prohibition on modification is unacceptable, some +kinds of limits on the method of modification pose no problem. For +example, requirements to preserve the original author's copyright +notice, the distribution terms, or the list of authors, are ok. It is +also no problem to require modified versions to include notice that +they were modified, even to have entire sections that may not be +deleted or changed, as long as these sections deal with nontechnical +topics. (Some GNU manuals have them.) + + + +These kinds of restrictions are not a problem because, as a practical +matter, they don't stop the conscientious programmer from adapting the +manual to fit the modified program. In other words, they don't block +the free software community from making full use of the manual. + + + +However, it must be possible to modify all the technical +content of the manual, and then distribute the result in all the usual +media, through all the usual channels; otherwise, the restrictions do +block the community, the manual is not free, and so we need another +manual. + + + +Unfortunately, it is often hard to find someone to write another +manual when a proprietary manual exists. The obstacle is that many +users think that a proprietary manual is good enough--so they don't +see the need to write a free manual. They do not see that the free +operating system has a gap that needs filling. + + + +Why do users think that proprietary manuals are good enough? Some +have not considered the issue. I hope this article will do something +to change that. + + + +Other users consider proprietary manuals acceptable for the same +reason so many people consider proprietary software acceptable: they +judge in purely practical terms, not using freedom as a criterion. +These people are entitled to their opinions, but since those opinions +spring from values which do not include freedom, they are no guide for +those of us who do value freedom. + + + +Please spread the word about this issue. We continue to lose manuals +to proprietary publishing. If we spread the word that proprietary +manuals are not sufficient, perhaps the next person who wants to help +GNU by writing documentation will realize, before it is too late, that +he must above all make it free. + + + +We can also encourage commercial publishers to sell free, copylefted +manuals instead of proprietary ones. One way you can help this is to +check the distribution terms of a manual before you buy it, and +prefer copylefted manuals to non-copylefted ones. + + +[Note: We now maintain a web page +that lists free books available from other publishers]. + + +Copyright © 2004, 2005, 2006, 2007 Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA + +Verbatim copying and distribution of this entire article are +permitted worldwide, without royalty, in any medium, provided this +notice is preserved. + +Report any problems or suggestions to webmaster@fsf.org. + + diff --git a/libstdc++-v3/doc/xml/manual/appendix_porting.xml b/libstdc++-v3/doc/xml/manual/appendix_porting.xml new file mode 100644 index 00000000000..faa24125013 --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/appendix_porting.xml @@ -0,0 +1,47 @@ + + + + + + + + + + ISO C++ + + + library + + + + +Porting and Maintenance + + + + + + + + + + + + + + + + + + + + + + diff --git a/libstdc++-v3/doc/xml/manual/auto_ptr.xml b/libstdc++-v3/doc/xml/manual/auto_ptr.xml new file mode 100644 index 00000000000..a7a0e97bc6c --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/auto_ptr.xml @@ -0,0 +1,133 @@ + + + + + + + ISO C++ + + + auto_ptr + + + + +auto_ptr + + +Limitations + + Explaining all of the fun and delicious things that can + happen with misuse of the auto_ptr class + template (called AP here) would take some + time. Suffice it to say that the use of AP + safely in the presence of copying has some subtleties. + + + The AP class is a really + nifty idea for a smart pointer, but it is one of the dumbest of + all the smart pointers -- and that's fine. + + + AP is not meant to be a supersmart solution to all resource + leaks everywhere. Neither is it meant to be an effective form + of garbage collection (although it can help, a little bit). + And it can notbe used for arrays! + + + AP is meant to prevent nasty leaks in the + presence of exceptions. That's all. This + code is AP-friendly: + + + // Not a recommend naming scheme, but good for web-based FAQs. + typedef std::auto_ptr<MyClass> APMC; + + extern function_taking_MyClass_pointer (MyClass*); + extern some_throwable_function (); + + void func (int data) + { + APMC ap (new MyClass(data)); + + some_throwable_function(); // this will throw an exception + + function_taking_MyClass_pointer (ap.get()); + } + + When an exception gets thrown, the instance of MyClass that's + been created on the heap will be delete'd as the stack is + unwound past func(). + + Changing that code as follows is not AP-friendly: + + + APMC ap (new MyClass[22]); + + You will get the same problems as you would without the use + of AP: + + + char* array = new char[10]; // array new... + ... + delete array; // ...but single-object delete + + + AP cannot tell whether the pointer you've passed at creation points + to one or many things. If it points to many things, you are about + to die. AP is trivial to write, however, so you could write your + own auto_array_ptr for that situation (in fact, this has + been done many times; check the mailing lists, Usenet, Boost, etc). + + + + +Use in Containers + + + + All of the containers + described in the standard library require their contained types + to have, among other things, a copy constructor like this: + + + struct My_Type + { + My_Type (My_Type const&); + }; + + + Note the const keyword; the object being copied shouldn't change. + The template class auto_ptr (called AP here) does not + meet this requirement. Creating a new AP by copying an existing + one transfers ownership of the pointed-to object, which means that + the AP being copied must change, which in turn means that the + copy ctors of AP do not take const objects. + + + The resulting rule is simple: Never ever use a + container of auto_ptr objects. The standard says that + undefined behavior is the result, but it is + guaranteed to be messy. + + + To prevent you from doing this to yourself, the + concept checks built + in to this implementation will issue an error if you try to + compile code like this: + + + #include <vector> + #include <memory> + + void f() + { + std::vector< std::auto_ptr<int> > vec_ap_int; + } + + +Should you try this with the checks enabled, you will see an error. + + + + \ No newline at end of file diff --git a/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml b/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml new file mode 100644 index 00000000000..49a0ca813b6 --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml @@ -0,0 +1,1315 @@ + + + + + + + ISO C++ + + + backwards + + + + +Backwards Compatibility + + +First + +The first generation GNU C++ library was called libg++. It was a +separate GNU project, although reliably paired with GCC. Rumors imply +that it had a working relationship with at least two kinds of +dinosaur. + + +Some background: libg++ was designed and created when there was no +ISO standard to provide guidance. Classes like linked lists are now +provided for by list<T> and do not need to be +created by genclass. (For that matter, templates exist +now and are well-supported, whereas genclass (mostly) predates them.) + + +There are other classes in libg++ that are not specified in the +ISO Standard (e.g., statistical analysis). While there are a lot of +really useful things that are used by a lot of people, the Standards +Committee couldn't include everything, and so a lot of those +obvious classes didn't get included. + + +Known Issues include many of the limitations of its immediate ancestor. + +Portability notes and known implementation limitations are as follows. + + + No <code>ios_base</code> + + At least some older implementations don't have std::ios_base, so you should use std::ios::badbit, std::ios::failbit and std::ios::eofbit and std::ios::goodbit. + + + + +No <code>cout</code> in <code>ostream.h</code>, no <code>cin</code> in <code>istream.h</code> + + + In earlier versions of the standard, + fstream.h, + ostream.h + and istream.h + used to define + cout, cin and so on. ISO C++ specifies that one needs to include + iostream + explicitly to get the required definitions. + + Some include adjustment may be required. + +This project is no longer maintained or supported, and the sources +archived. For the desperate, +the GCC extensions +page describes where to find the last libg++ source. The code is +considered replaced and rewritten. + + + + + +Second + + + The second generation GNU C++ library was called libstdc++, or + libstdc++-v2. It spans the time between libg++ and pre-ISO C++ + standardization and is usually associated with the following GCC + releases: egcs 1.x, gcc 2.95, and gcc 2.96. + + + + The STL portions of this library are based on SGI/HP STL release 3.11. + + + + This project is no longer maintained or supported, and the sources + archived. The code is considered replaced and rewritten. + + + + Portability notes and known implementation limitations are as follows. + + + + Namespace <code>std::</code> not supported + + + Some care is required to support C++ compiler and or library + implementation that do not have the standard library in + namespace std. + + + + The following sections list some possible solutions to support compilers + that cannot ignore std::-qualified names. + + + + First, see if the compiler has a flag for this. Namespace + back-portability-issues are generally not a problem for g++ + compilers that do not have libstdc++ in std::, as the + compilers use -fno-honor-std (ignore + std::, :: = std::) by default. That is, + the responsibility for enabling or disabling std:: is + on the user; the maintainer does not have to care about it. This + probably applies to some other compilers as well. + + + + Second, experiment with a variety of pre-processor tricks. + + + + By defining std as a macro, fully-qualified namespace + calls become global. Volia. + + + +#ifdef WICKEDLY_OLD_COMPILER +# define std +#endif + + + + Thanks to Juergen Heinzl who posted this solution on gnu.gcc.help. + + + + Another pre-processor based approach is to define a macro + NAMESPACE_STD, which is defined to either + or std based on a compile-type + test. On GNU systems, this can be done with autotools by means of + an autoconf test (see below) for HAVE_NAMESPACE_STD, + then using that to set a value for the NAMESPACE_STD + macro. At that point, one is able to use + NAMESPACE_STD::string, which will evaluate to + std::string or ::string (ie, in the + global namespace on systems that do not put string in + std::). + + + +dnl @synopsis AC_CXX_NAMESPACE_STD +dnl +dnl If the compiler supports namespace std, define +dnl HAVE_NAMESPACE_STD. +dnl +dnl @category Cxx +dnl @author Todd Veldhuizen +dnl @author Luc Maisonobe <luc@spaceroots.org> +dnl @version 2004-02-04 +dnl @license AllPermissive +AC_DEFUN([AC_CXX_NAMESPACE_STD], [ + AC_CACHE_CHECK(if g++ supports namespace std, + ac_cv_cxx_have_std_namespace, + [AC_LANG_SAVE + AC_LANG_CPLUSPLUS + AC_TRY_COMPILE([#include <iostream> + std::istream& is = std::cin;],, + ac_cv_cxx_have_std_namespace=yes, ac_cv_cxx_have_std_namespace=no) + AC_LANG_RESTORE + ]) + if test "$ac_cv_cxx_have_std_namespace" = yes; then + AC_DEFINE(HAVE_NAMESPACE_STD,,[Define if g++ supports namespace std. ]) + fi +]) + + + + +Illegal iterator usage + + The following illustrate implementation-allowed illegal iterator + use, and then correct use. + + + + + + you cannot do ostream::operator<<(iterator) + to print the address of the iterator => use + operator<< &*iterator instead + + + + + you cannot clear an iterator's reference (iterator = + 0) => use iterator = iterator_type(); + + + + + if (iterator) won't work any more => use + if (iterator != iterator_type()) + + + + + + + <code>isspace</code> from <filename class="headerfile">cctype</filename> is a macro + + + + Glibc 2.0.x and 2.1.x define ctype.h functionality as macros + (isspace, isalpha etc.). + + + + This implementations of libstdc++, however, keep these functions + as macros, and so it is not back-portable to use fully qualified + names. For example: + + + +#include <cctype> +int main() { std::isspace('X'); } + + + + Results in something like this: + + + +std:: (__ctype_b[(int) ( ( 'X' ) )] & (unsigned short int) _ISspace ) ; + + + + A solution is to modify a header-file so that the compiler tells + ctype.h to define functions + instead of macros: + + + +// This keeps isalnum, et al from being propagated as macros. +#if __linux__ +# define __NO_CTYPE 1 +#endif + + + + Then, include ctype.h + + + + Another problem arises if you put a using namespace + std; declaration at the top, and include ctype.h. This will result in + ambiguities between the definitions in the global namespace + (ctype.h) and the + definitions in namespace std:: + (<cctype>). + + + + +No <code>vector::at</code>, <code>deque::at</code>, <code>string::at</code> + + + One solution is to add an autoconf-test for this: + + + +AC_MSG_CHECKING(for container::at) +AC_TRY_COMPILE( +[ +#include <vector> +#include <deque> +#include <string> + +using namespace std; +], +[ +deque<int> test_deque(3); +test_deque.at(2); +vector<int> test_vector(2); +test_vector.at(1); +string test_string(test_string); +test_string.at(3); +], +[AC_MSG_RESULT(yes) +AC_DEFINE(HAVE_CONTAINER_AT)], +[AC_MSG_RESULT(no)]) + + + + If you are using other (non-GNU) compilers it might be a good idea + to check for string::at separately. + + + + + +No <code>std::char_traits<char>::eof</code> + + + Use some kind of autoconf test, plus this: + + + +#ifdef HAVE_CHAR_TRAITS +#define CPP_EOF std::char_traits<char>::eof() +#else +#define CPP_EOF EOF +#endif + + + + + +No <code>string::clear</code> + + + There are two functions for deleting the contents of a string: + clear and erase (the latter returns the + string). + + + +void +clear() { _M_mutate(0, this->size(), 0); } + + + +basic_string& +erase(size_type __pos = 0, size_type __n = npos) +{ + return this->replace(_M_check(__pos), _M_fold(__pos, __n), + _M_data(), _M_data()); +} + + + + Unfortunately, ut clear is not implemented in this + version, so you should use erase (which is probably + faster than operator=(charT*)). + + + + + + Removal of <code>ostream::form</code> and <code>istream::scan</code> + extensions + + + + These are no longer supported. Please use stringstreams instead. + + + + +No <code>basic_stringbuf</code>, <code>basic_stringstream</code> + + + Although the ISO standard i/ostringstream-classes are + provided, (sstream), for + compatibility with older implementations the pre-ISO + i/ostrstream (strstream) interface is also provided, + with these caveats: + + + + + + strstream is considered to be deprecated + + + + + strstream is limited to char + + + + + with ostringstream you don't have to take care of + terminating the string or freeing its memory + + + + + istringstream can be re-filled (clear(); + str(input);) + + + + + + You can then use output-stringstreams like this: + + + +#ifdef HAVE_SSTREAM +# include <sstream> +#else +# include <strstream> +#endif + +#ifdef HAVE_SSTREAM + std::ostringstream oss; +#else + std::ostrstream oss; +#endif + +oss << Name= << m_name << , number= << m_number << std::endl; +... +#ifndef HAVE_SSTREAM + oss << std::ends; // terminate the char*-string +#endif + +// str() returns char* for ostrstream and a string for ostringstream +// this also causes ostrstream to think that the buffer's memory +// is yours +m_label.set_text(oss.str()); +#ifndef HAVE_SSTREAM + // let the ostrstream take care of freeing the memory + oss.freeze(false); +#endif + + + + Input-stringstreams can be used similarly: + + + +std::string input; +... +#ifdef HAVE_SSTREAM +std::istringstream iss(input); +#else +std::istrstream iss(input.c_str()); +#endif + +int i; +iss >> i; + + + One (the only?) restriction is that an istrstream cannot be re-filled: + + + +std::istringstream iss(numerator); +iss >> m_num; +// this is not possible with istrstream +iss.clear(); +iss.str(denominator); +iss >> m_den; + + + +If you don't care about speed, you can put these conversions in + a template-function: + + +template <class X> +void fromString(const string& input, X& any) +{ +#ifdef HAVE_SSTREAM +std::istringstream iss(input); +#else +std::istrstream iss(input.c_str()); +#endif +X temp; +iss >> temp; +if (iss.fail()) +throw runtime_error(..) +any = temp; +} + + + + Another example of using stringstreams is in this howto. + + + There is additional information in the libstdc++-v2 info files, in +particular info iostream. + + + + + Little or no wide character support + + Classes wstring and + char_traits<wchar_t> are + not supported. + + + + + No templatized iostreams + + Classes wfilebuf and + wstringstream are not supported. + + + + +Thread safety issues + + + Earlier GCC releases had a somewhat different approach to + threading configuration and proper compilation. Before GCC 3.0, + configuration of the threading model was dictated by compiler + command-line options and macros (both of which were somewhat + thread-implementation and port-specific). There were no + guarantees related to being able to link code compiled with one + set of options and macro setting with another set. + + + + For GCC 3.0, configuration of the threading model used with + libraries and user-code is performed when GCC is configured and + built using the --enable-threads and --disable-threads options. + The ABI is stable for symbol name-mangling and limited functional + compatibility exists between code compiled under different + threading models. + + + + The libstdc++ library has been designed so that it can be used in + multithreaded applications (with libstdc++-v2 this was only true + of the STL parts.) The first problem is finding a + fast method of implementation portable to + all platforms. Due to historical reasons, some of the library is + written against per-CPU-architecture spinlocks and other parts + against the gthr.h abstraction layer which is provided by gcc. A + minor problem that pops up every so often is different + interpretations of what "thread-safe" means for a + library (not a general program). We currently use the same + definition that SGI uses for their STL subset. However, + the exception for read-only containers only applies to the STL + components. This definition is widely-used and something similar + will be used in the next version of the C++ standard library. + + + + Here is a small link farm to threads (no pun) in the mail + archives that discuss the threading problem. Each link is to the + first relevant message in the thread; from there you can use + "Thread Next" to move down the thread. This farm is in + latest-to-oldest order. + + + + + + Our threading expert Loren gives a breakdown of the + six situations involving threads for the 3.0 + release series. + + + + + + This message inspired a recent updating of issues with + threading and the SGI STL library. It also contains some + example POSIX-multithreaded STL code. + + + + + + (A large selection of links to older messages has been removed; + many of the messages from 1999 were lost in a disk crash, and the + few people with access to the backup tapes have been too swamped + with work to restore them. Many of the points have been + superseded anyhow.) + + + + + + +Third + + The third generation GNU C++ library is called libstdc++, or +libstdc++-v3. + + + The subset commonly known as the Standard Template Library + (chapters 23 through 25, mostly) is adapted from the final release + of the SGI STL (version 3.3), with extensive changes. + + + A more formal description of the V3 goals can be found in the + official design document. + + +Portability notes and known implementation limitations are as follows. + + +Pre-ISO headers moved to backwards or removed + + The pre-ISO C++ headers + (iostream.h, defalloc.h etc.) are + available, unlike previous libstdc++ versions, but inclusion + generates a warning that you are using deprecated headers. + + + This compatibility layer is constructed by including the + standard C++ headers, and injecting any items in + std:: into the global namespace. + + For those of you new to ISO C++ (welcome, time travelers!), no, + that isn't a typo. Yes, the headers really have new names. + Marshall Cline's C++ FAQ Lite has a good explanation in item + [27.4]. + + + Some include adjustment may be required. What follows is an +autoconf test that defines PRE_STDCXX_HEADERS when they +exist. + + +# AC_HEADER_PRE_STDCXX +AC_DEFUN([AC_HEADER_PRE_STDCXX], [ + AC_CACHE_CHECK(for pre-ISO C++ include files, + ac_cv_cxx_pre_stdcxx, + [AC_LANG_SAVE + AC_LANG_CPLUSPLUS + ac_save_CXXFLAGS="$CXXFLAGS" + CXXFLAGS="$CXXFLAGS -Wno-deprecated" + + # Omit defalloc.h, as compilation with newer compilers is problematic. + AC_TRY_COMPILE([ + #include <new.h> + #include <iterator.h> + #include <alloc.h> + #include <set.h> + #include <hashtable.h> + #include <hash_set.h> + #include <fstream.h> + #include <tempbuf.h> + #include <istream.h> + #include <bvector.h> + #include <stack.h> + #include <rope.h> + #include <complex.h> + #include <ostream.h> + #include <heap.h> + #include <iostream.h> + #include <function.h> + #include <multimap.h> + #include <pair.h> + #include <stream.h> + #include <iomanip.h> + #include <slist.h> + #include <tree.h> + #include <vector.h> + #include <deque.h> + #include <multiset.h> + #include <list.h> + #include <map.h> + #include <algobase.h> + #include <hash_map.h> + #include <algo.h> + #include <queue.h> + #include <streambuf.h> + ],, + ac_cv_cxx_pre_stdcxx=yes, ac_cv_cxx_pre_stdcxx=no) + CXXFLAGS="$ac_save_CXXFLAGS" + AC_LANG_RESTORE + ]) + if test "$ac_cv_cxx_pre_stdcxx" = yes; then + AC_DEFINE(PRE_STDCXX_HEADERS,,[Define if pre-ISO C++ header files are present. ]) + fi +]) + + +Porting between pre-ISO headers and ISO headers is simple: headers +like vector.h can be replaced with vector and a using +directive using namespace std; can be put at the global +scope. This should be enough to get this code compiling, assuming the +other usage is correct. + + + + +Extension headers hash_map, hash_set moved to ext or backwards + + At this time most of the features of the SGI STL extension have been + replaced by standardized libraries. + In particular, the unordered_map and unordered_set containers of TR1 + are suitable replacement for the non-standard hash_map and hash_set + containers in the SGI STL. + + Header files hash_map and hash_set moved +to ext/hash_map and ext/hash_set, +respectively. At the same time, all types in these files are enclosed +in namespace __gnu_cxx. Later versions move deprecate +these files, and suggest using TR1's unordered_map +and unordered_set instead. + + + The extensions are no longer in the global or std + namespaces, instead they are declared in the __gnu_cxx + namespace. For maximum portability, consider defining a namespace + alias to use to talk about extensions, e.g.: + + + #ifdef __GNUC__ + #if __GNUC__ < 3 + #include <hash_map.h> + namespace extension { using ::hash_map; }; // inherit globals + #else + #include <backward/hash_map> + #if __GNUC__ == 3 && __GNUC_MINOR__ == 0 + namespace extension = std; // GCC 3.0 + #else + namespace extension = ::__gnu_cxx; // GCC 3.1 and later + #endif + #endif + #else // ... there are other compilers, right? + namespace extension = std; + #endif + + extension::hash_map<int,int> my_map; + + This is a bit cleaner than defining typedefs for all the + instantiations you might need. + + + +The following autoconf tests check for working HP/SGI hash containers. + + + +# AC_HEADER_EXT_HASH_MAP +AC_DEFUN([AC_HEADER_EXT_HASH_MAP], [ + AC_CACHE_CHECK(for ext/hash_map, + ac_cv_cxx_ext_hash_map, + [AC_LANG_SAVE + AC_LANG_CPLUSPLUS + ac_save_CXXFLAGS="$CXXFLAGS" + CXXFLAGS="$CXXFLAGS -Werror" + AC_TRY_COMPILE([#include <ext/hash_map>], [using __gnu_cxx::hash_map;], + ac_cv_cxx_ext_hash_map=yes, ac_cv_cxx_ext_hash_map=no) + CXXFLAGS="$ac_save_CXXFLAGS" + AC_LANG_RESTORE + ]) + if test "$ac_cv_cxx_ext_hash_map" = yes; then + AC_DEFINE(HAVE_EXT_HASH_MAP,,[Define if ext/hash_map is present. ]) + fi +]) + + + +# AC_HEADER_EXT_HASH_SET +AC_DEFUN([AC_HEADER_EXT_HASH_SET], [ + AC_CACHE_CHECK(for ext/hash_set, + ac_cv_cxx_ext_hash_set, + [AC_LANG_SAVE + AC_LANG_CPLUSPLUS + ac_save_CXXFLAGS="$CXXFLAGS" + CXXFLAGS="$CXXFLAGS -Werror" + AC_TRY_COMPILE([#include <ext/hash_set>], [using __gnu_cxx::hash_set;], + ac_cv_cxx_ext_hash_set=yes, ac_cv_cxx_ext_hash_set=no) + CXXFLAGS="$ac_save_CXXFLAGS" + AC_LANG_RESTORE + ]) + if test "$ac_cv_cxx_ext_hash_set" = yes; then + AC_DEFINE(HAVE_EXT_HASH_SET,,[Define if ext/hash_set is present. ]) + fi +]) + + + + +No <code>ios::nocreate/ios::noreplace</code>. + + + The existence of ios::nocreate being used for +input-streams has been confirmed, most probably because the author +thought it would be more correct to specify nocreate explicitly. So +it can be left out for input-streams. + + +For output streams, nocreate is probably the default, +unless you specify std::ios::trunc ? To be safe, you can +open the file for reading, check if it has been opened, and then +decide whether you want to create/replace or not. To my knowledge, +even older implementations support app, ate +and trunc (except for app ?). + + + + + +No <code>stream::attach(int fd)</code> + + + + Phil Edwards writes: It was considered and rejected for the ISO + standard. Not all environments use file descriptors. Of those + that do, not all of them use integers to represent them. + + + + For a portable solution (among systems which use + filedescriptors), you need to implement a subclass of + std::streambuf (or + std::basic_streambuf<..>) which opens a file + given a descriptor, and then pass an instance of this to the + stream-constructor. + + + + An extension is available that implements this. + ext/stdio_filebuf.h contains a derived class called + __gnu_cxx::stdio_filebuf. + This class can be constructed from a C FILE* or a file + descriptor, and provides the fd() function. + + + + For another example of this, refer to + fdstream example + by Nicolai Josuttis. + + + + + +Support for C++98 dialect. + + +Check for complete library coverage of the C++1998/2003 standard. + + + +# AC_HEADER_STDCXX_98 +AC_DEFUN([AC_HEADER_STDCXX_98], [ + AC_CACHE_CHECK(for ISO C++ 98 include files, + ac_cv_cxx_stdcxx_98, + [AC_LANG_SAVE + AC_LANG_CPLUSPLUS + AC_TRY_COMPILE([ + #include <cassert> + #include <cctype> + #include <cerrno> + #include <cfloat> + #include <ciso646> + #include <climits> + #include <clocale> + #include <cmath> + #include <csetjmp> + #include <csignal> + #include <cstdarg> + #include <cstddef> + #include <cstdio> + #include <cstdlib> + #include <cstring> + #include <ctime> + + #include <algorithm> + #include <bitset> + #include <complex> + #include <deque> + #include <exception> + #include <fstream> + #include <functional> + #include <iomanip> + #include <ios> + #include <iosfwd> + #include <iostream> + #include <istream> + #include <iterator> + #include <limits> + #include <list> + #include <locale> + #include <map> + #include <memory> + #include <new> + #include <numeric> + #include <ostream> + #include <queue> + #include <set> + #include <sstream> + #include <stack> + #include <stdexcept> + #include <streambuf> + #include <string> + #include <typeinfo> + #include <utility> + #include <valarray> + #include <vector> + ],, + ac_cv_cxx_stdcxx_98=yes, ac_cv_cxx_stdcxx_98=no) + AC_LANG_RESTORE + ]) + if test "$ac_cv_cxx_stdcxx_98" = yes; then + AC_DEFINE(STDCXX_98_HEADERS,,[Define if ISO C++ 1998 header files are present. ]) + fi +]) + + + + + +Support for C++TR1 dialect. + + +Check for library coverage of the TR1 standard. + + + +# AC_HEADER_STDCXX_TR1 +AC_DEFUN([AC_HEADER_STDCXX_TR1], [ + AC_CACHE_CHECK(for ISO C++ TR1 include files, + ac_cv_cxx_stdcxx_tr1, + [AC_LANG_SAVE + AC_LANG_CPLUSPLUS + AC_TRY_COMPILE([ + #include <tr1/array> + #include <tr1/ccomplex> + #include <tr1/cctype> + #include <tr1/cfenv> + #include <tr1/cfloat> + #include <tr1/cinttypes> + #include <tr1/climits> + #include <tr1/cmath> + #include <tr1/complex> + #include <tr1/cstdarg> + #include <tr1/cstdbool> + #include <tr1/cstdint> + #include <tr1/cstdio> + #include <tr1/cstdlib> + #include <tr1/ctgmath> + #include <tr1/ctime> + #include <tr1/cwchar> + #include <tr1/cwctype> + #include <tr1/functional> + #include <tr1/memory> + #include <tr1/random> + #include <tr1/regex> + #include <tr1/tuple> + #include <tr1/type_traits> + #include <tr1/unordered_set> + #include <tr1/unordered_map> + #include <tr1/utility> + ],, + ac_cv_cxx_stdcxx_tr1=yes, ac_cv_cxx_stdcxx_tr1=no) + AC_LANG_RESTORE + ]) + if test "$ac_cv_cxx_stdcxx_tr1" = yes; then + AC_DEFINE(STDCXX_TR1_HEADERS,,[Define if ISO C++ TR1 header files are present. ]) + fi +]) + + +An alternative is to check just for specific TR1 includes, such as <unordered_map> and <unordered_set>. + + + +# AC_HEADER_TR1_UNORDERED_MAP +AC_DEFUN([AC_HEADER_TR1_UNORDERED_MAP], [ + AC_CACHE_CHECK(for tr1/unordered_map, + ac_cv_cxx_tr1_unordered_map, + [AC_LANG_SAVE + AC_LANG_CPLUSPLUS + AC_TRY_COMPILE([#include <tr1/unordered_map>], [using std::tr1::unordered_map;], + ac_cv_cxx_tr1_unordered_map=yes, ac_cv_cxx_tr1_unordered_map=no) + AC_LANG_RESTORE + ]) + if test "$ac_cv_cxx_tr1_unordered_map" = yes; then + AC_DEFINE(HAVE_TR1_UNORDERED_MAP,,[Define if tr1/unordered_map is present. ]) + fi +]) + + + +# AC_HEADER_TR1_UNORDERED_SET +AC_DEFUN([AC_HEADER_TR1_UNORDERED_SET], [ + AC_CACHE_CHECK(for tr1/unordered_set, + ac_cv_cxx_tr1_unordered_set, + [AC_LANG_SAVE + AC_LANG_CPLUSPLUS + AC_TRY_COMPILE([#include <tr1/unordered_set>], [using std::tr1::unordered_set;], + ac_cv_cxx_tr1_unordered_set=yes, ac_cv_cxx_tr1_unordered_set=no) + AC_LANG_RESTORE + ]) + if test "$ac_cv_cxx_tr1_unordered_set" = yes; then + AC_DEFINE(HAVE_TR1_UNORDERED_SET,,[Define if tr1/unordered_set is present. ]) + fi +]) + + + + + + +Support for C++0x dialect. + + +Check for baseline language coverage in the compiler for the C++0xstandard. + + + +# AC_COMPILE_STDCXX_OX +AC_DEFUN([AC_COMPILE_STDCXX_0X], [ + AC_CACHE_CHECK(if g++ supports C++0x features without additional flags, + ac_cv_cxx_compile_cxx0x_native, + [AC_LANG_SAVE + AC_LANG_CPLUSPLUS + AC_TRY_COMPILE([ + template <typename T> + struct check + { + static_assert(sizeof(int) <= sizeof(T), "not big enough"); + }; + + typedef check<check<bool>> right_angle_brackets; + + int a; + decltype(a) b; + + typedef check<int> check_type; + check_type c; + check_type&& cr = c;],, + ac_cv_cxx_compile_cxx0x_native=yes, ac_cv_cxx_compile_cxx0x_native=no) + AC_LANG_RESTORE + ]) + + AC_CACHE_CHECK(if g++ supports C++0x features with -std=c++0x, + ac_cv_cxx_compile_cxx0x_cxx, + [AC_LANG_SAVE + AC_LANG_CPLUSPLUS + ac_save_CXXFLAGS="$CXXFLAGS" + CXXFLAGS="$CXXFLAGS -std=c++0x" + AC_TRY_COMPILE([ + template <typename T> + struct check + { + static_assert(sizeof(int) <= sizeof(T), "not big enough"); + }; + + typedef check<check<bool>> right_angle_brackets; + + int a; + decltype(a) b; + + typedef check<int> check_type; + check_type c; + check_type&& cr = c;],, + ac_cv_cxx_compile_cxx0x_cxx=yes, ac_cv_cxx_compile_cxx0x_cxx=no) + CXXFLAGS="$ac_save_CXXFLAGS" + AC_LANG_RESTORE + ]) + + AC_CACHE_CHECK(if g++ supports C++0x features with -std=gnu++0x, + ac_cv_cxx_compile_cxx0x_gxx, + [AC_LANG_SAVE + AC_LANG_CPLUSPLUS + ac_save_CXXFLAGS="$CXXFLAGS" + CXXFLAGS="$CXXFLAGS -std=gnu++0x" + AC_TRY_COMPILE([ + template <typename T> + struct check + { + static_assert(sizeof(int) <= sizeof(T), "not big enough"); + }; + + typedef check<check<bool>> right_angle_brackets; + + int a; + decltype(a) b; + + typedef check<int> check_type; + check_type c; + check_type&& cr = c;],, + ac_cv_cxx_compile_cxx0x_gxx=yes, ac_cv_cxx_compile_cxx0x_gxx=no) + CXXFLAGS="$ac_save_CXXFLAGS" + AC_LANG_RESTORE + ]) + + if test "$ac_cv_cxx_compile_cxx0x_native" = yes || + test "$ac_cv_cxx_compile_cxx0x_cxx" = yes || + test "$ac_cv_cxx_compile_cxx0x_gxx" = yes; then + AC_DEFINE(HAVE_STDCXX_0X,,[Define if g++ supports C++0x features. ]) + fi +]) + + + +Check for library coverage of the C++0xstandard. + + + +# AC_HEADER_STDCXX_0X +AC_DEFUN([AC_HEADER_STDCXX_0X], [ + AC_CACHE_CHECK(for ISO C++ 0x include files, + ac_cv_cxx_stdcxx_0x, + [AC_REQUIRE([AC_COMPILE_STDCXX_0X]) + AC_LANG_SAVE + AC_LANG_CPLUSPLUS + ac_save_CXXFLAGS="$CXXFLAGS" + CXXFLAGS="$CXXFLAGS -std=gnu++0x" + + AC_TRY_COMPILE([ + #include <cassert> + #include <ccomplex> + #include <cctype> + #include <cerrno> + #include <cfenv> + #include <cfloat> + #include <cinttypes> + #include <ciso646> + #include <climits> + #include <clocale> + #include <cmath> + #include <csetjmp> + #include <csignal> + #include <cstdarg> + #include <cstdbool> + #include <cstddef> + #include <cstdint> + #include <cstdio> + #include <cstdlib> + #include <cstring> + #include <ctgmath> + #include <ctime> + #include <cwchar> + #include <cwctype> + + #include <algorithm> + #include <array> + #include <bitset> + #include <complex> + #include <deque> + #include <exception> + #include <fstream> + #include <functional> + #include <iomanip> + #include <ios> + #include <iosfwd> + #include <iostream> + #include <istream> + #include <iterator> + #include <limits> + #include <list> + #include <locale> + #include <map> + #include <memory> + #include <new> + #include <numeric> + #include <ostream> + #include <queue> + #include <random> + #include <regex> + #include <set> + #include <sstream> + #include <stack> + #include <stdexcept> + #include <streambuf> + #include <string> + #include <tuple> + #include <typeinfo> + #include <type_traits> + #include <unordered_map> + #include <unordered_set> + #include <utility> + #include <valarray> + #include <vector> + ],, + ac_cv_cxx_stdcxx_0x=yes, ac_cv_cxx_stdcxx_0x=no) + AC_LANG_RESTORE + CXXFLAGS="$ac_save_CXXFLAGS" + ]) + if test "$ac_cv_cxx_stdcxx_0x" = yes; then + AC_DEFINE(STDCXX_0X_HEADERS,,[Define if ISO C++ 0x header files are present. ]) + fi +]) + + +As is the case for TR1 support, these autoconf macros can be made for a finer-grained, per-header-file check. For <unordered_map> + + + +# AC_HEADER_UNORDERED_MAP +AC_DEFUN([AC_HEADER_UNORDERED_MAP], [ + AC_CACHE_CHECK(for unordered_map, + ac_cv_cxx_unordered_map, + [AC_REQUIRE([AC_COMPILE_STDCXX_0X]) + AC_LANG_SAVE + AC_LANG_CPLUSPLUS + ac_save_CXXFLAGS="$CXXFLAGS" + CXXFLAGS="$CXXFLAGS -std=gnu++0x" + AC_TRY_COMPILE([#include <unordered_map>], [using std::unordered_map;], + ac_cv_cxx_unordered_map=yes, ac_cv_cxx_unordered_map=no) + CXXFLAGS="$ac_save_CXXFLAGS" + AC_LANG_RESTORE + ]) + if test "$ac_cv_cxx_unordered_map" = yes; then + AC_DEFINE(HAVE_UNORDERED_MAP,,[Define if unordered_map is present. ]) + fi +]) + + + +# AC_HEADER_UNORDERED_SET +AC_DEFUN([AC_HEADER_UNORDERED_SET], [ + AC_CACHE_CHECK(for unordered_set, + ac_cv_cxx_unordered_set, + [AC_REQUIRE([AC_COMPILE_STDCXX_0X]) + AC_LANG_SAVE + AC_LANG_CPLUSPLUS + ac_save_CXXFLAGS="$CXXFLAGS" + CXXFLAGS="$CXXFLAGS -std=gnu++0x" + AC_TRY_COMPILE([#include <unordered_set>], [using std::unordered_set;], + ac_cv_cxx_unordered_set=yes, ac_cv_cxx_unordered_set=no) + CXXFLAGS="$ac_save_CXXFLAGS" + AC_LANG_RESTORE + ]) + if test "$ac_cv_cxx_unordered_set" = yes; then + AC_DEFINE(HAVE_UNORDERED_SET,,[Define if unordered_set is present. ]) + fi +]) + + + + + + Container::iterator_type is not necessarily Container::value_type* + + + + This is a change in behavior from the previous version. Now, most + iterator_type typedefs in container classes are POD + objects, not value_type pointers. + + + + + + +Bibliography + + + + kegel41 + + + + Migrating to GCC 4.1 + + + + Dan + Kegel + + + + + + + + + + + + kegel41 + + + + Building the Whole Debian Archive with GCC 4.1: A Summary + + + + Martin + Michlmayr + + + + + + + + + + + + lbl32 + + + + Migration guide for GCC-3.2 + + + + + + + + + + + \ No newline at end of file diff --git a/libstdc++-v3/doc/xml/manual/bitmap_allocator.xml b/libstdc++-v3/doc/xml/manual/bitmap_allocator.xml new file mode 100644 index 00000000000..e05fc16c56a --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/bitmap_allocator.xml @@ -0,0 +1,559 @@ + + + + + + + ISO C++ + + + allocator + + + + +bitmap_allocator + + + + + +Design + + + As this name suggests, this allocator uses a bit-map to keep track + of the used and unused memory locations for it's book-keeping + purposes. + + + This allocator will make use of 1 single bit to keep track of + whether it has been allocated or not. A bit 1 indicates free, + while 0 indicates allocated. This has been done so that you can + easily check a collection of bits for a free block. This kind of + Bitmapped strategy works best for single object allocations, and + with the STL type parameterized allocators, we do not need to + choose any size for the block which will be represented by a + single bit. This will be the size of the parameter around which + the allocator has been parameterized. Thus, close to optimal + performance will result. Hence, this should be used for node based + containers which call the allocate function with an argument of 1. + + + + The bitmapped allocator's internal pool is exponentially growing. + Meaning that internally, the blocks acquired from the Free List + Store will double every time the bitmapped allocator runs out of + memory. + + + + The macro __GTHREADS decides whether to use + Mutex Protection around every allocation/deallocation. The state + of the macro is picked up automatically from the gthr abstraction + layer. + + + + + +Implementation + + + Free List Store + + + The Free List Store (referred to as FLS for the remaining part of this + document) is the Global memory pool that is shared by all instances of + the bitmapped allocator instantiated for any type. This maintains a + sorted order of all free memory blocks given back to it by the + bitmapped allocator, and is also responsible for giving memory to the + bitmapped allocator when it asks for more. + + + Internally, there is a Free List threshold which indicates the + Maximum number of free lists that the FLS can hold internally + (cache). Currently, this value is set at 64. So, if there are + more than 64 free lists coming in, then some of them will be given + back to the OS using operator delete so that at any given time the + Free List's size does not exceed 64 entries. This is done because + a Binary Search is used to locate an entry in a free list when a + request for memory comes along. Thus, the run-time complexity of + the search would go up given an increasing size, for 64 entries + however, lg(64) == 6 comparisons are enough to locate the correct + free list if it exists. + + + Suppose the free list size has reached it's threshold, then the + largest block from among those in the list and the new block will + be selected and given back to the OS. This is done because it + reduces external fragmentation, and allows the OS to use the + larger blocks later in an orderly fashion, possibly merging them + later. Also, on some systems, large blocks are obtained via calls + to mmap, so giving them back to free system resources becomes most + important. + + + The function _S_should_i_give decides the policy that determines + whether the current block of memory should be given to the + allocator for the request that it has made. That's because we may + not always have exact fits for the memory size that the allocator + requests. We do this mainly to prevent external fragmentation at + the cost of a little internal fragmentation. Now, the value of + this internal fragmentation has to be decided by this function. I + can see 3 possibilities right now. Please add more as and when you + find better strategies. + + + + Equal size check. Return true only when the 2 blocks are of equal +size. + Difference Threshold: Return true only when the _block_size is +greater than or equal to the _required_size, and if the _BS is > _RS +by a difference of less than some THRESHOLD value, then return true, +else return false. + Percentage Threshold. Return true only when the _block_size is +greater than or equal to the _required_size, and if the _BS is > _RS +by a percentage of less than some THRESHOLD value, then return true, +else return false. + + + + Currently, (3) is being used with a value of 36% Maximum wastage per + Super Block. + + + + + Super Block + + + A super block is the block of memory acquired from the FLS from + which the bitmap allocator carves out memory for single objects + and satisfies the user's requests. These super blocks come in + sizes that are powers of 2 and multiples of 32 + (_Bits_Per_Block). Yes both at the same time! That's because the + next super block acquired will be 2 times the previous one, and + also all super blocks have to be multiples of the _Bits_Per_Block + value. + + + How does it interact with the free list store? + + + The super block is contained in the FLS, and the FLS is responsible for + getting / returning Super Bocks to and from the OS using operator new + as defined by the C++ standard. + + + + + Super Block Data Layout + + Each Super Block will be of some size that is a multiple of the + number of Bits Per Block. Typically, this value is chosen as + Bits_Per_Byte x sizeof(size_t). On an x86 system, this gives the + figure 8 x 4 = 32. Thus, each Super Block will be of size 32 + x Some_Value. This Some_Value is sizeof(value_type). For now, let + it be called 'K'. Thus, finally, Super Block size is 32 x K bytes. + + + This value of 32 has been chosen because each size_t has 32-bits + and Maximum use of these can be made with such a figure. + + + Consider a block of size 64 ints. In memory, it would look like this: + (assume a 32-bit system where, size_t is a 32-bit entity). + + + +Bitmap Allocator Memory Map + + + + + + + + + + 268 + 0 + 4294967295 + 4294967295 + Data -> Space for 64 ints + + + +
+ + + The first Column(268) represents the size of the Block in bytes as + seen by the Bitmap Allocator. Internally, a global free list is + used to keep track of the free blocks used and given back by the + bitmap allocator. It is this Free List Store that is responsible + for writing and managing this information. Actually the number of + bytes allocated in this case would be: 4 + 4 + (4x2) + (64x4) = + 272 bytes, but the first 4 bytes are an addition by the Free List + Store, so the Bitmap Allocator sees only 268 bytes. These first 4 + bytes about which the bitmapped allocator is not aware hold the + value 268. + + + + What do the remaining values represent? + + The 2nd 4 in the expression is the sizeof(size_t) because the + Bitmapped Allocator maintains a used count for each Super Block, + which is initially set to 0 (as indicated in the diagram). This is + incremented every time a block is removed from this super block + (allocated), and decremented whenever it is given back. So, when + the used count falls to 0, the whole super block will be given + back to the Free List Store. + + + The value 4294967295 represents the integer corresponding to the bit + representation of all bits set: 11111111111111111111111111111111. + + + The 3rd 4x2 is size of the bitmap itself, which is the size of 32-bits + x 2, + which is 8-bytes, or 2 x sizeof(size_t). + + + + + Maximum Wasted Percentage + + + This has nothing to do with the algorithm per-se, + only with some vales that must be chosen correctly to ensure that the + allocator performs well in a real word scenario, and maintains a good + balance between the memory consumption and the allocation/deallocation + speed. + + + The formula for calculating the maximum wastage as a percentage: + + + +(32 x k + 1) / (2 x (32 x k + 1 + 32 x c)) x 100. + + + + Where, k => The constant overhead per node. eg. for list, it is + 8 bytes, and for map it is 12 bytes. c => The size of the + base type on which the map/list is instantiated. Thus, suppose the + type1 is int and type2 is double, they are related by the relation + sizeof(double) == 2*sizeof(int). Thus, all types must have this + double size relation for this formula to work properly. + + + Plugging-in: For List: k = 8 and c = 4 (int and double), we get: + 33.376% + + + +For map/multimap: k = 12, and c = 4 (int and double), we get: 37.524% + + + Thus, knowing these values, and based on the sizeof(value_type), we may + create a function that returns the Max_Wastage_Percentage for us to use. + + + + + + <function>allocate</function> + + + The allocate function is specialized for single object allocation + ONLY. Thus, ONLY if n == 1, will the bitmap_allocator's + specialized algorithm be used. Otherwise, the request is satisfied + directly by calling operator new. + + + Suppose n == 1, then the allocator does the following: + + + + + Checks to see whether a free block exists somewhere in a region + of memory close to the last satisfied request. If so, then that + block is marked as allocated in the bit map and given to the + user. If not, then (2) is executed. + + + + + Is there a free block anywhere after the current block right + up to the end of the memory that we have? If so, that block is + found, and the same procedure is applied as above, and + returned to the user. If not, then (3) is executed. + + + + + Is there any block in whatever region of memory that we own + free? This is done by checking + + + + + The use count for each super block, and if that fails then + + + + + The individual bit-maps for each super block. + + + + + + Note: Here we are never touching any of the memory that the + user will be given, and we are confining all memory accesses + to a small region of memory! This helps reduce cache + misses. If this succeeds then we apply the same procedure on + that bit-map as (1), and return that block of memory to the + user. However, if this process fails, then we resort to (4). + + + + + This process involves Refilling the internal exponentially + growing memory pool. The said effect is achieved by calling + _S_refill_pool which does the following: + + + + + Gets more memory from the Global Free List of the Required + size. + + + + + Adjusts the size for the next call to itself. + + + + + Writes the appropriate headers in the bit-maps. + + + + + Sets the use count for that super-block just allocated to 0 + (zero). + + + + + All of the above accounts to maintaining the basic invariant + for the allocator. If the invariant is maintained, we are + sure that all is well. Now, the same process is applied on + the newly acquired free blocks, which are dispatched + accordingly. + + + + + + + +Thus, you can clearly see that the allocate function is nothing but a +combination of the next-fit and first-fit algorithm optimized ONLY for +single object allocations. + + + + + + <function>deallocate</function> + + The deallocate function again is specialized for single objects ONLY. + For all n belonging to > 1, the operator delete is called without + further ado, and the deallocate function returns. + + + However for n == 1, a series of steps are performed: + + + + + We first need to locate that super-block which holds the memory + location given to us by the user. For that purpose, we maintain + a static variable _S_last_dealloc_index, which holds the index + into the vector of block pairs which indicates the index of the + last super-block from which memory was freed. We use this + strategy in the hope that the user will deallocate memory in a + region close to what he/she deallocated the last time around. If + the check for belongs_to succeeds, then we determine the bit-map + for the given pointer, and locate the index into that bit-map, + and mark that bit as free by setting it. + + + If the _S_last_dealloc_index does not point to the memory block + that we're looking for, then we do a linear search on the block + stored in the vector of Block Pairs. This vector in code is + called _S_mem_blocks. When the corresponding super-block is + found, we apply the same procedure as we did for (1) to mark the + block as free in the bit-map. + + + + + Now, whenever a block is freed, the use count of that particular + super block goes down by 1. When this use count hits 0, we remove + that super block from the list of all valid super blocks stored in + the vector. While doing this, we also make sure that the basic + invariant is maintained by making sure that _S_last_request and + _S_last_dealloc_index point to valid locations within the vector. + + + + + Questions + + + 1 + +Q1) The "Data Layout" section is +cryptic. I have no idea of what you are trying to say. Layout of what? +The free-list? Each bitmap? The Super Block? + + + The layout of a Super Block of a given +size. In the example, a super block of size 32 x 1 is taken. The +general formula for calculating the size of a super block is +32 x sizeof(value_type) x 2^n, where n ranges from 0 to 32 for 32-bit +systems. + + + + + 2 + + And since I just mentioned the +term `each bitmap', what in the world is meant by it? What does each +bitmap manage? How does it relate to the super block? Is the Super +Block a bitmap as well? + + + Each bitmap is part of a Super Block which is made up of 3 parts + as I have mentioned earlier. Re-iterating, 1. The use count, + 2. The bit-map for that Super Block. 3. The actual memory that + will be eventually given to the user. Each bitmap is a multiple + of 32 in size. If there are 32 x (2^3) blocks of single objects + to be given, there will be '32 x (2^3)' bits present. Each 32 + bits managing the allocated / free status for 32 blocks. Since + each size_t contains 32-bits, one size_t can manage up to 32 + blocks' status. Each bit-map is made up of a number of size_t, + whose exact number for a super-block of a given size I have just + mentioned. + + + + + 3 + + How do the allocate and deallocate functions work in regard to + bitmaps? + + + The allocate and deallocate functions manipulate the bitmaps and + have nothing to do with the memory that is given to the user. As + I have earlier mentioned, a 1 in the bitmap's bit field + indicates free, while a 0 indicates allocated. This lets us + check 32 bits at a time to check whether there is at lease one + free block in those 32 blocks by testing for equality with + (0). Now, the allocate function will given a memory block find + the corresponding bit in the bitmap, and will reset it (i.e., + make it re-set (0)). And when the deallocate function is called, + it will again set that bit after locating it to indicate that + that particular block corresponding to this bit in the bit-map + is not being used by anyone, and may be used to satisfy future + requests. + + + e.g.: Consider a bit-map of 64-bits as represented below: + 1111111111111111111111111111111111111111111111111111111111111111 + + + + Now, when the first request for allocation of a single object + comes along, the first block in address order is returned. And + since the bit-maps in the reverse order to that of the address + order, the last bit (LSB if the bit-map is considered as a + binary word of 64-bits) is re-set to 0. + + + + The bit-map now looks like this: + 1111111111111111111111111111111111111111111111111111111111111110 + + + + + + Locality + + Another issue would be whether to keep the all bitmaps in a + separate area in memory, or to keep them near the actual blocks + that will be given out or allocated for the client. After some + testing, I've decided to keep these bitmaps close to the actual + blocks. This will help in 2 ways. + + + + Constant time access for the bitmap themselves, since no kind of +look up will be needed to find the correct bitmap list or it's +equivalent. + And also this would preserve the cache as far as possible. + + + + So in effect, this kind of an allocator might prove beneficial from a + purely cache point of view. But this allocator has been made to try and + roll out the defects of the node_allocator, wherein the nodes get + skewed about in memory, if they are not returned in the exact reverse + order or in the same order in which they were allocated. Also, the + new_allocator's book keeping overhead is too much for small objects and + single object allocations, though it preserves the locality of blocks + very well when they are returned back to the allocator. + + + + + Overhead and Grow Policy + + Expected overhead per block would be 1 bit in memory. Also, once + the address of the free list has been found, the cost for + allocation/deallocation would be negligible, and is supposed to be + constant time. For these very reasons, it is very important to + minimize the linear time costs, which include finding a free list + with a free block while allocating, and finding the corresponding + free list for a block while deallocating. Therefore, I have + decided that the growth of the internal pool for this allocator + will be exponential as compared to linear for + node_allocator. There, linear time works well, because we are + mainly concerned with speed of allocation/deallocation and memory + consumption, whereas here, the allocation/deallocation part does + have some linear/logarithmic complexity components in it. Thus, to + try and minimize them would be a good thing to do at the cost of a + little bit of memory. + + + + Another thing to be noted is the pool size will double every time + the internal pool gets exhausted, and all the free blocks have + been given away. The initial size of the pool would be + sizeof(size_t) x 8 which is the number of bits in an integer, + which can fit exactly in a CPU register. Hence, the term given is + exponential growth of the internal pool. + + + + + + \ No newline at end of file diff --git a/libstdc++-v3/doc/xml/manual/build.xml b/libstdc++-v3/doc/xml/manual/build.xml new file mode 100644 index 00000000000..d5d78291f43 --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/build.xml @@ -0,0 +1,182 @@ + + + + + + + ISO C++ + + + build + + + + +Build + + + Because libstdc++ is part of GCC, the primary source for + installation instructions is + the GCC install page. + Additional data is given here only where it applies to libstdc++. + + + +Prerequisites + + The list of software needed to build the library is kept with the + rest of the compiler, at + + http://gcc.gnu.org/install/prerequisites.html. The same page + also lists the tools you will need if you wish to modify the source. + + + As of GCC 4.0.1 the minimum version of binutils required to build + libstdc++ is 2.15.90.0.1.1. You can get snapshots + (as well as releases) of binutils from + + ftp://sources.redhat.com/pub/binutils. + Older releases of libstdc++ do not require such a recent version, + but to take full advantage of useful space-saving features and + bug-fixes you should use a recent binutils if possible. + The configure process will automatically detect and use these + features if the underlying support is present. + + + + Finally, a few system-specific requirements: + + + + + linux + + + + If gcc 3.1.0 or later on is being used on linux, an attempt + will be made to use "C" library functionality necessary for + C++ named locale support. For gcc 3.2.1 and later, this + means that glibc 2.2.5 or later is required and the "C" + library de_DE locale information must be installed. + + + + Note however that the sanity checks involving the de_DE + locale are skipped when an explicit --enable-clocale=gnu + configure option is used: only the basic checks are carried + out, defending against misconfigurations. + + + + If the 'gnu' locale model is being used, the following + locales are used and tested in the libstdc++ testsuites. + The first column is the name of the locale, the second is + the character set it is expected to use. + + +de_DE ISO-8859-1 +de_DE@euro ISO-8859-15 +en_HK ISO-8859-1 +en_PH ISO-8859-1 +en_US ISO-8859-1 +en_US.ISO-8859-1 ISO-8859-1 +en_US.ISO-8859-15 ISO-8859-15 +en_US.UTF-8 UTF-8 +es_ES ISO-8859-1 +es_MX ISO-8859-1 +fr_FR ISO-8859-1 +fr_FR@euro ISO-8859-15 +is_IS UTF-8 +it_IT ISO-8859-1 +ja_JP.eucjp EUC-JP +se_NO.UTF-8 UTF-8 +ta_IN UTF-8 +zh_TW BIG5 + + Failure to have the underlying "C" library locale + information installed will mean that C++ named locales for the + above regions will not work: because of this, the libstdc++ + testsuite will skip the named locale tests. If this isn't an + issue, don't worry about it. If named locales are needed, the + underlying locale information must be installed. Note that + rebuilding libstdc++ after the "C" locales are installed is not + necessary. + + + + To install support for locales, do only one of the following: + + + + + install all locales + + + with RedHat Linux: + + export LC_ALL=C + + rpm -e glibc-common --nodeps + + + rpm -i --define "_install_langs all" + glibc-common-2.2.5-34.i386.rpm + + + + + + Instructions for other operating systems solicited. + + + + + + install just the necessary locales + + + with Debian Linux: + Add the above list, as shown, to the file + /etc/locale.gen + run /usr/sbin/locale-gen + + + on most Unix-like operating systems: + localedef -i de_DE -f ISO-8859-1 de_DE + (repeat for each entry in the above list) + + + + Instructions for other operating systems solicited. + + + + + + + + + + + + +Make + If you have never done this before, you should read the basic + GCC Installation + Instructions first. Read all of them. + Twice. + + When building libstdc++ you'll have to configure + the entire gccsrcdir directory. The full list of libstdc++ + specific configuration options, not dependent on the specific compiler + release being used, can be found here. + + Consider possibly using --enable-languages=c++ to save time by only + building the C++ language parts. + + + + cd gccbuilddir + gccsrcdir/configure --prefix=destdir --other-opts... + + \ No newline at end of file diff --git a/libstdc++-v3/doc/xml/manual/build_hacking.xml b/libstdc++-v3/doc/xml/manual/build_hacking.xml new file mode 100644 index 00000000000..b420f4f0706 --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/build_hacking.xml @@ -0,0 +1,354 @@ + + + + + + + C++ + + + BUILD_HACKING + + + version + + + dynamic + + + shared + + + + +Configure and Build Hacking + + + Prerequisites + + As noted previously, + certain other tools are necessary for hacking on files that + control configure (configure.ac, + acinclude.m4) and make + (Makefile.am). These additional tools + (automake, and autoconf) are further + described in detail in their respective manuals. All the libraries + in GCC try to stay in sync with each other in terms of versions of + the auto-tools used, so please try to play nicely with the + neighbors. + + + + + Overview: What Comes from Where + + + + + + + + Dependency Graph Configure to Build Files + + + + + + Regenerate all generated files by using the command sequence + "autoreconf" at the top level of the libstdc++ source + directory. The following will also work, but is much more complex: + "aclocal-1.7 && autoconf-2.59 && + autoheader-2.59 && automake-1.7" The version + numbers may be absent entirely or otherwise vary depending on + the + current requirements and your vendor's choice of + installation names. + + + + + Storing Information in non-AC files (like configure.host) + + + Until that glorious day when we can use AC_TRY_LINK with a + cross-compiler, we have to hardcode the results of what the tests + would have shown if they could be run. So we have an inflexible + mess like crossconfig.m4. + + + + Wouldn't it be nice if we could store that information in files + like configure.host, which can be modified without needing to + regenerate anything, and can even be tweaked without really + knowing how the configury all works? Perhaps break the pieces of + crossconfig.m4 out and place them in their appropriate + config/{cpu,os} directory. + + + + Alas, writing macros like + "AC_DEFINE(HAVE_A_NICE_DAY)" can only be done inside + files which are passed through autoconf. Files which are pure + shell script can be source'd at configure time. Files which + contain autoconf macros must be processed with autoconf. We could + still try breaking the pieces out into "config/*/cross.m4" bits, + for instance, but then we would need arguments to aclocal/autoconf + to properly find them all when generating configure. I would + discourage that. + + + + + Coding and Commenting Conventions + + + Most comments should use {octothorpes, shibboleths, hash marks, + pound signs, whatevers} rather than "dnl". Nearly all comments in + configure.ac should. Comments inside macros written in ancilliary + .m4 files should. About the only comments which should + not use #, but use dnl instead, are comments + outside our own macros in the ancilliary + files. The difference is that # comments show up in + configure (which is most helpful for debugging), + while dnl'd lines just vanish. Since the macros in ancilliary + files generate code which appears in odd places, their "outside" + comments tend to not be useful while reading + configure. + + + + Do not use any $target* variables, such as + $target_alias. The single exception is in + configure.ac, for automake+dejagnu's sake. + + + + + The acinclude.m4 layout + + The nice thing about acinclude.m4/aclocal.m4 is that macros aren't + actually performed/called/expanded/whatever here, just loaded. So + we can arrange the contents however we like. As of this writing, + acinclude.m4 is arranged as follows: + + + GLIBCXX_CHECK_HOST + GLIBCXX_TOPREL_CONFIGURE + GLIBCXX_CONFIGURE + + + All the major variable "discovery" is done here. CXX, multilibs, + etc. + + + fragments included from elsewhere + + + Right now, "fragments" == "the math/linkage bits". + + + GLIBCXX_CHECK_COMPILER_FEATURES + GLIBCXX_CHECK_LINKER_FEATURES + GLIBCXX_CHECK_WCHAR_T_SUPPORT + + + Next come extra compiler/linker feature tests. Wide character + support was placed here because I couldn't think of another place + for it. It will probably get broken apart like the math tests, + because we're still disabling wchars on systems which could actually + support them. + + + GLIBCXX_CHECK_SETRLIMIT_ancilliary + GLIBCXX_CHECK_SETRLIMIT + GLIBCXX_CHECK_S_ISREG_OR_S_IFREG + GLIBCXX_CHECK_POLL + GLIBCXX_CHECK_WRITEV + + GLIBCXX_CONFIGURE_TESTSUITE + + + Feature tests which only get used in one place. Here, things used + only in the testsuite, plus a couple bits used in the guts of I/O. + + + GLIBCXX_EXPORT_INCLUDES + GLIBCXX_EXPORT_FLAGS + GLIBCXX_EXPORT_INSTALL_INFO + + + Installation variables, multilibs, working with the rest of the + compiler. Many of the critical variables used in the makefiles are + set here. + + + GLIBGCC_ENABLE + GLIBCXX_ENABLE_C99 + GLIBCXX_ENABLE_CHEADERS + GLIBCXX_ENABLE_CLOCALE + GLIBCXX_ENABLE_CONCEPT_CHECKS + GLIBCXX_ENABLE_CSTDIO + GLIBCXX_ENABLE_CXX_FLAGS + GLIBCXX_ENABLE_C_MBCHAR + GLIBCXX_ENABLE_DEBUG + GLIBCXX_ENABLE_DEBUG_FLAGS + GLIBCXX_ENABLE_LONG_LONG + GLIBCXX_ENABLE_PCH + GLIBCXX_ENABLE_SJLJ_EXCEPTIONS + GLIBCXX_ENABLE_SYMVERS + GLIBCXX_ENABLE_THREADS + + + All the features which can be controlled with enable/disable + configure options. Note how they're alphabetized now? Keep them + like that. :-) + + + AC_LC_MESSAGES + libtool bits + + + Things which we don't seem to use directly, but just has to be + present otherwise stuff magically goes wonky. + + + + + + <constant>GLIBCXX_ENABLE</constant>, the <literal>--enable</literal> maker + + + All the GLIBCXX_ENABLE_FOO macros use a common helper, + GLIBCXX_ENABLE. (You don't have to use it, but it's easy.) The + helper does two things for us: + + + + + + Builds the call to the AC_ARG_ENABLE macro, with --help text + properly quoted and aligned. (Death to changequote!) + + + + + Checks the result against a list of allowed possibilities, and + signals a fatal error if there's no match. This means that the + rest of the GLIBCXX_ENABLE_FOO macro doesn't need to test for + strange arguments, nor do we need to protect against + empty/whitespace strings with the "x$foo" = "xbar" + idiom. + + + + +Doing these things correctly takes some extra autoconf/autom4te code, + which made our macros nearly illegible. So all the ugliness is factored + out into this one helper macro. + + +Many of the macros take an argument, passed from when they are expanded + in configure.ac. The argument controls the default value of the + enable/disable switch. Previously, the arguments themselves had defaults. + Now they don't, because that's extra complexity with zero gain for us. + + +There are three "overloaded signatures". When reading the descriptions + below, keep in mind that the brackets are autoconf's quotation characters, + and that they will be stripped. Examples of just about everything occur + in acinclude.m4, if you want to look. + + + + GLIBCXX_ENABLE (FEATURE, DEFAULT, HELP-ARG, HELP-STRING) + GLIBCXX_ENABLE (FEATURE, DEFAULT, HELP-ARG, HELP-STRING, permit a|b|c) + GLIBCXX_ENABLE (FEATURE, DEFAULT, HELP-ARG, HELP-STRING, SHELL-CODE-HANDLER) + + + + + + FEATURE is the string that follows --enable. The results of the + test (such as it is) will be in the variable $enable_FEATURE, + where FEATURE has been squashed. Example: + [extra-foo], controlled by the --enable-extra-foo + option and stored in $enable_extra_foo. + + + + + DEFAULT is the value to store in $enable_FEATURE if the user does + not pass --enable/--disable. It should be one of the permitted + values passed later. Examples: [yes], or + [bar], or [$1] (which passes the + argument given to the GLIBCXX_ENABLE_FOO macro as the + default). + + + For cases where we need to probe for particular models of things, + it is useful to have an undocumented "auto" value here (see + GLIBCXX_ENABLE_CLOCALE for an example). + + + + + HELP-ARG is any text to append to the option string itself in the + --help output. Examples: [] (i.e., an empty string, + which appends nothing), [=BAR], which produces + --enable-extra-foo=BAR, and + [@<:@=BAR@:>@], which produces + --enable-extra-foo[=BAR]. See the difference? See + what it implies to the user? + + + If you're wondering what that line noise in the last example was, + that's how you embed autoconf special characters in output text. + They're called quadrigraphs + and you should use them whenever necessary. + + + + HELP-STRING is what you think it is. Do not include the + "default" text like we used to do; it will be done for you by + GLIBCXX_ENABLE. By convention, these are not full English + sentences. Example: [turn on extra foo] + + + + + + With no other arguments, only the standard autoconf patterns are + allowed: "--{enable,disable}-foo[={yes,no}]" The + $enable_FEATURE variable is guaranteed to equal either "yes" or "no" + after the macro. If the user tries to pass something else, an + explanatory error message will be given, and configure will halt. + + + + The second signature takes a fifth argument, "[permit + a | b | c | ...]" + This allows a or b or + ... after the equals sign in the option, and $enable_FEATURE is + guaranteed to equal one of them after the macro. Note that if you + want to allow plain --enable/--disable with no "=whatever", you must + include "yes" and "no" in the list of permitted values. Also note + that whatever you passed as DEFAULT must be in the list. If the + user tries to pass something not on the list, a semi-explanatory + error message will be given, and configure will halt. Example: + [permit generic|gnu|ieee_1003.1-2001|yes|no|auto] + + + + The third signature takes a fifth argument. It is arbitrary shell + code to execute if the user actually passes the enable/disable + option. (If the user does not, the default is used. Duh.) No + argument checking at all is done in this signature. See + GLIBCXX_ENABLE_CXX_FLAGS for an example of handling, and an error + message. + + + + + \ No newline at end of file diff --git a/libstdc++-v3/doc/xml/manual/codecvt.xml b/libstdc++-v3/doc/xml/manual/codecvt.xml new file mode 100644 index 00000000000..4c14d6253f0 --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/codecvt.xml @@ -0,0 +1,730 @@ + + + + + + + ISO C++ + + + codecvt + + + + +codecvt + + +The standard class codecvt attempts to address conversions between +different character encoding schemes. In particular, the standard +attempts to detail conversions between the implementation-defined wide +characters (hereafter referred to as wchar_t) and the standard type +char that is so beloved in classic C (which can now be +referred to as narrow characters.) This document attempts to describe +how the GNU libstdc++ implementation deals with the conversion between +wide and narrow characters, and also presents a framework for dealing +with the huge number of other encodings that iconv can convert, +including Unicode and UTF8. Design issues and requirements are +addressed, and examples of correct usage for both the required +specializations for wide and narrow characters and the +implementation-provided extended functionality are given. + + + +Requirements + + +Around page 425 of the C++ Standard, this charming heading comes into view: + + +
+ +22.2.1.5 - Template class codecvt + +
+ + +The text around the codecvt definition gives some clues: + + +
+ + +-1- The class codecvt<internT,externT,stateT> is for use when +converting from one codeset to another, such as from wide characters +to multibyte characters, between wide character encodings such as +Unicode and EUC. + + +
+ + +Hmm. So, in some unspecified way, Unicode encodings and +translations between other character sets should be handled by this +class. + + +
+ + +-2- The stateT argument selects the pair of codesets being mapped between. + + +
+ + +Ah ha! Another clue... + + +
+ + +-3- The instantiations required in the Table ?? +(lib.locale.category), namely codecvt<wchar_t,char,mbstate_t> and +codecvt<char,char,mbstate_t>, convert the implementation-defined +native character set. codecvt<char,char,mbstate_t> implements a +degenerate conversion; it does not convert at +all. codecvt<wchar_t,char,mbstate_t> converts between the native +character sets for tiny and wide characters. Instantiations on +mbstate_t perform conversion between encodings known to the library +implementor. Other encodings can be converted by specializing on a +user-defined stateT type. The stateT object can contain any state that +is useful to communicate to or from the specialized do_convert member. + + +
+ + +At this point, a couple points become clear: + + + +One: The standard clearly implies that attempts to add non-required +(yet useful and widely used) conversions need to do so through the +third template parameter, stateT. + + +Two: The required conversions, by specifying mbstate_t as the third +template parameter, imply an implementation strategy that is mostly +(or wholly) based on the underlying C library, and the functions +mcsrtombs and wcsrtombs in particular. + + + +Design + + + <type>wchar_t</type> Size + + + The simple implementation detail of wchar_t's size seems to + repeatedly confound people. Many systems use a two byte, + unsigned integral type to represent wide characters, and use an + internal encoding of Unicode or UCS2. (See AIX, Microsoft NT, + Java, others.) Other systems, use a four byte, unsigned integral + type to represent wide characters, and use an internal encoding + of UCS4. (GNU/Linux systems using glibc, in particular.) The C + programming language (and thus C++) does not specify a specific + size for the type wchar_t. + + + + Thus, portable C++ code cannot assume a byte size (or endianness) either. + + + + + Support for Unicode + + Probably the most frequently asked question about code conversion + is: "So dudes, what's the deal with Unicode strings?" + The dude part is optional, but apparently the usefulness of + Unicode strings is pretty widely appreciated. Sadly, this specific + encoding (And other useful encodings like UTF8, UCS4, ISO 8859-10, + etc etc etc) are not mentioned in the C++ standard. + + + + A couple of comments: + + + + The thought that all one needs to convert between two arbitrary + codesets is two types and some kind of state argument is + unfortunate. In particular, encodings may be stateless. The naming + of the third parameter as stateT is unfortunate, as what is really + needed is some kind of generalized type that accounts for the + issues that abstract encodings will need. The minimum information + that is required includes: + + + + + + Identifiers for each of the codesets involved in the + conversion. For example, using the iconv family of functions + from the Single Unix Specification (what used to be called + X/Open) hosted on the GNU/Linux operating system allows + bi-directional mapping between far more than the following + tantalizing possibilities: + + + + (An edited list taken from `iconv --list` on a + Red Hat 6.2/Intel system: + + +
+ +8859_1, 8859_9, 10646-1:1993, 10646-1:1993/UCS4, ARABIC, ARABIC7, +ASCII, EUC-CN, EUC-JP, EUC-KR, EUC-TW, GREEK-CCIcode, GREEK, GREEK7-OLD, +GREEK7, GREEK8, HEBREW, ISO-8859-1, ISO-8859-2, ISO-8859-3, +ISO-8859-4, ISO-8859-5, ISO-8859-6, ISO-8859-7, ISO-8859-8, +ISO-8859-9, ISO-8859-10, ISO-8859-11, ISO-8859-13, ISO-8859-14, +ISO-8859-15, ISO-10646, ISO-10646/UCS2, ISO-10646/UCS4, +ISO-10646/UTF-8, ISO-10646/UTF8, SHIFT-JIS, SHIFT_JIS, UCS-2, UCS-4, +UCS2, UCS4, UNICODE, UNICODEBIG, UNICODELIcodeLE, US-ASCII, US, UTF-8, +UTF-16, UTF8, UTF16). + +
+ + +For iconv-based implementations, string literals for each of the +encodings (ie. "UCS-2" and "UTF-8") are necessary, +although for other, +non-iconv implementations a table of enumerated values or some other +mechanism may be required. + + + + + Maximum length of the identifying string literal. + + + + Some encodings require explicit endian-ness. As such, some kind + of endian marker or other byte-order marker will be necessary. See + "Footnotes for C/C++ developers" in Haible for more information on + UCS-2/Unicode endian issues. (Summary: big endian seems most likely, + however implementations, most notably Microsoft, vary.) + + + + Types representing the conversion state, for conversions involving + the machinery in the "C" library, or the conversion descriptor, for + conversions using iconv (such as the type iconv_t.) Note that the + conversion descriptor encodes more information than a simple encoding + state type. + + + + Conversion descriptors for both directions of encoding. (ie, both + UCS-2 to UTF-8 and UTF-8 to UCS-2.) + + + + Something to indicate if the conversion requested if valid. + + + + Something to represent if the conversion descriptors are valid. + + + + Some way to enforce strict type checking on the internal and + external types. As part of this, the size of the internal and + external types will need to be known. + + + + + + Other Issues + +In addition, multi-threaded and multi-locale environments also impact +the design and requirements for code conversions. In particular, they +affect the required specialization codecvt<wchar_t, char, mbstate_t> +when implemented using standard "C" functions. + + + +Three problems arise, one big, one of medium importance, and one small. + + + +First, the small: mcsrtombs and wcsrtombs may not be multithread-safe +on all systems required by the GNU tools. For GNU/Linux and glibc, +this is not an issue. + + + +Of medium concern, in the grand scope of things, is that the functions +used to implement this specialization work on null-terminated +strings. Buffers, especially file buffers, may not be null-terminated, +thus giving conversions that end prematurely or are otherwise +incorrect. Yikes! + + + +The last, and fundamental problem, is the assumption of a global +locale for all the "C" functions referenced above. For something like +C++ iostreams (where codecvt is explicitly used) the notion of +multiple locales is fundamental. In practice, most users may not run +into this limitation. However, as a quality of implementation issue, +the GNU C++ library would like to offer a solution that allows +multiple locales and or simultaneous usage with computationally +correct results. In short, libstdc++ is trying to offer, as an +option, a high-quality implementation, damn the additional complexity! + + + +For the required specialization codecvt<wchar_t, char, mbstate_t> , +conversions are made between the internal character set (always UCS4 +on GNU/Linux) and whatever the currently selected locale for the +LC_CTYPE category implements. + + + + + + + +Implementation + + +The two required specializations are implemented as follows: + + + + +codecvt<char, char, mbstate_t> + + + +This is a degenerate (ie, does nothing) specialization. Implementing +this was a piece of cake. + + + + +codecvt<char, wchar_t, mbstate_t> + + + + +This specialization, by specifying all the template parameters, pretty +much ties the hands of implementors. As such, the implementation is +straightforward, involving mcsrtombs for the conversions between char +to wchar_t and wcsrtombs for conversions between wchar_t and char. + + + +Neither of these two required specializations deals with Unicode +characters. As such, libstdc++ implements a partial specialization +of the codecvt class with and iconv wrapper class, encoding_state as the +third template parameter. + + + +This implementation should be standards conformant. First of all, the +standard explicitly points out that instantiations on the third +template parameter, stateT, are the proper way to implement +non-required conversions. Second of all, the standard says (in Chapter +17) that partial specializations of required classes are a-ok. Third +of all, the requirements for the stateT type elsewhere in the standard +(see 21.1.2 traits typedefs) only indicate that this type be copy +constructible. + + + +As such, the type encoding_state is defined as a non-templatized, POD +type to be used as the third type of a codecvt instantiation. This +type is just a wrapper class for iconv, and provides an easy interface +to iconv functionality. + + + +There are two constructors for encoding_state: + + + + +encoding_state() : __in_desc(0), __out_desc(0) + + + +This default constructor sets the internal encoding to some default +(currently UCS4) and the external encoding to whatever is returned by +nl_langinfo(CODESET). + + + + +encoding_state(const char* __int, const char* __ext) + + + + +This constructor takes as parameters string literals that indicate the +desired internal and external encoding. There are no defaults for +either argument. + + + +One of the issues with iconv is that the string literals identifying +conversions are not standardized. Because of this, the thought of +mandating and or enforcing some set of pre-determined valid +identifiers seems iffy: thus, a more practical (and non-migraine +inducing) strategy was implemented: end-users can specify any string +(subject to a pre-determined length qualifier, currently 32 bytes) for +encodings. It is up to the user to make sure that these strings are +valid on the target system. + + + + +void +_M_init() + + + +Strangely enough, this member function attempts to open conversion +descriptors for a given encoding_state object. If the conversion +descriptors are not valid, the conversion descriptors returned will +not be valid and the resulting calls to the codecvt conversion +functions will return error. + + + + +bool +_M_good() + + + + +Provides a way to see if the given encoding_state object has been +properly initialized. If the string literals describing the desired +internal and external encoding are not valid, initialization will +fail, and this will return false. If the internal and external +encodings are valid, but iconv_open could not allocate conversion +descriptors, this will also return false. Otherwise, the object is +ready to convert and will return true. + + + + +encoding_state(const encoding_state&) + + + + +As iconv allocates memory and sets up conversion descriptors, the copy +constructor can only copy the member data pertaining to the internal +and external code conversions, and not the conversion descriptors +themselves. + + + +Definitions for all the required codecvt member functions are provided +for this specialization, and usage of codecvt<internal character type, +external character type, encoding_state> is consistent with other +codecvt usage. + + + + + +Use +A conversions involving string literal. + + + typedef codecvt_base::result result; + typedef unsigned short unicode_t; + typedef unicode_t int_type; + typedef char ext_type; + typedef encoding_state state_type; + typedef codecvt<int_type, ext_type, state_type> unicode_codecvt; + + const ext_type* e_lit = "black pearl jasmine tea"; + int size = strlen(e_lit); + int_type i_lit_base[24] = + { 25088, 27648, 24832, 25344, 27392, 8192, 28672, 25856, 24832, 29184, + 27648, 8192, 27136, 24832, 29440, 27904, 26880, 28160, 25856, 8192, 29696, + 25856, 24832, 2560 + }; + const int_type* i_lit = i_lit_base; + const ext_type* efrom_next; + const int_type* ifrom_next; + ext_type* e_arr = new ext_type[size + 1]; + ext_type* eto_next; + int_type* i_arr = new int_type[size + 1]; + int_type* ito_next; + + // construct a locale object with the specialized facet. + locale loc(locale::classic(), new unicode_codecvt); + // sanity check the constructed locale has the specialized facet. + VERIFY( has_facet<unicode_codecvt>(loc) ); + const unicode_codecvt& cvt = use_facet<unicode_codecvt>(loc); + // convert between const char* and unicode strings + unicode_codecvt::state_type state01("UNICODE", "ISO_8859-1"); + initialize_state(state01); + result r1 = cvt.in(state01, e_lit, e_lit + size, efrom_next, + i_arr, i_arr + size, ito_next); + VERIFY( r1 == codecvt_base::ok ); + VERIFY( !int_traits::compare(i_arr, i_lit, size) ); + VERIFY( efrom_next == e_lit + size ); + VERIFY( ito_next == i_arr + size ); + + + + + +Future + + + + a. things that are sketchy, or remain unimplemented: + do_encoding, max_length and length member functions + are only weakly implemented. I have no idea how to do + this correctly, and in a generic manner. Nathan? + + + + + + b. conversions involving std::string + + + + how should operators != and == work for string of + different/same encoding? + + + + what is equal? A byte by byte comparison or an + encoding then byte comparison? + + + + conversions between narrow, wide, and unicode strings + + + + + c. conversions involving std::filebuf and std::ostream + + + + how to initialize the state object in a + standards-conformant manner? + + + + how to synchronize the "C" and "C++" + conversion information? + + + + wchar_t/char internal buffers and conversions between + internal/external buffers? + + + + + + + + +Bibliography + + + + The GNU C Library + + + + McGrath + Roland + + + Drepper + Ulrich + + + + 2007 + FSF + + Chapters 6 Character Set Handling and 7 Locales and Internationalization + + + + + + Correspondence + + + + Drepper + Ulrich + + + + 2002 + + + + + + + ISO/IEC 14882:1998 Programming languages - C++ + + + + 1998 + ISO + + + + + + ISO/IEC 9899:1999 Programming languages - C + + + + 1999 + ISO + + + + + + System Interface Definitions, Issue 6 (IEEE Std. 1003.1-200x) + + + + 1999 + + The Open Group/The Institute of Electrical and Electronics Engineers, Inc. + + + + + + + + + + + + The C++ Programming Language, Special Edition + + + + Stroustrup + Bjarne + + + + 2000 + Addison Wesley, Inc. + + Appendix D + + + + Addison Wesley + + + + + + + + + Standard C++ IOStreams and Locales + + + Advanced Programmer's Guide and Reference + + + + Langer + Angelika + + + + Kreft + Klaus + + + + 2000 + Addison Wesley Longman, Inc. + + + + + Addison Wesley Longman + + + + + + + + A brief description of Normative Addendum 1 + + + + Feather + Clive + + + Extended Character Sets + + + + + + + + + + The Unicode HOWTO + + + + Haible + Bruno + + + + + + + + + + + + UTF-8 and Unicode FAQ for Unix/Linux + + + + Khun + Markus + + + + + + + + + + + + + \ No newline at end of file diff --git a/libstdc++-v3/doc/xml/manual/concurrency.xml b/libstdc++-v3/doc/xml/manual/concurrency.xml new file mode 100644 index 00000000000..5740e424373 --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/concurrency.xml @@ -0,0 +1,334 @@ + + + + + + + + + + ISO C++ + + + library + + + + +Concurrency + + + Design + + + Interface to Locks and Mutexes + +The file <ext/concurrence.h> contains all the higher-level +constructs for playing with threads. In contrast to the atomics layer, +the concurrence layer consists largely of types. All types are defined within namespace __gnu_cxx. + + + +These types can be used in a portable manner, regardless of the +specific environment. They are carefully designed to provide optimum +efficiency and speed, abstracting out underlying thread calls and +accesses when compiling for single-threaded situations (even on hosts +that support multiple threads.) + + +The enumerated type _Lock_policy details the set of +available locking +policies: _S_single, _S_mutex, +and _S_atomic. + + + +_S_single +Indicates single-threaded code that does not need locking. + + + +_S_mutex +Indicates multi-threaded code using thread-layer abstractions. + + +_S_atomic +Indicates multi-threaded code using atomic operations. + + + + +The compile-time constant __default_lock_policy is set +to one of the three values above, depending on characteristics of the +host environment and the current compilation flags. + + +Two more datatypes make up the rest of the +interface: __mutex, and __scoped_lock. + + + + + +The scoped lock idiom is well-discussed within the C++ +community. This version takes a __mutex reference, and +locks it during construction of __scoped_locke and +unlocks it during destruction. This is an efficient way of locking +critical sections, while retaining exception-safety. + + + + + Interface to Atomic Functions + + + +Two functions and one type form the base of atomic support. + + + +The type _Atomic_word is a signed integral type +supporting atomic operations. + + + +The two functions functions are: + + + +_Atomic_word +__exchange_and_add_dispatch(volatile _Atomic_word*, int); + +void +__atomic_add_dispatch(volatile _Atomic_word*, int); + + +Both of these functions are declared in the header file +<ext/atomicity.h>, and are in namespace __gnu_cxx. + + + + + +__exchange_and_add_dispatch + + +Adds the second argument's value to the first argument. Returns the old value. + + + + +__atomic_add_dispatch + + +Adds the second argument's value to the first argument. Has no return value. + + + + + +These functions forward to one of several specialized helper +functions, depending on the circumstances. For instance, + + + + +__exchange_and_add_dispatch + + + + +Calls through to either of: + + + +__exchange_and_add + +Multi-thread version. Inlined if compiler-generated builtin atomics +can be used, otherwise resolved at link time to a non-builtin code +sequence. + + + +__exchange_and_add_single + +Single threaded version. Inlined. + + + +However, only __exchange_and_add_dispatch +and __atomic_add_dispatch should be used. These functions +can be used in a portable manner, regardless of the specific +environment. They are carefully designed to provide optimum efficiency +and speed, abstracting out atomic accesses when they are not required +(even on hosts that support compiler intrinsics for atomic +operations.) + + + +In addition, there are two macros + + + + +_GLIBCXX_READ_MEM_BARRIER + + + + +_GLIBCXX_WRITE_MEM_BARRIER + + + + +Which expand to the appropriate write and read barrier required by the +host hardware and operating system. + + + + + + + + Implementation + + Using Builitin Atomic Functions + +The functions for atomic operations described above are either +implemented via compiler intrinsics (if the underlying host is +capable) or by library fallbacks. + +Compiler intrinsics (builtins) are always preferred. However, as +the compiler builtins for atomics are not universally implemented, +using them directly is problematic, and can result in undefined +function calls. (An example of an undefined symbol from the use +of __sync_fetch_and_add on an unsupported host is a +missing reference to __sync_fetch_and_add_4.) + + +In addition, on some hosts the compiler intrinsics are enabled +conditionally, via the -march command line flag. This makes +usage vary depending on the target hardware and the flags used during +compile. + + + If builtins are possible, _GLIBCXX_ATOMIC_BUILTINS +will be defined. + + + +For the following hosts, intrinsics are enabled by default. + + + + alpha + ia64 + powerpc + s390 + + +For others, some form of -march may work. On +non-ancient x86 hardware, -march=native usually does the +trick. + + For hosts without compiler intrinsics, but with capable +hardware, hand-crafted assembly is selected. This is the case for the following hosts: + + + + cris + hppa + i386 + i486 + m48k + mips + sparc + + +And for the rest, a simulated atomic lock via pthreads. + + + Detailed information about compiler intrinsics for atomic operations can be found in the GCC documentation. + + + More details on the library fallbacks from the porting section. + + + + + + Thread Abstraction + +A thin layer above IEEE 1003.1 (ie pthreads) is used to abstract +the thread interface for GCC. This layer is called "gthread," and is +comprised of one header file that wraps the host's default thread layer with +a POSIX-like interface. + + + The file <gthr-default.h> points to the deduced wrapper for +the current host. In libstdc++ implementation files, +<bits/gthr.h> is used to select the proper gthreads file. + + +Within libstdc++ sources, all calls to underlying thread functionality +use this layer. More detail as to the specific interface can be found in the source documentation. + + +By design, the gthread layer is interoperable with the types, +functions, and usage found in the usual <pthread.h> file, +including pthread_t, pthread_once_t, pthread_create, +etc. + + + + + + + + Use + +Typical usage of the last two constructs is demonstrated as follows: + + + +#include <ext/concurrence.h> + +namespace +{ + __gnu_cxx::__mutex safe_base_mutex; +} // anonymous namespace + +namespace other +{ + void + foo() + { + __gnu_cxx::__scoped_lock sentry(safe_base_mutex); + for (int i = 0; i < max; ++i) + { + _Safe_iterator_base* __old = __iter; + __iter = __iter-<_M_next; + __old-<_M_detach_single(); + } +} + + +In this sample code, an anonymous namespace is used to keep +the __mutex private to the compilation unit, +and __scoped_lock is used to guard access to the critical +section within the for loop, locking the mutex on creation and freeing +the mutex as control moves out of this block. + + +Several exception classes are used to keep track of +concurrence-related errors. These classes +are: __concurrence_lock_error, __concurrence_unlock_error, __concurrence_wait_error, +and __concurrence_broadcast_error. + + + + + + diff --git a/libstdc++-v3/doc/xml/manual/configure.xml b/libstdc++-v3/doc/xml/manual/configure.xml new file mode 100644 index 00000000000..a47635cd029 --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/configure.xml @@ -0,0 +1,318 @@ + + + + + + + ISO C++ + + + configure + + + options + + + + +Configure + + + Here are some of the non-obvious options to libstdc++'s configure. + Keep in mind that + + they + all have opposite forms as well + (enable/disable and with/without). The defaults are for current + development sources, which may be different than those for + released versions. + +The canonical way to find out the configure options that are + available for a given set of libstdc++ sources is to go to the + source directory and then type: ./configure --help + + + + --enable-multilib[default] + This is part of the generic multilib support for building cross + compilers. As such, targets like "powerpc-elf" will have + libstdc++ built many different ways: "-msoft-float" + and not, etc. A different libstdc++ will be built for each of + the different multilib versions. This option is on by default. + + + + --enable-sjlj-exceptions + Forces old, set-jump/long-jump exception handling model. If + at all possible, the new, frame unwinding exception handling routines + should be used instead, as they significantly reduce both + runtime memory usage and executable size. This option can + change the library ABI. + + + + --enable-version-specific-runtime-libs + Specify that run-time libraries should be installed in the + compiler-specific subdirectory (i.e., + ${libdir}/gcc-lib/${target_alias}/${gcc_version}) + instead of ${libdir}. This option is useful if you + intend to use several versions of gcc in parallel. In addition, + libstdc++'s include files will be installed in + ${libdir}/gcc-lib/${target_alias}/${gcc_version}/include/g++, + unless you also specify + --with-gxx-include-dir=dirname during configuration. + + + + --with-gxx-include-dir=<include-files dir> + Adds support for named libstdc++ include directory. For instance, + the following puts all the libstdc++ headers into a directory + called "2.97-20001008" instead of the usual + "c++/(version)". + + + --with-gxx-include-dir=/foo/H-x86-gcc-3-c-gxx-inc/include/2.97-20001008 + + --enable-cstdio + This is an abbreviated form of '--enable-cstdio=stdio' + (described next). This option can change the library ABI. + + + + --enable-cstdio=OPTION + Select a target-specific I/O package. At the moment, the only + choice is to use 'stdio', a generic "C" abstraction. + The default is 'stdio'. + + + + --enable-clocale + This is an abbreviated form of '--enable-clocale=generic' + (described next). This option can change the library ABI. + + + + --enable-clocale=OPTION + Select a target-specific underlying locale package. The + choices are 'ieee_1003.1-2001' to specify an X/Open, Standard Unix + (IEEE Std. 1003.1-2001) model based on langinfo/iconv/catgets, + 'gnu' to specify a model based on functionality from the GNU C + library (langinfo/iconv/gettext) (from glibc, the GNU C + library), or 'generic' to use a generic "C" + abstraction which consists of "C" locale info. + + + As part of the configuration process, the "C" library is + probed both for sufficient vintage, and installed locale + data. If either of these elements are not present, the C++ + locale model default to 'generic.' On glibc-based systems of + version 2.2.5 and above with installed locale files, 'gnu' is + automatically selected. + + + + --enable-libstdcxx-allocator + This is an abbreviated form of + '--enable-libstdcxx-allocator=auto' (described + next). This option can change the library ABI. + + + + --enable-libstdcxx-allocator=OPTION + Select a target-specific underlying std::allocator. The + choices are 'new' to specify a wrapper for new, 'malloc' to + specify a wrapper for malloc, 'mt' for a fixed power of two allocator + (documented under extensions), + 'pool' for the SGI pooled allocator or 'bitmap' for a bitmap allocator. + This option can change the library ABI. + + + + --enable-cheaders=OPTION + This allows the user to define the approach taken for C header + compatibility with C++. Options are c, c_std, and c_global. + These correspond to the source directory's include/c, + include/c_std, and include/c_global, and may also include + include/c_compatibility. The default is c_global. + + + + --enable-threads + This is an abbreviated form of '--enable-threads=yes' + (described next). This option can change the library ABI. + + + + --enable-threads=OPTION + Select a threading library. A full description is given in the + general compiler + configuration instructions. + + + + --enable-libstdcxx-debug + Build separate debug libraries in addition to what is normally built. + By default, the debug libraries are compiled with + CXXFLAGS='-g3 -O0' + , are installed in ${libdir}/debug, and have the + same names and versioning information as the non-debug + libraries. This option is off by default. + + Note this make command, executed in + the build directory, will do much the same thing, without the + configuration difference and without building everything twice: + make CXXFLAGS='-g3 -O0' all + + + + --enable-libstdcxx-debug-flags=FLAGS + + This option is only valid when --enable-debug + is also specified, and applies to the debug builds only. With + this option, you can pass a specific string of flags to the + compiler to use when building the debug versions of libstdc++. + FLAGS is a quoted string of options, like + + + --enable-libstdcxx-debug-flags='-g3 -O1 -gdwarf-2' + + + --enable-cxx-flags=FLAGS + With this option, you can pass a string of -f (functionality) + flags to the compiler to use when building libstdc++. This + option can change the library ABI. FLAGS is a quoted string of + options, like + + + --enable-cxx-flags='-fvtable-gc -fomit-frame-pointer -ansi' + + Note that the flags don't necessarily have to all be -f flags, + as shown, but usually those are the ones that will make sense + for experimentation and configure-time overriding. + + The advantage of --enable-cxx-flags over setting CXXFLAGS in + the 'make' environment is that, if files are automatically + rebuilt, the same flags will be used when compiling those files + as well, so that everything matches. + + Fun flags to try might include combinations of + + + -fstrict-aliasing + -fno-exceptions + -ffunction-sections + -fvtable-gc + and opposite forms (-fno-) of the same. Tell us (the libstdc++ + mailing list) if you discover more! + + + + --enable-c99 + The "long long" type was introduced in C99, along + with many other functions for wide characters, and math + classification macros, etc. If enabled, all C99 functions not + specified by the C++ standard will be put into namespace + __gnu_cxx, and then all these names will + be injected into namespace std, so that C99 functions can be + used "as if" they were in the C++ standard (as they + will eventually be in some future revision of the standard, + without a doubt). By default, C99 support is on, assuming the + configure probes find all the necessary functions and bits + necessary. This option can change the library ABI. + + + + --enable-wchar_t[default] + Template specializations for the "wchar_t" type are + required for wide character conversion support. Disabling + wide character specializations may be expedient for initial + porting efforts, but builds only a subset of what is required by + ISO, and is not recommended. By default, this option is on. + This option can change the library ABI. + + + + --enable-long-long + The "long long" type was introduced in C99. It is + provided as a GNU extension to C++98 in g++. This flag builds + support for "long long" into the library (specialized + templates and the like for iostreams). This option is on by default: + if enabled, users will have to either use the new-style "C" + headers by default (i.e., <cmath> not <math.h>) + or add appropriate compile-time flags to all compile lines to + allow "C" visibility of this feature (on GNU/Linux, + the flag is -D_ISOC99_SOURCE, which is added automatically via + CPLUSPLUS_CPP_SPEC's addition of _GNU_SOURCE). + This option can change the library ABI. + + + + --enable-fully-dynamic-string + This option enables a special version of basic_string avoiding + the optimization that allocates empty objects in static memory. + Mostly useful together with shared memory allocators, see PR + libstdc++/16612 for details. + + + + --enable-concept-checks + This turns on additional compile-time checks for instantiated + library templates, in the form of specialized templates, + described here. They + can help users discover when they break the rules of the STL, before + their programs run. + + + + --enable-symvers[=style] + + In 3.1 and later, tries to turn on symbol versioning in the + shared library (if a shared library has been + requested). Values for 'style' that are currently supported + are 'gnu', 'gnu-versioned-namespace', 'darwin', and + 'darwin-export'. Both gnu- options require that a recent + version of the GNU linker be in use. Both darwin options are + equivalent. With no style given, the configure script will try + to guess correct defaults for the host system, probe to see if + additional requirements are necessary and present for + activation, and if so, will turn symbol versioning on. This + option can change the library ABI. + + + + + --enable-visibility + In 4.2 and later, enables or disables visibility attributes. + If enabled (as by default), and the compiler seems capable of + passing the simple sanity checks thrown at it, adjusts items + in namespace std, namespace std::tr1, and namespace __gnu_cxx + so that -fvisibility options work. + + + + --enable-libstdcxx-pch + In 3.4 and later, tries to turn on the generation of + stdc++.h.gch, a pre-compiled file including all the standard + C++ includes. If enabled (as by default), and the compiler + seems capable of passing the simple sanity checks thrown at + it, try to build stdc++.h.gch as part of the make process. + In addition, this generated file is used later on (by appending + --include bits/stdc++.h to CXXFLAGS) when running the + testsuite. + + + + --disable-hosted-libstdcxx + + + By default, a complete hosted C++ library is + built. The C++ Standard also describes a + freestanding environment, in which only a + minimal set of headers are provided. This option builds such an + environment. + + + + + + \ No newline at end of file diff --git a/libstdc++-v3/doc/xml/manual/containers.xml b/libstdc++-v3/doc/xml/manual/containers.xml new file mode 100644 index 00000000000..a13d52734a4 --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/containers.xml @@ -0,0 +1,441 @@ + + + + + + + + + + ISO C++ + + + library + + + + +Containers + + + + Sequences + + + list + + list::size() is O(n) + + Yes it is, and that's okay. This is a decision that we preserved + when we imported SGI's STL implementation. The following is + quoted from their FAQ: + +
+ + The size() member function, for list and slist, takes time + proportional to the number of elements in the list. This was a + deliberate tradeoff. The only way to get a constant-time + size() for linked lists would be to maintain an extra member + variable containing the list's size. This would require taking + extra time to update that variable (it would make splice() a + linear time operation, for example), and it would also make the + list larger. Many list algorithms don't require that extra + word (algorithms that do require it might do better with + vectors than with lists), and, when it is necessary to maintain + an explicit size count, it's something that users can do + themselves. + + + This choice is permitted by the C++ standard. The standard says + that size() should be constant time, and + should does not mean the same thing as + shall. This is the officially recommended ISO + wording for saying that an implementation is supposed to do + something unless there is a good reason not to. + + + One implication of linear time size(): you should never write + + + if (L.size() == 0) + ... + + + + Instead, you should write + + + + if (L.empty()) + ... + +
+ + + + + vector + + + + Space Overhead Management + + In this + message to the list, Daniel Kostecky announced work on an + alternate form of std::vector that would support + hints on the number of elements to be over-allocated. The design + was also described, along with possible implementation choices. + + + The first two alpha releases were announced here + and here. + The releases themselves are available at + + http://www.kotelna.sk/dk/sw/caphint/. + + + + + + + + Associative + + + Insertion Hints + + Section [23.1.2], Table 69, of the C++ standard lists this + function for all of the associative containers (map, set, etc): + + + a.insert(p,t); + + + where 'p' is an iterator into the container 'a', and 't' is the + item to insert. The standard says that t is + inserted as close as possible to the position just prior to + p. (Library DR #233 addresses this topic, + referring to N1780. + Since version 4.2 GCC implements the resolution to DR 233, so + that insertions happen as close as possible to the hint. For + earlier releases the hint was only used as described below. + + + Here we'll describe how the hinting works in the libstdc++ + implementation, and what you need to do in order to take + advantage of it. (Insertions can change from logarithmic + complexity to amortized constant time, if the hint is properly + used.) Also, since the current implementation is based on the + SGI STL one, these points may hold true for other library + implementations also, since the HP/SGI code is used in a lot of + places. + + + In the following text, the phrases greater + than and less than refer to the + results of the strict weak ordering imposed on the container by + its comparison object, which defaults to (basically) + <. Using those phrases is semantically sloppy, + but I didn't want to get bogged down in syntax. I assume that if + you are intelligent enough to use your own comparison objects, + you are also intelligent enough to assign greater + and lesser their new meanings in the next + paragraph. *grin* + + + If the hint parameter ('p' above) is equivalent to: + + + + + begin(), then the item being inserted should + have a key less than all the other keys in the container. + The item will be inserted at the beginning of the container, + becoming the new entry at begin(). + + + + + end(), then the item being inserted should have + a key greater than all the other keys in the container. The + item will be inserted at the end of the container, becoming + the new entry at end(). + + + + + neither begin() nor end(), then: + Let h be the entry in the container pointed to + by hint, that is, h = *hint. Then + the item being inserted should have a key less than that of + h, and greater than that of the item preceding + h. The new item will be inserted between + h and h's predecessor. + + + + + For multimap and multiset, the + restrictions are slightly looser: greater than + should be replaced by not less thanand less + than should be replaced by not greater + than. (Why not replace greater with + greater-than-or-equal-to? You probably could in your head, but + the mathematicians will tell you that it isn't the same thing.) + + + If the conditions are not met, then the hint is not used, and the + insertion proceeds as if you had called a.insert(t) + instead. (Note that GCC releases + prior to 3.0.2 had a bug in the case with hint == + begin() for the map and set + classes. You should not use a hint argument in those releases.) + + + This behavior goes well with other containers' + insert() functions which take an iterator: if used, + the new item will be inserted before the iterator passed as an + argument, same as the other containers. + + + Note also that the hint in this + implementation is a one-shot. The older insertion-with-hint + routines check the immediately surrounding entries to ensure that + the new item would in fact belong there. If the hint does not + point to the correct place, then no further local searching is + done; the search begins from scratch in logarithmic time. + + + + + + bitset + + Size Variable + + No, you cannot write code of the form + + + + #include <bitset> + + void foo (size_t n) + { + std::bitset<n> bits; + .... + } + + + because n must be known at compile time. Your + compiler is correct; it is not a bug. That's the way templates + work. (Yes, it is a feature.) + + + There are a couple of ways to handle this kind of thing. Please + consider all of them before passing judgement. They include, in + no particular order: + + + A very large N in bitset<N>. + A container<bool>. + Extremely weird solutions. + + + A very large N in + bitset<N>.   It has been + pointed out a few times in newsgroups that N bits only takes up + (N/8) bytes on most systems, and division by a factor of eight is + pretty impressive when speaking of memory. Half a megabyte given + over to a bitset (recall that there is zero space overhead for + housekeeping info; it is known at compile time exactly how large + the set is) will hold over four million bits. If you're using + those bits as status flags (e.g., + changed/unchanged flags), that's a + lot of state. + + + You can then keep track of the maximum bit used + during some testing runs on representative data, make note of how + many of those bits really need to be there, and then reduce N to + a smaller number. Leave some extra space, of course. (If you + plan to write code like the incorrect example above, where the + bitset is a local variable, then you may have to talk your + compiler into allowing that much stack space; there may be zero + space overhead, but it's all allocated inside the object.) + + + A container<bool>.   The + Committee made provision for the space savings possible with that + (N/8) usage previously mentioned, so that you don't have to do + wasteful things like Container<char> or + Container<short int>. Specifically, + vector<bool> is required to be specialized for + that space savings. + + + The problem is that vector<bool> doesn't + behave like a normal vector anymore. There have been recent + journal articles which discuss the problems (the ones by Herb + Sutter in the May and July/August 1999 issues of C++ Report cover + it well). Future revisions of the ISO C++ Standard will change + the requirement for vector<bool> + specialization. In the meantime, deque<bool> + is recommended (although its behavior is sane, you probably will + not get the space savings, but the allocation scheme is different + than that of vector). + + + Extremely weird solutions.   If + you have access to the compiler and linker at runtime, you can do + something insane, like figuring out just how many bits you need, + then writing a temporary source code file. That file contains an + instantiation of bitset for the required number of + bits, inside some wrapper functions with unchanging signatures. + Have your program then call the compiler on that file using + Position Independent Code, then open the newly-created object + file and load those wrapper functions. You'll have an + instantiation of bitset<N> for the exact + N that you need at the time. Don't forget to delete + the temporary files. (Yes, this can be, and + has been, done.) + + + + This would be the approach of either a visionary genius or a + raving lunatic, depending on your programming and management + style. Probably the latter. + + + Which of the above techniques you use, if any, are up to you and + your intended application. Some time/space profiling is + indicated if it really matters (don't just guess). And, if you + manage to do anything along the lines of the third category, the + author would love to hear from you... + + + Also note that the implementation of bitset used in libstdc++ has + some extensions. + + + + + Type String + + + + Bitmasks do not take char* nor const char* arguments in their + constructors. This is something of an accident, but you can read + about the problem: follow the library's Links from + the homepage, and from the C++ information defect + reflector link, select the library issues list. Issue + number 116 describes the problem. + + + For now you can simply make a temporary string object using the + constructor expression: + + + std::bitset<5> b ( std::string(10110) ); + + + + instead of + + + + std::bitset<5> b ( 10110 ); // invalid + + + + + + + + + Interacting with C + + + Containers vs. Arrays + + You're writing some code and can't decide whether to use builtin + arrays or some kind of container. There are compelling reasons + to use one of the container classes, but you're afraid that + you'll eventually run into difficulties, change everything back + to arrays, and then have to change all the code that uses those + data types to keep up with the change. + + + If your code makes use of the standard algorithms, this isn't as + scary as it sounds. The algorithms don't know, nor care, about + the kind of container on which they work, since + the algorithms are only given endpoints to work with. For the + container classes, these are iterators (usually + begin() and end(), but not always). + For builtin arrays, these are the address of the first element + and the past-the-end element. + + + Some very simple wrapper functions can hide all of that from the + rest of the code. For example, a pair of functions called + beginof can be written, one that takes an array, + another that takes a vector. The first returns a pointer to the + first element, and the second returns the vector's + begin() iterator. + + + The functions should be made template functions, and should also + be declared inline. As pointed out in the comments in the code + below, this can lead to beginof being optimized out + of existence, so you pay absolutely nothing in terms of increased + code size or execution time. + + + The result is that if all your algorithm calls look like + + + std::transform(beginof(foo), endof(foo), beginof(foo), SomeFunction); + + + then the type of foo can change from an array of ints to a vector + of ints to a deque of ints and back again, without ever changing + any client code. + + + This author has a collection of such functions, called + *of because they all extend the builtin + sizeof. It started with some Usenet discussions + on a transparent way to find the length of an array. A + simplified and much-reduced version for easier reading is given here. + + + Astute readers will notice two things at once: first, that the + container class is still a vector<T> instead + of a more general Container<T>. This would + mean that three functions for deque would have to be + added, another three for list, and so on. This is + due to problems with getting template resolution correct; I find + it easier just to give the extra three lines and avoid confusion. + + + Second, the line + + + inline unsigned int lengthof (T (&)[sz]) { return sz; } + + + looks just weird! Hint: unused parameters can be left nameless. + + + + + + diff --git a/libstdc++-v3/doc/xml/manual/ctype.xml b/libstdc++-v3/doc/xml/manual/ctype.xml new file mode 100644 index 00000000000..8ecd7b9c3d2 --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/ctype.xml @@ -0,0 +1,259 @@ + + + + + + + ISO C++ + + + ctype + + + + +ctype + + +Implementation + + + Specializations + + +For the required specialization codecvt<wchar_t, char, mbstate_t> , +conversions are made between the internal character set (always UCS4 +on GNU/Linux) and whatever the currently selected locale for the +LC_CTYPE category implements. + + + +The two required specializations are implemented as follows: + + + + +ctype<char> + + + +This is simple specialization. Implementing this was a piece of cake. + + + + +ctype<wchar_t> + + + +This specialization, by specifying all the template parameters, pretty +much ties the hands of implementors. As such, the implementation is +straightforward, involving mcsrtombs for the conversions between char +to wchar_t and wcsrtombs for conversions between wchar_t and char. + + + +Neither of these two required specializations deals with Unicode +characters. + + + + + + +Future + + + + + + How to deal with the global locale issue? + + + + + How to deal with different types than char, wchar_t? + + + Overlap between codecvt/ctype: narrow/widen + + + + + Mask typedef in codecvt_base, argument types in codecvt. what + is know about this type? + + + + + Why mask* argument in codecvt? + + + + + Can this be made (more) generic? is there a simple way to + straighten out the configure-time mess that is a by-product of + this class? + + + + + Get the ctype<wchar_t>::mask stuff under control. Need to + make some kind of static table, and not do lookup evertime + somebody hits the do_is... functions. Too bad we can't just + redefine mask for ctype<wchar_t> + + + + + Rename abstract base class. See if just smash-overriding is a + better approach. Clarify, add sanity to naming. + + + + + + + + + + +Bibliography + + + + The GNU C Library + + + + McGrath + Roland + + + Drepper + Ulrich + + + + 2007 + FSF + + Chapters 6 Character Set Handling and 7 Locales and Internationalization + + + + + + Correspondence + + + + Drepper + Ulrich + + + + 2002 + + + + + + + ISO/IEC 14882:1998 Programming languages - C++ + + + + 1998 + ISO + + + + + + ISO/IEC 9899:1999 Programming languages - C + + + + 1999 + ISO + + + + + + System Interface Definitions, Issue 6 (IEEE Std. 1003.1-200x) + + + + 1999 + + The Open Group/The Institute of Electrical and Electronics Engineers, Inc. + + + + + + + + + + + + The C++ Programming Language, Special Edition + + + + Stroustrup + Bjarne + + + + 2000 + Addison Wesley, Inc. + + Appendix D + + + + Addison Wesley + + + + + + + + + Standard C++ IOStreams and Locales + + + Advanced Programmer's Guide and Reference + + + + Langer + Angelika + + + + Kreft + Klaus + + + + 2000 + Addison Wesley Longman, Inc. + + + + + Addison Wesley Longman + + + + + + + + \ No newline at end of file diff --git a/libstdc++-v3/doc/xml/manual/debug.xml b/libstdc++-v3/doc/xml/manual/debug.xml new file mode 100644 index 00000000000..b52a2469161 --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/debug.xml @@ -0,0 +1,245 @@ + + + + + + + C++ + + + debug + + + + +Debugging Support + + + There are numerous things that can be done to improve the ease with + which C++ binaries are debugged when using the GNU tool chain. Here + are some of them. + + + +Using <command>g++</command> + + Compiler flags determine how debug information is transmitted + between compilation and debug or analysis tools. + + + + The default optimizations and debug flags for a libstdc++ build + are -g -O2. However, both debug and optimization + flags can be varied to change debugging characteristics. For + instance, turning off all optimization via the -g -O0 + flag will disable inlining, so that stepping through all + functions, including inlined constructors and destructors, is + possible. In addition, + -fno-eliminate-unused-debug-types can be used when + additional debug information, such as nested class info, is + desired. + + + + Or, the debug format that the compiler and debugger use to + communicate information about source constructs can be changed via + -gdwarf-2 or -gstabs flags: some + debugging formats permit more expressive type and scope information + to be shown in gdb. The default debug information for a particular + platform can be identified via the value set by the + PREFERRED_DEBUGGING_TYPE macro in the gcc sources. + + + + Many other options are available: please see "Options + for Debugging Your Program" in Using the GNU Compiler + Collection (GCC) for a complete list. + + + + +Debug Versions of Library Binary Files + + + If you would like debug symbols in libstdc++, there are two ways to + build libstdc++ with debug flags. The first is to run make from the + toplevel in a freshly-configured tree with + + + --enable-libstdcxx-debug + +and perhaps + + --enable-libstdcxx-debug-flags='...' + + + to create a separate debug build. Both the normal build and the + debug build will persist, without having to specify + CXXFLAGS, and the debug library will be installed in a + separate directory tree, in (prefix)/lib/debug. For + more information, look at the configuration options document. + + + + A second approach is to use the configuration flags + + + make CXXFLAGS='-g3 -O0' all + + + + This quick and dirty approach is often sufficient for quick + debugging tasks, when you cannot or don't want to recompile your + application to use the debug mode. + + + +Memory Leak Hunting + + + There are various third party memory tracing and debug utilities + that can be used to provide detailed memory allocation information + about C++ code. An exhaustive list of tools is not going to be + attempted, but includes mtrace, valgrind, + mudflap, and the non-free commercial product + purify. In addition, libcwd has a + replacement for the global new and delete operators that can track + memory allocation and deallocation and provide useful memory + statistics. + + + + Regardless of the memory debugging tool being used, there is one + thing of great importance to keep in mind when debugging C++ code + that uses new and delete: there are + different kinds of allocation schemes that can be used by + std::allocator . For implementation details, see the mt allocator documentation and + look specifically for GLIBCXX_FORCE_NEW. + + + + In a nutshell, the default allocator used by + std::allocator is a high-performance pool allocator, and can + give the mistaken impression that in a suspect executable, memory is + being leaked, when in reality the memory "leak" is a pool being used + by the library's allocator and is reclaimed after program + termination. + + + + For valgrind, there are some specific items to keep in mind. First + of all, use a version of valgrind that will work with current GNU + C++ tools: the first that can do this is valgrind 1.0.4, but later + versions should work at least as well. Second of all, use a + completely unoptimized build to avoid confusing valgrind. Third, use + GLIBCXX_FORCE_NEW to keep extraneous pool allocation noise from + cluttering debug information. + + + + Fourth, it may be necessary to force deallocation in other libraries + as well, namely the "C" library. On linux, this can be accomplished + with the appropriate use of the __cxa_atexit or + atexit functions. + + + + #include <cstdlib> + + extern "C" void __libc_freeres(void); + + void do_something() { } + + int main() + { + atexit(__libc_freeres); + do_something(); + return 0; + } + + + +or, using __cxa_atexit: + + + extern "C" void __libc_freeres(void); + extern "C" int __cxa_atexit(void (*func) (void *), void *arg, void *d); + + void do_something() { } + + int main() + { + extern void* __dso_handle __attribute__ ((__weak__)); + __cxa_atexit((void (*) (void *)) __libc_freeres, NULL, + &__dso_handle ? __dso_handle : NULL); + do_test(); + return 0; + } + + + + Suggested valgrind flags, given the suggestions above about setting + up the runtime environment, library, and test file, might be: + + + valgrind -v --num-callers=20 --leak-check=yes --leak-resolution=high --show-reachable=yes a.out + + + + + +Using <command>gdb</command> + + + + + Many options are available for gdb itself: please see + "GDB features for C++" in the gdb documentation. Also + recommended: the other parts of this manual. + + + + These settings can either be switched on in at the gdb command line, + or put into a .gdbint file to establish default debugging + characteristics, like so: + + + + set print pretty on + set print object on + set print static-members on + set print vtbl on + set print demangle on + set demangle-style gnu-v3 + + + + +Tracking uncaught exceptions + + The verbose + termination handler gives information about uncaught + exceptions which are killing the program. It is described in the + linked-to page. + + + + +Debug Mode + The Debug Mode + has compile and run-time checks for many containers. + + + + +Compile Time Checking + The Compile-Time + Checks Extension has compile-time checks for many algorithms. + + + + \ No newline at end of file diff --git a/libstdc++-v3/doc/xml/manual/debug_mode.xml b/libstdc++-v3/doc/xml/manual/debug_mode.xml new file mode 100644 index 00000000000..e5f3becd590 --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/debug_mode.xml @@ -0,0 +1,888 @@ + + + + + + + + + + C++ + + + library + + + debug + + + + +Debug Mode + + + Intro + + By default, libstdc++ is built with efficiency in mind, and + therefore performs little or no error checking that is not + required by the C++ standard. This means that programs that + incorrectly use the C++ standard library will exhibit behavior + that is not portable and may not even be predictable, because they + tread into implementation-specific or undefined behavior. To + detect some of these errors before they can become problematic, + libstdc++ offers a debug mode that provides additional checking of + library facilities, and will report errors in the use of libstdc++ + as soon as they can be detected by emitting a description of the + problem to standard error and aborting the program. This debug + mode is available with GCC 3.4.0 and later versions. + + + + The libstdc++ debug mode performs checking for many areas of the + C++ standard, but the focus is on checking interactions among + standard iterators, containers, and algorithms, including: + + + + Safe iterators: Iterators keep track of the + container whose elements they reference, so errors such as + incrementing a past-the-end iterator or dereferencing an iterator + that points to a container that has been destructed are diagnosed + immediately. + + Algorithm preconditions: Algorithms attempt to + validate their input parameters to detect errors as early as + possible. For instance, the set_intersection + algorithm requires that its iterator + parameters first1 and last1 form a valid + iterator range, and that the sequence + [first1, last1) is sorted according to + the same predicate that was passed + to set_intersection; the libstdc++ debug mode will + detect an error if the sequence is not sorted or was sorted by a + different predicate. + + + + + + Semantics + + + +A program that uses the C++ standard library correctly + will maintain the same semantics under debug mode as it had with + the normal (release) library. All functional and exception-handling + guarantees made by the normal library also hold for the debug mode + library, with one exception: performance guarantees made by the + normal library may not hold in the debug mode library. For + instance, erasing an element in a std::list is a + constant-time operation in normal library, but in debug mode it is + linear in the number of iterators that reference that particular + list. So while your (correct) program won't change its results, it + is likely to execute more slowly. + +libstdc++ includes many extensions to the C++ standard library. In + some cases the extensions are obvious, such as the hashed + associative containers, whereas other extensions give predictable + results to behavior that would otherwise be undefined, such as + throwing an exception when a std::basic_string is + constructed from a NULL character pointer. This latter category also + includes implementation-defined and unspecified semantics, such as + the growth rate of a vector. Use of these extensions is not + considered incorrect, so code that relies on them will not be + rejected by debug mode. However, use of these extensions may affect + the portability of code to other implementations of the C++ standard + library, and is therefore somewhat hazardous. For this reason, the + libstdc++ debug mode offers a "pedantic" mode (similar to + GCC's -pedantic compiler flag) that attempts to emulate + the semantics guaranteed by the C++ standard. For + instance, constructing a std::basic_string with a NULL + character pointer would result in an exception under normal mode or + non-pedantic debug mode (this is a libstdc++ extension), whereas + under pedantic debug mode libstdc++ would signal an error. To enable + the pedantic debug mode, compile your program with + both -D_GLIBCXX_DEBUG + and -D_GLIBCXX_DEBUG_PEDANTIC . + (N.B. In GCC 3.4.x and 4.0.0, due to a bug, + -D_GLIBXX_DEBUG_PEDANTIC was also needed. The problem has + been fixed in GCC 4.0.1 and later versions.) + +The following library components provide extra debugging + capabilities in debug mode: + + std::basic_string (no safe iterators and see note below) + std::bitset + std::deque + std::list + std::map + std::multimap + std::multiset + std::set + std::vector + std::unordered_map + std::unordered_multimap + std::unordered_set + std::unordered_multiset + + +N.B. although there are precondition checks for some string operations, +e.g. operator[], +they will not always be run when using the char and +wchar_t specialisations (std::string and +std::wstring). This is because libstdc++ uses GCC's +extern template extension to provide explicit instantiations +of std::string and std::wstring, and those +explicit instantiations don't include the debug-mode checks. If the +containing functions are inlined then the checks will run, so compiling +with -O1 might be enough to enable them. Alternatively +-D_GLIBCXX_EXTERN_TEMPLATE=0 will suppress the declarations +of the explicit instantiations and cause the functions to be instantiated +with the debug-mode checks included, but this is unsupported and not +guaranteed to work. For full debug-mode support you can use the +__gnu_debug::basic_string debugging container directly, +which always works correctly. + + + + + + Using + + + + Using the Debug Mode + +To use the libstdc++ debug mode, compile your application with the + compiler flag -D_GLIBCXX_DEBUG. Note that this flag + changes the sizes and behavior of standard class templates such + as std::vector, and therefore you can only link code + compiled with debug mode and code compiled without debug mode if no + instantiation of a container is passed between the two translation + units. + +By default, error messages are formatted to fit on lines of about + 78 characters. The environment variable + GLIBCXX_DEBUG_MESSAGE_LENGTH can be used to request a + different length. + + + + + Using a Specific Debug Container +When it is not feasible to recompile your entire application, or + only specific containers need checking, debugging containers are + available as GNU extensions. These debugging containers are + functionally equivalent to the standard drop-in containers used in + debug mode, but they are available in a separate namespace as GNU + extensions and may be used in programs compiled with either release + mode or with debug mode. The + following table provides the names and headers of the debugging + containers: + + + +Debugging Containers + + + + + + + + + Container + Header + Debug container + Debug header + + + + + std::bitset + bitset + __gnu_debug::bitset + bitset + + + std::deque + deque + __gnu_debug::deque + deque + + + std::list + list + __gnu_debug::list + list + + + std::map + map + __gnu_debug::map + map + + + std::multimap + map + __gnu_debug::multimap + map + + + std::multiset + set + __gnu_debug::multiset + set + + + std::set + set + __gnu_debug::set + set + + + std::string + string + __gnu_debug::string + string + + + std::wstring + string + __gnu_debug::wstring + string + + + std::basic_string + string + __gnu_debug::basic_string + string + + + std::vector + vector + __gnu_debug::vector + vector + + + +
+ +In addition, when compiling in C++0x mode, these additional +containers have additional debug capability. + + + +Debugging Containers C++0x + + + + + + + + + Container + Header + Debug container + Debug header + + + + + std::unordered_map + unordered_map + __gnu_debug::unordered_map + unordered_map + + + std::unordered_multimap + unordered_map + __gnu_debug::unordered_multimap + unordered_map + + + std::unordered_set + unordered_set + __gnu_debug::unordered_set + unordered_set + + + std::unordered_multiset + unordered_set + __gnu_debug::unordered_multiset + unordered_set + + + +
+ + + + + Design + + + + Goals + + + The libstdc++ debug mode replaces unsafe (but efficient) standard + containers and iterators with semantically equivalent safe standard + containers and iterators to aid in debugging user programs. The + following goals directed the design of the libstdc++ debug mode: + + + + Correctness: the libstdc++ debug mode must not change + the semantics of the standard library for all cases specified in + the ANSI/ISO C++ standard. The essence of this constraint is that + any valid C++ program should behave in the same manner regardless + of whether it is compiled with debug mode or release mode. In + particular, entities that are defined in namespace std in release + mode should remain defined in namespace std in debug mode, so that + legal specializations of namespace std entities will remain + valid. A program that is not valid C++ (e.g., invokes undefined + behavior) is not required to behave similarly, although the debug + mode will abort with a diagnostic when it detects undefined + behavior. + + Performance: the additional of the libstdc++ debug mode + must not affect the performance of the library when it is compiled + in release mode. Performance of the libstdc++ debug mode is + secondary (and, in fact, will be worse than the release + mode). + + Usability: the libstdc++ debug mode should be easy to + use. It should be easily incorporated into the user's development + environment (e.g., by requiring only a single new compiler switch) + and should produce reasonable diagnostics when it detects a + problem with the user program. Usability also involves detection + of errors when using the debug mode incorrectly, e.g., by linking + a release-compiled object against a debug-compiled object if in + fact the resulting program will not run correctly. + + Minimize recompilation: While it is expected that + users recompile at least part of their program to use debug + mode, the amount of recompilation affects the + detect-compile-debug turnaround time. This indirectly affects the + usefulness of the debug mode, because debugging some applications + may require rebuilding a large amount of code, which may not be + feasible when the suspect code may be very localized. There are + several levels of conformance to this requirement, each with its + own usability and implementation characteristics. In general, the + higher-numbered conformance levels are more usable (i.e., require + less recompilation) but are more complicated to implement than + the lower-numbered conformance levels. + + Full recompilation: The user must recompile his or + her entire application and all C++ libraries it depends on, + including the C++ standard library that ships with the + compiler. This must be done even if only a small part of the + program can use debugging features. + + Full user recompilation: The user must recompile + his or her entire application and all C++ libraries it depends + on, but not the C++ standard library itself. This must be done + even if only a small part of the program can use debugging + features. This can be achieved given a full recompilation + system by compiling two versions of the standard library when + the compiler is installed and linking against the appropriate + one, e.g., a multilibs approach. + + Partial recompilation: The user must recompile the + parts of his or her application and the C++ libraries it + depends on that will use the debugging facilities + directly. This means that any code that uses the debuggable + standard containers would need to be recompiled, but code + that does not use them (but may, for instance, use IOStreams) + would not have to be recompiled. + + Per-use recompilation: The user must recompile the + parts of his or her application and the C++ libraries it + depends on where debugging should occur, and any other code + that interacts with those containers. This means that a set of + translation units that accesses a particular standard + container instance may either be compiled in release mode (no + checking) or debug mode (full checking), but must all be + compiled in the same way; a translation unit that does not see + that standard container instance need not be recompiled. This + also means that a translation unit A that contains a + particular instantiation + (say, std::vector<int>) compiled in release + mode can be linked against a translation unit B that + contains the same instantiation compiled in debug mode (a + feature not present with partial recompilation). While this + behavior is technically a violation of the One Definition + Rule, this ability tends to be very important in + practice. The libstdc++ debug mode supports this level of + recompilation. + + Per-unit recompilation: The user must only + recompile the translation units where checking should occur, + regardless of where debuggable standard containers are + used. This has also been dubbed "-g mode", + because the -g compiler switch works in this way, + emitting debugging information at a per--translation-unit + granularity. We believe that this level of recompilation is in + fact not possible if we intend to supply safe iterators, leave + the program semantics unchanged, and not regress in + performance under release mode because we cannot associate + extra information with an iterator (to form a safe iterator) + without either reserving that space in release mode + (performance regression) or allocating extra memory associated + with each iterator with new (changes the program + semantics). + + + + + + + Methods + + +This section provides an overall view of the design of the + libstdc++ debug mode and details the relationship between design + decisions and the stated design goals. + + + The Wrapper Model +The libstdc++ debug mode uses a wrapper model where the debugging + versions of library components (e.g., iterators and containers) form + a layer on top of the release versions of the library + components. The debugging components first verify that the operation + is correct (aborting with a diagnostic if an error is found) and + will then forward to the underlying release-mode container that will + perform the actual work. This design decision ensures that we cannot + regress release-mode performance (because the release-mode + containers are left untouched) and partially enables mixing debug and release code at link time, + although that will not be discussed at this time. + +Two types of wrappers are used in the implementation of the debug + mode: container wrappers and iterator wrappers. The two types of + wrappers interact to maintain relationships between iterators and + their associated containers, which are necessary to detect certain + types of standard library usage errors such as dereferencing + past-the-end iterators or inserting into a container using an + iterator from a different container. + + + Safe Iterators +Iterator wrappers provide a debugging layer over any iterator that + is attached to a particular container, and will manage the + information detailing the iterator's state (singular, + dereferenceable, etc.) and tracking the container to which the + iterator is attached. Because iterators have a well-defined, common + interface the iterator wrapper is implemented with the iterator + adaptor class template __gnu_debug::_Safe_iterator, + which takes two template parameters: + + + Iterator: The underlying iterator type, which must + be either the iterator or const_iterator + typedef from the sequence type this iterator can reference. + + Sequence: The type of sequence that this iterator + references. This sequence must be a safe sequence (discussed below) + whose iterator or const_iterator typedef + is the type of the safe iterator. + + + + + Safe Sequences (Containers) + +Container wrappers provide a debugging layer over a particular + container type. Because containers vary greatly in the member + functions they support and the semantics of those member functions + (especially in the area of iterator invalidation), container + wrappers are tailored to the container they reference, e.g., the + debugging version of std::list duplicates the entire + interface of std::list, adding additional semantic + checks and then forwarding operations to the + real std::list (a public base class of the debugging + version) as appropriate. However, all safe containers inherit from + the class template __gnu_debug::_Safe_sequence, + instantiated with the type of the safe container itself (an instance + of the curiously recurring template pattern). + +The iterators of a container wrapper will be + safe iterators that reference sequences + of this type and wrap the iterators provided by the release-mode + base class. The debugging container will use only the safe + iterators within its own interface (therefore requiring the user to + use safe iterators, although this does not change correct user + code) and will communicate with the release-mode base class with + only the underlying, unsafe, release-mode iterators that the base + class exports. + + The debugging version of std::list will have the + following basic structure: + + +template<typename _Tp, typename _Allocator = allocator<_Tp> + class debug-list : + public release-list<_Tp, _Allocator>, + public __gnu_debug::_Safe_sequence<debug-list<_Tp, _Allocator> > + { + typedef release-list<_Tp, _Allocator> _Base; + typedef debug-list<_Tp, _Allocator> _Self; + + public: + typedef __gnu_debug::_Safe_iterator<typename _Base::iterator, _Self> iterator; + typedef __gnu_debug::_Safe_iterator<typename _Base::const_iterator, _Self> const_iterator; + + // duplicate std::list interface with debugging semantics + }; + + + + + + Precondition Checking +The debug mode operates primarily by checking the preconditions of + all standard library operations that it supports. Preconditions that + are always checked (regardless of whether or not we are in debug + mode) are checked via the __check_xxx macros defined + and documented in the source + file include/debug/debug.h. Preconditions that may or + may not be checked, depending on the debug-mode + macro _GLIBCXX_DEBUG, are checked via + the __requires_xxx macros defined and documented in the + same source file. Preconditions are validated using any additional + information available at run-time, e.g., the containers that are + associated with a particular iterator, the position of the iterator + within those containers, the distance between two iterators that may + form a valid range, etc. In the absence of suitable information, + e.g., an input iterator that is not a safe iterator, these + precondition checks will silently succeed. + +The majority of precondition checks use the aforementioned macros, + which have the secondary benefit of having prewritten debug + messages that use information about the current status of the + objects involved (e.g., whether an iterator is singular or what + sequence it is attached to) along with some static information + (e.g., the names of the function parameters corresponding to the + objects involved). When not using these macros, the debug mode uses + either the debug-mode assertion + macro _GLIBCXX_DEBUG_ASSERT , its pedantic + cousin _GLIBCXX_DEBUG_PEDASSERT, or the assertion + check macro that supports more advance formulation of error + messages, _GLIBCXX_DEBUG_VERIFY. These macros are + documented more thoroughly in the debug mode source code. + + + + Release- and debug-mode coexistence +The libstdc++ debug mode is the first debug mode we know of that + is able to provide the "Per-use recompilation" (4) guarantee, that + allows release-compiled and debug-compiled code to be linked and + executed together without causing unpredictable behavior. This + guarantee minimizes the recompilation that users are required to + perform, shortening the detect-compile-debug bughunting cycle + and making the debug mode easier to incorporate into development + environments by minimizing dependencies. + +Achieving link- and run-time coexistence is not a trivial + implementation task. To achieve this goal we required a small + extension to the GNU C++ compiler (described in the GCC Manual for + C++ Extensions, see strong + using), and a complex organization of debug- and + release-modes. The end result is that we have achieved per-use + recompilation but have had to give up some checking of the + std::basic_string class template (namely, safe + iterators). + + + + Compile-time coexistence of release- and debug-mode components + +Both the release-mode components and the debug-mode + components need to exist within a single translation unit so that + the debug versions can wrap the release versions. However, only one + of these components should be user-visible at any particular + time with the standard name, e.g., std::list. + +In release mode, we define only the release-mode version of the + component with its standard name and do not include the debugging + component at all. The release mode version is defined within the + namespace std. Minus the namespace associations, this + method leaves the behavior of release mode completely unchanged from + its behavior prior to the introduction of the libstdc++ debug + mode. Here's an example of what this ends up looking like, in + C++. + + +namespace std +{ + template<typename _Tp, typename _Alloc = allocator<_Tp> > + class list + { + // ... + }; +} // namespace std + + +In debug mode we include the release-mode container (which is now +defined in in the namespace __norm) and also the +debug-mode container. The debug-mode container is defined within the +namespace __debug, which is associated with namespace +std via the GNU namespace association extension. This +method allows the debug and release versions of the same component to +coexist at compile-time and link-time without causing an unreasonable +maintenance burden, while minimizing confusion. Again, this boils down +to C++ code as follows: + + +namespace std +{ + namespace __norm + { + template<typename _Tp, typename _Alloc = allocator<_Tp> > + class list + { + // ... + }; + } // namespace __gnu_norm + + namespace __debug + { + template<typename _Tp, typename _Alloc = allocator<_Tp> > + class list + : public __norm::list<_Tp, _Alloc>, + public __gnu_debug::_Safe_sequence<list<_Tp, _Alloc> > + { + // ... + }; + } // namespace __norm + + using namespace __debug __attribute__ ((strong)); +} + + + + + Link- and run-time coexistence of release- and + debug-mode components + +Because each component has a distinct and separate release and +debug implementation, there are are no issues with link-time +coexistence: the separate namespaces result in different mangled +names, and thus unique linkage. + +However, components that are defined and used within the C++ +standard library itself face additional constraints. For instance, +some of the member functions of std::moneypunct return +std::basic_string. Normally, this is not a problem, but +with a mixed mode standard library that could be using either +debug-mode or release-mode basic_string objects, things +get more complicated. As the return value of a function is not +encoded into the mangled name, there is no way to specify a +release-mode or a debug-mode string. In practice, this results in +runtime errors. A simplified example of this problem is as follows. + + + Take this translation unit, compiled in debug-mode: + +// -D_GLIBCXX_DEBUG +#include <string> + +std::string test02(); + +std::string test01() +{ + return test02(); +} + +int main() +{ + test01(); + return 0; +} + + + ... and linked to this translation unit, compiled in release mode: + + +#include <string> + +std::string +test02() +{ + return std::string("toast"); +} + + + For this reason we cannot easily provide safe iterators for + the std::basic_string class template, as it is present + throughout the C++ standard library. For instance, locale facets + define typedefs that include basic_string: in a mixed + debug/release program, should that typedef be based on the + debug-mode basic_string or the + release-mode basic_string? While the answer could be + "both", and the difference hidden via renaming a la the + debug/release containers, we must note two things about locale + facets: + + + They exist as shared state: one can create a facet in one + translation unit and access the facet via the same type name in a + different translation unit. This means that we cannot have two + different versions of locale facets, because the types would not be + the same across debug/release-mode translation unit barriers. + + They have virtual functions returning strings: these functions + mangle in the same way regardless of the mangling of their return + types (see above), and their precise signatures can be relied upon + by users because they may be overridden in derived classes. + + +With the design of libstdc++ debug mode, we cannot effectively hide + the differences between debug and release-mode strings from the + user. Failure to hide the differences may result in unpredictable + behavior, and for this reason we have opted to only + perform basic_string changes that do not require ABI + changes. The effect on users is expected to be minimal, as there are + simple alternatives (e.g., __gnu_debug::basic_string), + and the usability benefit we gain from the ability to mix debug- and + release-compiled translation units is enormous. + + + +Alternatives for Coexistence + +The coexistence scheme above was chosen over many alternatives, + including language-only solutions and solutions that also required + extensions to the C++ front end. The following is a partial list of + solutions, with justifications for our rejection of each. + + + Completely separate debug/release libraries: This is by + far the simplest implementation option, where we do not allow any + coexistence of debug- and release-compiled translation units in a + program. This solution has an extreme negative affect on usability, + because it is quite likely that some libraries an application + depends on cannot be recompiled easily. This would not meet + our usability or minimize recompilation criteria + well. + + Add a Debug boolean template parameter: + Partial specialization could be used to select the debug + implementation when Debug == true, and the state + of _GLIBCXX_DEBUG could decide whether the + default Debug argument is true + or false. This option would break conformance with the + C++ standard in both debug and release modes. This would + not meet our correctness criteria. + + Packaging a debug flag in the allocators: We could + reuse the Allocator template parameter of containers + by adding a sentinel wrapper debug<> that + signals the user's intention to use debugging, and pick up + the debug<> allocator wrapper in a partial + specialization. However, this has two drawbacks: first, there is a + conformance issue because the default allocator would not be the + standard-specified std::allocator<T>. Secondly + (and more importantly), users that specify allocators instead of + implicitly using the default allocator would not get debugging + containers. Thus this solution fails the correctness + criteria. + + Define debug containers in another namespace, and employ + a using declaration (or directive): This is an + enticing option, because it would eliminate the need for + the link_name extension by aliasing the + templates. However, there is no true template aliasing mechanism + is C++, because both using directives and using + declarations disallow specialization. This method fails + the correctness criteria. + + Use implementation-specific properties of anonymous + namespaces. + See this post + + This method fails the correctness criteria. + + Extension: allow reopening on namespaces: This would + allow the debug mode to effectively alias the + namespace std to an internal namespace, such + as __gnu_std_debug, so that it is completely + separate from the release-mode std namespace. While + this will solve some renaming problems and ensure that + debug- and release-compiled code cannot be mixed unsafely, it ensures that + debug- and release-compiled code cannot be mixed at all. For + instance, the program would have two std::cout + objects! This solution would fails the minimize + recompilation requirement, because we would only be able to + support option (1) or (2). + + Extension: use link name: This option involves + complicated re-naming between debug-mode and release-mode + components at compile time, and then a g++ extension called + link name to recover the original names at link time. There + are two drawbacks to this approach. One, it's very verbose, + relying on macro renaming at compile time and several levels of + include ordering. Two, ODR issues remained with container member + functions taking no arguments in mixed-mode settings resulting in + equivalent link names, vector::push_back() being + one example. + See link + name + + +Other options may exist for implementing the debug mode, many of + which have probably been considered and others that may still be + lurking. This list may be expanded over time to include other + options that we could have implemented, but in all cases the full + ramifications of the approach (as measured against the design goals + for a libstdc++ debug mode) should be considered first. The DejaGNU + testsuite includes some testcases that check for known problems with + some solutions (e.g., the using declaration solution + that breaks user specialization), and additional testcases will be + added as we are able to identify other typical problem cases. These + test cases will serve as a benchmark by which we can compare debug + mode implementations. + + + + + + Other Implementations + + + There are several existing implementations of debug modes for C++ + standard library implementations, although none of them directly + supports debugging for programs using libstdc++. The existing + implementations include: + + SafeSTL: + SafeSTL was the original debugging version of the Standard Template + Library (STL), implemented by Cay S. Horstmann on top of the + Hewlett-Packard STL. Though it inspired much work in this area, it + has not been kept up-to-date for use with modern compilers or C++ + standard library implementations. + + STLport: STLport is a free + implementation of the C++ standard library derived from the SGI implementation, and + ported to many other platforms. It includes a debug mode that uses a + wrapper model (that in some way inspired the libstdc++ debug mode + design), although at the time of this writing the debug mode is + somewhat incomplete and meets only the "Full user recompilation" (2) + recompilation guarantee by requiring the user to link against a + different library in debug mode vs. release mode. + + Metrowerks + CodeWarrior: The C++ standard library that ships with Metrowerks + CodeWarrior includes a debug mode. It is a full debug-mode + implementation (including debugging for CodeWarrior extensions) and + is easy to use, although it meets only the "Full recompilation" (1) + recompilation guarantee. + + + + + + diff --git a/libstdc++-v3/doc/xml/manual/diagnostics.xml b/libstdc++-v3/doc/xml/manual/diagnostics.xml new file mode 100644 index 00000000000..f43614c861e --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/diagnostics.xml @@ -0,0 +1,126 @@ + + + + + + + + + + ISO C++ + + + library + + + + +Diagnostics + + + Exceptions + + + Exception Classes + + All exception objects are defined in one of the standard header + files: exception, + stdexcept, new, and + typeinfo. + + + + The base exception object is exception, + located in exception. This object has no + string member. + + + + Derived from this are several classes that may have a + string member: a full heirarchy can be + found in the source documentation. + + + + + Adding Data to Exceptions + + The standard exception classes carry with them a single string as + data (usually describing what went wrong or where the 'throw' took + place). It's good to remember that you can add your own data to + these exceptions when extending the hierarchy: + + + struct My_Exception : public std::runtime_error + { + public: + My_Exception (const string& whatarg) + : std::runtime_error(whatarg), e(errno), id(GetDataBaseID()) { } + int errno_at_time_of_throw() const { return e; } + DBID id_of_thing_that_threw() const { return id; } + protected: + int e; + DBID id; // some user-defined type + }; + + + + + Cancellation + + + + + + + Concept Checking + + In 1999, SGI added concept checkers to their + implementation of the STL: code which checked the template + parameters of instantiated pieces of the STL, in order to insure + that the parameters being used met the requirements of the + standard. For example, the Standard requires that types passed as + template parameters to vector be + "Assignable" (which means what you think it means). The + checking was done during compilation, and none of the code was + executed at runtime. + + + Unfortunately, the size of the compiler files grew significantly + as a result. The checking code itself was cumbersome. And bugs + were found in it on more than one occasion. + + + The primary author of the checking code, Jeremy Siek, had already + started work on a replacement implementation. The new code has been + formally reviewed and accepted into + the + Boost libraries, and we are pleased to incorporate it into the + GNU C++ library. + + + The new version imposes a much smaller space overhead on the generated + object file. The checks are also cleaner and easier to read and + understand. + + + + They are off by default for all versions of GCC. + They can be enabled at configure time with + --enable-concept-checks. + You can enable them on a per-translation-unit basis with + -D_GLIBCXX_CONCEPT_CHECKS. + + + + Please note that the upcoming C++ standard has first-class + support for template parameter constraints based on concepts in the core + language. This will obviate the need for the library-simulated concept + checking described above. + + + + + diff --git a/libstdc++-v3/doc/xml/manual/evolution.xml b/libstdc++-v3/doc/xml/manual/evolution.xml new file mode 100644 index 00000000000..296e228311a --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/evolution.xml @@ -0,0 +1,452 @@ + + + + + + ISO C++ + api + evolution + deprecation + history + + + +API Evolution and Deprecation History + + +A list of user-visible changes, in cronological order + + + +<constant>3.0</constant> + + +Extensions moved to include/ext. + + + +Include files from the SGI/HP sources that pre-date the ISO standard +are added. These files are placed into +the include/backward directory and a deprecated warning +is added that notifies on inclusion (-Wno-deprecated +deactivates the warning.) + + +Deprecated include backward/strstream added. + +Removal of include builtinbuf.h, indstream.h, parsestream.h, PlotFile.h, SFile.h, stdiostream.h, and stream.h. + + + + + + + +<constant>3.1</constant> + + + + +Extensions from SGI/HP moved from namespace std +to namespace __gnu_cxx. As part of this, the following +new includes are +added: ext/algorithm, ext/functional, ext/iterator, ext/memory, and ext/numeric. + + + +Extensions to basic_filebuf introduced: __gnu_cxx::enc_filebuf, and __gnu_cxx::stdio_filebuf. + + + +Extensions to tree data structures added in ext/rb_tree. + + + +Removal of ext/tree, moved to backward/tree.h. + + + + + +<constant>3.2</constant> + + +Symbol versioning introduced for shared library. + +Removal of include backward/strstream.h. + +Allocator changes. Change __malloc_alloc to malloc_allocator and __new_alloc to new_allocator. + + For GCC releases from 2.95 through the 3.1 series, defining + __USE_MALLOC on the gcc command line would change the + default allocation strategy to instead use malloc and + free. See + this note + for details as to why this was something needing improvement. + + + +Error handling in iostreams cleaned up, made consistent. + + + + + +<constant>3.3</constant> + + + + + +<constant>3.4</constant> + + + +Large file support. + + + Extensions for generic characters and char_traits added in ext/pod_char_traits.h. + + + +Support for wchar_t specializations of basic_filebuf enhanced to support UTF-8 and Unicode, depending on host. More hosts support basic wchar_t functionality. + + + +Support for char_traits beyond builtin types. + + + +Conformant allocator class and usage in containers. As +part of this, the following extensions are +added: ext/bitmap_allocator.h, ext/debug_allocator.h, ext/mt_allocator.h, ext/malloc_allocator.h,ext/new_allocator.h, ext/pool_allocator.h. + + + +This is a change from all previous versions, and may require +source-level changes due to allocator-related changes to structures +names and template parameters, filenames, and file locations. Some, +like __simple_alloc, __allocator, __alloc, and +_Alloc_traits have been removed. + + +Default behavior of std::allocator has changed. + + + Previous versions prior to 3.4 cache allocations in a memory + pool, instead of passing through to call the global allocation + operators (ie, __gnu_cxx::pool_allocator). More + recent versions default to the + simpler __gnu_cxx::new_allocator. + + + Previously, all allocators were written to the SGI + style, and all STL containers expected this interface. This + interface had a traits class called _Alloc_traits that + attempted to provide more information for compile-time allocation + selection and optimization. This traits class had another allocator + wrapper, __simple_alloc<T,A>, which was a + wrapper around another allocator, A, which itself is an allocator + for instances of T. But wait, there's more: + __allocator<T,A> is another adapter. Many of + the provided allocator classes were SGI style: such classes can be + changed to a conforming interface with this wrapper: + __allocator<T, __alloc> is thus the same as + allocator<T>. + + + The class allocator used the typedef + __alloc to select an underlying allocator that + satisfied memory allocation requests. The selection of this + underlying allocator was not user-configurable. + + + +Extension Allocators + + + + + + + + + Allocator (3.4) + Header (3.4) + Allocator (3.[0-3]) + Header (3.[0-3]) + + + + + + __gnu_cxx::new_allocator<T> + ext/new_allocator.h + std::__new_alloc + memory + + + __gnu_cxx::malloc_allocator<T> + ext/malloc_allocator.h + std::__malloc_alloc_template<int> + memory + + + __gnu_cxx::debug_allocator<T> + ext/debug_allocator.h + std::debug_alloc<T> + memory + + + __gnu_cxx::__pool_alloc<T> + ext/pool_allocator.h + std::__default_alloc_template<bool,int> + memory + + + __gnu_cxx::__mt_alloc<T> + ext/mt_allocator.h + + + + + __gnu_cxx::bitmap_allocator<T> + ext/bitmap_allocator.h + + + + + +
+ + Releases after gcc-3.4 have continued to add to the collection + of available allocators. All of these new allocators are + standard-style. The following table includes details, along with + the first released version of GCC that included the extension allocator. + + + +Extension Allocators Continued + + + + + + + + Allocator + Include + Version + + + + + + __gnu_cxx::array_allocator<T> + ext/array_allocator.h + 4.0.0 + + + __gnu_cxx::throw_allocator<T> + ext/throw_allocator.h + 4.2.0 + + + +
+ + + +Debug mode first appears. + + + +Precompiled header support PCH support. + + + +Macro guard for changed, from _GLIBCPP_ to _GLIBCXX_. + + + +Extension ext/stdio_sync_filebuf.h added. + + + +Extension ext/demangle.h added. + + + + + + +<constant>4.0</constant> + + + +TR1 features first appear. + + + +Extension allocator ext/array_allocator.h added. + + + +Extension codecvt specializations moved to ext/codecvt_specializations.h. + + + +Removal of ext/demangle.h. + + + + + + +<constant>4.1</constant> + + + + + +Removal of cassert from all standard headers: now has to be explicitly included for std::assert calls. + + + Extensions for policy-based data structures first added. New includes, +types, namespace pb_assoc. + + + + + Extensions for typelists added in ext/typelist.h. + + + Extension for policy-based basic_string first added: __gnu_cxx::__versa_string in ext/vstring.h. + + + + + +<constant>4.2</constant> + + + + + Default visibility attributes applied to namespace std. Support for -fvisibility. + + +TR1 random, complex, and C compatibility headers added. + + Extensions for concurrent programming consolidated +into ext/concurrence.h and ext/atomicity.h, +including change of namespace to __gnu_cxx in some +cases. Added types +include _Lock_policy, __concurrence_lock_error, __concurrence_unlock_error, __mutex, __scoped_lock. + + Extensions for type traits consolidated +into ext/type_traits.h. Additional traits are added +(__conditional_type, __enable_if, others.) + + + Extensions for policy-based data structures revised. New includes, +types, namespace moved to __pb_ds. + + + Extensions for debug mode modified: now nested in namespace +std::__debug and extensions in namespace +__gnu_cxx::__debug. + + Extensions added: ext/typelist.h +and ext/throw_allocator.h. + + + + + +<constant>4.3</constant> + + + + + +C++0X features first appear. + + +TR1 regex and cmath's mathematical special function added. + + +Backward include edit. + + + + Removed + +algobase.h algo.h alloc.h bvector.h complex.h +defalloc.h deque.h fstream.h function.h hash_map.h hash_set.h +hashtable.h heap.h iomanip.h iostream.h istream.h iterator.h +list.h map.h multimap.h multiset.h new.h ostream.h pair.h queue.h rope.h set.h slist.h stack.h streambuf.h stream.h tempbuf.h +tree.h vector.h + + + + Added + + hash_map and hash_set + + + + Added in C++0x + + auto_ptr.h and binders.h + + + + + + +Header dependency streamlining. + + + + algorithm no longer includes climits, cstring, or iosfwd + bitset no longer includes istream or ostream, adds iosfwd + functional no longer includes cstddef + iomanip no longer includes istream, istream, or functional, adds ioswd + numeric no longer includes iterator + string no longer includes algorithm or memory + + valarray no longer includes numeric or cstdlib + tr1/hashtable no longer includes memory or functional + tr1/memory no longer includes algorithm + tr1/random no longer includes algorithm or fstream + + + +Debug mode for unordered_map and unordered_set. + + + +Parallel mode first appears. + + +Variadic template implementations of items in tuple and + functional. + + +Default what implementations give more elaborate + exception strings for bad_cast, + bad_typeid, bad_exception, and + bad_alloc. + + + +PCH binary files no longer installed. Instead, the source files are installed. + + + +Namespace pb_ds moved to __gnu_pb_ds. + + + + + \ No newline at end of file diff --git a/libstdc++-v3/doc/xml/manual/extensions.xml b/libstdc++-v3/doc/xml/manual/extensions.xml new file mode 100644 index 00000000000..517d3bba39f --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/extensions.xml @@ -0,0 +1,577 @@ + + + + + + + + + + ISO C++ + + + library + + + + +Extensions + + + + + Here we will make an attempt at describing the non-Standard extensions to + the library. Some of these are from SGI's STL, some of these are GNU's, + and some just seemed to appear on the doorstep. + +Before you leap in and use any of these +extensions, be aware of two things: + + + + + Non-Standard means exactly that. + + + The behavior, and the very + existence, of these extensions may change with little or no + warning. (Ideally, the really good ones will appear in the next + revision of C++.) Also, other platforms, other compilers, other + versions of g++ or libstdc++ may not recognize these names, or + treat them differently, or... + + + + + You should know how to access + these headers properly. + + + + + + + + Compile Time Checks + + Also known as concept checking. + + In 1999, SGI added concept checkers to their implementation + of the STL: code which checked the template parameters of + instantiated pieces of the STL, in order to insure that the parameters + being used met the requirements of the standard. For example, + the Standard requires that types passed as template parameters to + vector be Assignable (which means what you think + it means). The checking was done during compilation, and none of + the code was executed at runtime. + + Unfortunately, the size of the compiler files grew significantly + as a result. The checking code itself was cumbersome. And bugs + were found in it on more than one occasion. + + The primary author of the checking code, Jeremy Siek, had already + started work on a replacement implementation. The new code has been + formally reviewed and accepted into + the + Boost libraries, and we are pleased to incorporate it into the + GNU C++ library. + + The new version imposes a much smaller space overhead on the generated + object file. The checks are also cleaner and easier to read and + understand. + + They are off by default for all versions of GCC from 3.0 to 3.4 (the + latest release at the time of writing). + They can be enabled at configure time with + --enable-concept-checks. + You can enable them on a per-translation-unit basis with + #define _GLIBCXX_CONCEPT_CHECKS for GCC 3.4 and higher + (or with #define _GLIBCPP_CONCEPT_CHECKS for versions + 3.1, 3.2 and 3.3). + + + Please note that the upcoming C++ standard has first-class + support for template parameter constraints based on concepts in the core + language. This will obviate the need for the library-simulated concept + checking described above. + + + + + + + + + + + + + + + Allocators + + + + + + + + + + + + + + Containers + + + + Policy Based Data Structures + + More details here. + + + + + HP/SGI + + + +A few extensions and nods to backwards-compatibility have been made with + containers. Those dealing with older SGI-style allocators are dealt with + elsewhere. The remaining ones all deal with bits: + +The old pre-standard bit_vector class is present for + backwards compatibility. It is simply a typedef for the + vector<bool> specialization. + +The bitset class has a number of extensions, described in the + rest of this item. First, we'll mention that this implementation of + bitset<N> is specialized for cases where N number of + bits will fit into a single word of storage. If your choice of N is + within that range (<=32 on i686-pc-linux-gnu, for example), then all + of the operations will be faster. + +There are + versions of single-bit test, set, reset, and flip member functions which + do no range-checking. If we call them member functions of an instantiation + of "bitset<N>," then their names and signatures are: + + + bitset<N>& _Unchecked_set (size_t pos); + bitset<N>& _Unchecked_set (size_t pos, int val); + bitset<N>& _Unchecked_reset (size_t pos); + bitset<N>& _Unchecked_flip (size_t pos); + bool _Unchecked_test (size_t pos); + + Note that these may in fact be removed in the future, although we have + no present plans to do so (and there doesn't seem to be any immediate + reason to). + +The semantics of member function operator[] are not specified + in the C++ standard. A long-standing defect report calls for sensible + obvious semantics, which are already implemented here: op[] + on a const bitset returns a bool, and for a non-const bitset returns a + reference (a nested type). However, this implementation does + no range-checking on the index argument, which is in keeping with other + containers' op[] requirements. The defect report's proposed + resolution calls for range-checking to be done. We'll just wait and see... + +Finally, two additional searching functions have been added. They return + the index of the first "on" bit, and the index of the first + "on" bit that is after prev, respectively: + + + size_t _Find_first() const; + size_t _Find_next (size_t prev) const; +The same caveat given for the _Unchecked_* functions applies here also. + + + + + + Deprecated HP/SGI + + + The SGI hashing classes hash_set and + hash_set have been deprecated by the + unordered_set, unordered_multiset, unordered_map, + unordered_multimap containers in TR1 and the upcoming C++0x, and + may be removed in future releases. + + + The SGI headers + + <hash_map> + <hash_set> + <rope> + <slist> + <rb_tree> + + are all here; + <hash_map> and <hash_set> + are deprecated but available as backwards-compatible extensions, + as discussed further below. <rope> is the + SGI specialization for large strings ("rope," + "large strings," get it? Love that geeky humor.) + <slist> is a singly-linked list, for when the + doubly-linked list<> is too much space + overhead, and <rb_tree> exposes the red-black + tree classes used in the implementation of the standard maps and + sets. + + Each of the associative containers map, multimap, set, and multiset + have a counterpart which uses a + hashing + function to do the arranging, instead of a strict weak ordering + function. The classes take as one of their template parameters a + function object that will return the hash value; by default, an + instantiation of + hash. + You should specialize this functor for your class, or define your own, + before trying to use one of the hashing classes. + + The hashing classes support all the usual associative container + functions, as well as some extra constructors specifying the number + of buckets, etc. + + Why would you want to use a hashing class instead of the + normalimplementations? Matt Austern writes: + +
+ + [W]ith a well chosen hash function, hash tables + generally provide much better average-case performance than + binary search trees, and much worse worst-case performance. So + if your implementation has hash_map, if you don't mind using + nonstandard components, and if you aren't scared about the + possibility of pathological cases, you'll probably get better + performance from hash_map. + + +
+ + + + + + + Utilities + + The <functional> header contains many additional functors + and helper functions, extending section 20.3. They are + implemented in the file stl_function.h: + + + + identity_element for addition and multiplication. * + + + + The functor identity, whose operator() + returns the argument unchanged. * + + + + Composition functors unary_function and + binary_function, and their helpers compose1 + and compose2. * + + + + select1st and select2nd, to strip pairs. * + + + project1st and project2nd. * + A set of functors/functions which always return the same result. They + are constant_void_fun, constant_binary_fun, + constant_unary_fun, constant0, + constant1, and constant2. * + The class subtractive_rng. * + mem_fun adaptor helpers mem_fun1 and + mem_fun1_ref are provided for backwards compatibility. + + + 20.4.1 can use several different allocators; they are described on the + main extensions page. + + + 20.4.3 is extended with a special version of + get_temporary_buffer taking a second argument. The + argument is a pointer, which is ignored, but can be used to specify + the template type (instead of using explicit function template + arguments like the standard version does). That is, in addition to + + +get_temporary_buffer<int>(5); + + + +you can also use + + + +get_temporary_buffer(5, (int*)0); + + + A class temporary_buffer is given in stl_tempbuf.h. * + + + The specialized algorithms of section 20.4.4 are extended with + uninitialized_copy_n. * + + + + + + + Algorithms +25.1.6 (count, count_if) is extended with two more versions of count + and count_if. The standard versions return their results. The + additional signatures return void, but take a final parameter by + reference to which they assign their results, e.g., + + + void count (first, last, value, n); +25.2 (mutating algorithms) is extended with two families of signatures, + random_sample and random_sample_n. + +25.2.1 (copy) is extended with + + + copy_n (_InputIter first, _Size count, _OutputIter result); +which copies the first 'count' elements at 'first' into 'result'. + +25.3 (sorting 'n' heaps 'n' stuff) is extended with some helper + predicates. Look in the doxygen-generated pages for notes on these. + + + is_heap tests whether or not a range is a heap. + is_sorted tests whether or not a range is sorted in + nondescending order. + +25.3.8 (lexigraphical_compare) is extended with + + + lexicographical_compare_3way(_InputIter1 first1, _InputIter1 last1, + _InputIter2 first2, _InputIter2 last2) +which does... what? + + + + + + + Numerics +26.4, the generalized numeric operations such as accumulate, are extended + with the following functions: + + + power (x, n); + power (x, n, moniod_operation); +Returns, in FORTRAN syntax, "x ** n" where n>=0. In the + case of n == 0, returns the identity element for the + monoid operation. The two-argument signature uses multiplication (for + a true "power" implementation), but addition is supported as well. + The operation functor must be associative. + +The iota function wins the award for Extension With the + Coolest Name. It "assigns sequentially increasing values to a range. + That is, it assigns value to *first, value + 1 to *(first + 1) and so + on." Quoted from SGI documentation. + + + void iota(_ForwardIter first, _ForwardIter last, _Tp value); + + + + + Iterators +24.3.2 describes struct iterator, which didn't exist in the + original HP STL implementation (the language wasn't rich enough at the + time). For backwards compatibility, base classes are provided which + declare the same nested typedefs: + + + input_iterator + output_iterator + forward_iterator + bidirectional_iterator + random_access_iterator + +24.3.4 describes iterator operation distance, which takes + two iterators and returns a result. It is extended by another signature + which takes two iterators and a reference to a result. The result is + modified, and the function returns nothing. + + + + + + + Input and Output + + + Extensions allowing filebufs to be constructed from + "C" types like FILE*s and file descriptors. + + + + Derived filebufs + + The v2 library included non-standard extensions to construct + std::filebufs from C stdio types such as + FILE*s and POSIX file descriptors. + Today the recommended way to use stdio types with libstdc++ + IOStreams is via the stdio_filebuf class (see below), + but earlier releases provided slightly different mechanisms. + + + 3.0.x filebufs have another ctor with this signature: + basic_filebuf(__c_file_type*, ios_base::openmode, int_type); + + This comes in very handy in a number of places, such as + attaching Unix sockets, pipes, and anything else which uses file + descriptors, into the IOStream buffering classes. The three + arguments are as follows: + + __c_file_type* F + // the __c_file_type typedef usually boils down to stdio's FILE + + ios_base::openmode M + // same as all the other uses of openmode + + int_type B + // buffer size, defaults to BUFSIZ if not specified + + + For those wanting to use file descriptors instead of FILE*'s, I + invite you to contemplate the mysteries of C's fdopen(). + + In library snapshot 3.0.95 and later, filebufs bring + back an old extension: the fd() member function. The + integer returned from this function can be used for whatever file + descriptors can be used for on your platform. Naturally, the + library cannot track what you do on your own with a file descriptor, + so if you perform any I/O directly, don't expect the library to be + aware of it. + + Beginning with 3.1, the extra filebuf constructor and + the fd() function were removed from the standard + filebuf. Instead, <ext/stdio_filebuf.h> contains + a derived class called + __gnu_cxx::stdio_filebuf. + This class can be constructed from a C FILE* or a file + descriptor, and provides the fd() function. + + + If you want to access a filebuf's file descriptor to + implement file locking (e.g. using the fcntl() system + call) then you might be interested in Henry Suter's + RWLock + class. + + + + + + + + + + Demangling + + Transforming C++ ABI itentifiers (like RTTI symbols) into the + original C++ source identifiers is called + demangling. + + + If you have read the source + documentation for namespace abi then you are + aware of the cross-vendor C++ ABI in use by GCC. One of the + exposed functions is used for demangling, + abi::__cxa_demangle. + + + In programs like c++filt, the linker, and other tools + have the ability to decode C++ ABI names, and now so can you. + + + (The function itself might use different demanglers, but that's the + whole point of abstract interfaces. If we change the implementation, + you won't notice.) + + + Probably the only times you'll be interested in demangling at runtime + are when you're seeing typeid strings in RTTI, or when + you're handling the runtime-support exception classes. For example: + + +#include <exception> +#include <iostream> +#include <cxxabi.h> + +struct empty { }; + +template <typename T, int N> + struct bar { }; + + +int main() +{ + int status; + char *realname; + + // exception classes not in <stdexcept>, thrown by the implementation + // instead of the user + std::bad_exception e; + realname = abi::__cxa_demangle(e.what(), 0, 0, &status); + std::cout << e.what() << "\t=> " << realname << "\t: " << status << '\n'; + free(realname); + + + // typeid + bar<empty,17> u; + const std::type_info &ti = typeid(u); + + realname = abi::__cxa_demangle(ti.name(), 0, 0, &status); + std::cout << ti.name() << "\t=> " << realname << "\t: " << status << '\n'; + free(realname); + + return 0; +} + + + This prints + + + + + St13bad_exception => std::bad_exception : 0 + 3barI5emptyLi17EE => bar<empty, 17> : 0 + + + + + The demangler interface is described in the source documentation + linked to above. It is actually written in C, so you don't need to + be writing C++ in order to demangle C++. (That also means we have to + use crummy memory management facilities, so don't forget to free() + the returned char array.) + + + + + + + + diff --git a/libstdc++-v3/doc/xml/manual/internals.xml b/libstdc++-v3/doc/xml/manual/internals.xml new file mode 100644 index 00000000000..ccde22791bd --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/internals.xml @@ -0,0 +1,548 @@ + + + + + + + ISO C++ + + + internals + + + + +Porting to New Hardware or Operating Systems + + + + + +This document explains how to port libstdc++ (the GNU C++ library) to +a new target. + + + In order to make the GNU C++ library (libstdc++) work with a new +target, you must edit some configuration files and provide some new +header files. Unless this is done, libstdc++ will use generic +settings which may not be correct for your target; even if they are +correct, they will likely be inefficient. + + + Before you get started, make sure that you have a working C library on +your target. The C library need not precisely comply with any +particular standard, but should generally conform to the requirements +imposed by the ANSI/ISO standard. + + + In addition, you should try to verify that the C++ compiler generally +works. It is difficult to test the C++ compiler without a working +library, but you should at least try some minimal test cases. + + + (Note that what we think of as a "target," the library refers to as +a "host." The comment at the top of configure.ac explains why.) + + + + +Operating System + +If you are porting to a new operating system (as opposed to a new chip +using an existing operating system), you will need to create a new +directory in the config/os hierarchy. For example, the IRIX +configuration files are all in config/os/irix. There is no set +way to organize the OS configuration directory. For example, +config/os/solaris/solaris-2.6 and +config/os/solaris/solaris-2.7 are used as configuration +directories for these two versions of Solaris. On the other hand, both +Solaris 2.7 and Solaris 2.8 use the config/os/solaris/solaris-2.7 +directory. The important information is that there needs to be a +directory under config/os to store the files for your operating +system. + + + You might have to change the configure.host file to ensure that +your new directory is activated. Look for the switch statement that sets +os_include_dir, and add a pattern to handle your operating system +if the default will not suffice. The switch statement switches on only +the OS portion of the standard target triplet; e.g., the solaris2.8 +in sparc-sun-solaris2.8. If the new directory is named after the +OS portion of the triplet (the default), then nothing needs to be changed. + + + The first file to create in this directory, should be called +os_defines.h. This file contains basic macro definitions +that are required to allow the C++ library to work with your C library. + + + Several libstdc++ source files unconditionally define the macro +_POSIX_SOURCE. On many systems, defining this macro causes +large portions of the C library header files to be eliminated +at preprocessing time. Therefore, you may have to #undef this +macro, or define other macros (like _LARGEFILE_SOURCE or +__EXTENSIONS__). You won't know what macros to define or +undefine at this point; you'll have to try compiling the library and +seeing what goes wrong. If you see errors about calling functions +that have not been declared, look in your C library headers to see if +the functions are declared there, and then figure out what macros you +need to define. You will need to add them to the +CPLUSPLUS_CPP_SPEC macro in the GCC configuration file for your +target. It will not work to simply define these macros in +os_defines.h. + + + At this time, there are a few libstdc++-specific macros which may be +defined: + + + _GLIBCXX_USE_C99_CHECK may be defined to 1 to check C99 +function declarations (which are not covered by specialization below) +found in system headers against versions found in the library headers +derived from the standard. + + + _GLIBCXX_USE_C99_DYNAMIC may be defined to an expression that +yields 0 if and only if the system headers are exposing proper support +for C99 functions (which are not covered by specialization below). If +defined, it must be 0 while bootstrapping the compiler/rebuilding the +library. + + + _GLIBCXX_USE_C99_LONG_LONG_CHECK may be defined to 1 to check +the set of C99 long long function declarations found in system headers +against versions found in the library headers derived from the +standard. + + + _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC may be defined to an +expression that yields 0 if and only if the system headers are +exposing proper support for the set of C99 long long functions. If +defined, it must be 0 while bootstrapping the compiler/rebuilding the +library. + + _GLIBCXX_USE_C99_FP_MACROS_DYNAMIC may be defined to an +expression that yields 0 if and only if the system headers +are exposing proper support for the related set of macros. If defined, +it must be 0 while bootstrapping the compiler/rebuilding the library. + + _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_CHECK may be defined +to 1 to check the related set of function declarations found in system +headers against versions found in the library headers derived from +the standard. + + _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_DYNAMIC may be defined +to an expression that yields 0 if and only if the system headers +are exposing proper support for the related set of functions. If defined, +it must be 0 while bootstrapping the compiler/rebuilding the library. + + Finally, you should bracket the entire file in an include-guard, like +this: + + + + +#ifndef _GLIBCXX_OS_DEFINES +#define _GLIBCXX_OS_DEFINES +... +#endif + + + We recommend copying an existing os_defines.h to use as a +starting point. + + + + + +CPU + +If you are porting to a new chip (as opposed to a new operating system +running on an existing chip), you will need to create a new directory in the +config/cpu hierarchy. Much like the Operating system setup, +there are no strict rules on how to organize the CPU configuration +directory, but careful naming choices will allow the configury to find your +setup files without explicit help. + + + We recommend that for a target triplet <CPU>-<vendor>-<OS>, you +name your configuration directory config/cpu/<CPU>. If you do this, +the configury will find the directory by itself. Otherwise you will need to +edit the configure.host file and, in the switch statement that sets +cpu_include_dir, add a pattern to handle your chip. + + + Note that some chip families share a single configuration directory, for +example, alpha, alphaev5, and alphaev6 all use the +config/cpu/alpha directory, and there is an entry in the +configure.host switch statement to handle this. + + + The cpu_include_dir sets default locations for the files controlling +Thread safety and Numeric limits, if the defaults are not +appropriate for your chip. + + + + + + +Character Types + +The library requires that you provide three header files to implement +character classification, analogous to that provided by the C libraries +<ctype.h> header. You can model these on the files provided in +config/os/generic. However, these files will almost +certainly need some modification. + + + The first file to write is ctype_base.h. This file provides +some very basic information about character classification. The libstdc++ +library assumes that your C library implements <ctype.h> by using +a table (indexed by character code) containing integers, where each of +these integers is a bit-mask indicating whether the character is +upper-case, lower-case, alphabetic, etc. The ctype_base.h +file gives the type of the integer, and the values of the various bit +masks. You will have to peer at your own <ctype.h> to figure out +how to define the values required by this file. + + + The ctype_base.h header file does not need include guards. +It should contain a single struct definition called +ctype_base. This struct should contain two type +declarations, and one enumeration declaration, like this example, taken +from the IRIX configuration: + + + + struct ctype_base + { + typedef unsigned int mask; + typedef int* __to_type; + + enum + { + space = _ISspace, + print = _ISprint, + cntrl = _IScntrl, + upper = _ISupper, + lower = _ISlower, + alpha = _ISalpha, + digit = _ISdigit, + punct = _ISpunct, + xdigit = _ISxdigit, + alnum = _ISalnum, + graph = _ISgraph + }; + }; + + +The mask type is the type of the elements in the table. If your +C library uses a table to map lower-case numbers to upper-case numbers, +and vice versa, you should define __to_type to be the type of the +elements in that table. If you don't mind taking a minor performance +penalty, or if your library doesn't implement toupper and +tolower in this way, you can pick any pointer-to-integer type, +but you must still define the type. + + + The enumeration should give definitions for all the values in the above +example, using the values from your native <ctype.h>. They can +be given symbolically (as above), or numerically, if you prefer. You do +not have to include <ctype.h> in this header; it will always be +included before ctype_base.h is included. + + + The next file to write is ctype_noninline.h, which also does +not require include guards. This file defines a few member functions +that will be included in include/bits/locale_facets.h. The first +function that must be written is the ctype<char>::ctype +constructor. Here is the IRIX example: + + + +ctype<char>::ctype(const mask* __table = 0, bool __del = false, + size_t __refs = 0) + : _Ctype_nois<char>(__refs), _M_del(__table != 0 && __del), + _M_toupper(NULL), + _M_tolower(NULL), + _M_ctable(NULL), + _M_table(!__table + ? (const mask*) (__libc_attr._ctype_tbl->_class + 1) + : __table) + { } + + +There are two parts of this that you might choose to alter. The first, +and most important, is the line involving __libc_attr. That is +IRIX system-dependent code that gets the base of the table mapping +character codes to attributes. You need to substitute code that obtains +the address of this table on your system. If you want to use your +operating system's tables to map upper-case letters to lower-case, and +vice versa, you should initialize _M_toupper and +_M_tolower with those tables, in similar fashion. + + + Now, you have to write two functions to convert from upper-case to +lower-case, and vice versa. Here are the IRIX versions: + + + + char + ctype<char>::do_toupper(char __c) const + { return _toupper(__c); } + + char + ctype<char>::do_tolower(char __c) const + { return _tolower(__c); } + + +Your C library provides equivalents to IRIX's _toupper and +_tolower. If you initialized _M_toupper and +_M_tolower above, then you could use those tables instead. + + + Finally, you have to provide two utility functions that convert strings +of characters. The versions provided here will always work - but you +could use specialized routines for greater performance if you have +machinery to do that on your system: + + + + const char* + ctype<char>::do_toupper(char* __low, const char* __high) const + { + while (__low < __high) + { + *__low = do_toupper(*__low); + ++__low; + } + return __high; + } + + const char* + ctype<char>::do_tolower(char* __low, const char* __high) const + { + while (__low < __high) + { + *__low = do_tolower(*__low); + ++__low; + } + return __high; + } + + + You must also provide the ctype_inline.h file, which +contains a few more functions. On most systems, you can just copy +config/os/generic/ctype_inline.h and use it on your system. + + + In detail, the functions provided test characters for particular +properties; they are analogous to the functions like isalpha and +islower provided by the C library. + + + The first function is implemented like this on IRIX: + + + + bool + ctype<char>:: + is(mask __m, char __c) const throw() + { return (_M_table)[(unsigned char)(__c)] & __m; } + + +The _M_table is the table passed in above, in the constructor. +This is the table that contains the bitmasks for each character. The +implementation here should work on all systems. + + + The next function is: + + + + const char* + ctype<char>:: + is(const char* __low, const char* __high, mask* __vec) const throw() + { + while (__low < __high) + *__vec++ = (_M_table)[(unsigned char)(*__low++)]; + return __high; + } + + +This function is similar; it copies the masks for all the characters +from __low up until __high into the vector given by +__vec. + + + The last two functions again are entirely generic: + + + + const char* + ctype<char>:: + scan_is(mask __m, const char* __low, const char* __high) const throw() + { + while (__low < __high && !this->is(__m, *__low)) + ++__low; + return __low; + } + + const char* + ctype<char>:: + scan_not(mask __m, const char* __low, const char* __high) const throw() + { + while (__low < __high && this->is(__m, *__low)) + ++__low; + return __low; + } + + + + + + +Thread Safety + +The C++ library string functionality requires a couple of atomic +operations to provide thread-safety. If you don't take any special +action, the library will use stub versions of these functions that are +not thread-safe. They will work fine, unless your applications are +multi-threaded. + + + If you want to provide custom, safe, versions of these functions, there +are two distinct approaches. One is to provide a version for your CPU, +using assembly language constructs. The other is to use the +thread-safety primitives in your operating system. In either case, you +make a file called atomicity.h, and the variable +ATOMICITYH must point to this file. + + + If you are using the assembly-language approach, put this code in +config/cpu/<chip>/atomicity.h, where chip is the name of +your processor (see CPU). No additional changes are necessary to +locate the file in this case; ATOMICITYH will be set by default. + + + If you are using the operating system thread-safety primitives approach, +you can also put this code in the same CPU directory, in which case no more +work is needed to locate the file. For examples of this approach, +see the atomicity.h file for IRIX or IA64. + + + Alternatively, if the primitives are more closely related to the OS +than they are to the CPU, you can put the atomicity.h file in +the Operating system directory instead. In this case, you must +edit configure.host, and in the switch statement that handles +operating systems, override the ATOMICITYH variable to point to +the appropriate os_include_dir. For examples of this approach, +see the atomicity.h file for AIX. + + + With those bits out of the way, you have to actually write +atomicity.h itself. This file should be wrapped in an +include guard named _GLIBCXX_ATOMICITY_H. It should define one +type, and two functions. + + + The type is _Atomic_word. Here is the version used on IRIX: + + + +typedef long _Atomic_word; + + +This type must be a signed integral type supporting atomic operations. +If you're using the OS approach, use the same type used by your system's +primitives. Otherwise, use the type for which your CPU provides atomic +primitives. + + + Then, you must provide two functions. The bodies of these functions +must be equivalent to those provided here, but using atomic operations: + + + + static inline _Atomic_word + __attribute__ ((__unused__)) + __exchange_and_add (_Atomic_word* __mem, int __val) + { + _Atomic_word __result = *__mem; + *__mem += __val; + return __result; + } + + static inline void + __attribute__ ((__unused__)) + __atomic_add (_Atomic_word* __mem, int __val) + { + *__mem += __val; + } + + + + + + +Numeric Limits + +The C++ library requires information about the fundamental data types, +such as the minimum and maximum representable values of each type. +You can define each of these values individually, but it is usually +easiest just to indicate how many bits are used in each of the data +types and let the library do the rest. For information about the +macros to define, see the top of include/bits/std_limits.h. + + + If you need to define any macros, you can do so in os_defines.h. +However, if all operating systems for your CPU are likely to use the +same values, you can provide a CPU-specific file instead so that you +do not have to provide the same definitions for each operating system. +To take that approach, create a new file called cpu_limits.h in +your CPU configuration directory (see CPU). + + + + + + +Libtool + +The C++ library is compiled, archived and linked with libtool. +Explaining the full workings of libtool is beyond the scope of this +document, but there are a few, particular bits that are necessary for +porting. + + + Some parts of the libstdc++ library are compiled with the libtool +--tags CXX option (the C++ definitions for libtool). Therefore, +ltcf-cxx.sh in the top-level directory needs to have the correct +logic to compile and archive objects equivalent to the C version of libtool, +ltcf-c.sh. Some libtool targets have definitions for C but not +for C++, or C++ definitions which have not been kept up to date. + + + The C++ run-time library contains initialization code that needs to be +run as the library is loaded. Often, that requires linking in special +object files when the C++ library is built as a shared library, or +taking other system-specific actions. + + + The libstdc++ library is linked with the C version of libtool, even +though it is a C++ library. Therefore, the C version of libtool needs to +ensure that the run-time library initializers are run. The usual way to +do this is to build the library using gcc -shared. + + + If you need to change how the library is linked, look at +ltcf-c.sh in the top-level directory. Find the switch statement +that sets archive_cmds. Here, adjust the setting for your +operating system. + + + + + + \ No newline at end of file diff --git a/libstdc++-v3/doc/xml/manual/intro.xml b/libstdc++-v3/doc/xml/manual/intro.xml new file mode 100644 index 00000000000..1a51e9e44f9 --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/intro.xml @@ -0,0 +1,664 @@ + + + + + + + + + + ISO C++ + + + library + + + + +Introduction + + + + Status + + + + Implementation Status + + + + + + + + + + + + + + + + + License + + There are two licenses affecting GNU libstdc++: one for the code, + and one for the documentation. + + + + There is a license section in the FAQ regarding common questions. If you have more + questions, ask the FSF or the gcc mailing list. + + + + The Code: GPL + + + The source code is distributed under the GNU General Public License version 2, + with the so-called Runtime Exception + as follows (or see any header or implementation file): + + + + As a special exception, you may use this file as part of a free software + library without restriction. Specifically, if other files instantiate + templates or use macros or inline functions from this file, or you compile + this file and link it with other files to produce an executable, this + file does not by itself cause the resulting executable to be covered by + the GNU General Public License. This exception does not however + invalidate any other reasons why the executable file might be covered by + the GNU General Public License. + + + + Hopefully that text is self-explanatory. If it isn't, you need to speak + to your lawyer, or the Free Software Foundation. + + + + + The Documentation: GPL, FDL + + + The documentation shipped with the library and made available over + the web, excluding the pages generated from source comments, are + copyrighted by the Free Software Foundation, and placed under the + GNU Free Documentation + License version 1.2. There are no Front-Cover Texts, no + Back-Cover Texts, and no Invariant Sections. + + + + For documentation generated by doxygen or other automated tools + via processing source code comments and markup, the original source + code license applies to the generated files. Thus, the doxygen + documents are licensed GPL. + + + + If you plan on making copies of the documentation, please let us know. + We can probably offer suggestions. + + + + + + + + Bugs + + + Implementation Bugs + + Information on known bugs, details on efforts to fix them, and + fixed bugs are all available as part of the GCC bug tracking + system, bugzilla, with the + category set to libstdc++. + + + + + Standard Bugs + + Everybody's got issues. Even the C++ Standard Library. + + + The Library Working Group, or LWG, is the ISO subcommittee responsible + for making changes to the library. They periodically publish an + Issues List containing problems and possible solutions. As they reach + a consensus on proposed solutions, we often incorporate the solution. + + + Here are the issues which have resulted in code changes to the library. + The links are to the specific defect reports from a partial + copy of the Issues List. You can read the full version online + at the ISO C++ + Committee homepage, linked to on the + GCC "Readings" + page. If + you spend a lot of time reading the issues, we recommend downloading + the ZIP file and reading them locally. + + + (NB: partial copy means that not all + links within the lwg-*.html pages will work. Specifically, + links to defect reports that have not been accorded full DR + status will probably break. Rather than trying to mirror the + entire issues list on our overworked web server, we recommend + you go to the LWG homepage instead.) + + + If a DR is not listed here, we may simply not have gotten to + it yet; feel free to submit a patch. Search the include/bits + and src directories for appearances of + _GLIBCXX_RESOLVE_LIB_DEFECTS for examples + of style. Note that we usually do not make changes to the + code until an issue has reached DR status. + + + + 5: + string::compare specification questionable + + This should be two overloaded functions rather than a single function. + + + 17: + Bad bool parsing + + Apparently extracting Boolean values was messed up... + + + 19: + "Noconv" definition too vague + + If codecvt::do_in returns noconv there are + no changes to the values in [to, to_limit). + + + 22: + Member open vs flags + + Re-opening a file stream does not clear the state flags. + + + 25: + String operator<< uses width() value wrong + + Padding issues. + + + 48: + Use of non-existent exception constructor + + An instance of ios_base::failure is constructed instead. + + + 49: + Underspecification of ios_base::sync_with_stdio + + The return type is the previous state of synchronization. + + + 50: + Copy constructor and assignment operator of ios_base + + These members functions are declared private and are + thus inaccessible. Specifying the correct semantics of + "copying stream state" was deemed too complicated. + + + 60: + What is a formatted input function? + + This DR made many widespread changes to basic_istream + and basic_ostream all of which have been implemented. + + + 63: + Exception-handling policy for unformatted output + + Make the policy consistent with that of formatted input, unformatted + input, and formatted output. + + + 68: + Extractors for char* should store null at end + + And they do now. An editing glitch in the last item in the list of + [27.6.1.2.3]/7. + + + 74: + Garbled text for codecvt::do_max_length + + The text of the standard was gibberish. Typos gone rampant. + + + 75: + Contradiction in codecvt::length's argument types + + Change the first parameter to stateT& and implement + the new effects paragraph. + + + 83: + string::npos vs. string::max_size() + + Safety checks on the size of the string should test against + max_size() rather than npos. + + + 90: + Incorrect description of operator>> for strings + + The effect contain isspace(c,getloc()) which must be + replaced by isspace(c,is.getloc()). + + + 91: + Description of operator>> and getline() for string<> + might cause endless loop + + They behave as a formatted input function and as an unformatted + input function, respectively (except that getline is + not required to set gcount). + + + 103: + set::iterator is required to be modifiable, but this allows + modification of keys. + + For associative containers where the value type is the same as + the key type, both iterator and const_iterator + are constant iterators. + + + 109: + Missing binders for non-const sequence elements + + The binder1st and binder2nd didn't have an + operator() taking a non-const parameter. + + + 110: + istreambuf_iterator::equal not const + + This was not a const member function. Note that the DR says to + replace the function with a const one; we have instead provided an + overloaded version with identical contents. + + + 117: + basic_ostream uses nonexistent num_put member functions + + num_put::put() was overloaded on the wrong types. + + + 118: + basic_istream uses nonexistent num_get member functions + + Same as 117, but for num_get::get(). + + + 129: + Need error indication from seekp() and seekg() + + These functions set failbit on error now. + + + 136: + seekp, seekg setting wrong streams? + + seekp should only set the output stream, and + seekg should only set the input stream. + + + + + 167: + Improper use of traits_type::length() + + op<< with a const char* was + calculating an incorrect number of characters to write. + + + 169: + Bad efficiency of overflow() mandated + + Grow efficiently the internal array object. + + + 171: + Strange seekpos() semantics due to joint position + + Quite complex to summarize... + + + 181: + make_pair() unintended behavior + + This function used to take its arguments as reference-to-const, now + it copies them (pass by value). + + + 195: + Should basic_istream::sentry's constructor ever set eofbit? + + Yes, it can, specifically if EOF is reached while skipping whitespace. + + + 211: + operator>>(istream&, string&) doesn't set failbit + + If nothing is extracted into the string, op>> now + sets failbit (which can cause an exception, etc., etc.). + + + 214: + set::find() missing const overload + + Both set and multiset were missing + overloaded find, lower_bound, upper_bound, and equal_range functions + for const instances. + + + 231: + Precision in iostream? + + For conversion from a floating-point type, str.precision() + is specified in the conversion specification. + + + 233: + Insertion hints in associative containers + + Implement N1780, first check before then check after, insert as close + to hint as possible. + + + 235: + No specification of default ctor for reverse_iterator + + The declaration of reverse_iterator lists a default constructor. + However, no specification is given what this constructor should do. + + + 241: + Does unique_copy() require CopyConstructible and Assignable? + + Add a helper for forward_iterator/output_iterator, fix the existing + one for input_iterator/output_iterator to not rely on Assignability. + + + 243: + get and getline when sentry reports failure + + Store a null character only if the character array has a non-zero size. + + + 251: + basic_stringbuf missing allocator_type + + This nested typedef was originally not specified. + + + 253: + valarray helper functions are almost entirely useless + + Make the copy constructor and copy-assignment operator declarations + public in gslice_array, indirect_array, mask_array, slice_array; provide + definitions. + + + 265: + std::pair::pair() effects overly restrictive + + The default ctor would build its members from copies of temporaries; + now it simply uses their respective default ctors. + + + 266: + bad_exception::~bad_exception() missing Effects clause + + The bad_* classes no longer have destructors (they + are trivial), since no description of them was ever given. + + + 271: + basic_iostream missing typedefs + + The typedefs it inherits from its base classes can't be used, since + (for example) basic_iostream<T>::traits_type is ambiguous. + + + 275: + Wrong type in num_get::get() overloads + + Similar to 118. + + + 280: + Comparison of reverse_iterator to const reverse_iterator + + Add global functions with two template parameters. + (NB: not added for now a templated assignment operator) + + + 292: + Effects of a.copyfmt (a) + + If (this == &rhs) do nothing. + + + 300: + List::merge() specification incomplete + + If (this == &x) do nothing. + + + 303: + Bitset input operator underspecified + + Basically, compare the input character to is.widen(0) + and is.widen(1). + + + 305: + Default behavior of codecvt<wchar_t, char, mbstate_t>::length() + + Do not specify what codecvt<wchar_t, char, mbstate_t>::do_length + must return. + + + 328: + Bad sprintf format modifier in money_put<>::do_put() + + Change the format string to "%.0Lf". + + + 365: + Lack of const-qualification in clause 27 + + Add const overloads of is_open. + + + 389: + Const overload of valarray::operator[] returns by value + + Change it to return a const T&. + + + 402: + Wrong new expression in [some_]allocator::construct + + Replace "new" with "::new". + + + 409: + Closing an fstream should clear the error state + + Have open clear the error flags. + + + 431: + Swapping containers with unequal allocators + + Implement Option 3, as per N1599. + + + 432: + stringbuf::overflow() makes only one write position + available + + Implement the resolution, beyond DR 169. + + + 434: + bitset::to_string() hard to use + + Add three overloads, taking fewer template arguments. + + + 438: + Ambiguity in the "do the right thing" clause + + Implement the resolution, basically cast less. + + + 453: + basic_stringbuf::seekoff need not always fail for an empty stream + + Don't fail if the next pointer is null and newoff is zero. + + + 455: + cerr::tie() and wcerr::tie() are overspecified + + Initialize cerr tied to cout and wcerr tied to wcout. + + + 464: + Suggestion for new member functions in standard containers + + Add data() to std::vector and + at(const key_type&) to std::map. + + + 508: + Bad parameters for ranlux64_base_01 + + Fix the parameters. + + + 512: + Seeding subtract_with_carry_01 from a single unsigned long + + Construct a linear_congruential engine and seed with it. + + + 526: + Is it undefined if a function in the standard changes in + parameters? + + Use &value. + + + 538: + 241 again: Does unique_copy() require CopyConstructible + and Assignable? + + In case of input_iterator/output_iterator rely on Assignability of + input_iterator' value_type. + + + 541: + shared_ptr template assignment and void + + Add an auto_ptr<void> specialization. + + + 543: + valarray slice default constructor + + Follow the straightforward proposed resolution. + + + 586: + string inserter not a formatted function + + Change it to be a formatted output function (i.e. catch exceptions). + + + 596: + 27.8.1.3 Table 112 omits "a+" and "a+b" modes + + Add the missing modes to fopen_mode. + + + 660: + Missing bitwise operations + + Add the missing operations. + + + 693: + std::bitset::all() missing + + Add it, consistently with the discussion. + + + 695: + ctype<char>::classic_table() not accessible + + Make the member functions table and classic_table public. + + + + + + + + + + + Setup + + + + + + + + + + + + + + + + + + + + diff --git a/libstdc++-v3/doc/xml/manual/io.xml b/libstdc++-v3/doc/xml/manual/io.xml new file mode 100644 index 00000000000..8b6806f90a7 --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/io.xml @@ -0,0 +1,665 @@ + + + + + + + + + + ISO C++ + + + library + + + + +Input and Output + + + + Iostream Objects + + To minimize the time you have to wait on the compiler, it's good to + only include the headers you really need. Many people simply include + <iostream> when they don't need to -- and that can penalize + your runtime as well. Here are some tips on which header to use + for which situations, starting with the simplest. + + <iosfwd> should be included whenever you simply + need the name of an I/O-related class, such as + "ofstream" or "basic_streambuf". Like the name + implies, these are forward declarations. (A word to all you fellow + old school programmers: trying to forward declare classes like + "class istream;" won't work. Look in the iosfwd header if + you'd like to know why.) For example, + + + #include <iosfwd> + + class MyClass + { + .... + std::ifstream& input_file; + }; + + extern std::ostream& operator<< (std::ostream&, MyClass&); + + <ios> declares the base classes for the entire + I/O stream hierarchy, std::ios_base and std::basic_ios<charT>, the + counting types std::streamoff and std::streamsize, the file + positioning type std::fpos, and the various manipulators like + std::hex, std::fixed, std::noshowbase, and so forth. + + The ios_base class is what holds the format flags, the state flags, + and the functions which change them (setf(), width(), precision(), + etc). You can also store extra data and register callback functions + through ios_base, but that has been historically underused. Anything + which doesn't depend on the type of characters stored is consolidated + here. + + The template class basic_ios is the highest template class in the + hierarchy; it is the first one depending on the character type, and + holds all general state associated with that type: the pointer to the + polymorphic stream buffer, the facet information, etc. + + <streambuf> declares the template class + basic_streambuf, and two standard instantiations, streambuf and + wstreambuf. If you need to work with the vastly useful and capable + stream buffer classes, e.g., to create a new form of storage + transport, this header is the one to include. + + <istream>/<ostream> are + the headers to include when you are using the >>/<< + interface, or any of the other abstract stream formatting functions. + For example, + + + #include <istream> + + std::ostream& operator<< (std::ostream& os, MyClass& c) + { + return os << c.data1() << c.data2(); + } + + The std::istream and std::ostream classes are the abstract parents of + the various concrete implementations. If you are only using the + interfaces, then you only need to use the appropriate interface header. + + <iomanip> provides "extractors and inserters + that alter information maintained by class ios_base and its derived + classes," such as std::setprecision and std::setw. If you need + to write expressions like os << setw(3); or + is >> setbase(8);, you must include <iomanip>. + + <sstream>/<fstream> + declare the six stringstream and fstream classes. As they are the + standard concrete descendants of istream and ostream, you will already + know about them. + + Finally, <iostream> provides the eight standard + global objects (cin, cout, etc). To do this correctly, this header + also provides the contents of the <istream> and <ostream> + headers, but nothing else. The contents of this header look like + + + #include <ostream> + #include <istream> + + namespace std + { + extern istream cin; + extern ostream cout; + .... + + // this is explained below + static ios_base::Init __foo; // not its real name + } + + Now, the runtime penalty mentioned previously: the global objects + must be initialized before any of your own code uses them; this is + guaranteed by the standard. Like any other global object, they must + be initialized once and only once. This is typically done with a + construct like the one above, and the nested class ios_base::Init is + specified in the standard for just this reason. + + How does it work? Because the header is included before any of your + code, the __foo object is constructed before any of + your objects. (Global objects are built in the order in which they + are declared, and destroyed in reverse order.) The first time the + constructor runs, the eight stream objects are set up. + + The static keyword means that each object file compiled + from a source file containing <iostream> will have its own + private copy of __foo. There is no specified order + of construction across object files (it's one of those pesky NP + problems that make life so interesting), so one copy in each object + file means that the stream objects are guaranteed to be set up before + any of your code which uses them could run, thereby meeting the + requirements of the standard. + + The penalty, of course, is that after the first copy of + __foo is constructed, all the others are just wasted + processor time. The time spent is merely for an increment-and-test + inside a function call, but over several dozen or hundreds of object + files, that time can add up. (It's not in a tight loop, either.) + + The lesson? Only include <iostream> when you need to use one of + the standard objects in that source file; you'll pay less startup + time. Only include the header files you need to in general; your + compile times will go down when there's less parsing work to do. + + + + + + + Stream Buffers + + + Derived streambuf Classes + + + + Creating your own stream buffers for I/O can be remarkably easy. + If you are interested in doing so, we highly recommend two very + excellent books: + Standard C++ + IOStreams and Locales by Langer and Kreft, ISBN 0-201-18395-1, and + The C++ Standard Library + by Nicolai Josuttis, ISBN 0-201-37926-0. Both are published by + Addison-Wesley, who isn't paying us a cent for saying that, honest. + + Here is a simple example, io/outbuf1, from the Josuttis text. It + transforms everything sent through it to uppercase. This version + assumes many things about the nature of the character type being + used (for more information, read the books or the newsgroups): + + + #include <iostream> + #include <streambuf> + #include <locale> + #include <cstdio> + + class outbuf : public std::streambuf + { + protected: + /* central output function + * - print characters in uppercase mode + */ + virtual int_type overflow (int_type c) { + if (c != EOF) { + // convert lowercase to uppercase + c = std::toupper(static_cast<char>(c),getloc()); + + // and write the character to the standard output + if (putchar(c) == EOF) { + return EOF; + } + } + return c; + } + }; + + int main() + { + // create special output buffer + outbuf ob; + // initialize output stream with that output buffer + std::ostream out(&ob); + + out << "31 hexadecimal: " + << std::hex << 31 << std::endl; + return 0; + } + + Try it yourself! More examples can be found in 3.1.x code, in + include/ext/*_filebuf.h, and on + Dietmar + Kühl's IOStreams page. + + + + + + Buffering + First, are you sure that you understand buffering? Particularly + the fact that C++ may not, in fact, have anything to do with it? + + The rules for buffering can be a little odd, but they aren't any + different from those of C. (Maybe that's why they can be a bit + odd.) Many people think that writing a newline to an output + stream automatically flushes the output buffer. This is true only + when the output stream is, in fact, a terminal and not a file + or some other device -- and that may not even be true + since C++ says nothing about files nor terminals. All of that is + system-dependent. (The "newline-buffer-flushing only occurring + on terminals" thing is mostly true on Unix systems, though.) + + Some people also believe that sending endl down an + output stream only writes a newline. This is incorrect; after a + newline is written, the buffer is also flushed. Perhaps this + is the effect you want when writing to a screen -- get the text + out as soon as possible, etc -- but the buffering is largely + wasted when doing this to a file: + + + output << "a line of text" << endl; + output << some_data_variable << endl; + output << "another line of text" << endl; + The proper thing to do in this case to just write the data out + and let the libraries and the system worry about the buffering. + If you need a newline, just write a newline: + + + output << "a line of text\n" + << some_data_variable << '\n' + << "another line of text\n"; + I have also joined the output statements into a single statement. + You could make the code prettier by moving the single newline to + the start of the quoted text on the last line, for example. + + If you do need to flush the buffer above, you can send an + endl if you also need a newline, or just flush the buffer + yourself: + + + output << ...... << flush; // can use std::flush manipulator + output.flush(); // or call a member fn + On the other hand, there are times when writing to a file should + be like writing to standard error; no buffering should be done + because the data needs to appear quickly (a prime example is a + log file for security-related information). The way to do this is + just to turn off the buffering before any I/O operations at + all have been done (note that opening counts as an I/O operation): + + + std::ofstream os; + std::ifstream is; + int i; + + os.rdbuf()->pubsetbuf(0,0); + is.rdbuf()->pubsetbuf(0,0); + + os.open("/foo/bar/baz"); + is.open("/qux/quux/quuux"); + ... + os << "this data is written immediately\n"; + is >> i; // and this will probably cause a disk read + Since all aspects of buffering are handled by a streambuf-derived + member, it is necessary to get at that member with rdbuf(). + Then the public version of setbuf can be called. The + arguments are the same as those for the Standard C I/O Library + function (a buffer area followed by its size). + + A great deal of this is implementation-dependent. For example, + streambuf does not specify any actions for its own + setbuf()-ish functions; the classes derived from + streambuf each define behavior that "makes + sense" for that class: an argument of (0,0) turns off buffering + for filebuf but does nothing at all for its siblings + stringbuf and strstreambuf, and specifying + anything other than (0,0) has varying effects. + User-defined classes derived from streambuf can + do whatever they want. (For filebuf and arguments for + (p,s) other than zeros, libstdc++ does what you'd expect: + the first s bytes of p are used as a buffer, + which you must allocate and deallocate.) + + A last reminder: there are usually more buffers involved than + just those at the language/library level. Kernel buffers, disk + buffers, and the like will also have an effect. Inspecting and + changing those are system-dependent. + + + + + + + + Memory Based Streams + + Compatibility With strstream + + + Stringstreams (defined in the header <sstream>) + are in this author's opinion one of the coolest things since + sliced time. An example of their use is in the Received Wisdom + section for Chapter 21 (Strings), + describing how to + format strings. + + The quick definition is: they are siblings of ifstream and ofstream, + and they do for std::string what their siblings do for + files. All that work you put into writing << and + >> functions for your classes now pays off + again! Need to format a string before passing the string + to a function? Send your stuff via << to an + ostringstream. You've read a string as input and need to parse it? + Initialize an istringstream with that string, and then pull pieces + out of it with >>. Have a stringstream and need to + get a copy of the string inside? Just call the str() + member function. + + This only works if you've written your + <</>> functions correctly, though, + and correctly means that they take istreams and ostreams as + parameters, not ifstreams and ofstreams. If they + take the latter, then your I/O operators will work fine with + file streams, but with nothing else -- including stringstreams. + + If you are a user of the strstream classes, you need to update + your code. You don't have to explicitly append ends to + terminate the C-style character array, you don't have to mess with + "freezing" functions, and you don't have to manage the + memory yourself. The strstreams have been officially deprecated, + which means that 1) future revisions of the C++ Standard won't + support them, and 2) if you use them, people will laugh at you. + + + + + + + + + File Based Streams + + + Copying a File + + + + So you want to copy a file quickly and easily, and most important, + completely portably. And since this is C++, you have an open + ifstream (call it IN) and an open ofstream (call it OUT): + + + #include <fstream> + + std::ifstream IN ("input_file"); + std::ofstream OUT ("output_file"); + Here's the easiest way to get it completely wrong: + + + OUT << IN; + For those of you who don't already know why this doesn't work + (probably from having done it before), I invite you to quickly + create a simple text file called "input_file" containing + the sentence + + + The quick brown fox jumped over the lazy dog. + surrounded by blank lines. Code it up and try it. The contents + of "output_file" may surprise you. + + Seriously, go do it. Get surprised, then come back. It's worth it. + + The thing to remember is that the basic_[io]stream classes + handle formatting, nothing else. In particular, they break up on + whitespace. The actual reading, writing, and storing of data is + handled by the basic_streambuf family. Fortunately, the + operator<< is overloaded to take an ostream and + a pointer-to-streambuf, in order to help with just this kind of + "dump the data verbatim" situation. + + Why a pointer to streambuf and not just a streambuf? Well, + the [io]streams hold pointers (or references, depending on the + implementation) to their buffers, not the actual + buffers. This allows polymorphic behavior on the part of the buffers + as well as the streams themselves. The pointer is easily retrieved + using the rdbuf() member function. Therefore, the easiest + way to copy the file is: + + + OUT << IN.rdbuf(); + So what was happening with OUT<<IN? Undefined + behavior, since that particular << isn't defined by the Standard. + I have seen instances where it is implemented, but the character + extraction process removes all the whitespace, leaving you with no + blank lines and only "Thequickbrownfox...". With + libraries that do not define that operator, IN (or one of IN's + member pointers) sometimes gets converted to a void*, and the output + file then contains a perfect text representation of a hexadecimal + address (quite a big surprise). Others don't compile at all. + + Also note that none of this is specific to o*f*streams. + The operators shown above are all defined in the parent + basic_ostream class and are therefore available with all possible + descendants. + + + + + + Binary Input and Output + + + The first and most important thing to remember about binary I/O is + that opening a file with ios::binary is not, repeat + not, the only thing you have to do. It is not a silver + bullet, and will not allow you to use the <</>> + operators of the normal fstreams to do binary I/O. + + Sorry. Them's the breaks. + + This isn't going to try and be a complete tutorial on reading and + writing binary files (because "binary" + covers a lot of ground), but we will try and clear + up a couple of misconceptions and common errors. + + First, ios::binary has exactly one defined effect, no more + and no less. Normal text mode has to be concerned with the newline + characters, and the runtime system will translate between (for + example) '\n' and the appropriate end-of-line sequence (LF on Unix, + CRLF on DOS, CR on Macintosh, etc). (There are other things that + normal mode does, but that's the most obvious.) Opening a file in + binary mode disables this conversion, so reading a CRLF sequence + under Windows won't accidentally get mapped to a '\n' character, etc. + Binary mode is not supposed to suddenly give you a bitstream, and + if it is doing so in your program then you've discovered a bug in + your vendor's compiler (or some other part of the C++ implementation, + possibly the runtime system). + + Second, using << to write and >> to + read isn't going to work with the standard file stream classes, even + if you use skipws during reading. Why not? Because + ifstream and ofstream exist for the purpose of formatting, + not reading and writing. Their job is to interpret the data into + text characters, and that's exactly what you don't want to happen + during binary I/O. + + Third, using the get() and put()/write() member + functions still aren't guaranteed to help you. These are + "unformatted" I/O functions, but still character-based. + (This may or may not be what you want, see below.) + + Notice how all the problems here are due to the inappropriate use + of formatting functions and classes to perform something + which requires that formatting not be done? There are a + seemingly infinite number of solutions, and a few are listed here: + + + + Derive your own fstream-type classes and write your own + <</>> operators to do binary I/O on whatever data + types you're using. + + + This is a Bad Thing, because while + the compiler would probably be just fine with it, other humans + are going to be confused. The overloaded bitshift operators + have a well-defined meaning (formatting), and this breaks it. + + + + + Build the file structure in memory, then + mmap() the file and copy the + structure. + + + + Well, this is easy to make work, and easy to break, and is + pretty equivalent to using ::read() and + ::write() directly, and makes no use of the + iostream library at all... + + + + + Use streambufs, that's what they're there for. + + + While not trivial for the beginner, this is the best of all + solutions. The streambuf/filebuf layer is the layer that is + responsible for actual I/O. If you want to use the C++ + library for binary I/O, this is where you start. + + + + How to go about using streambufs is a bit beyond the scope of this + document (at least for now), but while streambufs go a long way, + they still leave a couple of things up to you, the programmer. + As an example, byte ordering is completely between you and the + operating system, and you have to handle it yourself. + + Deriving a streambuf or filebuf + class from the standard ones, one that is specific to your data + types (or an abstraction thereof) is probably a good idea, and + lots of examples exist in journals and on Usenet. Using the + standard filebufs directly (either by declaring your own or by + using the pointer returned from an fstream's rdbuf()) + is certainly feasible as well. + + One area that causes problems is trying to do bit-by-bit operations + with filebufs. C++ is no different from C in this respect: I/O + must be done at the byte level. If you're trying to read or write + a few bits at a time, you're going about it the wrong way. You + must read/write an integral number of bytes and then process the + bytes. (For example, the streambuf functions take and return + variables of type int_type.) + + Another area of problems is opening text files in binary mode. + Generally, binary mode is intended for binary files, and opening + text files in binary mode means that you now have to deal with all of + those end-of-line and end-of-file problems that we mentioned before. + An instructive thread from comp.lang.c++.moderated delved off into + this topic starting more or less at + this + article and continuing to the end of the thread. (You'll have to + sort through some flames every couple of paragraphs, but the points + made are good ones.) + + + + + + More Binary Input and Output + Towards the beginning of February 2001, the subject of + "binary" I/O was brought up in a couple of places at the + same time. One notable place was Usenet, where James Kanze and + Dietmar Kühl separately posted articles on why attempting + generic binary I/O was not a good idea. (Here are copies of + Kanze's article and + Kühl's article.) + + Briefly, the problems of byte ordering and type sizes mean that + the unformatted functions like ostream::put() and + istream::get() cannot safely be used to communicate + between arbitrary programs, or across a network, or from one + invocation of a program to another invocation of the same program + on a different platform, etc. + + The entire Usenet thread is instructive, and took place under the + subject heading "binary iostreams" on both comp.std.c++ + and comp.lang.c++.moderated in parallel. Also in that thread, + Dietmar Kühl mentioned that he had written a pair of stream + classes that would read and write XDR, which is a good step towards + a portable binary format. + + + + + + + + + Interacting with C + + + + Using FILE* and file descriptors + + See the extensions for using + FILE and file descriptors with + ofstream and + ifstream. + + + + + Performance + + Pathetic Performance? Ditch C. + + It sounds like a flame on C, but it isn't. Really. Calm down. + I'm just saying it to get your attention. + + Because the C++ library includes the C library, both C-style and + C++-style I/O have to work at the same time. For example: + + + #include <iostream> + #include <cstdio> + + std::cout << "Hel"; + std::printf ("lo, worl"); + std::cout << "d!\n"; + + This must do what you think it does. + + Alert members of the audience will immediately notice that buffering + is going to make a hash of the output unless special steps are taken. + + The special steps taken by libstdc++, at least for version 3.0, + involve doing very little buffering for the standard streams, leaving + most of the buffering to the underlying C library. (This kind of + thing is tricky to get right.) + The upside is that correctness is ensured. The downside is that + writing through cout can quite easily lead to awful + performance when the C++ I/O library is layered on top of the C I/O + library (as it is for 3.0 by default). Some patches have been applied + which improve the situation for 3.1. + + However, the C and C++ standard streams only need to be kept in sync + when both libraries' facilities are in use. If your program only uses + C++ I/O, then there's no need to sync with the C streams. The right + thing to do in this case is to call + + + #include any of the I/O headers such as ios, iostream, etc + + std::ios::sync_with_stdio(false); + + You must do this before performing any I/O via the C++ stream objects. + Once you call this, the C++ streams will operate independently of the + (unused) C streams. For GCC 3.x, this means that cout and + company will become fully buffered on their own. + + Note, by the way, that the synchronization requirement only applies to + the standard streams (cin, cout, + cerr, + clog, and their wide-character counterparts). File stream + objects that you declare yourself have no such requirement and are fully + buffered. + + + + + + + diff --git a/libstdc++-v3/doc/xml/manual/iterators.xml b/libstdc++-v3/doc/xml/manual/iterators.xml new file mode 100644 index 00000000000..757249d277e --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/iterators.xml @@ -0,0 +1,177 @@ + + + + + + + + + + ISO C++ + + + library + + + + +Iterators + + + + Predefined + + + Iterators vs. Pointers + FAQ 5.1 points out that iterators + are not implemented as pointers. They are a generalization of + pointers, but they are implemented in libstdc++ as separate classes. + + Keeping that simple fact in mind as you design your code will + prevent a whole lot of difficult-to-understand bugs. + + You can think of it the other way 'round, even. Since iterators + are a generalization, that means that pointers are + iterators, and that pointers can be used whenever an + iterator would be. All those functions in the Algorithms chapter + of the Standard will work just as well on plain arrays and their + pointers. + + That doesn't mean that when you pass in a pointer, it gets wrapped + into some special delegating iterator-to-pointer class with a layer + of overhead. (If you think that's the case anywhere, you don't + understand templates to begin with...) Oh, no; if you pass + in a pointer, then the compiler will instantiate that template + using T* as a type, and good old high-speed pointer arithmetic as + its operations, so the resulting code will be doing exactly the same + things as it would be doing if you had hand-coded it yourself (for + the 273rd time). + + How much overhead is there when using an iterator class? + Very little. Most of the layering classes contain nothing but + typedefs, and typedefs are "meta-information" that simply + tell the compiler some nicknames; they don't create code. That + information gets passed down through inheritance, so while the + compiler has to do work looking up all the names, your runtime code + does not. (This has been a prime concern from the beginning.) + + + + + + + One Past the End + + This starts off sounding complicated, but is actually very easy, + especially towards the end. Trust me. + + Beginners usually have a little trouble understand the whole + 'past-the-end' thing, until they remember their early algebra classes + (see, they told you that stuff would come in handy!) and + the concept of half-open ranges. + + First, some history, and a reminder of some of the funkier rules in + C and C++ for builtin arrays. The following rules have always been + true for both languages: + + + + You can point anywhere in the array, or to the first element + past the end of the array. A pointer that points to one + past the end of the array is guaranteed to be as unique as a + pointer to somewhere inside the array, so that you can compare + such pointers safely. + + + + You can only dereference a pointer that points into an array. + If your array pointer points outside the array -- even to just + one past the end -- and you dereference it, Bad Things happen. + + + + Strictly speaking, simply pointing anywhere else invokes + undefined behavior. Most programs won't puke until such a + pointer is actually dereferenced, but the standards leave that + up to the platform. + + + + The reason this past-the-end addressing was allowed is to make it + easy to write a loop to go over an entire array, e.g., + while (*d++ = *s++);. + + So, when you think of two pointers delimiting an array, don't think + of them as indexing 0 through n-1. Think of them as boundary + markers: + + + + beginning end + | | + | | This is bad. Always having to + | | remember to add or subtract one. + | | Off-by-one bugs very common here. + V V + array of N elements + |---|---|--...--|---|---| + | 0 | 1 | ... |N-2|N-1| + |---|---|--...--|---|---| + + ^ ^ + | | + | | This is good. This is safe. This + | | is guaranteed to work. Just don't + | | dereference 'end'. + beginning end + + + See? Everything between the boundary markers is part of the array. + Simple. + + Now think back to your junior-high school algebra course, when you + were learning how to draw graphs. Remember that a graph terminating + with a solid dot meant, "Everything up through this point," + and a graph terminating with an open dot meant, "Everything up + to, but not including, this point," respectively called closed + and open ranges? Remember how closed ranges were written with + brackets, [a,b], and open ranges were written with parentheses, + (a,b)? + + The boundary markers for arrays describe a half-open range, + starting with (and including) the first element, and ending with (but + not including) the last element: [beginning,end). See, I + told you it would be simple in the end. + + Iterators, and everything working with iterators, follows this same + time-honored tradition. A container's begin() method returns + an iterator referring to the first element, and its end() + method returns a past-the-end iterator, which is guaranteed to be + unique and comparable against any other iterator pointing into the + middle of the container. + + Container constructors, container methods, and algorithms, all take + pairs of iterators describing a range of values on which to operate. + All of these ranges are half-open ranges, so you pass the beginning + iterator as the starting parameter, and the one-past-the-end iterator + as the finishing parameter. + + This generalizes very well. You can operate on sub-ranges quite + easily this way; functions accepting a [first,last) range + don't know or care whether they are the boundaries of an entire {array, + sequence, container, whatever}, or whether they only enclose a few + elements from the center. This approach also makes zero-length + sequences very simple to recognize: if the two endpoints compare + equal, then the {array, sequence, container, whatever} is empty. + + Just don't dereference end(). + + + + + + + + diff --git a/libstdc++-v3/doc/xml/manual/locale.xml b/libstdc++-v3/doc/xml/manual/locale.xml new file mode 100644 index 00000000000..a4f20bd974c --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/locale.xml @@ -0,0 +1,653 @@ + + + + + + + ISO C++ + + + locale + + + + +locale + + +Describes the basic locale object, including nested +classes id, facet, and the reference-counted implementation object, +class _Impl. + + + +Requirements + + +Class locale is non-templatized and has two distinct types nested +inside of it: + + +
+ + +class facet +22.1.1.1.2 Class locale::facet + + +
+ + +Facets actually implement locale functionality. For instance, a facet +called numpunct is the data objects that can be used to query for the +thousands separator is in the German locale. + + + +Literally, a facet is strictly defined: + + + + + + Dontaining the following public data member: + + + static locale::id id; + + + + + + Derived from another facet: + + + class gnu_codecvt: public std::ctype<user-defined-type> + + + + + +Of interest in this class are the memory management options explicitly +specified as an argument to facet's constructor. Each constructor of a +facet class takes a std::size_t __refs argument: if __refs == 0, the +facet is deleted when the locale containing it is destroyed. If __refs +== 1, the facet is not destroyed, even when it is no longer +referenced. + + +
+ + +class id +22.1.1.1.3 - Class locale::id + + +
+ + +Provides an index for looking up specific facets. + + + + +Design + + +The major design challenge is fitting an object-orientated and +non-global locale design ontop of POSIX and other relevant stanards, +which include the Single Unix (nee X/Open.) + + + +Because C and earlier versions of POSIX falls down so completely, +portibility is an issue. + + + + + +Implementation + + + Interacting with "C" locales + + + + + `locale -a` displays available locales. + +
+ +af_ZA +ar_AE +ar_AE.utf8 +ar_BH +ar_BH.utf8 +ar_DZ +ar_DZ.utf8 +ar_EG +ar_EG.utf8 +ar_IN +ar_IQ +ar_IQ.utf8 +ar_JO +ar_JO.utf8 +ar_KW +ar_KW.utf8 +ar_LB +ar_LB.utf8 +ar_LY +ar_LY.utf8 +ar_MA +ar_MA.utf8 +ar_OM +ar_OM.utf8 +ar_QA +ar_QA.utf8 +ar_SA +ar_SA.utf8 +ar_SD +ar_SD.utf8 +ar_SY +ar_SY.utf8 +ar_TN +ar_TN.utf8 +ar_YE +ar_YE.utf8 +be_BY +be_BY.utf8 +bg_BG +bg_BG.utf8 +br_FR +bs_BA +C +ca_ES +ca_ES@euro +ca_ES.utf8 +ca_ES.utf8@euro +cs_CZ +cs_CZ.utf8 +cy_GB +da_DK +da_DK.iso885915 +da_DK.utf8 +de_AT +de_AT@euro +de_AT.utf8 +de_AT.utf8@euro +de_BE +de_BE@euro +de_BE.utf8 +de_BE.utf8@euro +de_CH +de_CH.utf8 +de_DE +de_DE@euro +de_DE.utf8 +de_DE.utf8@euro +de_LU +de_LU@euro +de_LU.utf8 +de_LU.utf8@euro +el_GR +el_GR.utf8 +en_AU +en_AU.utf8 +en_BW +en_BW.utf8 +en_CA +en_CA.utf8 +en_DK +en_DK.utf8 +en_GB +en_GB.iso885915 +en_GB.utf8 +en_HK +en_HK.utf8 +en_IE +en_IE@euro +en_IE.utf8 +en_IE.utf8@euro +en_IN +en_NZ +en_NZ.utf8 +en_PH +en_PH.utf8 +en_SG +en_SG.utf8 +en_US +en_US.iso885915 +en_US.utf8 +en_ZA +en_ZA.utf8 +en_ZW +en_ZW.utf8 +es_AR +es_AR.utf8 +es_BO +es_BO.utf8 +es_CL +es_CL.utf8 +es_CO +es_CO.utf8 +es_CR +es_CR.utf8 +es_DO +es_DO.utf8 +es_EC +es_EC.utf8 +es_ES +es_ES@euro +es_ES.utf8 +es_ES.utf8@euro +es_GT +es_GT.utf8 +es_HN +es_HN.utf8 +es_MX +es_MX.utf8 +es_NI +es_NI.utf8 +es_PA +es_PA.utf8 +es_PE +es_PE.utf8 +es_PR +es_PR.utf8 +es_PY +es_PY.utf8 +es_SV +es_SV.utf8 +es_US +es_US.utf8 +es_UY +es_UY.utf8 +es_VE +es_VE.utf8 +et_EE +et_EE.utf8 +eu_ES +eu_ES@euro +eu_ES.utf8 +eu_ES.utf8@euro +fa_IR +fi_FI +fi_FI@euro +fi_FI.utf8 +fi_FI.utf8@euro +fo_FO +fo_FO.utf8 +fr_BE +fr_BE@euro +fr_BE.utf8 +fr_BE.utf8@euro +fr_CA +fr_CA.utf8 +fr_CH +fr_CH.utf8 +fr_FR +fr_FR@euro +fr_FR.utf8 +fr_FR.utf8@euro +fr_LU +fr_LU@euro +fr_LU.utf8 +fr_LU.utf8@euro +ga_IE +ga_IE@euro +ga_IE.utf8 +ga_IE.utf8@euro +gl_ES +gl_ES@euro +gl_ES.utf8 +gl_ES.utf8@euro +gv_GB +gv_GB.utf8 +he_IL +he_IL.utf8 +hi_IN +hr_HR +hr_HR.utf8 +hu_HU +hu_HU.utf8 +id_ID +id_ID.utf8 +is_IS +is_IS.utf8 +it_CH +it_CH.utf8 +it_IT +it_IT@euro +it_IT.utf8 +it_IT.utf8@euro +iw_IL +iw_IL.utf8 +ja_JP.eucjp +ja_JP.utf8 +ka_GE +kl_GL +kl_GL.utf8 +ko_KR.euckr +ko_KR.utf8 +kw_GB +kw_GB.utf8 +lt_LT +lt_LT.utf8 +lv_LV +lv_LV.utf8 +mi_NZ +mk_MK +mk_MK.utf8 +mr_IN +ms_MY +ms_MY.utf8 +mt_MT +mt_MT.utf8 +nl_BE +nl_BE@euro +nl_BE.utf8 +nl_BE.utf8@euro +nl_NL +nl_NL@euro +nl_NL.utf8 +nl_NL.utf8@euro +nn_NO +nn_NO.utf8 +no_NO +no_NO.utf8 +oc_FR +pl_PL +pl_PL.utf8 +POSIX +pt_BR +pt_BR.utf8 +pt_PT +pt_PT@euro +pt_PT.utf8 +pt_PT.utf8@euro +ro_RO +ro_RO.utf8 +ru_RU +ru_RU.koi8r +ru_RU.utf8 +ru_UA +ru_UA.utf8 +se_NO +sk_SK +sk_SK.utf8 +sl_SI +sl_SI.utf8 +sq_AL +sq_AL.utf8 +sr_YU +sr_YU@cyrillic +sr_YU.utf8 +sr_YU.utf8@cyrillic +sv_FI +sv_FI@euro +sv_FI.utf8 +sv_FI.utf8@euro +sv_SE +sv_SE.iso885915 +sv_SE.utf8 +ta_IN +te_IN +tg_TJ +th_TH +th_TH.utf8 +tl_PH +tr_TR +tr_TR.utf8 +uk_UA +uk_UA.utf8 +ur_PK +uz_UZ +vi_VN +vi_VN.tcvn +wa_BE +wa_BE@euro +yi_US +zh_CN +zh_CN.gb18030 +zh_CN.gbk +zh_CN.utf8 +zh_HK +zh_HK.utf8 +zh_TW +zh_TW.euctw +zh_TW.utf8 + +
+ + + + + `locale` displays environmental variables that + impact how locale("") will be deduced. + +
+ +LANG=en_US +LC_CTYPE="en_US" +LC_NUMERIC="en_US" +LC_TIME="en_US" +LC_COLLATE="en_US" +LC_MONETARY="en_US" +LC_MESSAGES="en_US" +LC_PAPER="en_US" +LC_NAME="en_US" +LC_ADDRESS="en_US" +LC_TELEPHONE="en_US" +LC_MEASUREMENT="en_US" +LC_IDENTIFICATION="en_US" +LC_ALL= + +
+ + + + +From Josuttis, p. 697-698, which says, that "there is only *one* +relation (of the C++ locale mechanism) to the C locale mechanism: the +global C locale is modified if a named C++ locale object is set as the +global locale" (emphasis Paolo), that is: + + +std::locale::global(std::locale("")); + +affects the C functions as if the following call was made: + +std::setlocale(LC_ALL, ""); + + + On the other hand, there is *no* viceversa, that is, calling + setlocale has *no* whatsoever on the C++ locale mechanism, in + particular on the working of locale(""), which constructs the locale + object from the environment of the running program, that is, in + practice, the set of LC_ALL, LANG, etc. variable of the shell. + + + + + + +Future + + + + + Locale initialization: at what point does _S_classic, _S_global + get initialized? Can named locales assume this initialization + has already taken place? + + + + + + Document how named locales error check when filling data + members. Ie, a fr_FR locale that doesn't have + numpunct::truename(): does it use "true"? Or is it a blank + string? What's the convention? + + + + + + Explain how locale aliasing happens. When does "de_DE" use "de" + information? What is the rule for locales composed of just an + ISO language code (say, "de") and locales with both an ISO + language code and ISO country code (say, "de_DE"). + + + + + + What should non-required facet instantiations do? If the + generic implemenation is provided, then how to end-users + provide specializations? + + + + + + +Bibliography + + + + The GNU C Library + + + + McGrath + Roland + + + Drepper + Ulrich + + + + 2007 + FSF + + Chapters 6 Character Set Handling and 7 Locales and Internationalization + + + + + + Correspondence + + + + Drepper + Ulrich + + + + 2002 + + + + + + + ISO/IEC 14882:1998 Programming languages - C++ + + + + 1998 + ISO + + + + + + ISO/IEC 9899:1999 Programming languages - C + + + + 1999 + ISO + + + + + + System Interface Definitions, Issue 6 (IEEE Std. 1003.1-200x) + + + + 1999 + + The Open Group/The Institute of Electrical and Electronics Engineers, Inc. + + + + + + + + + + + + The C++ Programming Language, Special Edition + + + + Stroustrup + Bjarne + + + + 2000 + Addison Wesley, Inc. + + Appendix D + + + + Addison Wesley + + + + + + + + + Standard C++ IOStreams and Locales + + + Advanced Programmer's Guide and Reference + + + + Langer + Angelika + + + + Kreft + Klaus + + + + 2000 + Addison Wesley Longman, Inc. + + + + + Addison Wesley Longman + + + + + + + + \ No newline at end of file diff --git a/libstdc++-v3/doc/xml/manual/localization.xml b/libstdc++-v3/doc/xml/manual/localization.xml new file mode 100644 index 00000000000..0c6d82ea762 --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/localization.xml @@ -0,0 +1,54 @@ + + + + + + + + + + ISO C++ + + + library + + + + +Localization + + + + Locales + + + + + + + + + Facets aka Categories + + + + + + + + + + + + + + + + + diff --git a/libstdc++-v3/doc/xml/manual/messages.xml b/libstdc++-v3/doc/xml/manual/messages.xml new file mode 100644 index 00000000000..d32620fb3ad --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/messages.xml @@ -0,0 +1,604 @@ + + + + + + + ISO C++ + + + messages + + + + +messages + + +The std::messages facet implements message retrieval functionality +equivalent to Java's java.text.MessageFormat .using either GNU gettext +or IEEE 1003.1-200 functions. + + + +Requirements + + +The std::messages facet is probably the most vaguely defined facet in +the standard library. It's assumed that this facility was built into +the standard library in order to convert string literals from one +locale to the other. For instance, converting the "C" locale's +const char* c = "please" to a German-localized "bitte" +during program execution. + + +
+ +22.2.7.1 - Template class messages [lib.locale.messages] + +
+ + +This class has three public member functions, which directly +correspond to three protected virtual member functions. + + + +The public member functions are: + + + +catalog open(const string&, const locale&) const + + + +string_type get(catalog, int, int, const string_type&) const + + + +void close(catalog) const + + + +While the virtual functions are: + + + +catalog do_open(const string&, const locale&) const + +
+ + +-1- Returns: A value that may be passed to get() to retrieve a +message, from the message catalog identified by the string name +according to an implementation-defined mapping. The result can be used +until it is passed to close(). Returns a value less than 0 if no such +catalog can be opened. + + +
+ + +string_type do_get(catalog, int, int, const string_type&) const + +
+ + +-3- Requires: A catalog cat obtained from open() and not yet closed. +-4- Returns: A message identified by arguments set, msgid, and dfault, +according to an implementation-defined mapping. If no such message can +be found, returns dfault. + + +
+ + +void do_close(catalog) const + +
+ + +-5- Requires: A catalog cat obtained from open() and not yet closed. +-6- Effects: Releases unspecified resources associated with cat. +-7- Notes: The limit on such resources, if any, is implementation-defined. + + +
+ + + + + +Design + + +A couple of notes on the standard. + + + +First, why is messages_base::catalog specified as a typedef +to int? This makes sense for implementations that use +catopen, but not for others. Fortunately, it's not heavily +used and so only a minor irritant. + + + +Second, by making the member functions const, it is +impossible to save state in them. Thus, storing away information used +in the 'open' member function for use in 'get' is impossible. This is +unfortunate. + + + +The 'open' member function in particular seems to be oddly +designed. The signature seems quite peculiar. Why specify a const +string& argument, for instance, instead of just const +char*? Or, why specify a const locale& argument that is +to be used in the 'get' member function? How, exactly, is this locale +argument useful? What was the intent? It might make sense if a locale +argument was associated with a given default message string in the +'open' member function, for instance. Quite murky and unclear, on +reflection. + + + +Lastly, it seems odd that messages, which explicitly require code +conversion, don't use the codecvt facet. Because the messages facet +has only one template parameter, it is assumed that ctype, and not +codecvt, is to be used to convert between character sets. + + + +It is implicitly assumed that the locale for the default message +string in 'get' is in the "C" locale. Thus, all source code is assumed +to be written in English, so translations are always from "en_US" to +other, explicitly named locales. + + + + + +Implementation + + + Models + + This is a relatively simple class, on the face of it. The standard + specifies very little in concrete terms, so generic + implementations that are conforming yet do very little are the + norm. Adding functionality that would be useful to programmers and + comparable to Java's java.text.MessageFormat takes a bit of work, + and is highly dependent on the capabilities of the underlying + operating system. + + + + Three different mechanisms have been provided, selectable via + configure flags: + + + + + + generic + + + This model does very little, and is what is used by default. + + + + + + gnu + + + The gnu model is complete and fully tested. It's based on the + GNU gettext package, which is part of glibc. It uses the + functions textdomain, bindtextdomain, gettext to + implement full functionality. Creating message catalogs is a + relatively straight-forward process and is lightly documented + below, and fully documented in gettext's distributed + documentation. + + + + + + ieee_1003.1-200x + + + This is a complete, though untested, implementation based on + the IEEE standard. The functions catopen, catgets, + catclose are used to retrieve locale-specific messages + given the appropriate message catalogs that have been + constructed for their use. Note, the script + po2msg.sed that is part of the gettext distribution can + convert gettext catalogs into catalogs that + catopen can use. + + + + + +A new, standards-conformant non-virtual member function signature was +added for 'open' so that a directory could be specified with a given +message catalog. This simplifies calling conventions for the gnu +model. + + + + + + The GNU Model + + + The messages facet, because it is retrieving and converting + between characters sets, depends on the ctype and perhaps the + codecvt facet in a given locale. In addition, underlying "C" + library locale support is necessary for more than just the + LC_MESSAGES mask: LC_CTYPE is also + necessary. To avoid any unpleasantness, all bits of the "C" mask + (ie LC_ALL) are set before retrieving messages. + + + + Making the message catalogs can be initially tricky, but become + quite simple with practice. For complete info, see the gettext + documentation. Here's an idea of what is required: + + + + + + Make a source file with the required string literals that need + to be translated. See intl/string_literals.cc for + an example. + + + + + + Make initial catalog (see "4 Making the PO Template File" from + the gettext docs). + + xgettext --c++ --debug string_literals.cc -o libstdc++.pot + + + + + Make language and country-specific locale catalogs. + + cp libstdc++.pot fr_FR.po + + + cp libstdc++.pot de_DE.po + + + + + + Edit localized catalogs in emacs so that strings are + translated. + + + emacs fr_FR.po + + + + + Make the binary mo files. + + msgfmt fr_FR.po -o fr_FR.mo + + + msgfmt de_DE.po -o de_DE.mo + + + + + Copy the binary files into the correct directory structure. + + cp fr_FR.mo (dir)/fr_FR/LC_MESSAGES/libstdc++.mo + + + cp de_DE.mo (dir)/de_DE/LC_MESSAGES/libstdc++.mo + + + + + Use the new message catalogs. + + locale loc_de("de_DE"); + + + + use_facet<messages<char> >(loc_de).open("libstdc++", locale(), dir); + + + + + + + + + +Use + + A simple example using the GNU model of message conversion. + + + +#include <iostream> +#include <locale> +using namespace std; + +void test01() +{ + typedef messages<char>::catalog catalog; + const char* dir = + "/mnt/egcs/build/i686-pc-linux-gnu/libstdc++/po/share/locale"; + const locale loc_de("de_DE"); + const messages<char>& mssg_de = use_facet<messages<char> >(loc_de); + + catalog cat_de = mssg_de.open("libstdc++", loc_de, dir); + string s01 = mssg_de.get(cat_de, 0, 0, "please"); + string s02 = mssg_de.get(cat_de, 0, 0, "thank you"); + cout << "please in german:" << s01 << '\n'; + cout << "thank you in german:" << s02 << '\n'; + mssg_de.close(cat_de); +} + + + + + +Future + + + + + Things that are sketchy, or remain unimplemented: + + + + + _M_convert_from_char, _M_convert_to_char are in flux, + depending on how the library ends up doing character set + conversions. It might not be possible to do a real character + set based conversion, due to the fact that the template + parameter for messages is not enough to instantiate the + codecvt facet (1 supplied, need at least 2 but would prefer + 3). + + + + + + There are issues with gettext needing the global locale set + to extract a message. This dependence on the global locale + makes the current "gnu" model non MT-safe. Future versions + of glibc, ie glibc 2.3.x will fix this, and the C++ library + bits are already in place. + + + + + + + + Development versions of the GNU "C" library, glibc 2.3 will allow + a more efficient, MT implementation of std::messages, and will + allow the removal of the _M_name_messages data member. If this is + done, it will change the library ABI. The C++ parts to support + glibc 2.3 have already been coded, but are not in use: once this + version of the "C" library is released, the marked parts of the + messages implementation can be switched over to the new "C" + library functionality. + + + + + At some point in the near future, std::numpunct will probably use + std::messages facilities to implement truename/falename + correctly. This is currently not done, but entries in + libstdc++.pot have already been made for "true" and "false" string + literals, so all that remains is the std::numpunct coding and the + configure/make hassles to make the installed library search its + own catalog. Currently the libstdc++.mo catalog is only searched + for the testsuite cases involving messages members. + + + + + The following member functions: + + + + catalog + open(const basic_string<char>& __s, const locale& __loc) const + + + + + + catalog + open(const basic_string<char>&, const locale&, const char*) const; + + + + + Don't actually return a "value less than 0 if no such catalog + can be opened" as required by the standard in the "gnu" + model. As of this writing, it is unknown how to query to see + if a specified message catalog exists using the gettext + package. + + + + + + + +Bibliography + + + + The GNU C Library + + + + McGrath + Roland + + + Drepper + Ulrich + + + + 2007 + FSF + + Chapters 6 Character Set Handling, and 7 Locales and Internationalization + + + + + + + Correspondence + + + + Drepper + Ulrich + + + + 2002 + + + + + + + ISO/IEC 14882:1998 Programming languages - C++ + + + + 1998 + ISO + + + + + + ISO/IEC 9899:1999 Programming languages - C + + + + 1999 + ISO + + + + + + System Interface Definitions, Issue 6 (IEEE Std. 1003.1-200x) + + + + 1999 + + The Open Group/The Institute of Electrical and Electronics Engineers, Inc. + + + + + + + + + + + + The C++ Programming Language, Special Edition + + + + Stroustrup + Bjarne + + + + 2000 + Addison Wesley, Inc. + + Appendix D + + + + Addison Wesley + + + + + + + + + Standard C++ IOStreams and Locales + + + Advanced Programmer's Guide and Reference + + + + Langer + Angelika + + + + Kreft + Klaus + + + + 2000 + Addison Wesley Longman, Inc. + + + + + Addison Wesley Longman + + + + + + + + Java 2 Platform, Standard Edition, v 1.3.1 API Specification + + java.util.Properties, java.text.MessageFormat, +java.util.Locale, java.util.ResourceBundle + + + + + + + + + GNU gettext tools, version 0.10.38, Native Language Support +Library and Tools. + + + + + + + + + + \ No newline at end of file diff --git a/libstdc++-v3/doc/xml/manual/mt_allocator.xml b/libstdc++-v3/doc/xml/manual/mt_allocator.xml new file mode 100644 index 00000000000..48f5c2fe502 --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/mt_allocator.xml @@ -0,0 +1,554 @@ + + + + + + + ISO C++ + + + allocator + + + + +mt_allocator + + + + + +Intro + + + The mt allocator [hereinafter referred to simply as "the allocator"] + is a fixed size (power of two) allocator that was initially + developed specifically to suit the needs of multi threaded + applications [hereinafter referred to as an MT application]. Over + time the allocator has evolved and been improved in many ways, in + particular it now also does a good job in single threaded + applications [hereinafter referred to as a ST application]. (Note: + In this document, when referring to single threaded applications + this also includes applications that are compiled with gcc without + thread support enabled. This is accomplished using ifdef's on + __GTHREADS). This allocator is tunable, very flexible, and capable + of high-performance. + + + + The aim of this document is to describe - from an application point of + view - the "inner workings" of the allocator. + + + + + + +Design Issues + + +Overview + + + There are three general components to the allocator: a datum +describing the characteristics of the memory pool, a policy class +containing this pool that links instantiation types to common or +individual pools, and a class inheriting from the policy class that is +the actual allocator. + + +The datum describing pools characteristics is + + + template<bool _Thread> + class __pool + + This class is parametrized on thread support, and is explicitly +specialized for both multiple threads (with bool==true) +and single threads (via bool==false.) It is possible to +use a custom pool datum instead of the default class that is provided. + + + There are two distinct policy classes, each of which can be used +with either type of underlying pool datum. + + + + template<bool _Thread> + struct __common_pool_policy + + template<typename _Tp, bool _Thread> + struct __per_type_pool_policy + + + The first policy, __common_pool_policy, implements a +common pool. This means that allocators that are instantiated with +different types, say char and long will both +use the same pool. This is the default policy. + + + The second policy, __per_type_pool_policy, implements +a separate pool for each instantiating type. Thus, char +and long will use separate pools. This allows per-type +tuning, for instance. + + + Putting this all together, the actual allocator class is + + + template<typename _Tp, typename _Poolp = __default_policy> + class __mt_alloc : public __mt_alloc_base<_Tp>, _Poolp + + This class has the interface required for standard library allocator +classes, namely member functions allocate and +deallocate, plus others. + + + + + + +Implementation + + + +Tunable Parameters + +Certain allocation parameters can be modified, or tuned. There +exists a nested struct __pool_base::_Tune that contains all +these parameters, which include settings for + + + Alignment + Maximum bytes before calling ::operator new directly + Minimum bytes + Size of underlying global allocations + Maximum number of supported threads + Migration of deallocations to the global free list + Shunt for global new and delete + +Adjusting parameters for a given instance of an allocator can only +happen before any allocations take place, when the allocator itself is +initialized. For instance: + + +#include <ext/mt_allocator.h> + +struct pod +{ + int i; + int j; +}; + +int main() +{ + typedef pod value_type; + typedef __gnu_cxx::__mt_alloc<value_type> allocator_type; + typedef __gnu_cxx::__pool_base::_Tune tune_type; + + tune_type t_default; + tune_type t_opt(16, 5120, 32, 5120, 20, 10, false); + tune_type t_single(16, 5120, 32, 5120, 1, 10, false); + + tune_type t; + t = allocator_type::_M_get_options(); + allocator_type::_M_set_options(t_opt); + t = allocator_type::_M_get_options(); + + allocator_type a; + allocator_type::pointer p1 = a.allocate(128); + allocator_type::pointer p2 = a.allocate(5128); + + a.deallocate(p1, 128); + a.deallocate(p2, 5128); + + return 0; +} + + + + + +Initialization + + +The static variables (pointers to freelists, tuning parameters etc) +are initialized as above, or are set to the global defaults. + + + +The very first allocate() call will always call the +_S_initialize_once() function. In order to make sure that this +function is called exactly once we make use of a __gthread_once call +in MT applications and check a static bool (_S_init) in ST +applications. + + + +The _S_initialize() function: +- If the GLIBCXX_FORCE_NEW environment variable is set, it sets the bool + _S_force_new to true and then returns. This will cause subsequent calls to + allocate() to return memory directly from a new() call, and deallocate will + only do a delete() call. + + + +- If the GLIBCXX_FORCE_NEW environment variable is not set, both ST and MT + applications will: + - Calculate the number of bins needed. A bin is a specific power of two size + of bytes. I.e., by default the allocator will deal with requests of up to + 128 bytes (or whatever the value of _S_max_bytes is when _S_init() is + called). This means that there will be bins of the following sizes + (in bytes): 1, 2, 4, 8, 16, 32, 64, 128. + + - Create the _S_binmap array. All requests are rounded up to the next + "large enough" bin. I.e., a request for 29 bytes will cause a block from + the "32 byte bin" to be returned to the application. The purpose of + _S_binmap is to speed up the process of finding out which bin to use. + I.e., the value of _S_binmap[ 29 ] is initialized to 5 (bin 5 = 32 bytes). + + + - Create the _S_bin array. This array consists of bin_records. There will be + as many bin_records in this array as the number of bins that we calculated + earlier. I.e., if _S_max_bytes = 128 there will be 8 entries. + Each bin_record is then initialized: + - bin_record->first = An array of pointers to block_records. There will be + as many block_records pointers as there are maximum number of threads + (in a ST application there is only 1 thread, in a MT application there + are _S_max_threads). + This holds the pointer to the first free block for each thread in this + bin. I.e., if we would like to know where the first free block of size 32 + for thread number 3 is we would look this up by: _S_bin[ 5 ].first[ 3 ] + + The above created block_record pointers members are now initialized to + their initial values. I.e. _S_bin[ n ].first[ n ] = NULL; + + + +- Additionally a MT application will: + - Create a list of free thread id's. The pointer to the first entry + is stored in _S_thread_freelist_first. The reason for this approach is + that the __gthread_self() call will not return a value that corresponds to + the maximum number of threads allowed but rather a process id number or + something else. So what we do is that we create a list of thread_records. + This list is _S_max_threads long and each entry holds a size_t thread_id + which is initialized to 1, 2, 3, 4, 5 and so on up to _S_max_threads. + Each time a thread calls allocate() or deallocate() we call + _S_get_thread_id() which looks at the value of _S_thread_key which is a + thread local storage pointer. If this is NULL we know that this is a newly + created thread and we pop the first entry from this list and saves the + pointer to this record in the _S_thread_key variable. The next time + we will get the pointer to the thread_record back and we use the + thread_record->thread_id as identification. I.e., the first thread that + calls allocate will get the first record in this list and thus be thread + number 1 and will then find the pointer to its first free 32 byte block + in _S_bin[ 5 ].first[ 1 ] + When we create the _S_thread_key we also define a destructor + (_S_thread_key_destr) which means that when the thread dies, this + thread_record is returned to the front of this list and the thread id + can then be reused if a new thread is created. + This list is protected by a mutex (_S_thread_freelist_mutex) which is only + locked when records are removed or added to the list. + + + - Initialize the free and used counters of each bin_record: + - bin_record->free = An array of size_t. This keeps track of the number + of blocks on a specific thread's freelist in each bin. I.e., if a thread + has 12 32-byte blocks on it's freelists and allocates one of these, this + counter would be decreased to 11. + + - bin_record->used = An array of size_t. This keeps track of the number + of blocks currently in use of this size by this thread. I.e., if a thread + has made 678 requests (and no deallocations...) of 32-byte blocks this + counter will read 678. + + The above created arrays are now initialized with their initial values. + I.e. _S_bin[ n ].free[ n ] = 0; + + + - Initialize the mutex of each bin_record: The bin_record->mutex + is used to protect the global freelist. This concept of a global + freelist is explained in more detail in the section "A multi + threaded example", but basically this mutex is locked whenever a + block of memory is retrieved or returned to the global freelist + for this specific bin. This only occurs when a number of blocks + are grabbed from the global list to a thread specific list or when + a thread decides to return some blocks to the global freelist. + + + + + +Deallocation Notes + + Notes about deallocation. This allocator does not explicitly +release memory. Because of this, memory debugging programs like +valgrind or purify may notice leaks: sorry about this +inconvenience. Operating systems will reclaim allocated memory at +program termination anyway. If sidestepping this kind of noise is +desired, there are three options: use an allocator, like +new_allocator that releases memory while debugging, use +GLIBCXX_FORCE_NEW to bypass the allocator's internal pools, or use a +custom pool datum that releases resources on destruction. + + + + On systems with the function __cxa_atexit, the +allocator can be forced to free all memory allocated before program +termination with the member function +__pool_type::_M_destroy. However, because this member +function relies on the precise and exactly-conforming ordering of +static destructors, including those of a static local +__pool object, it should not be used, ever, on systems +that don't have the necessary underlying support. In addition, in +practice, forcing deallocation can be tricky, as it requires the +__pool object to be fully-constructed before the object +that uses it is fully constructed. For most (but not all) STL +containers, this works, as an instance of the allocator is constructed +as part of a container's constructor. However, this assumption is +implementation-specific, and subject to change. For an example of a +pool that frees memory, see the following + + example. + + + + + + + +Single Thread Example + + +Let's start by describing how the data on a freelist is laid out in memory. +This is the first two blocks in freelist for thread id 3 in bin 3 (8 bytes): + + ++----------------+ +| next* ---------|--+ (_S_bin[ 3 ].first[ 3 ] points here) +| | | +| | | +| | | ++----------------+ | +| thread_id = 3 | | +| | | +| | | +| | | ++----------------+ | +| DATA | | (A pointer to here is what is returned to the +| | | the application when needed) +| | | +| | | +| | | +| | | +| | | +| | | ++----------------+ | ++----------------+ | +| next* |<-+ (If next == NULL it's the last one on the list) +| | +| | +| | ++----------------+ +| thread_id = 3 | +| | +| | +| | ++----------------+ +| DATA | +| | +| | +| | +| | +| | +| | +| | ++----------------+ + + + +With this in mind we simplify things a bit for a while and say that there is +only one thread (a ST application). In this case all operations are made to +what is referred to as the global pool - thread id 0 (No thread may be +assigned this id since they span from 1 to _S_max_threads in a MT application). + + +When the application requests memory (calling allocate()) we first look at the +requested size and if this is > _S_max_bytes we call new() directly and return. + + +If the requested size is within limits we start by finding out from which +bin we should serve this request by looking in _S_binmap. + + +A quick look at _S_bin[ bin ].first[ 0 ] tells us if there are any blocks of +this size on the freelist (0). If this is not NULL - fine, just remove the +block that _S_bin[ bin ].first[ 0 ] points to from the list, +update _S_bin[ bin ].first[ 0 ] and return a pointer to that blocks data. + + +If the freelist is empty (the pointer is NULL) we must get memory from the +system and build us a freelist within this memory. All requests for new memory +is made in chunks of _S_chunk_size. Knowing the size of a block_record and +the bytes that this bin stores we then calculate how many blocks we can create +within this chunk, build the list, remove the first block, update the pointer +(_S_bin[ bin ].first[ 0 ]) and return a pointer to that blocks data. + + + +Deallocation is equally simple; the pointer is casted back to a block_record +pointer, lookup which bin to use based on the size, add the block to the front +of the global freelist and update the pointer as needed +(_S_bin[ bin ].first[ 0 ]). + + + +The decision to add deallocated blocks to the front of the freelist was made +after a set of performance measurements that showed that this is roughly 10% +faster than maintaining a set of "last pointers" as well. + + + + + +Multiple Thread Example + + +In the ST example we never used the thread_id variable present in each block. +Let's start by explaining the purpose of this in a MT application. + + + +The concept of "ownership" was introduced since many MT applications +allocate and deallocate memory to shared containers from different +threads (such as a cache shared amongst all threads). This introduces +a problem if the allocator only returns memory to the current threads +freelist (I.e., there might be one thread doing all the allocation and +thus obtaining ever more memory from the system and another thread +that is getting a longer and longer freelist - this will in the end +consume all available memory). + + + +Each time a block is moved from the global list (where ownership is +irrelevant), to a threads freelist (or when a new freelist is built +from a chunk directly onto a threads freelist or when a deallocation +occurs on a block which was not allocated by the same thread id as the +one doing the deallocation) the thread id is set to the current one. + + + +What's the use? Well, when a deallocation occurs we can now look at +the thread id and find out if it was allocated by another thread id +and decrease the used counter of that thread instead, thus keeping the +free and used counters correct. And keeping the free and used counters +corrects is very important since the relationship between these two +variables decides if memory should be returned to the global pool or +not when a deallocation occurs. + + + +When the application requests memory (calling allocate()) we first +look at the requested size and if this is >_S_max_bytes we call new() +directly and return. + + + +If the requested size is within limits we start by finding out from which +bin we should serve this request by looking in _S_binmap. + + + +A call to _S_get_thread_id() returns the thread id for the calling thread +(and if no value has been set in _S_thread_key, a new id is assigned and +returned). + + + +A quick look at _S_bin[ bin ].first[ thread_id ] tells us if there are +any blocks of this size on the current threads freelist. If this is +not NULL - fine, just remove the block that _S_bin[ bin ].first[ +thread_id ] points to from the list, update _S_bin[ bin ].first[ +thread_id ], update the free and used counters and return a pointer to +that blocks data. + + + +If the freelist is empty (the pointer is NULL) we start by looking at +the global freelist (0). If there are blocks available on the global +freelist we lock this bins mutex and move up to block_count (the +number of blocks of this bins size that will fit into a _S_chunk_size) +or until end of list - whatever comes first - to the current threads +freelist and at the same time change the thread_id ownership and +update the counters and pointers. When the bins mutex has been +unlocked, we remove the block that _S_bin[ bin ].first[ thread_id ] +points to from the list, update _S_bin[ bin ].first[ thread_id ], +update the free and used counters, and return a pointer to that blocks +data. + + + +The reason that the number of blocks moved to the current threads +freelist is limited to block_count is to minimize the chance that a +subsequent deallocate() call will return the excess blocks to the +global freelist (based on the _S_freelist_headroom calculation, see +below). + + + +However if there isn't any memory on the global pool we need to get +memory from the system - this is done in exactly the same way as in a +single threaded application with one major difference; the list built +in the newly allocated memory (of _S_chunk_size size) is added to the +current threads freelist instead of to the global. + + + +The basic process of a deallocation call is simple: always add the +block to the front of the current threads freelist and update the +counters and pointers (as described earlier with the specific check of +ownership that causes the used counter of the thread that originally +allocated the block to be decreased instead of the current threads +counter). + + + +And here comes the free and used counters to service. Each time a +deallocation() call is made, the length of the current threads +freelist is compared to the amount memory in use by this thread. + + + +Let's go back to the example of an application that has one thread +that does all the allocations and one that deallocates. Both these +threads use say 516 32-byte blocks that was allocated during thread +creation for example. Their used counters will both say 516 at this +point. The allocation thread now grabs 1000 32-byte blocks and puts +them in a shared container. The used counter for this thread is now +1516. + + + +The deallocation thread now deallocates 500 of these blocks. For each +deallocation made the used counter of the allocating thread is +decreased and the freelist of the deallocation thread gets longer and +longer. But the calculation made in deallocate() will limit the length +of the freelist in the deallocation thread to _S_freelist_headroom % +of it's used counter. In this case, when the freelist (given that the +_S_freelist_headroom is at it's default value of 10%) exceeds 52 +(516/10) blocks will be returned to the global pool where the +allocating thread may pick them up and reuse them. + + + +In order to reduce lock contention (since this requires this bins +mutex to be locked) this operation is also made in chunks of blocks +(just like when chunks of blocks are moved from the global freelist to +a threads freelist mentioned above). The "formula" used can probably +be improved to further reduce the risk of blocks being "bounced back +and forth" between freelists. + + + + + \ No newline at end of file diff --git a/libstdc++-v3/doc/xml/manual/numerics.xml b/libstdc++-v3/doc/xml/manual/numerics.xml new file mode 100644 index 00000000000..835cd1e7454 --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/numerics.xml @@ -0,0 +1,143 @@ + + + + + + + + + + ISO C++ + + + library + + + + +Numerics + + + + Complex + + + + complex Processing + + + Using complex<> becomes even more comple- er, sorry, + complicated, with the not-quite-gratuitously-incompatible + addition of complex types to the C language. David Tribble has + compiled a list of C++98 and C99 conflict points; his description of + C's new type versus those of C++ and how to get them playing together + nicely is +here. + + complex<> is intended to be instantiated with a + floating-point type. As long as you meet that and some other basic + requirements, then the resulting instantiation has all of the usual + math operators defined, as well as definitions of op<< + and op>> that work with iostreams: op<< + prints (u,v) and op>> can read u, + (u), and (u,v). + + + + + + + + Generalized Operations + + + + There are four generalized functions in the <numeric> header + that follow the same conventions as those in <algorithm>. Each + of them is overloaded: one signature for common default operations, + and a second for fully general operations. Their names are + self-explanatory to anyone who works with numerics on a regular basis: + + + accumulate + inner_product + partial_sum + adjacent_difference + + Here is a simple example of the two forms of accumulate. + + + int ar[50]; + int someval = somefunction(); + + // ...initialize members of ar to something... + + int sum = std::accumulate(ar,ar+50,0); + int sum_stuff = std::accumulate(ar,ar+50,someval); + int product = std::accumulate(ar,ar+50,1,std::multiplies<int>()); + + The first call adds all the members of the array, using zero as an + initial value for sum. The second does the same, but uses + someval as the starting value (thus, sum_stuff == sum + + someval). The final call uses the second of the two signatures, + and multiplies all the members of the array; here we must obviously + use 1 as a starting value instead of 0. + + The other three functions have similar dual-signature forms. + + + + + + + Interacting with C + + + Numerics vs. Arrays + + One of the major reasons why FORTRAN can chew through numbers so well + is that it is defined to be free of pointer aliasing, an assumption + that C89 is not allowed to make, and neither is C++98. C99 adds a new + keyword, restrict, to apply to individual pointers. The + C++ solution is contained in the library rather than the language + (although many vendors can be expected to add this to their compilers + as an extension). + + That library solution is a set of two classes, five template classes, + and "a whole bunch" of functions. The classes are required + to be free of pointer aliasing, so compilers can optimize the + daylights out of them the same way that they have been for FORTRAN. + They are collectively called valarray, although strictly + speaking this is only one of the five template classes, and they are + designed to be familiar to people who have worked with the BLAS + libraries before. + + + + + + C99 + + In addition to the other topics on this page, we'll note here some + of the C99 features that appear in libstdc++. + + The C99 features depend on the --enable-c99 configure flag. + This flag is already on by default, but it can be disabled by the + user. Also, the configuration machinery will disable it if the + necessary support for C99 (e.g., header files) cannot be found. + + As of GCC 3.0, C99 support includes classification functions + such as isnormal, isgreater, + isnan, etc. + The functions used for 'long long' support such as strtoll + are supported, as is the lldiv_t typedef. Also supported + are the wide character functions using 'long long', like + wcstoll. + + + + + + diff --git a/libstdc++-v3/doc/xml/manual/parallel_mode.xml b/libstdc++-v3/doc/xml/manual/parallel_mode.xml new file mode 100644 index 00000000000..4236f63c8b1 --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/parallel_mode.xml @@ -0,0 +1,674 @@ + + + + + + + + + + C++ + + + library + + + parallel + + + + +Parallel Mode + + The libstdc++ parallel mode is an experimental parallel +implementation of many algorithms the C++ Standard Library. + + + +Several of the standard algorithms, for instance +std::sort, are made parallel using OpenMP +annotations. These parallel mode constructs and can be invoked by +explicit source declaration or by compiling existing sources with a +specific compiler flag. + + + + + Intro + +The following library components in the include +<numeric> are included in the parallel mode: + + std::accumulate + std::adjacent_difference + std::inner_product + std::partial_sum + + +The following library components in the include +<algorithm> are included in the parallel mode: + + std::adjacent_find + std::count + std::count_if + std::equal + std::find + std::find_if + std::find_first_of + std::for_each + std::generate + std::generate_n + std::lexicographical_compare + std::mismatch + std::search + std::search_n + std::transform + std::replace + std::replace_if + std::max_element + std::merge + std::min_element + std::nth_element + std::partial_sort + std::partition + std::random_shuffle + std::set_union + std::set_intersection + std::set_symmetric_difference + std::set_difference + std::sort + std::stable_sort + std::unique_copy + + +The following library components in the includes +<set> and <map> are included in the parallel mode: + + std::(multi_)map/set<T>::(multi_)map/set(Iterator begin, Iterator end) (bulk construction) + std::(multi_)map/set<T>::insert(Iterator begin, Iterator end) (bulk insertion) + + + + + + Semantics + + The parallel mode STL algorithms are currently not exception-safe, +i. e. user-defined functors must not throw exceptions. + + + Since the current GCC OpenMP implementation does not support +OpenMP parallel regions in concurrent threads, +it is not possible to call parallel STL algorithm in +concurrent threads, either. +It might work with other compilers, though. + + + + + Using + + + Using Parallel Mode + +To use the libstdc++ parallel mode, compile your application with + the compiler flag -D_GLIBCXX_PARALLEL -fopenmp. This + will link in libgomp, the GNU OpenMP implementation, + whose presence is mandatory. In addition, hardware capable of atomic + operations is mandatory. Actually activating these atomic + operations may require explicit compiler flags on some targets + (like sparc and x86), such as -march=i686, + -march=native or -mcpu=v9. + + +Note that the _GLIBCXX_PARALLEL define may change the + sizes and behavior of standard class templates such as + std::search, and therefore one can only link code + compiled with parallel mode and code compiled without parallel mode + if no instantiation of a container is passed between the two + translation units. Parallel mode functionality has distinct linkage, + and cannot be confused with normal mode symbols. + + + + Using Specific Parallel Components + +When it is not feasible to recompile your entire application, or + only specific algorithms need to be parallel-aware, individual + parallel algorithms can be made available explicitly. These + parallel algorithms are functionally equivalent to the standard + drop-in algorithms used in parallel mode, but they are available in + a separate namespace as GNU extensions and may be used in programs + compiled with either release mode or with parallel mode. The + following table provides the names and headers of the parallel + algorithms: + + + +Parallel Algorithms + + + + + + + + + Algorithm + Header + Parallel algorithm + Parallel header + + + + + + std::accumulate + numeric + __gnu_parallel::accumulate + parallel/numeric + + + std::adjacent_difference + numeric + __gnu_parallel::adjacent_difference + parallel/numeric + + + std::inner_product + numeric + __gnu_parallel::inner_product + parallel/numeric + + + std::partial_sum + numeric + __gnu_parallel::partial_sum + parallel/numeric + + + std::adjacent_find + algorithm + __gnu_parallel::adjacent_find + parallel/algorithm + + + + std::count + algorithm + __gnu_parallel::count + parallel/algorithm + + + + std::count_if + algorithm + __gnu_parallel::count_if + parallel/algorithm + + + + std::equal + algorithm + __gnu_parallel::equal + parallel/algorithm + + + + std::find + algorithm + __gnu_parallel::find + parallel/algorithm + + + + std::find_if + algorithm + __gnu_parallel::find_if + parallel/algorithm + + + + std::find_first_of + algorithm + __gnu_parallel::find_first_of + parallel/algorithm + + + + std::for_each + algorithm + __gnu_parallel::for_each + parallel/algorithm + + + + std::generate + algorithm + __gnu_parallel::generate + parallel/algorithm + + + + std::generate_n + algorithm + __gnu_parallel::generate_n + parallel/algorithm + + + + std::lexicographical_compare + algorithm + __gnu_parallel::lexicographical_compare + parallel/algorithm + + + + std::mismatch + algorithm + __gnu_parallel::mismatch + parallel/algorithm + + + + std::search + algorithm + __gnu_parallel::search + parallel/algorithm + + + + std::search_n + algorithm + __gnu_parallel::search_n + parallel/algorithm + + + + std::transform + algorithm + __gnu_parallel::transform + parallel/algorithm + + + + std::replace + algorithm + __gnu_parallel::replace + parallel/algorithm + + + + std::replace_if + algorithm + __gnu_parallel::replace_if + parallel/algorithm + + + + std::max_element + algorithm + __gnu_parallel::max_element + parallel/algorithm + + + + std::merge + algorithm + __gnu_parallel::merge + parallel/algorithm + + + + std::min_element + algorithm + __gnu_parallel::min_element + parallel/algorithm + + + + std::nth_element + algorithm + __gnu_parallel::nth_element + parallel/algorithm + + + + std::partial_sort + algorithm + __gnu_parallel::partial_sort + parallel/algorithm + + + + std::partition + algorithm + __gnu_parallel::partition + parallel/algorithm + + + + std::random_shuffle + algorithm + __gnu_parallel::random_shuffle + parallel/algorithm + + + + std::set_union + algorithm + __gnu_parallel::set_union + parallel/algorithm + + + + std::set_intersection + algorithm + __gnu_parallel::set_intersection + parallel/algorithm + + + + std::set_symmetric_difference + algorithm + __gnu_parallel::set_symmetric_difference + parallel/algorithm + + + + std::set_difference + algorithm + __gnu_parallel::set_difference + parallel/algorithm + + + + std::sort + algorithm + __gnu_parallel::sort + parallel/algorithm + + + + std::stable_sort + algorithm + __gnu_parallel::stable_sort + parallel/algorithm + + + + std::unique_copy + algorithm + __gnu_parallel::unique_copy + parallel/algorithm + + + +
+ + + + + + + Design + + + + Interface Basics + + +All parallel algorithms are intended to have signatures that are +equivalent to the ISO C++ algorithms replaced. For instance, the +std::adjacent_find function is declared as: + + +namespace std +{ + template<typename _FIter> + _FIter + adjacent_find(_FIter, _FIter); +} + + + +Which means that there should be something equivalent for the parallel +version. Indeed, this is the case: + + + +namespace std +{ + namespace __parallel + { + template<typename _FIter> + _FIter + adjacent_find(_FIter, _FIter); + + ... + } +} + + +But.... why the elipses? + + + The elipses in the example above represent additional overloads +required for the parallel version of the function. These additional +overloads are used to dispatch calls from the ISO C++ function +signature to the appropriate parallel function (or sequential +function, if no parallel functions are deemed worthy), based on either +compile-time or run-time conditions. + + + Compile-time conditions are referred to as "embarrassingly +parallel," and are denoted with the appropriate dispatch object, ie +one of __gnu_parallel::sequential_tag, +__gnu_parallel::parallel_tag, +__gnu_parallel::balanced_tag, +__gnu_parallel::unbalanced_tag, +__gnu_parallel::omp_loop_tag, or +__gnu_parallel::omp_loop_static_tag. + + + Run-time conditions depend on the hardware being used, the number +of threads available, etc., and are denoted by the use of the enum +__gnu_parallel::parallelism. Values of this enum include +__gnu_parallel::sequential, +__gnu_parallel::parallel_unbalanced, +__gnu_parallel::parallel_balanced, +__gnu_parallel::parallel_omp_loop, +__gnu_parallel::parallel_omp_loop_static, or +__gnu_parallel::parallel_taskqueue. + + + Putting all this together, the general view of overloads for the +parallel algorithms look like this: + + + ISO C++ signature + ISO C++ signature + sequential_tag argument + ISO C++ signature + parallelism argument + + + Please note that the implementation may use additional functions +(designated with the _switch suffix) to dispatch from the +ISO C++ signature to the correct parallel version. Also, some of the +algorithms do not have support for run-time conditions, so the last +overload is therefore missing. + + + + + + + Configuration and Tuning + + Some algorithm variants can be enabled/disabled/selected at compile-time. +See +<compiletime_settings.h> and +See +<features.h> for details. + + + +To specify the number of threads to be used for an algorithm, +use omp_set_num_threads. +To force a function to execute sequentially, +even though parallelism is switched on in general, +add __gnu_parallel::sequential_tag() +to the end of the argument list. + + + +Parallelism always incurs some overhead. Thus, it is not +helpful to parallelize operations on very small sets of data. +There are measures to avoid parallelizing stuff that is not worth it. +For each algorithm, a minimum problem size can be stated, +usually using the variable +__gnu_parallel::Settings::[algorithm]_minimal_n. +Please see +<settings.h> for details. + + + + + + Implementation Namespaces + + One namespace contain versions of code that are explicitly sequential: +__gnu_serial. + + + Two namespaces contain the parallel mode: +std::__parallel and __gnu_parallel. + + + Parallel implementations of standard components, including +template helpers to select parallelism, are defined in namespace +std::__parallel. For instance, std::transform from +<algorithm> has a parallel counterpart in +std::__parallel::transform from +<parallel/algorithm>. In addition, these parallel +implementations are injected into namespace +__gnu_parallel with using declarations. + + + Support and general infrastructure is in namespace +__gnu_parallel. + + + More information, and an organized index of types and functions +related to the parallel mode on a per-namespace basis, can be found in +the generated source documentation. + + + + + + + + Testing + + + Both the normal conformance and regression tests and the + supplemental performance tests work. + + + + To run the conformance and regression tests with the parallel mode + active, + + + + make check-parallel + + + + The log and summary files for conformance testing are in the + testsuite/parallel directory. + + + + To run the performance tests with the parallel mode active, + + + + check-performance-parallel + + + + The result file for performance testing are in the + testsuite directory, in the file + libstdc++_performance.sum. In addition, the + policy-based containers have their own visualizations, which have + additional software dependencies than the usual bare-boned text + file, and can be generated by using the make + doc-performance rule in the testsuite's Makefile. + + + + +Bibliography + + + + Parallelization of Bulk Operations for STL Dictionaries + + + + Johannes + Singler + + + Leonor + Frias + + + + 2007 + + + + + + Workshop on Highly Parallel Processing on a Chip (HPPC) 2007. (LNCS) + + + + + + + The Multi-Core Standard Template Library + + + + Johannes + Singler + + + Peter + Sanders + + + Felix + Putze + + + + 2007 + + + + + + Euro-Par 2007: Parallel Processing. (LNCS 4641) + + + + + + + diff --git a/libstdc++-v3/doc/xml/manual/shared_ptr.xml b/libstdc++-v3/doc/xml/manual/shared_ptr.xml new file mode 100644 index 00000000000..cd517f1250a --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/shared_ptr.xml @@ -0,0 +1,580 @@ + + + + + + + ISO C++ + + + shared_ptr + + + + +shared_ptr + + +The shared_ptr class template stores a pointer, usually obtained via new, +and implements shared ownership semantics. + + + +Requirements + + + + + + The standard deliberately doesn't require a reference-counted + implementation, allowing other techniques such as a + circular-linked-list. + + + + At the time of writing the C++0x working paper doesn't mention how + threads affect shared_ptr, but it is likely to follow the existing + practice set by boost::shared_ptr. The + shared_ptr in libstdc++ is derived from Boost's, so the same rules + apply. + + + + + + + +Design Issues + + + +The shared_ptr code is kindly donated to GCC by the Boost +project and the original authors of the code. The basic design and +algorithms are from Boost, the notes below describe details specific to +the GCC implementation. Names have been uglified in this implementation, +but the design should be recognisable to anyone familiar with the Boost +1.32 shared_ptr. + + + +The basic design is an abstract base class, _Sp_counted_base that +does the reference-counting and calls virtual functions when the count +drops to zero. +Derived classes override those functions to destroy resources in a context +where the correct dynamic type is known. This is an application of the +technique known as type erasure. + + + + + +Implementation + + + Class Hierarchy + + +A shared_ptr<T> contains a pointer of +type T* and an object of type +__shared_count. The shared_count contains a +pointer of type _Sp_counted_base* which points to the +object that maintains the reference-counts and destroys the managed +resource. + + + + + + _Sp_counted_base<Lp> + + +The base of the hierarchy is parameterized on the lock policy alone. +_Sp_counted_base doesn't depend on the type of pointer being managed, +it only maintains the reference counts and calls virtual functions when +the counts drop to zero. The managed object is destroyed when the last +strong reference is dropped, but the _Sp_counted_base itself must exist +until the last weak reference is dropped. + + + + + + _Sp_counted_base_impl<Ptr, Deleter, Lp> + + +Inherits from _Sp_counted_base and stores a pointer of type Ptr +and a deleter of type Deleter. _Sp_deleter is +used when the user doesn't supply a custom deleter. Unlike Boost's, this +default deleter is not "checked" because GCC already issues a warning if +delete is used with an incomplete type. +This is the only derived type used by shared_ptr<Ptr> +and it is never used by shared_ptr, which uses one of +the following types, depending on how the shared_ptr is constructed. + + + + + + _Sp_counted_ptr<Ptr, Lp> + + +Inherits from _Sp_counted_base and stores a pointer of type Ptr, +which is passed to delete when the last reference is dropped. +This is the simplest form and is used when there is no custom deleter or +allocator. + + + + + + _Sp_counted_deleter<Ptr, Deleter, Alloc> + + +Inherits from _Sp_counted_ptr and adds support for custom deleter and +allocator. Empty Base Optimization is used for the allocator. This class +is used even when the user only provides a custom deleter, in which case +allocator is used as the allocator. + + + + + + _Sp_counted_ptr_inplace<Tp, Alloc, Lp> + + +Used by allocate_shared and make_shared. +Contains aligned storage to hold an object of type Tp, +which is constructed in-place with placement new. +Has a variadic template constructor allowing any number of arguments to +be forwarded to Tp's constructor. +Unlike the other _Sp_counted_* classes, this one is parameterized on the +type of object, not the type of pointer; this is purely a convenience +that simplifies the implementation slightly. + + + + + + + + + + Thread Safety + + +The interface of tr1::shared_ptr was extended for C++0x +with support for rvalue-references and the other features from +N2351. As with other libstdc++ headers shared by TR1 and C++0x, +boost_shared_ptr.h uses conditional compilation, based on the macros +_GLIBCXX_INCLUDE_AS_CXX0X and +_GLIBCXX_INCLUDE_AS_TR1, to enable and disable +features. + + + +C++0x-only features are: rvalue-ref/move support, allocator support, +aliasing constructor, make_shared & allocate_shared. Additionally, +the constructors taking auto_ptr parameters are +deprecated in C++0x mode. + + + +The +Thread +Safety section of the Boost shared_ptr documentation says "shared_ptr +objects offer the same level of thread safety as built-in types." +The implementation must ensure that concurrent updates to separate shared_ptr +instances are correct even when those instances share a reference count e.g. + + + +shared_ptr<A> a(new A); +shared_ptr<A> b(a); + +// Thread 1 // Thread 2 + a.reset(); b.reset(); + + + +The dynamically-allocated object must be destroyed by exactly one of the +threads. Weak references make things even more interesting. +The shared state used to implement shared_ptr must be transparent to the +user and invariants must be preserved at all times. +The key pieces of shared state are the strong and weak reference counts. +Updates to these need to be atomic and visible to all threads to ensure +correct cleanup of the managed resource (which is, after all, shared_ptr's +job!) +On multi-processor systems memory synchronisation may be needed so that +reference-count updates and the destruction of the managed resource are +race-free. + + + +The function _Sp_counted_base::_M_add_ref_lock(), called when +obtaining a shared_ptr from a weak_ptr, has to test if the managed +resource still exists and either increment the reference count or throw +bad_weak_ptr. +In a multi-threaded program there is a potential race condition if the last +reference is dropped (and the managed resource destroyed) between testing +the reference count and incrementing it, which could result in a shared_ptr +pointing to invalid memory. + + +The Boost shared_ptr (as used in GCC) features a clever lock-free +algorithm to avoid the race condition, but this relies on the +processor supporting an atomic Compare-And-Swap +instruction. For other platforms there are fall-backs using mutex +locks. Boost (as of version 1.35) includes several different +implementations and the preprocessor selects one based on the +compiler, standard library, platform etc. For the version of +shared_ptr in libstdc++ the compiler and library are fixed, which +makes things much simpler: we have an atomic CAS or we don't, see Lock +Policy below for details. + + + + + + Selecting Lock Policy + + + + + +There is a single _Sp_counted_base class, +which is a template parameterized on the enum +__gnu_cxx::_Lock_policy. The entire family of classes is +parameterized on the lock policy, right up to +__shared_ptr, __weak_ptr and +__enable_shared_from_this. The actual +std::shared_ptr class inherits from +__shared_ptr with the lock policy parameter +selected automatically based on the thread model and platform that +libstdc++ is configured for, so that the best available template +specialization will be used. This design is necessary because it would +not be conforming for shared_ptr to have an +extra template parameter, even if it had a default value. The +available policies are: + + + + + + _S_Atomic + + +Selected when GCC supports a builtin atomic compare-and-swap operation +on the target processor (see Atomic +Builtins.) The reference counts are maintained using a lock-free +algorithm and GCC's atomic builtins, which provide the required memory +synchronisation. + + + + + + _S_Mutex + + +The _Sp_counted_base specialization for this policy contains a mutex, +which is locked in add_ref_lock(). This policy is used when GCC's atomic +builtins aren't available so explicit memory barriers are needed in places. + + + + + + _S_Single + + +This policy uses a non-reentrant add_ref_lock() with no locking. It is +used when libstdc++ is built without --enable-threads. + + + + + + For all three policies, reference count increments and + decrements are done via the functions in + ext/atomicity.h, which detect if the program + is multi-threaded. If only one thread of execution exists in + the program then less expensive non-atomic operations are used. + + + + + Dual C++0x and TR1 Implementation + + +The classes derived from _Sp_counted_base (see Class Hierarchy +below) and __shared_count are implemented separately for C++0x +and TR1, in bits/boost_sp_shared_count.h and +tr1/boost_sp_shared_count.h respectively. All other classes +including _Sp_counted_base are shared by both implementations. + + + +The TR1 implementation is considered relatively stable, so is unlikely to +change unless bug fixes require it. If the code that is common to both +C++0x and TR1 modes needs to diverge further then it might be necessary to +duplicate additional classes and only make changes to the C++0x versions. + + + + +Related functions and classes + + + + + dynamic_pointer_cast, static_pointer_cast, +const_pointer_cast + + +As noted in N2351, these functions can be implemented non-intrusively using +the alias constructor. However the aliasing constructor is only available +in C++0x mode, so in TR1 mode these casts rely on three non-standard +constructors in shared_ptr and __shared_ptr. +In C++0x mode these constructors and the related tag types are not needed. + + + + + + enable_shared_from_this + + +The clever overload to detect a base class of type +enable_shared_from_this comes straight from Boost. +There is an extra overload for __enable_shared_from_this to +work smoothly with __shared_ptr<Tp, Lp> using any lock +policy. + + + + + + make_shared, allocate_shared + + +make_shared simply forwards to allocate_shared +with std::allocator as the allocator. +Although these functions can be implemented non-intrusively using the +alias constructor, if they have access to the implementation then it is +possible to save storage and reduce the number of heap allocations. The +newly constructed object and the _Sp_counted_* can be allocated in a single +block and the standard says implementations are "encouraged, but not required," +to do so. This implementation provides additional non-standard constructors +(selected with the type _Sp_make_shared_tag) which create an +object of type _Sp_counted_ptr_inplace to hold the new object. +The returned shared_ptr<A> needs to know the address of the +new A object embedded in the _Sp_counted_ptr_inplace, +but it has no way to access it. +This implementation uses a "covert channel" to return the address of the +embedded object when get_deleter<_Sp_make_shared_tag>() +is called. Users should not try to use this. +As well as the extra constructors, this implementation also needs some +members of _Sp_counted_deleter to be protected where they could otherwise +be private. + + + + + + + + + + + + + +Use + + + Examples + + Examples of use can be found in the testsuite, under + testsuite/tr1/2_general_utilities/shared_ptr. + + + + + Unresolved Issues + + The resolution to C++ Standard Library issue 674, + "shared_ptr interface changes for consistency with N1856" will + need to be implemented after it is accepted into the working + paper. Issue 743 + might also require changes. + + + + The _S_single policy uses atomics when used in MT + code, because it uses the same dispatcher functions that check + __gthread_active_p(). This could be + addressed by providing template specialisations for some members + of _Sp_counted_base<_S_single>. + + + + Unlike Boost, this implementation does not use separate classes + for the pointer+deleter and pointer+deleter+allocator cases in + C++0x mode, combining both into _Sp_counted_deleter and using + allocator when the user doesn't specify + an allocator. If it was found to be beneficial an additional + class could easily be added. With the current implementation, + the _Sp_counted_deleter and __shared_count constructors taking a + custom deleter but no allocator are technically redundant and + could be removed, changing callers to always specify an + allocator. If a separate pointer+deleter class was added the + __shared_count constructor would be needed, so it has been kept + for now. + + + + The hack used to get the address of the managed object from + _Sp_counted_ptr_inplace::_M_get_deleter() + is accessible to users. This could be prevented if + get_deleter<_Sp_make_shared_tag>() + always returned NULL, since the hack only needs to work at a + lower level, not in the public API. This wouldn't be difficult, + but hasn't been done since there is no danger of accidental + misuse: users already know they are relying on unsupported + features if they refer to implementation details such as + _Sp_make_shared_tag. + + + + tr1::_Sp_deleter could be a private member of tr1::__shared_count but it + would alter the ABI. + + + + Exposing the alias constructor in TR1 mode could simplify the + *_pointer_cast functions. Constructor could be private in TR1 + mode, with the cast functions as friends. + + + + + + +Acknowledgments + + + The original authors of the Boost shared_ptr, which is really nice + code to work with, Peter Dimov in particular for his help and + invaluable advice on thread safety. Phillip Jordan and Paolo + Carlini for the lock policy implementation. + + + + + +Bibliography + + + + n2351 + + + + Improving shared_ptr for C++0x, Revision 2 + + + N2351 + + + + + + + + + + + + n2456 + + + + C++ Standard Library Active Issues List (Revision R52) + + + N2456 + + + + + + + + + + + + n2461 + + + + Working Draft, Standard for Programming Language C++ + + + N2461 + + + + + + + + + + + + boostshared_ptr + + + + Boost C++ Libraries documentation - shared_ptr class template + + + N2461 + + + + shared_ptr + + + + + + + \ No newline at end of file diff --git a/libstdc++-v3/doc/xml/manual/spine.xml b/libstdc++-v3/doc/xml/manual/spine.xml new file mode 100644 index 00000000000..4c9c62842a1 --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/spine.xml @@ -0,0 +1,111 @@ + + + + + + +The GNU C++ Library + + + + 2008 + + FSF + + + + + License + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/libstdc++-v3/doc/xml/manual/status_cxx1998.xml b/libstdc++-v3/doc/xml/manual/status_cxx1998.xml new file mode 100644 index 00000000000..fc22af00d3b --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/status_cxx1998.xml @@ -0,0 +1,6153 @@ + + + + + + + ISO C++ + + + 1998 + + + + +C++ 1998 + + + Checklist + + + Completion Checklist for the Standard C++ Library + Updated: 2003-04-25 + + Status Code Legend: + M - Missing + S - Present as stub. + X - Partially implemented, or buggy. + T - Implemented, pending test/inspection. + V - Verified to pass all available test suites. + Q - Qualified by inspection for non-testable correctness. + P - Portability verified. + C - Certified. + + Lexical notes: + Only status codes appear in column 0. Notes relating to conformance + issues appear [in brackets]. + + Note that this checklist does not (yet) include all emendations + recommended by the ISO Library Working Group: + http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-toc.html + + Detailed explanation of status codes: + + M - Missing: The name is not visible to programs that include + the specified header, either at compile or link stage. + + S - Present as stub: A program can use the name, but no implementation + is provided. Programs that use the name link correctly, but + cannot usefully be run. + + X - Partially implemented, or buggy: Some implementation has been + provided, but it is known or believed not to conform fully. + It may have an incorrect base class, wrong namespace, wrong + storage class, or simply not fully implement requirements. + However, it may be sufficiently usable to help test other + components. + + T - Implemented, pending test/inspection: Implementation believed + to be complete, and informal testing suggests it is ready for + formal verification. + + V - Verified, passes all test suites: Verified to satisfy all + generically testable conformance requirements. + + Q - Qualified by inspection for non-testable correctness: + Inspected, "implementation-defined" documentation accepted, + local usability criteria satisfied, formally inspected for + other untestable conformance. (Untestable requirements + include exception-safety, thread-safety, worst-case + complexity, memory cleanliness, usefulness.) + + P - Portability verified: Qualified on all primary target platforms. + + C - Certified: Formally certified to have passed all tests, + inspections, qualifications; approved under "signing authority" + to be used to satisfy contractual guarantees. + + ---------------------------------------------------------------------- + <algorithm> <iomanip> <list> <ostream> <streambuf> + <bitset> <ios> <locale> <queue> <string> + <complex> <iosfwd> <map> <set> <typeinfo> +X <deque> <iostream> <memory> <sstream> <utility> + <exception> <istream> <new> <stack> <valarray> + <fstream> <iterator> <numeric> <stdexcept> <vector> + <functional> <limits> + + [C header names must be in std:: to qualify. Related to shadow/ dir.] + <cassert> <ciso646> <csetjmp> <cstdio> <ctime> + <cctype> <climits> <csignal> <cstdlib> <cwchar> +X <cerrno> <clocale> <cstdarg> <cstring> <cwctype> + <cfloat> <cmath> <cstddef> + + Macro: +X errno, declared or defined in <cerrno>. + + Macro fn: +X setjmp(jmp_buf), declared or defined in <csetjmp> +X va_end(va_list), declared or defined in <cstdarg> + + Types: +X clock_t, div_t, FILE, fpos_t, lconv, ldiv_t, mbstate_t, +X ptrdiff_t, sig_atomic_t, size_t, time_t, tm, va_list, +X wctrans_t, wctype_t, and wint_t. + + 1 Which of the functions in the C++ Standard Library are not reentrant + subroutines is implementation-defined. + + 18.1 Types [lib.support.types] +X <cstddef> +X NULL +X offsetof +X ptrdiff_t +X size_t + + 18.2 Implementation properties [lib.support.limits] + + <limits>, <climits>, and <cfloat> + + 18.2.1 Numeric limits [lib.limits] + +X template<class T> class numeric_limits; + +T enum float_round_style; +T enum float_denorm_style; + +T template<> class numeric_limits<bool>; + +T template<> class numeric_limits<char>; +T template<> class numeric_limits<signed char>; +T template<> class numeric_limits<unsigned char>; +T template<> class numeric_limits<wchar_t>; + +T template<> class numeric_limits<short>; +T template<> class numeric_limits<int>; +T template<> class numeric_limits<long>; +T template<> class numeric_limits<unsigned short>; +T template<> class numeric_limits<unsigned int>; +T template<> class numeric_limits<unsigned long>; + +X template<> class numeric_limits<float>; +X template<> class numeric_limits<double>; +X template<> class numeric_limits<long double>; + + 18.2.1.1 Template class numeric_limits [lib.numeric.limits] +T template<class T> class numeric_limits { + public: +T static const bool is_specialized = false; +T static T min() throw(); +T static T max() throw(); +T static const int digits = 0; +T static const int digits10 = 0; +T static const bool is_signed = false; +T static const bool is_integer = false; +T static const bool is_exact = false; +T static const int radix = 0; +T static T epsilon() throw(); +T static T round_error() throw(); + +T static const int min_exponent = 0; +T static const int min_exponent10 = 0; +T static const int max_exponent = 0; +T static const int max_exponent10 = 0; + +T static const bool has_infinity = false; +T static const bool has_quiet_NaN = false; +T static const bool has_signaling_NaN = false; +T static const float_denorm_style has_denorm = denorm_absent; +T static const bool has_denorm_loss = false; +T static T infinity() throw(); +T static T quiet_NaN() throw(); +T static T signaling_NaN() throw(); +T static T denorm_min() throw(); + +T static const bool is_iec559 = false; +T static const bool is_bounded = false; +T static const bool is_modulo = false; + +T static const bool traps = false; +T static const bool tinyness_before = false; +T static const float_round_style round_style = round_toward_zero; + }; + + 18.2.1.3 Type float_round_style [lib.round.style] + +T enum float_round_style { +T round_indeterminate = -1, +T round_toward_zero = 0, +T round_to_nearest = 1, +T round_toward_infinity = 2, +T round_toward_neg_infinity = 3 + }; + + 18.2.1.4 Type float_denorm_style [lib.denorm.style] + +T enum float_denorm_style { +T denorm_indeterminate = -1; +T denorm_absent = 0; +T denorm present = 1; + }; + + 18.2.1.5 numeric_limits specializations [lib.numeric.special] + + [Note: see Note at 18.2.1. ] + + 18.2.2 C Library [lib.c.limits] + + 1 Header <climits> (Table 3): + CHAR_BIT INT_MAX LONG_MIN SCHAR_MIN UCHAR_MAX USHRT_MAX +X CHAR_MAX INT_MIN MB_LEN_MAX SHRT_MAX UINT_MAX + CHAR_MIN LONG_MAX SCHAR_MAX SHRT_MIN ULONG_MAX + + 3 Header <cfloat> (Table 4): + + DBL_DIG DBL_MIN_EXP FLT_MIN_10_EXP LDBL_MAX_10_EXP + DBL_EPSILON FLT_DIG FLT_MIN_EXP LDBL_MAX_EXP + DBL_MANT_DIG FLT_EPSILON FLT_RADIX LDBL_MIN +X DBL_MAX FLT_MANT_DIG FLT_ROUNDS LDBL_MIN_10_EXP + DBL_MAX_10_EXP FLT_MAX LDBL_DIG LDBL_MIN_EXP + DBL_MAX_EXP FLT_MAX_10_EXP LDBL_EPSILON + DBL_MIN FLT_MAX_EXP LDBL_MANT_DIG + DBL_MIN_10_EXP FLT_MIN LDBL_MAX + + + 1 Header <cstdlib> (partial), Table 5: +X EXIT_FAILURE EXIT_SUCCESS + abort atexit exit + +S abort(void) +S extern "C" int atexit(void (*f)(void)) +S extern "C++" int atexit(void (*f)(void)) +S exit(int status) + + 18.4 Dynamic memory management [lib.support.dynamic] + + Header <new> synopsis + +T class bad_alloc; +T struct nothrow_t {}; +T extern const nothrow_t nothrow; +T typedef void (*new_handler)(); +T new_handler set_new_handler(new_handler new_p) throw(); + +T void* operator new(std::size_t size) throw(std::bad_alloc); +T void* operator new(std::size_t size, const std::nothrow_t&) throw(); +T void operator delete(void* ptr) throw(); +T void operator delete(void* ptr, const std::nothrow_t&) throw(); +T void* operator new[](std::size_t size) throw(std::bad_alloc); +T void* operator new[](std::size_t size, const std::nothrow_t&) throw(); +T void operator delete[](void* ptr) throw(); +T void operator delete[](void* ptr, const std::nothrow_t&) throw(); +T void* operator new (std::size_t size, void* ptr) throw(); +T void* operator new[](std::size_t size, void* ptr) throw(); +T void operator delete (void* ptr, void*) throw(); +T void operator delete[](void* ptr, void*) throw(); + + 18.4.2.1 Class bad_alloc [lib.bad.alloc] + +T class bad_alloc : public exception { + public: +T bad_alloc() throw(); +T bad_alloc(const bad_alloc&) throw(); +T bad_alloc& operator=(const bad_alloc&) throw(); +T virtual ~bad_alloc() throw(); +T virtual const char* what() const throw(); + + + +T new_handler set_new_handler(new_handler new_p) throw(); + + + Header <typeinfo> synopsis + +T class type_info; +T class bad_cast; +T class bad_typeid; + + 18.5.1 - Class type_info [lib.type.info] + +T class type_info { + public: +T virtual ~type_info(); +T bool operator==(const type_info& rhs) const; +T bool operator!=(const type_info& rhs) const; +T bool before(const type_info& rhs) const; +T const char* name() const; + private: +T type_info(const type_info& rhs); +T type_info& operator=(const type_info& rhs); + }; + + 18.5.2 - Class bad_cast [lib.bad.cast] + +T bad_cast() throw(); +T virtual const char* bad_cast::what() const throw(); + + 18.5.3 Class bad_typeid [lib.bad.typeid] + +T class bad_typeid : public exception { + public: +T bad_typeid() throw(); +T bad_typeid(const bad_typeid&) throw(); +T bad_typeid& operator=(const bad_typeid&) throw(); +T virtual ~bad_typeid() throw(); +T virtual const char* what() const throw(); + }; + + 18.6 Exception handling [lib.support.exception] + +T Header <exception> synopsis + +T class exception; +T class bad_exception; + +T typedef void (*unexpected_handler)(); +T unexpected_handler set_unexpected(unexpected_handler f) throw(); +T void unexpected(); +T typedef void (*terminate_handler)(); +T terminate_handler set_terminate(terminate_handler f) throw(); +T void terminate(); +T bool uncaught_exception(); + + 18.6.1 Class exception [lib.exception] + +T class exception { + public: +T exception() throw(); +T exception(const exception&) throw(); +T exception& operator=(const exception&) throw(); +T virtual ~exception() throw(); +T virtual const char* what() const throw(); + }; + + 18.6.2.1 Class bad_exception [lib.bad.exception] +T class bad_exception : public exception { + public: +T bad_exception() throw(); +T bad_exception(const bad_exception&) throw(); +T bad_exception& operator=(const bad_exception&) throw(); +T virtual ~bad_exception() throw(); +T virtual const char* what() const throw(); + }; + + 18.7 Other runtime support [lib.support.runtime] + + 1 Headers <cstdarg> (variable arguments), <csetjmp> (nonlocal jumps), + <ctime> (system clock clock(), time()), <csignal> (signal handling), + and <cstdlib> (runtime environment getenv(), system()). + + Table 6--Header <cstdarg> synopsis + Macros: va_arg va_end va_start +X Type: va_list + + Table 7--Header <csetjmp> synopsis + + Macro: setjmp | +X Type: jmp_buf + Function: longjmp + + Table 8--Header <ctime> synopsis + + Macros: CLOCKS_PER_SEC +X Types: clock_t + Functions: clock + + Table 9--Header <csignal> synopsis + +X Macros: SIGABRT SIGILL SIGSEGV SIG_DFL + SIG_IGN SIGFPE SIGINT SIGTERM SIG_ERR + Type: sig_atomic_t + Functions: raise signal + + Table 10--Header <cstdlib> synopsis + +X Functions: getenv system + + 19.1 Exception classes [lib.std.exceptions] + + Header <stdexcept> synopsis + +T class logic_error; +T class domain_error; +T class invalid_argument; +T class length_error; +T class out_of_range; +T class runtime_error; +T class range_error; +T class overflow_error; +T class underflow_error; + + 19.1.1 Class logic_error [lib.logic.error] +T class logic_error : public exception { + public: +T explicit logic_error(const string& what_arg); + }; + + 19.1.2 Class domain_error [lib.domain.error] + +T class domain_error : public logic_error { + public: +T explicit domain_error(const string& what_arg); + }; + + 19.1.3 Class invalid_argument [lib.invalid.argument] + +T class invalid_argument : public logic_error { + public: +T explicit invalid_argument(const string& what_arg); + }; + + 19.1.4 Class length_error [lib.length.error] + +T class length_error : public logic_error { + public: +T explicit length_error(const string& what_arg); + }; + + 19.1.5 Class out_of_range [lib.out.of.range] + +T class out_of_range : public logic_error { + public: +T explicit out_of_range(const string& what_arg); + }; + + + 19.1.6 Class runtime_error [lib.runtime.error] + +T class runtime_error : public exception { + public: +T explicit runtime_error(const string& what_arg); + }; + + + 19.1.7 Class range_error [lib.range.error] + +T class range_error : public runtime_error { + public: +T explicit range_error(const string& what_arg); + }; + + 19.1.8 Class overflow_error [lib.overflow.error] + +T class overflow_error : public runtime_error { + public: +T explicit overflow_error(const string& what_arg); + }; + + + 19.1.9 Class underflow_error [lib.underflow.error] + +T class underflow_error : public runtime_error { + public: +T explicit underflow_error(const string& what_arg); + }; + + + 19.2 Assertions [lib.assertions] + + Table 2--Header <cassert> synopsis + +X Macro: assert + + 19.3 Error numbers [lib.errno] + + Table 3--Header <cerrno> synopsis + +X |Macros: EDOM ERANGE errno | + + + 20.2 Utility components [lib.utility] + + Header <utility> synopsis + + // _lib.operators_, operators: +T namespace rel_ops { +T template<class T> bool operator!=(const T&, const T&); +T template<class T> bool operator> (const T&, const T&); +T template<class T> bool operator<=(const T&, const T&); +T template<class T> bool operator>=(const T&, const T&); + } + // _lib.pairs_, pairs: +T template <class T1, class T2> struct pair; +T template <class T1, class T2> + bool operator==(const pair<T1,T2>&, const pair<T1,T2>&); +T template <class T1, class T2> + bool operator< (const pair<T1,T2>&, const pair<T1,T2>&); +T template <class T1, class T2> + bool operator!=(const pair<T1,T2>&, const pair<T1,T2>&); +T template <class T1, class T2> + bool operator> (const pair<T1,T2>&, const pair<T1,T2>&); +T template <class T1, class T2> + bool operator>=(const pair<T1,T2>&, const pair<T1,T2>&); +T template <class T1, class T2> + bool operator<=(const pair<T1,T2>&, const pair<T1,T2>&); +T template <class T1, class T2> pair<T1,T2> make_pair(const T1&, const T2&); + + + 20.2.2 Pairs [lib.pairs] + +T template <class T1, class T2> + struct pair { +T typedef T1 first_type; +T typedef T2 second_type; + +T T1 first; +T T2 second; +T pair(); +T pair(const T1& x, const T2& y); +T template<class U, class V> pair(const pair<U, V> &p); + }; + + 20.3 Function objects [lib.function.objects] + + Header <functional> synopsis + + // _lib.base_, base: +V template <class Arg, class Result> struct unary_function; +V template <class Arg1, class Arg2, class Result> struct binary_function; + + // _lib.arithmetic.operations_, arithmetic operations: +V template <class T> struct plus; +V template <class T> struct minus; +V template <class T> struct multiplies; +V template <class T> struct divides; +V template <class T> struct modulus; +V template <class T> struct negate; + // _lib.comparisons_, comparisons: +V template <class T> struct equal_to; +V template <class T> struct not_equal_to; +V template <class T> struct greater; +V template <class T> struct less; +V template <class T> struct greater_equal; +V template <class T> struct less_equal; + // _lib.logical.operations_, logical operations: +V template <class T> struct logical_and; +V template <class T> struct logical_or; +V template <class T> struct logical_not; + // _lib.negators_, negators: + template <class Predicate> struct unary_negate; +V template <class Predicate> + unary_negate<Predicate> not1(const Predicate&); +V template <class Predicate> struct binary_negate; +V template <class Predicate> + binary_negate<Predicate> not2(const Predicate&); + // _lib.binders_, binders: +V template <class Operation> class binder1st; +V template <class Operation, class T> + binder1st<Operation> bind1st(const Operation&, const T&); +V template <class Operation> class binder2nd; +V template <class Operation, class T> + binder2nd<Operation> bind2nd(const Operation&, const T&); + // _lib.function.pointer.adaptors_, adaptors: +V template <class Arg, class Result> class pointer_to_unary_function; +V template <class Arg, class Result> + pointer_to_unary_function<Arg,Result> ptr_fun(Result (*)(Arg)); +V template <class Arg1, class Arg2, class Result> + class pointer_to_binary_function; +V template <class Arg1, class Arg2, class Result> + pointer_to_binary_function<Arg1,Arg2,Result> + ptr_fun(Result (*)(Arg1,Arg2)); + + // _lib.member.pointer.adaptors_, adaptors: +V template<class S, class T> class mem_fun_t; +V template<class S, class T, class A> class mem_fun1_t; +V template<class S, class T> + mem_fun_t<S,T> mem_fun(S (T::*f)()); +V template<class S, class T, class A> + mem_fun1_t<S,T,A> mem_fun(S (T::*f)(A)); +V template<class S, class T> class mem_fun_ref_t; +V template<class S, class T, class A> class mem_fun1_ref_t; +V template<class S, class T> + mem_fun_ref_t<S,T> mem_fun_ref(S (T::*f)()); +V template<class S, class T, class A> + mem_fun1_ref_t<S,T,A> mem_fun_ref(S (T::*f)(A)); + +V template <class S, class T> class const_mem_fun_t; +V template <class S, class T, class A> class const_mem_fun1_t; +V template <class S, class T> + const_mem_fun_t<S,T> mem_fun(S (T::*f)() const); +V template <class S, class T, class A> + const_mem_fun1_t<S,T,A> mem_fun(S (T::*f)(A) const); +V template <class S, class T> class const_mem_fun_ref_t; +V template <class S, class T, class A> class const_mem_fun1_ref_t; +V template <class S, class T> + const_mem_fun_ref_t<S,T> mem_fun_ref(S (T::*f)() const); +V template <class S, class T, class A> + const_mem_fun1_ref_t<S,T,A> mem_fun_ref(S (T::*f)(A) const); + } + + 20.3.1 Base [lib.base] + +V template <class Arg, class Result> + struct unary_function { +V typedef Arg argument_type; +V typedef Result result_type; + }; +V template <class Arg1, class Arg2, class Result> + struct binary_function { +V typedef Arg1 first_argument_type; +V typedef Arg2 second_argument_type; +V typedef Result result_type; + }; + + 20.3.2 Arithmetic operations [lib.arithmetic.operations] + +T template <class T> struct plus : binary_function<T,T,T> { +V T operator()(const T& x, const T& y) const; + }; + +T template <class T> struct minus : binary_function<T,T,T> { +V T operator()(const T& x, const T& y) const; + }; + +T template <class T> struct multiplies : binary_function<T,T,T> { +V T operator()(const T& x, const T& y) const; + }; + +T template <class T> struct divides : binary_function<T,T,T> { +V T operator()(const T& x, const T& y) const; + }; + +T template <class T> struct modulus : binary_function<T,T,T> { +V T operator()(const T& x, const T& y) const; + }; + +T template <class T> struct negate : unary_function<T,T> { +V T operator()(const T& x) const; + }; + + 20.3.3 Comparisons [lib.comparisons] + +T template <class T> struct equal_to : binary_function<T,T,bool> { +V bool operator()(const T& x, const T& y) const; + }; + +T template <class T> struct not_equal_to : binary_function<T,T,bool> { +V bool operator()(const T& x, const T& y) const; + }; + +T template <class T> struct greater : binary_function<T,T,bool> { +V bool operator()(const T& x, const T& y) const; + }; + +T template <class T> struct less : binary_function<T,T,bool> { +V bool operator()(const T& x, const T& y) const; + }; + +T template <class T> struct greater_equal : binary_function<T,T,bool> { +V bool operator()(const T& x, const T& y) const; + }; + +T template <class T> struct less_equal : binary_function<T,T,bool> { +V bool operator()(const T& x, const T& y) const; + }; + + 20.3.4 Logical operations [lib.logical.operations] + +T template <class T> struct logical_and : binary_function<T,T,bool> { +V bool operator()(const T& x, const T& y) const; + }; + +T template <class T> struct logical_or : binary_function<T,T,bool> { +V bool operator()(const T& x, const T& y) const; + }; + +T template <class T> struct logical_not : unary_function<T,bool> { +V bool operator()(const T& x) const; + }; + + 20.3.5 Negators [lib.negators] + +T template <class Predicate> + class unary_negate + : public unary_function<typename Predicate::argument_type,bool> { + public: +T explicit unary_negate(const Predicate& pred); +V bool operator()(const typename Predicate::argument_type& x) const; + }; + +T template <class Predicate> + class binary_negate + : public binary_function<typename Predicate::first_argument_type, + typename Predicate::second_argument_type, bool> { + public: +T explicit binary_negate(const Predicate& pred); +V bool operator()(const typename Predicate::first_argument_type& x, + const typename Predicate::second_argument_type& y) const; + }; + + + 20.3.6 Binders [lib.binders] + + 20.3.6.1 Template class binder1st [lib.binder.1st] +T template <class Operation> + class binder1st + : public unary_function<typename Operation::second_argument_type, + typename Operation::result_type> { + protected: +T Operation op; +T typename Operation::first_argument_type value; + public: +V binder1st(const Operation& x, + const typename Operation::first_argument_type& y); +V typename Operation::result_type + operator()(const typename Operation::second_argument_type& x) const; + }; + + 20.3.6.2 bind1st [lib.bind.1st] + +V template <class Operation, class T> + binder1st<Operation> bind1st(const Operation& op, const T& x); + + 20.3.6.3 Template class binder2nd [lib.binder.2nd] +T template <class Operation> + class binder2nd + : public unary_function<typename Operation::first_argument_type, + typename Operation::result_type> { + protected: +T Operation op; +T typename Operation::second_argument_type value; + public: +V binder2nd(const Operation& x, + const typename Operation::second_argument_type& y); +V typename Operation::result_type + operator()(const typename Operation::first_argument_type& x) const; + }; + + 20.3.6.4 bind2nd [lib.bind.2nd] + +T template <class Operation, class T> + binder2nd<Operation> bind2nd(const Operation& op, const T& x); + + + 20.3.7 Adaptors for pointers to [lib.function.pointer.adaptors] + functions + + 1 To allow pointers to (unary and binary) functions to work with func- + tion adaptors the library provides: + +T template <class Arg, class Result> + class pointer_to_unary_function : public unary_function<Arg, Result> { + public: +T explicit pointer_to_unary_function(Result (*f)(Arg)); +V Result operator()(Arg x) const; + }; + +T template <class Arg, class Result> + pointer_to_unary_function<Arg, Result> ptr_fun(Result (*f)(Arg)); + +T template <class Arg1, class Arg2, class Result> + class pointer_to_binary_function : + public binary_function<Arg1,Arg2,Result> { + public: +T explicit pointer_to_binary_function(Result (*f)(Arg1, Arg2)); +V Result operator()(Arg1 x, Arg2 y) const; + }; + + + 20.3.8 Adaptors for pointers to [lib.member.pointer.adaptors] + members + +T template <class S, class T> class mem_fun_t + : public unary_function<T*, S> { + public: +T explicit mem_fun_t(S (T::*p)()); +V S operator()(T* p) const; + }; + +T template <class S, class T, class A> class mem_fun1_t + : public binary_function<T*, A, S> { + public: +T explicit mem_fun1_t(S (T::*p)(A)); +V S operator()(T* p, A x) const; + }; + +V template<class S, class T> mem_fun_t<S,T> + mem_fun(S (T::*f)()); +V template<class S, class T, class A> mem_fun1_t<S,T,A> + mem_fun(S (T::*f)(A)); + +T template <class S, class T> class mem_fun_ref_t + : public unary_function<T, S> { + public: +T explicit mem_fun_ref_t(S (T::*p)()); +V S operator()(T& p) const; + }; + +T template <class S, class T, class A> class mem_fun1_ref_t + : public binary_function<T, A, S> { + public: +T explicit mem_fun1_ref_t(S (T::*p)(A)); +V S operator()(T& p, A x) const; + }; + +T template<class S, class T> mem_fun_ref_t<S,T> + mem_fun_ref(S (T::*f)()); + +T template<class S, class T, class A> mem_fun1_ref_t<S,T,A> + mem_fun_ref(S (T::*f)(A)); + +T template <class S, class T> class const_mem_fun_t + : public unary_function<T*, S> { + public: +T explicit const_mem_fun_t(S (T::*p)() const); +V S operator()(const T* p) const; + }; + +T template <class S, class T, class A> class const_mem_fun1_t + : public binary_function<T*, A, S> { + public: +T explicit const mem_fun1_t(S (T::*p)(A) const); +V S operator()(const T* p, A x) const; + }; + +V template<class S, class T> const_mem_fun_t<S,T> + mem_fun(S (T::*f)() const); +V template<class S, class T, class A> const_mem_fun1_t<S,T,A> + mem_fun(S (T::*f)(A) const); + +T template <class S, class T> class const_mem_fun_ref_t + : public unary_function<T, S> { + public: +T explicit const_mem_fun_ref_t(S (T::*p)() const); +V S operator()(const T& p) const; + }; + +T template <class S, class T, class A> class const_mem_fun1_ref_t + : public binary_function<T, A, S> { + public: +T explicit const_mem_fun1_ref_t(S (T::*p)(A) const); +V S operator()(const T& p, A x) const; + }; + +T template<class S, class T> const_mem_fun_ref_t<S,T> + mem_fun_ref(S (T::*f)() const); + +T template<class S, class T, class A> const_mem_fun1_ref_t<S,T,A> + mem_fun_ref(S (T::*f)(A) const); + + 20.4 Memory [lib.memory] + + Header <memory> synopsis + + // _lib.default.allocator_, the default allocator: +T template <class T> class allocator; +T template <> class allocator<void>; +T template <class T, class U> + bool operator==(const allocator<T>&, const allocator<U>&) throw(); +T template <class T, class U> + bool operator!=(const allocator<T>&, const allocator<U>&) throw(); + // _lib.storage.iterator_, raw storage iterator: +T template <class OutputIterator, class T> class raw_storage_iterator; + // _lib.temporary.buffer_, temporary buffers: +T template <class T> + pair<T*,ptrdiff_t> get_temporary_buffer(ptrdiff_t n); +T template <class T> + void return_temporary_buffer(T* p); + // _lib.specialized.algorithms_, specialized algorithms: +T template <class InputIterator, class ForwardIterator> + ForwardIterator + uninitialized_copy(InputIterator first, InputIterator last, + ForwardIterator result); +T template <class ForwardIterator, class T> + void uninitialized_fill(ForwardIterator first, ForwardIterator last, + const T& x); +T template <class ForwardIterator, class Size, class T> + void uninitialized_fill_n(ForwardIterator first, Size n, const T& x); + // _lib.auto.ptr_, pointers: +X template<class X> class auto_ptr; + } + + 20.4.1 The default allocator [lib.default.allocator] + +T template <class T> class allocator; + // specialize for void: +T template <> class allocator<void> { + public: +T typedef void* pointer; +T typedef const void* const_pointer; + // reference-to-void members are impossible. +T typedef void value_type; +T template <class U> struct rebind { typedef allocator<U> other; }; + }; + +T template <class T> class allocator { + public: +T typedef size_t size_type; +T typedef ptrdiff_t difference_type; +T typedef T* pointer; +T typedef const T* const_pointer; +T typedef T& reference; +T typedef const T& const_reference; +T typedef T value_type; +T template <class U> struct rebind { typedef allocator<U> other; }; +T allocator() throw(); +T allocator(const allocator&) throw(); +T template <class U> allocator(const allocator<U>&) throw(); +T ~allocator() throw(); +T pointer address(reference x) const; +T const_pointer address(const_reference x) const; +T pointer allocate( + size_type, allocator<void>::const_pointer hint = 0); +T void deallocate(pointer p, size_type n); +T size_type max_size() const throw(); +T void construct(pointer p, const T& val); +T void destroy(pointer p); + }; + + 20.4.1.2 allocator globals [lib.allocator.globals] + +T template <class T1, class T2> + bool operator==(const allocator<T1>&, const allocator<T2>&) throw(); +T template <class T1, class T2> + bool operator!=(const allocator<T1>&, const allocator<T2>&) throw(); + + 20.4.2 Raw storage iterator [lib.storage.iterator] + +T template <class OutputIterator, class T> + class raw_storage_iterator + : public iterator<output_iterator_tag,void,void,void,void> { + public: +T explicit raw_storage_iterator(OutputIterator x); +T raw_storage_iterator<OutputIterator,T>& operator*(); +T raw_storage_iterator<OutputIterator,T>& operator=(const T& element); +T raw_storage_iterator<OutputIterator,T>& operator++(); +T raw_storage_iterator<OutputIterator,T> operator++(int); + }; + + 20.4.3 Temporary buffers [lib.temporary.buffer] + +T template <class T> + pair<T*, ptrdiff_t> get_temporary_buffer(ptrdiff_t n); + +T template <class T> void return_temporary_buffer(T* p); + + 20.4.4 Specialized algorithms [lib.specialized.algorithms] + + 20.4.4.1 uninitialized_copy [lib.uninitialized.copy] + +V template <class InputIterator, class ForwardIterator> + ForwardIterator + uninitialized_copy(InputIterator first, InputIterator last, + ForwardIterator result); + + 20.4.4.2 uninitialized_fill [lib.uninitialized.fill] + +V template <class ForwardIterator, class T> + void uninitialized_fill(ForwardIterator first, ForwardIterator last, + const T& x); + + 20.4.4.3 uninitialized_fill_n [lib.uninitialized.fill.n] + +V template <class ForwardIterator, class Size, class T> + void uninitialized_fill_n(ForwardIterator first, Size n, const T& x); + + 20.4.5 Template class auto_ptr [lib.auto.ptr] + +X template<class X> class auto_ptr { + template <class Y> struct auto_ptr_ref {}; + public: +T typedef X element_type; + // _lib.auto.ptr.cons_ construct/copy/destroy: +T explicit auto_ptr(X* p =0) throw(); +T auto_ptr(auto_ptr&) throw(); +T template<class Y> auto_ptr(auto_ptr<Y>&) throw(); +T auto_ptr& operator=(auto_ptr&) throw(); +T template<class Y> auto_ptr& operator=(auto_ptr<Y>&) throw(); +T ~auto_ptr() throw(); + // _lib.auto.ptr.members_ members: +T X& operator*() const throw(); +T X* operator->() const throw(); +T X* get() const throw(); +T X* release() throw(); +T void reset(X* p =0) throw(); + + // _lib.auto.ptr.conv_ conversions: +X auto_ptr(auto_ptr_ref<X>) throw(); +X template<class Y> operator auto_ptr_ref<Y>() throw(); +X template<class Y> operator auto_ptr<Y>() throw(); + }; + + 20.4.6 C Library [lib.c.malloc] + + Table 7--Header <cstdlib> synopsis + +X Functions: calloc malloc + free realloc + + + Table 8--Header <cstring> synopsis + +X Macro: NULL +X Type: size_t +X Functions: memchr memcmp +X memcpy memmove memset + + Table 9--Header <ctime> synopsis + +X Macros: NULL +X Types: size_t clock_t time_t +X Struct: tm + Functions: +X asctime clock difftime localtime strftime +X ctime gmtime mktime time + + 21.1.1 Character traits requirements [lib.char.traits.require] + + 2 The struct template +T template<class charT> struct char_traits; + shall be provided in the header <string> as a basis for explicit spe- + cializations. + + + 21.1.3.1 struct [lib.char.traits.specializations.char] + char_traits<char> + +T template<> + struct char_traits<char> { +T typedef char char_type; +T typedef int int_type; +T typedef streamoff off_type; +T typedef streampos pos_type; +T typedef mbstate_t state_type; + +T static void assign(char_type& c1, const char_type& c2); +T static bool eq(const char_type& c1, const char_type& c2); +T static bool lt(const char_type& c1, const char_type& c2); + +T static int compare(const char_type* s1, const char_type* s2, size_t n); +T static size_t length(const char_type* s); +T static const char_type* find(const char_type* s, size_t n, + const char_type& a); +T static char_type* move(char_type* s1, const char_type* s2, size_t n); +T static char_type* copy(char_type* s1, const char_type* s2, size_t n); +T static char_type* assign(char_type* s, size_t n, char_type a); + +T static int_type not_eof(const int_type& c); +T static char_type to_char_type(const int_type& c); +T static int_type to_int_type(const char_type& c); +T static bool eq_int_type(const int_type& c1, const int_type& c2); +T static int_type eof(); + }; + + 21.1.3.2 struct [lib.char.traits.specializations.wchar.t] + char_traits<wchar_t> + +V template<> + struct char_traits<wchar_t> { +V typedef wchar_t char_type; +V typedef wint_t int_type; +V typedef streamoff off_type; +V typedef wstreampos pos_type; +V typedef mbstate_t state_type; + +V static void assign(char_type& c1, const char_type& c2); +V static bool eq(const char_type& c1, const char_type& c2); +V static bool lt(const char_type& c1, const char_type& c2); + +V static int compare(const char_type* s1, const char_type* s2, size_t n); +V static size_t length(const char_type* s); +V static const char_type* find(const char_type* s, size_t n, + const char_type& a); +V static char_type* move(char_type* s1, const char_type* s2, size_t n); +V static char_type* copy(char_type* s1, const char_type* s2, size_t n); +V static char_type* assign(char_type* s, size_t n, char_type a); + +V static int_type not_eof(const int_type& c); +V static char_type to_char_type(const int_type& c); +V static int_type to_int_type(const char_type& c); +V static bool eq_int_type(const int_type& c1, const int_type& c2); +V static int_type eof(); + }; + + 21.2 String classes [lib.string.classes] + + // _lib.char.traits_, character traits: +V template<class charT> + struct char_traits; +V template <> struct char_traits<char>; +V template <> struct char_traits<wchar_t>; + + // _lib.basic.string_, basic_string: +V template<class charT, class traits = char_traits<charT>, + class Allocator = allocator<charT> > + class basic_string; +V template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator> + operator+(const basic_string<charT,traits,Allocator>& lhs, + const basic_string<charT,traits,Allocator>& rhs); +V template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator> + operator+(const charT* lhs, + const basic_string<charT,traits,Allocator>& rhs); +V template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator> + operator+(charT lhs, const basic_string<charT,traits,Allocator>& rhs); +V template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator> + operator+(const basic_string<charT,traits,Allocator>& lhs, + const charT* rhs); +V template<class charT, class traits, class Allocator> + basic_string<charT,traits,Allocator> + operator+(const basic_string<charT,traits,Allocator>& lhs, charT rhs); + +V template<class charT, class traits, class Allocator> + bool operator==(const basic_string<charT,traits,Allocator>& lhs, + const basic_string<charT,traits,Allocator>& rhs); +V template<class charT, class traits, class Allocator> + bool operator==(const charT* lhs, + const basic_string<charT,traits,Allocator>& rhs); +V template<class charT, class traits, class Allocator> + bool operator==(const basic_string<charT,traits,Allocator>& lhs, + const charT* rhs); +V template<class charT, class traits, class Allocator> + bool operator!=(const basic_string<charT,traits,Allocator>& lhs, + const basic_string<charT,traits,Allocator>& rhs); +V template<class charT, class traits, class Allocator> + bool operator!=(const charT* lhs, + const basic_string<charT,traits,Allocator>& rhs); +V template<class charT, class traits, class Allocator> + bool operator!=(const basic_string<charT,traits,Allocator>& lhs, + const charT* rhs); +V template<class charT, class traits, class Allocator> + bool operator< (const basic_string<charT,traits,Allocator>& lhs, + const basic_string<charT,traits,Allocator>& rhs); +V template<class charT, class traits, class Allocator> + bool operator< (const basic_string<charT,traits,Allocator>& lhs, + const charT* rhs); +V template<class charT, class traits, class Allocator> + bool operator< (const charT* lhs, + const basic_string<charT,traits,Allocator>& rhs); +V template<class charT, class traits, class Allocator> + bool operator> (const basic_string<charT,traits,Allocator>& lhs, + const basic_string<charT,traits,Allocator>& rhs); +V template<class charT, class traits, class Allocator> + bool operator> (const basic_string<charT,traits,Allocator>& lhs, + const charT* rhs); +V template<class charT, class traits, class Allocator> + bool operator> (const charT* lhs, + const basic_string<charT,traits,Allocator>& rhs); +V template<class charT, class traits, class Allocator> + bool operator<=(const basic_string<charT,traits,Allocator>& lhs, + const basic_string<charT,traits,Allocator>& rhs); +V template<class charT, class traits, class Allocator> + bool operator<=(const basic_string<charT,traits,Allocator>& lhs, + const charT* rhs); +V template<class charT, class traits, class Allocator> + bool operator<=(const charT* lhs, + const basic_string<charT,traits,Allocator>& rhs); +V template<class charT, class traits, class Allocator> + bool operator>=(const basic_string<charT,traits,Allocator>& lhs, + const basic_string<charT,traits,Allocator>& rhs); +V template<class charT, class traits, class Allocator> + bool operator>=(const basic_string<charT,traits,Allocator>& lhs, + const charT* rhs); +V template<class charT, class traits, class Allocator> + bool operator>=(const charT* lhs, + const basic_string<charT,traits,Allocator>& rhs); + + // _lib.string.special_: +V template<class charT, class traits, class Allocator> + void swap(basic_string<charT,traits,Allocator>& lhs, + basic_string<charT,traits,Allocator>& rhs); +V template<class charT, class traits, class Allocator> + basic_istream<charT,traits>& + operator>>(basic_istream<charT,traits>& is, + basic_string<charT,traits,Allocator>& str); +T template<class charT, class traits, class Allocator> + basic_ostream<charT, traits>& + operator<<(basic_ostream<charT, traits>& os, + const basic_string<charT,traits,Allocator>& str); +V template<class charT, class traits, class Allocator> + basic_istream<charT,traits>& + getline(basic_istream<charT,traits>& is, + basic_string<charT,traits,Allocator>& str, + charT delim); +V template<class charT, class traits, class Allocator> + basic_istream<charT,traits>& + getline(basic_istream<charT,traits>& is, + basic_string<charT,traits,Allocator>& str); +V typedef basic_string<char> string; +T typedef basic_string<wchar_t> wstring; + } + + 21.3 Template class basic_string [lib.basic.string] + +V namespace std { + template<class charT, class traits = char_traits<charT>, + class Allocator = allocator<charT> > + class basic_string { + public: + // types: + typedef traits traits_type; + typedef typename traits::char_type value_type; + typedef Allocator allocator_type; + typedef typename Allocator::size_type size_type; + typedef typename Allocator::difference_type difference_type; + typedef typename Allocator::reference reference; + typedef typename Allocator::const_reference const_reference; + typedef typename Allocator::pointer pointer; + typedef typename Allocator::const_pointer const_pointer; + typedef implementation defined iterator; + typedef implementation defined const_iterator; + typedef std::reverse_iterator<iterator> reverse_iterator; + typedef std::reverse_iterator<const_iterator> const_reverse_iterator; + static const size_type npos = -1; + + // _lib.string.cons_ construct/copy/destroy: +V explicit basic_string(const Allocator& a = Allocator()); +V basic_string(const basic_string& str, size_type pos = 0, + size_type n = npos, const Allocator& a = Allocator()); +V basic_string(const charT* s, + size_type n, const Allocator& a = Allocator()); +V basic_string(const charT* s, const Allocator& a = Allocator()); +V basic_string(size_type n, charT c, const Allocator& a = Allocator()); +V template<class InputIterator> + basic_string(InputIterator begin, InputIterator end, + const Allocator& a = Allocator()); +V ~basic_string(); +V basic_string& operator=(const basic_string& str); +V basic_string& operator=(const charT* s); +V basic_string& operator=(charT c); + // _lib.string.iterators_ iterators: +V iterator begin(); +V const_iterator begin() const; +V iterator end(); +V const_iterator end() const; + +V reverse_iterator rbegin(); +V const_reverse_iterator rbegin() const; +V reverse_iterator rend(); +V const_reverse_iterator rend() const; + // _lib.string.capacity_ capacity: +V size_type size() const; +V size_type length() const; +V size_type max_size() const; +V void resize(size_type n, charT c); +V void resize(size_type n); +V size_type capacity() const; +V void reserve(size_type res_arg = 0); +V void clear(); +V bool empty() const; + // _lib.string.access_ element access: +V const_reference operator[](size_type pos) const; +V reference operator[](size_type pos); +V const_reference at(size_type n) const; +V reference at(size_type n); + // _lib.string.modifiers_ modifiers: +V basic_string& operator+=(const basic_string& str); +V basic_string& operator+=(const charT* s); +V basic_string& operator+=(charT c); +V basic_string& append(const basic_string& str); +V basic_string& append(const basic_string& str, size_type pos, + size_type n); +V basic_string& append(const charT* s, size_type n); +V basic_string& append(const charT* s); +V basic_string& append(size_type n, charT c); +V template<class InputIterator> + basic_string& append(InputIterator first, InputIterator last); +V void push_back(const charT); + +V basic_string& assign(const basic_string&); +V basic_string& assign(const basic_string& str, size_type pos, + size_type n); +V basic_string& assign(const charT* s, size_type n); +V basic_string& assign(const charT* s); +V basic_string& assign(size_type n, charT c); +V template<class InputIterator> + basic_string& assign(InputIterator first, InputIterator last); +V basic_string& insert(size_type pos1, const basic_string& str); +V basic_string& insert(size_type pos1, const basic_string& str, + size_type pos2, size_type n); +V basic_string& insert(size_type pos, const charT* s, size_type n); +V basic_string& insert(size_type pos, const charT* s); +V basic_string& insert(size_type pos, size_type n, charT c); +V iterator insert(iterator p, charT c); +V void insert(iterator p, size_type n, charT c); +V template<class InputIterator> + void insert(iterator p, InputIterator first, InputIterator last); +V basic_string& erase(size_type pos = 0, size_type n = npos); +V iterator erase(iterator position); +V iterator erase(iterator first, iterator last); +V basic_string& replace(size_type pos1, size_type n1, + const basic_string& str); +V basic_string& replace(size_type pos1, size_type n1, + const basic_string& str, + size_type pos2, size_type n2); +V basic_string& replace(size_type pos, size_type n1, const charT* s, + size_type n2); +V basic_string& replace(size_type pos, size_type n1, const charT* s); +V basic_string& replace(size_type pos, size_type n1, size_type n2, + charT c); +V basic_string& replace(iterator i1, iterator i2, const basic_string& str); +V basic_string& replace(iterator i1, iterator i2, const charT* s, + size_type n); +V basic_string& replace(iterator i1, iterator i2, const charT* s); +V basic_string& replace(iterator i1, iterator i2, + size_type n, charT c); +V template<class InputIterator> + basic_string& replace(iterator i1, iterator i2, + InputIterator j1, InputIterator j2); +V size_type copy(charT* s, size_type n, size_type pos = 0) const; +V void swap(basic_string<charT,traits,Allocator>&); + // _lib.string.ops_ string operations: +V const charT* c_str() const; // explicit +V const charT* data() const; +V allocator_type get_allocator() const; +V size_type find (const basic_string& str, size_type pos = 0) const; +V size_type find (const charT* s, size_type pos, size_type n) const; +V size_type find (const charT* s, size_type pos = 0) const; +V size_type find (charT c, size_type pos = 0) const; +V size_type rfind(const basic_string& str, size_type pos = npos) const; +V size_type rfind(const charT* s, size_type pos, size_type n) const; +V size_type rfind(const charT* s, size_type pos = npos) const; +V size_type rfind(charT c, size_type pos = npos) const; + +V size_type find_first_of(const basic_string& str, + size_type pos = 0) const; +V size_type find_first_of(const charT* s, + size_type pos, size_type n) const; +V size_type find_first_of(const charT* s, size_type pos = 0) const; +V size_type find_first_of(charT c, size_type pos = 0) const; +V size_type find_last_of (const basic_string& str, + size_type pos = npos) const; +V size_type find_last_of (const charT* s, + size_type pos, size_type n) const; +V size_type find_last_of (const charT* s, size_type pos = npos) const; +V size_type find_last_of (charT c, size_type pos = npos) const; +V size_type find_first_not_of(const basic_string& str, + size_type pos = 0) const; +V size_type find_first_not_of(const charT* s, size_type pos, + size_type n) const; +V size_type find_first_not_of(const charT* s, size_type pos = 0) const; +V size_type find_first_not_of(charT c, size_type pos = 0) const; +V size_type find_last_not_of (const basic_string& str, + size_type pos = npos) const; +V size_type find_last_not_of (const charT* s, size_type pos, + size_type n) const; +V size_type find_last_not_of (const charT* s, + size_type pos = npos) const; +V size_type find_last_not_of (charT c, size_type pos = npos) const; +V basic_string substr(size_type pos = 0, size_type n = npos) const; +V int compare(const basic_string& str) const; +V int compare(size_type pos1, size_type n1, + const basic_string& str) const; +V int compare(size_type pos1, size_type n1, + const basic_string& str, + size_type pos2, size_type n2) const; +V int compare(const charT* s) const; +V int compare(size_type pos1, size_type n1, + const charT* s, size_type n2 = npos) const; + }; + } + + 21.4 Null-terminated sequence utilities [lib.c.strings] + + Table 10--Header <cctype> synopsis + + isalnum isdigit isprint isupper tolower +X isalpha isgraph ispunct isxdigit toupper + iscntrl islower isspace + + Table 11--Header <cwctype> synopsis + +X Macro: WEOF <cwctype> +X Types: wctrans_t wctype_t wint_t <cwctype> + Functions: +X iswalnum iswctype iswlower iswspace towctrans wctrans +X iswalpha iswdigit iswprint iswupper towlower wctype +X iswcntrl iswgraph iswpunct iswxdigit towupper + + Table 12--Header <cstring> synopsis + +X Macro: NULL <cstring> +X Type: size_t <cstring> + Functions: +X memchr strcat strcspn strncpy strtok +X memcmp strchr strerror strpbrk strxfrm +X memcpy strcmp strlen strrchr +X memmove strcoll strncat strspn +X memset strcpy strncmp strstr + + Table 13--Header <cwchar> synopsis + Macros: NULL <cwchar> WCHAR_MAX WCHAR_MIN WEOF <cwchar> + Types: mbstate_t wint_t <cwchar> size_t + Functions: +X btowc getwchar ungetwc wcscpy wcsrtombs wmemchr +X fgetwc mbrlen vfwprintf wcscspn wcsspn wmemcmp +X fgetws mbrtowc vswprintf wcsftime wcsstr wmemcpy +X fputwc mbsinit vwprintf wcslen wcstod wmemmove +X fputws mbsrtowcs wcrtomb wcsncat wcstok wmemset +X fwide putwc wcscat wcsncmp wcstol wprintf +X fwprintf putwchar wcschr wcsncpy wcstoul wscanf +X fwscanf swprintf wcscmp wcspbrk wcsxfrm +X getwc swscanf wcscoll wcsrchr wctob + + Table 14--Header <cstdlib> synopsis + + Macros: MB_CUR_MAX + Functions: +X atol mblen strtod wctomb +X atof mbstowcs strtol wcstombs +X atoi mbtowc strtoul + +X const char* strchr(const char* s, int c); +X char* strchr( char* s, int c); + +X const char* strpbrk(const char* s1, const char* s2); +X char* strpbrk( char* s1, const char* s2); + +X const char* strrchr(const char* s, int c); +X char* strrchr( char* s, int c); + +X const char* strstr(const char* s1, const char* s2); +X char* strstr( char* s1, const char* s2); + +X const void* memchr(const void* s, int c, size_t n); +X void* memchr( void* s, int c, size_t n); + +X const wchar_t* wcschr(const wchar_t* s, wchar_t c); +X wchar_t* wcschr( wchar_t* s, wchar_t c); + +X const wchar_t* wcspbrk(const wchar_t* s1, const wchar_t* s2); +X wchar_t* wcspbrk( wchar_t* s1, const wchar_t* s2); + +X const wchar_t* wcsrchr(const wchar_t* s, wchar_t c); +X wchar_t* wcsrchr( wchar_t* s, wchar_t c); + +X const wchar_t* wcsstr(const wchar_t* s1, const wchar_t* s2); +X wchar_t* wcsstr( wchar_t* s1, const wchar_t* s2); + +X const wchar_t* wmemchr(const wchar_t* s, wchar_t c, size_t n); +X wchar_t* wmemchr( wchar_t* s, wchar_t c, size_t n); + + [for initial efforts on the above, see shadow/string.h] + + 22.1 Locales [lib.locales] + + Header <locale> synopsis + + // _lib.locale_, locale: +T class locale; +T template <class Facet> const Facet& use_facet(const locale&); +T template <class Facet> bool has_facet(const locale&) throw(); + + // _lib.locale.convenience_, convenience interfaces: +T template <class charT> bool isspace (charT c, const locale& loc); +T template <class charT> bool isprint (charT c, const locale& loc); +T template <class charT> bool iscntrl (charT c, const locale& loc); +T template <class charT> bool isupper (charT c, const locale& loc); +T template <class charT> bool islower (charT c, const locale& loc); +T template <class charT> bool isalpha (charT c, const locale& loc); +T template <class charT> bool isdigit (charT c, const locale& loc); +T template <class charT> bool ispunct (charT c, const locale& loc); +T template <class charT> bool isxdigit(charT c, const locale& loc); +T template <class charT> bool isalnum (charT c, const locale& loc); +T template <class charT> bool isgraph (charT c, const locale& loc); +T template <class charT> charT toupper(charT c, const locale& loc); +T template <class charT> charT tolower(charT c, const locale& loc); + // _lib.category.ctype_ and _lib.facet.ctype.special_, ctype: + class ctype_base; +T template <class charT> class ctype; +T template <> class ctype<char>; // specialization +S template <class charT> class ctype_byname; +S template <> class ctype_byname<char>; // specialization +T class codecvt_base; +X template <class internT, class externT, class stateT> class codecvt; +S template <class internT, class externT, class stateT> class codecvt_byname; + // _lib.category.numeric_ and _lib.facet.numpunct_, numeric: +X template <class charT, class InputIterator> class num_get; +X template <class charT, class OutputIterator> class num_put; +T template <class charT> class numpunct; +S template <class charT> class numpunct_byname; + // _lib.category.collate_, collation: +T template <class charT> class collate; +S template <class charT> class collate_byname; + // _lib.category.time_, date and time: +T class time_base; +S template <class charT, class InputIterator> class time_get; +S template <class charT, class InputIterator> class time_get_byname; +S template <class charT, class OutputIterator> class time_put; +S template <class charT, class OutputIterator> class time_put_byname; + // _lib.category.monetary_, money: +T class money_base; +S template <class charT, class InputIterator> class money_get; +S template <class charT, class OutputIterator> class money_put; +S template <class charT, bool Intl> class moneypunct; +S template <class charT, bool Intl> class moneypunct_byname; + // _lib.category.messages_, message retrieval: +T class messages_base; +S template <class charT> class messages; +S template <class charT> class messages_byname; + + + 22.1.1 Class locale [lib.locale] + +X class locale { + public: + // types: +T class facet; +T class id; +T typedef int category; +T static const category // values assigned here are for exposition only +T none = 0, +T collate = 0x010, ctype = 0x020, +T monetary = 0x040, numeric = 0x080, +T time = 0x100, messages = 0x200, +T all = collate | ctype | monetary | numeric | time | messages; + // construct/copy/destroy: +T locale() throw() +T locale(const locale& other) throw() +X explicit locale(const char* std_name); +X locale(const locale& other, const char* std_name, category); +T template <class Facet> locale(const locale& other, Facet* f); +T locale(const locale& other, const locale& one, category); +T ~locale() throw(); // non-virtual +T const locale& operator=(const locale& other) throw(); +T template <class Facet> locale combine(const locale& other) const; + // locale operations: +X basic_string<char> name() const; +T bool operator==(const locale& other) const; +T bool operator!=(const locale& other) const; +T template <class charT, class Traits, class Allocator> + bool operator()(const basic_string<charT,Traits,Allocator>& s1, + const basic_string<charT,Traits,Allocator>& s2) const; + // global locale objects: +T static locale global(const locale&); +T static const locale& classic(); + }; + + 22.1.1.1 locale types [lib.locale.types] + + 22.1.1.1.1 Type locale::category [lib.locale.category] + +T typedef int category; + +T none, collate, ctype, monetary, numeric, time, and messages + + [required locale members] +T collate<char>, collate<wchar_t> +T ctype<char>, ctype<wchar_t> +T codecvt<char,char,mbstate_t>, +S codecvt<wchar_t,char,mbstate_t> +T moneypunct<char>, moneypunct<wchar_t> +T moneypunct<char,true>, moneypunct<wchar_t,true>, +S money_get<char>, money_get<wchar_t +S money_put<char>, money_put<wchar_t> +T numpunct<char>, numpunct<wchar_t>, +X num_get<char>, num_get<wchar_t> +X num_put<char>, num_put<wchar_t> +S time_get<char>, time_get<wchar_t>, +S time_put<char>, time_put<wchar_t> +S messages<char>, messages<wchar_t> + + [required instantiations] +S collate_byname<char>, collate_byname<wchar_t> +S ctype_byname<char>, ctype_byname<wchar_t> +S codecvt_byname<char,char,mbstate_t>, +S codecvt_byname<wchar_t,char,mbstate_t> +S moneypunct_byname<char,International>, +S moneypunct_byname<wchar_t,International>, +S money_get<C,InputIterator>, +S money_put<C,OutputIterator> +S numpunct_byname<char>, numpunct_byname<wchar_t> +X num_get<C,InputIterator>, num_put<C,OutputIterator> +S time_get<char,InputIterator>, +S time_get_byname<char,InputIterator>, +S time_get<wchar_t,OutputIterator>, +S time_get_byname<wchar_t,OutputIterator>, +S time_put<char,OutputIterator>, +S time_put_byname<char,OutputIterator>, +S time_put<wchar_t,OutputIterator> +S time_put_byname<wchar_t,OutputIterator> +S messages_byname<char>, messages_byname<wchar_t> + + + 22.1.1.1.2 Class locale::facet [lib.locale.facet] + +T class locale::facet { + protected: +T explicit facet(size_t refs = 0); +T virtual ~facet(); + private: +T facet(const facet&); // not defined +T void operator=(const facet&); // not defined + }; + } + + + 22.1.1.1.3 Class locale::id [lib.locale.id] + +T class locale::id { + public: +T id(); + private: +T void operator=(const id&); // not defined +T id(const id&); // not defined + }; + } + + + 22.2.1 The ctype category [lib.category.ctype] + +T class ctype_base { + public: +T enum mask { // numeric values are for exposition only. +T space=, print=, cntrl=, upper=, lower=, +T alpha=, digit=, punct=, xdigit=, +T alnum=, graph= + }; + }; + + + 22.2.1.1 Template class ctype [lib.locale.ctype] + +T template <class charT> + class ctype : public locale::facet, public ctype_base { + public: +T typedef charT char_type; +T explicit ctype(size_t refs = 0); +T bool is(mask m, charT c) const; +T const charT* is(const charT* low, const charT* high, mask* vec) const; +T const charT* scan_is(mask m, + const charT* low, const charT* high) const; +T const charT* scan_not(mask m, + const charT* low, const charT* high) const; +T charT toupper(charT c) const; +T const charT* toupper(charT* low, const charT* high) const; +T charT tolower(charT c) const; +T const charT* tolower(charT* low, const charT* high) const; +T charT widen(char c) const; +T const char* widen(const char* low, const char* high, charT* to) const; +T char narrow(charT c, char dfault) const; +T const charT* narrow(const charT* low, const charT*, char dfault, + char* to) const; +T static locale::id id; + + protected: +T ~ctype(); // virtual +T virtual bool do_is(mask m, charT c) const; +T virtual const charT* do_is(const charT* low, const charT* high, + mask* vec) const; +T virtual const charT* do_scan_is(mask m, + const charT* low, const charT* high) const; +T virtual const charT* do_scan_not(mask m, + const charT* low, const charT* high) const; +T virtual charT do_toupper(charT) const; +T virtual const charT* do_toupper(charT* low, const charT* high) const; +T virtual charT do_tolower(charT) const; +T virtual const charT* do_tolower(charT* low, const charT* high) const; +T virtual charT do_widen(char) const; +T virtual const char* do_widen(const char* low, const char* high, + charT* dest) const; +T virtual char do_narrow(charT, char dfault) const; +T virtual const charT* do_narrow(const charT* low, const charT* high, + char dfault, char* dest) const; + }; + + + 22.2.1.2 Template class ctype_byname [lib.locale.ctype.byname] + +X template <class charT> + class ctype_byname : public ctype<charT> { + public: +T typedef ctype<charT>::mask mask; +S explicit ctype_byname(const char*, size_t refs = 0); + protected: +S ~ctype_byname(); // virtual +S virtual bool do_is(mask m, charT c) const; +S virtual const charT* do_is(const charT* low, const charT* high, + mask* vec) const; +S virtual const char* do_scan_is(mask m, + const charT* low, const charT* high) const; +S virtual const char* do_scan_not(mask m, + const charT* low, const charT* high) const; +S virtual charT do_toupper(charT) const; +S virtual const charT* do_toupper(charT* low, const charT* high) const; +S virtual charT do_tolower(charT) const; +S virtual const charT* do_tolower(charT* low, const charT* high) const; +S virtual charT do_widen(char) const; +S virtual const char* do_widen(const char* low, const char* high, + charT* dest) const; +S virtual char do_narrow(charT, char dfault) const; +S virtual const charT* do_narrow(const charT* low, const charT* high, + char dfault, char* dest) const; + }; + + 22.2.1.3 ctype specializations [lib.facet.ctype.special] + +T template <> class ctype<char> + : public locale::facet, public ctype_base { + public: +T typedef char char_type; +T explicit ctype(const mask* tab = 0, bool del = false, + size_t refs = 0); +T bool is(mask m, char c) const; +T const char* is(const char* low, const char* high, mask* vec) const; +T const char* scan_is (mask m, + const char* low, const char* high) const; +T const char* scan_not(mask m, + const char* low, const char* high) const; +T char toupper(char c) const; +T const char* toupper(char* low, const char* high) const; +T char tolower(char c) const; +T const char* tolower(char* low, const char* high) const; +T char widen(char c) const; +T const char* widen(const char* low, const char* high, char* to) const; +T char narrow(char c, char dfault) const; +T const char* narrow(const char* low, const char* high, char dfault, + char* to) const; +T static locale::id id; +T static const size_t table_size = IMPLEMENTATION_DEFINED; + + protected: +T const mask* table() const throw(); +T static const mask* classic_table() throw(); +T ~ctype(); // virtual +T virtual char do_toupper(char c) const; +T virtual const char* do_toupper(char* low, const char* high) const; +T virtual char do_tolower(char c) const; +T virtual const char* do_tolower(char* low, const char* high) const; + +T virtual char do_widen(char c) const; +T virtual const char* do_widen(const char* low, + const char* high, + char* to) const; +T virtual char do_narrow(char c, char dfault) const; +T virtual const char* do_narrow(const char* low, + const char* high, + char dfault, char* to) const; + }; + + + 22.2.1.4 Class [lib.locale.ctype.byname.special] + ctype_byname<char> + +X template <> class ctype_byname<char> : public ctype<char> { + public: +S explicit ctype_byname(const char*, size_t refs = 0); + protected: +S ~ctype_byname(); // virtual +S virtual char do_toupper(char c) const; +S virtual const char* do_toupper(char* low, const char* high) const; +S virtual char do_tolower(char c) const; +S virtual const char* do_tolower(char* low, const char* high) const; + +S virtual char do_widen(char c) const; +S virtual const char* do_widen(char* low, + const char* high, + char* to) const; +S virtual char do_widen(char c) const; +S virtual const char* do_widen(char* low, const char* high) const; + + }; + + + + 22.2.1.5 Template class codecvt [lib.locale.codecvt] + +T class codecvt_base { + public: +T enum result { ok, partial, error, noconv }; + }; + +T template <class internT, class externT, class stateT> + class codecvt : public locale::facet, public codecvt_base { + public: +T typedef internT intern_type; +T typedef externT extern_type; +T typedef stateT state_type; +T explicit codecvt(size_t refs = 0) +T result out(stateT& state, + const internT* from, const internT* from_end, const internT*& from_next, + externT* to, externT* to_limit, externT*& to_next) const; +T result unshift(stateT& state, + externT* to, externT* to_limit, externT*& to_next) const; +T result in(stateT& state, + const externT* from, const externT* from_end, const externT*& from_next, + internT* to, internT* to_limit, internT*& to_next) const; +T int encoding() const throw(); +T bool always_noconv() const throw(); +T int length(const stateT&, const externT* from, const externT* end, + size_t max) const; +T int max_length() const throw(); +T static locale::id id; + + protected: +T ~codecvt(); // virtual +T virtual result do_out(stateT& state, + const internT* from, const internT* from_end, const internT*& from_next, + externT* to, externT* to_limit, externT*& to_next) const; +T virtual result do_in(stateT& state, +T const externT* from, const externT* from_end, const externT*& from_next, + internT* to, internT* to_limit, internT*& to_next) const; +T virtual result do_unshift(stateT& state, + externT* to, externT* to_limit, externT*& to_next) const; +T virtual int do_encoding() const throw(); +T virtual bool do_always_noconv() const throw(); +T virtual int do_length(const stateT&, const externT* from, + const externT* end, size_t max) const; +T virtual int do_max_length() const throw(); + }; + } + + + 22.2.1.6 Template class [lib.locale.codecvt.byname] + codecvt_byname + +X template <class internT, class externT, class stateT> + class codecvt_byname : public codecvt<internT, externT, stateT> { + public: +S explicit codecvt_byname(const char*, size_t refs = 0); + protected: +S ~codecvt_byname(); // virtual +S virtual result do_out(stateT& state, + const internT* from, const internT* from_end, const internT*& from_next, + externT* to, externT* to_limit, externT*& to_next) const; +S virtual result do_in(stateT& state, + const externT* from, const externT* from_end, const externT*& from_next, + internT* to, internT* to_limit, internT*& to_next) const; +S virtual result do_unshift(stateT& state, + externT* to, externT* to_limit, externT*& to_next) const; +S virtual int do_encoding() const throw(); +S virtual bool do_always_noconv() const throw(); +S virtual int do_length(const stateT&, const externT* from, + const externT* end, size_t max) const; +S virtual result do_unshift(stateT& state, + externT* to, externT* to_limit, externT*& to_next) const; +S virtual int do_max_length() const throw(); + }; + + + 22.2.2.1 Template class num_get [lib.locale.num.get] + +X template <class charT, class InputIterator = istreambuf_iterator<charT> > + class num_get : public locale::facet { + public: +T typedef charT char_type; +T typedef InputIterator iter_type; +T explicit num_get(size_t refs = 0); +T iter_type get(iter_type in, iter_type end, ios_base&, + ios_base::iostate& err, bool& v) const; +T iter_type get(iter_type in, iter_type end, ios_base& , + ios_base::iostate& err, long& v) const; +T iter_type get(iter_type in, iter_type end, ios_base&, + ios_base::iostate& err, unsigned short& v) const; +T iter_type get(iter_type in, iter_type end, ios_base&, + ios_base::iostate& err, unsigned int& v) const; +T iter_type get(iter_type in, iter_type end, ios_base&, + ios_base::iostate& err, unsigned long& v) const; +T iter_type get(iter_type in, iter_type end, ios_base&, + ios_base::iostate& err, float& v) const; +T iter_type get(iter_type in, iter_type end, ios_base&, + ios_base::iostate& err, double& v) const; +T iter_type get(iter_type in, iter_type end, ios_base&, + ios_base::iostate& err, long double& v) const; +T iter_type get(iter_type in, iter_type end, ios_base&, + ios_base::iostate& err, void*& v) const; +T static locale::id id; + + protected: +T ~num_get(); // virtual +T virtual iter_type do_get(iter_type, iter_type, ios_base&, + ios_base::iostate& err, bool& v) const; +S virtual iter_type do_get(iter_type, iter_type, ios_base&, + ios_base::iostate& err, long& v) const; +S virtual iter_type do_get(iter_type, iter_type, ios_base&, + ios_base::iostate& err, unsigned short& v) const; +S virtual iter_type do_get(iter_type, iter_type, ios_base&, + ios_base::iostate& err, unsigned int& v) const; +S virtual iter_type do_get(iter_type, iter_type, ios_base&, + ios_base::iostate& err, unsigned long& v) const; +S virtual iter_type do_get(iter_type, iter_type, ios_base&, + ios_base::iostate& err, float& v) const; +S virtual iter_type do_get(iter_type, iter_type, ios_base&, + ios_base::iostate& err, double& v) const; +S virtual iter_type do_get(iter_type, iter_type, ios_base&, + ios_base::iostate& err, long double& v) const; +S virtual iter_type do_get(iter_type, iter_type, ios_base&, + ios_base::iostate& err, void*& v) const; + }; + + + + 22.2.2.2 Template class num_put [lib.locale.nm.put] + +X template <class charT, class OutputIterator = ostreambuf_iterator<charT> > + class num_put : public locale::facet { + public: +T typedef charT char_type; +T typedef OutputIterator iter_type; +T explicit num_put(size_t refs = 0); +T iter_type put(iter_type s, ios_base& f, char_type fill, bool v) const; +T iter_type put(iter_type s, ios_base& f, char_type fill, long v) const; +T iter_type put(iter_type s, ios_base& f, char_type fill, + unsigned long v) const; +T iter_type put(iter_type s, ios_base& f, char_type fill, + double v) const; +T iter_type put(iter_type s, ios_base& f, char_type fill, + long double v) const; +T iter_type put(iter_type s, ios_base& f, char_type fill, + const void* v) const; +T static locale::id id; + protected: +T ~num_put(); // virtual +T virtual iter_type do_put(iter_type, ios_base&, char_type fill, + bool v) const; +T virtual iter_type do_put(iter_type, ios_base&, char_type fill, + long v) const; +T virtual iter_type do_put(iter_type, ios_base&, char_type fill, + unsigned long) const; +S virtual iter_type do_put(iter_type, ios_base&, char_type fill, + double v) const; +S virtual iter_type do_put(iter_type, ios_base&, char_type fill, + long double v) const; +T virtual iter_type do_put(iter_type, ios_base&, char_type fill, + const void* v) const; + }; + } + + 22.2.3.1 Template class numpunct [lib.locale.numpunct] + +T template <class charT> + class numpunct : public locale::facet { + public: +T typedef charT char_type; +T typedef basic_string<charT> string_type; +T explicit numpunct(size_t refs = 0); +T char_type decimal_point() const; +T char_type thousands_sep() const; +T string grouping() const; +T string_type truename() const; +T string_type falsename() const; +T static locale::id id; + protected: +T ~numpunct(); // virtual +T virtual char_type do_decimal_point() const; +T virtual char_type do_thousands_sep() const; +T virtual string do_grouping() const; +T virtual string_type do_truename() const; // for bool +T virtual string_type do_falsename() const; // for bool + }; + } + + + + 22.2.3.2 Template class [lib.locale.numpunct.byname] + numpunct_byname + +X template <class charT> + class numpunct_byname : public numpunct<charT> { + // this class is specialized for char and wchar_t. + public: +T typedef charT char_type; +T typedef basic_string<charT> string_type; +S explicit numpunct_byname(const char*, size_t refs = 0); + protected: +S ~numpunct_byname(); // virtual +S virtual char_type do_decimal_point() const; +S virtual char_type do_thousands_sep() const; +S virtual string do_grouping() const; +S virtual string_type do_truename() const; // for bool +S virtual string_type do_falsename() const; // for bool + }; + + + 22.2.4.1 Template class collate [lib.locale.collate] + +T template <class charT> + class collate : public locale::facet { + public: +T typedef charT char_type; +T typedef basic_string<charT> string_type; +T explicit collate(size_t refs = 0); +T int compare(const charT* low1, const charT* high1, + const charT* low2, const charT* high2) const; +T string_type transform(const charT* low, const charT* high) const; +T long hash(const charT* low, const charT* high) const; +T static locale::id id; + protected: +T ~collate(); // virtual +T virtual int do_compare(const charT* low1, const charT* high1, + const charT* low2, const charT* high2) const; +T virtual string_type do_transform + (const charT* low, const charT* high) const; +T virtual long do_hash (const charT* low, const charT* high) const; + }; + + + 22.2.4.2 Template class [lib.locale.collate.byname] + collate_byname + +X template <class charT> + class collate_byname : public collate<charT> { + public: +T typedef basic_string<charT> string_type; +T explicit collate_byname(const char*, size_t refs = 0); + protected: +S ~collate_byname(); // virtual +S virtual int do_compare(const charT* low1, const charT* high1, + const charT* low2, const charT* high2) const; +S virtual string_type do_transform + (const charT* low, const charT* high) const; +S virtual long do_hash (const charT* low, const charT* high) const; + }; + + + 22.2.5.1 Template class time_get [lib.locale.time.get] + +T class time_base { + public: +T enum dateorder { no_order, dmy, mdy, ymd, ydm }; + }; + + [Note: semantics of time_get members are implementation-defined. + To complete implementation requires documenting behavior.] + +X template <class charT, class InputIterator = istreambuf_iterator<charT> > + class time_get : public locale::facet, public time_base { + public: +T typedef charT char_type; +T typedef InputIterator iter_type; +T explicit time_get(size_t refs = 0); + +T dateorder date_order() const { return do_date_order(); } +T iter_type get_time(iter_type s, iter_type end, ios_base& f, + ios_base::iostate& err, tm* t) const; +T iter_type get_date(iter_type s, iter_type end, ios_base& f, + ios_base::iostate& err, tm* t) const; +T iter_type get_weekday(iter_type s, iter_type end, ios_base& f, + ios_base::iostate& err, tm* t) const; +T iter_type get_monthname(iter_type s, iter_type end, ios_base& f, + ios_base::iostate& err, tm* t) const; +T iter_type get_year(iter_type s, iter_type end, ios_base& f, + ios_base::iostate& err, tm* t) const; +T static locale::id id; + protected: + ~time_get(); // virtual +X virtual dateorder do_date_order() const; +S virtual iter_type do_get_time(iter_type s, iter_type end, ios_base&, + ios_base::iostate& err, tm* t) const; +S virtual iter_type do_get_date(iter_type s, iter_type end, ios_base&, + ios_base::iostate& err, tm* t) const; +S virtual iter_type do_get_weekday(iter_type s, iter_type end, ios_base&, + ios_base::iostate& err, tm* t) const; +S virtual iter_type do_get_monthname(iter_type s, ios_base&, + ios_base::iostate& err, tm* t) const; +S virtual iter_type do_get_year(iter_type s, iter_type end, ios_base&, + ios_base::iostate& err, tm* t) const; + }; + + + + 22.2.5.2 Template class [lib.locale.time.get.byname] + time_get_byname + +X template <class charT, class InputIterator = istreambuf_iterator<charT> > + class time_get_byname : public time_get<charT, InputIterator> { + public: +T typedef time_base::dateorder dateorder; +T typedef InputIterator iter_type + +S explicit time_get_byname(const char*, size_t refs = 0); + protected: +S ~time_get_byname(); // virtual +S virtual dateorder do_date_order() const; +S virtual iter_type do_get_time(iter_type s, iter_type end, ios_base&, + ios_base::iostate& err, tm* t) const; +S virtual iter_type do_get_date(iter_type s, iter_type end, ios_base&, + ios_base::iostate& err, tm* t) const; +T virtual iter_type do_get_weekday(iter_type s, iter_type end, ios_base&, + ios_base::iostate& err, tm* t) const; +T virtual iter_type do_get_monthname(iter_type s, iter_type end, ios_base&, + ios_base::iostate& err, tm* t) const; +S virtual iter_type do_get_year(iter_type s, iter_type end, ios_base&, + ios_base::iostate& err, tm* t) const; + }; + } + + 22.2.5.3 Template class time_put [lib.locale.time.put] + +X template <class charT, class OutputIterator = ostreambuf_iterator<charT> > + class time_put : public locale::facet { + public: +T typedef charT char_type; +T typedef OutputIterator iter_type; +T explicit time_put(size_t refs = 0); + // the following is implemented in terms of other member functions. +S iter_type put(iter_type s, ios_base& f, char_type fill, const tm* tmb, + const charT* pattern, const charT* pat_end) const; +T iter_type put(iter_type s, ios_base& f, char_type fill, + const tm* tmb, char format, char modifier = 0) const; +T static locale::id id; + protected: +T ~time_put(); // virtual +S virtual iter_type do_put(iter_type s, ios_base&, char_type, const tm* t, + char format, char modifier) const; + }; + + + + 22.2.5.4 Template class [lib.locale.time.put.byname] + time_put_byname + +T template <class charT, class OutputIterator = ostreambuf_iterator<charT> > + class time_put_byname : public time_put<charT, OutputIterator> + { + public: +T typedef charT char_type; +T typedef OutputIterator iter_type; + +T explicit time_put_byname(const char*, size_t refs = 0); + protected: +T ~time_put_byname(); // virtual +S virtual iter_type do_put(iter_type s, ios_base&, char_type, const tm* t, + char format, char modifier) const; + }; + + + 22.2.6.1 Template class money_get [lib.locale.money.get] + +X template <class charT, + class InputIterator = istreambuf_iterator<charT> > + class money_get : public locale::facet { + public: +T typedef charT char_type; +T typedef InputIterator iter_type; +T typedef basic_string<charT> string_type; +T explicit money_get(size_t refs = 0); +T iter_type get(iter_type s, iter_type end, bool intl, + ios_base& f, ios_base::iostate& err, + long double& units) const; +T iter_type get(iter_type s, iter_type end, bool intl, + ios_base& f, ios_base::iostate& err, + string_type& digits) const; +T static locale::id id; + protected: +T ~money_get(); // virtual +S virtual iter_type do_get(iter_type, iter_type, bool, ios_base&, + ios_base::iostate& err, long double& units) const; +S virtual iter_type do_get(iter_type, iter_type, bool, ios_base&, + ios_base::iostate& err, string_type& digits) const; + }; + + 22.2.6.2 Template class money_put [lib.locale.money.put] + +X template <class charT, + class OutputIterator = ostreambuf_iterator<charT> > + class money_put : public locale::facet { + public: +T typedef charT char_type; +T typedef OutputIterator iter_type; +T typedef basic_string<charT> string_type; +T explicit money_put(size_t refs = 0); +T iter_type put(iter_type s, bool intl, ios_base& f, + char_type fill, long double units) const; +T iter_type put(iter_type s, bool intl, ios_base& f, + char_type fill, const string_type& digits) const; +T static locale::id id; + + protected: +T ~money_put(); // virtual +S virtual iter_type + do_put(iter_type, bool, ios_base&, char_type fill, + long double units) const; +S virtual iter_type + do_put(iter_type, bool, ios_base&, char_type fill, + const string_type& digits) const; + }; + + + 22.2.6.3 Template class moneypunct [lib.locale.moneypunct] + +T class money_base { + public: +T enum part { none, space, symbol, sign, value }; +T struct pattern { char field[4]; }; + }; + +X template <class charT, bool International = false> + class moneypunct : public locale::facet, public money_base { + public: +T typedef charT char_type; +T typedef basic_string<charT> string_type; +T explicit moneypunct(size_t refs = 0); +T charT decimal_point() const; +T charT thousands_sep() const; +T string grouping() const; +T string_type curr_symbol() const; +T string_type positive_sign() const; +T string_type negative_sign() const; +T int frac_digits() const; +T pattern pos_format() const; +T pattern neg_format() const; +T static locale::id id; +T static const bool intl = International; + protected: +T ~moneypunct(); // virtual +S virtual charT do_decimal_point() const; +S virtual charT do_thousands_sep() const; +S virtual string do_grouping() const; +S virtual string_type do_curr_symbol() const; +S virtual string_type do_positive_sign() const; +S virtual string_type do_negative_sign() const; +S virtual int do_frac_digits() const; +T virtual pattern do_pos_format() const; +T virtual pattern do_neg_format() const; + }; + } + + 22.2.6.4 Template class [lib.locale.moneypunct.byname] + moneypunct_byname + +X template <class charT, bool Intl = false> + class moneypunct_byname : public moneypunct<charT, Intl> { + public: +T typedef money_base::pattern pattern; +T typedef basic_string<charT> string_type; + +T explicit moneypunct_byname(const char*, size_t refs = 0); + protected: +T ~moneypunct_byname(); // virtual +S virtual charT do_decimal_point() const; +S virtual charT do_thousands_sep() const; +S virtual string do_grouping() const; +S virtual string_type do_curr_symbol() const; +S virtual string_type do_positive_sign() const; +S virtual string_type do_negative_sign() const; +S virtual int do_frac_digits() const; +S virtual pattern do_pos_format() const; +S virtual pattern do_neg_format() const; + }; + + 22.2.7.1 Template class messages [lib.locale.messages] + +T class messages_base { + public: +T typedef int catalog; + }; + +X template <class charT> + class messages : public locale::facet, public messages_base { + public: +T typedef charT char_type; +T typedef basic_string<charT> string_type; +T explicit messages(size_t refs = 0); +T catalog open(const basic_string<char>& fn, const locale&) const; +T string_type get(catalog c, int set, int msgid, + const string_type& dfault) const; +T void close(catalog c) const; +T static locale::id id; + protected: +T ~messages(); // virtual +S virtual catalog do_open(const basic_string<char>&, const locale&) const; +S virtual string_type do_get(catalog, int set, int msgid, + const string_type& dfault) const; +S virtual void do_close(catalog) const; + }; + + 22.2.7.2 Template class [lib.locale.messages.byname] + messages_byname + + +X template <class charT> + class messages_byname : public messages<charT> { + public: +T typedef messages_base::catalog catalog; +T typedef basic_string<charT> string_type; + +T explicit messages_byname(const char*, size_t refs = 0); + protected: +T ~messages_byname(); // virtual +S virtual catalog do_open(const basic_string<char>&, const locale&) const; +S virtual string_type do_get(catalog, int set, int msgid, + const string_type& dfault) const; +S virtual void do_close(catalog) const; + }; + + + 22.3 C Library Locales [lib.c.locales] + + + Table 13--Header <clocale> synopsis + Macros: +X LC_ALL LC_COLLATE LC_CTYPE +X LC_MONETARY LC_NUMERIC LC_TIME +X NULL +X Struct: lconv +X Functions: localeconv setlocale + + + 23.2 Sequences [lib.sequences] + + <deque>, <list>, <queue>, <stack>, and <vector>. + + Header <deque> synopsis + +T template <class T, class Allocator = allocator<T> > class deque; +T template <class T, class Allocator> + bool operator==(const deque<T,Allocator>& x, const deque<T,Allocator>& y); +T template <class T, class Allocator> + bool operator< (const deque<T,Allocator>& x, const deque<T,Allocator>& y); +T template <class T, class Allocator> + bool operator!=(const deque<T,Allocator>& x, const deque<T,Allocator>& y); +T template <class T, class Allocator> + bool operator> (const deque<T,Allocator>& x, const deque<T,Allocator>& y); +T template <class T, class Allocator> + bool operator>=(const deque<T,Allocator>& x, const deque<T,Allocator>& y); +T template <class T, class Allocator> + bool operator<=(const deque<T,Allocator>& x, const deque<T,Allocator>& y); +T template <class T, class Allocator> + void swap(deque<T,Allocator>& x, deque<T,Allocator>& y); + } + + Header <list> synopsis + +T template <class T, class Allocator = allocator<T> > class list; +T template <class T, class Allocator> + bool operator==(const list<T,Allocator>& x, const list<T,Allocator>& y); +T template <class T, class Allocator> + bool operator< (const list<T,Allocator>& x, const list<T,Allocator>& y); +T template <class T, class Allocator> + bool operator!=(const list<T,Allocator>& x, const list<T,Allocator>& y); +T template <class T, class Allocator> + bool operator> (const list<T,Allocator>& x, const list<T,Allocator>& y); +T template <class T, class Allocator> + bool operator>=(const list<T,Allocator>& x, const list<T,Allocator>& y); +T template <class T, class Allocator> + bool operator<=(const list<T,Allocator>& x, const list<T,Allocator>& y); +T template <class T, class Allocator> + void swap(list<T,Allocator>& x, list<T,Allocator>& y); + } + + Header <queue> synopsis + + namespace std { +T template <class T, class Container = deque<T> > class queue; +T template <class T, class Container> + bool operator==(const queue<T, Container>& x, + const queue<T, Container>& y); +T template <class T, class Container> + bool operator< (const queue<T, Container>& x, + const queue<T, Container>& y); +T template <class T, class Container> + bool operator!=(const queue<T, Container>& x, + const queue<T, Container>& y); +T template <class T, class Container> + bool operator> (const queue<T, Container>& x, + const queue<T, Container>& y); +T template <class T, class Container> + bool operator>=(const queue<T, Container>& x, + const queue<T, Container>& y); +T template <class T, class Container> + bool operator<=(const queue<T, Container>& x, + const queue<T, Container>& y); +T template <class T, class Container = vector<T>, + class Compare = less<typename Container::value_type> > +T class priority_queue; + } + + Header <stack> synopsis + + namespace std { +T template <class T, class Container = deque<T> > class stack; +T template <class T, class Container> + bool operator==(const stack<T, Container>& x, + const stack<T, Container>& y); +T template <class T, class Container> + bool operator< (const stack<T, Container>& x, + const stack<T, Container>& y); +T template <class T, class Container> + bool operator!=(const stack<T, Container>& x, + const stack<T, Container>& y); +T template <class T, class Container> + bool operator> (const stack<T, Container>& x, + const stack<T, Container>& y); +T template <class T, class Container> + bool operator>=(const stack<T, Container>& x, + const stack<T, Container>& y); +T template <class T, class Container> + bool operator<=(const stack<T, Container>& x, + const stack<T, Container>& y); + } + + Header <vector> synopsis + +T template <class T, class Allocator = allocator<T> > class vector; + +T template <class T, class Allocator> + bool operator==(const vector<T,Allocator>& x, + const vector<T,Allocator>& y); +T template <class T, class Allocator> + bool operator< (const vector<T,Allocator>& x, + const vector<T,Allocator>& y); +T template <class T, class Allocator> + bool operator!=(const vector<T,Allocator>& x, + const vector<T,Allocator>& y); +T template <class T, class Allocator> + bool operator> (const vector<T,Allocator>& x, + const vector<T,Allocator>& y); +T template <class T, class Allocator> + bool operator>=(const vector<T,Allocator>& x, + const vector<T,Allocator>& y); +T template <class T, class Allocator> + bool operator<=(const vector<T,Allocator>& x, + const vector<T,Allocator>& y); +T template <class T, class Allocator> + void swap(vector<T,Allocator>& x, vector<T,Allocator>& y); + +T template <class Allocator> class vector<bool,Allocator>; +T template <class Allocator> + bool operator==(const vector<bool,Allocator>& x, + const vector<bool,Allocator>& y); +T template <class Allocator> + bool operator< (const vector<bool,Allocator>& x, + const vector<bool,Allocator>& y); +T template <class Allocator> + bool operator!=(const vector<bool,Allocator>& x, + const vector<bool,Allocator>& y); +T template <class Allocator> + bool operator> (const vector<bool,Allocator>& x, + const vector<bool,Allocator>& y); +T template <class Allocator> + bool operator>=(const vector<bool,Allocator>& x, + const vector<bool,Allocator>& y); +T template <class Allocator> + bool operator<=(const vector<bool,Allocator>& x, + const vector<bool,Allocator>& y); +T template <class Allocator> + void swap(vector<bool,Allocator>& x, vector<bool,Allocator>& y); + } + + 23.2.1 Template class deque [lib.deque] + + template <class T, class Allocator = allocator<T> > +T class deque { + public: + // types: +T typedef typename Allocator::reference reference; +T typedef typename Allocator::const_reference const_reference; +T typedef implementation defined iterator; +T typedef implementation defined const_iterator; +T typedef implementation defined size_type; +T typedef implementation defined difference_type; +T typedef T value_type; +T typedef Allocator allocator_type; +T typedef typename Allocator::pointer pointer; +T typedef typename Allocator::const_pointer const_pointer; +T typedef std::reverse_iterator<iterator> reverse_iterator; +T typedef std::reverse_iterator<const_iterator> const_reverse_iterator; + // _lib.deque.cons_ construct/copy/destroy: +T explicit deque(const Allocator& = Allocator()); +T explicit deque(size_type n, const T& value = T(), + const Allocator& = Allocator()); +T template <class InputIterator> + deque(InputIterator first, InputIterator last, + const Allocator& = Allocator()); +T deque(const deque<T,Allocator>& x); +T ~deque(); +T deque<T,Allocator>& operator=(const deque<T,Allocator>& x); +T template <class InputIterator> + void assign(InputIterator first, InputIterator last); +T void assign(size_type n, const T& t); +T allocator_type get_allocator() const; + // iterators: +T iterator begin(); +T const_iterator begin() const; +T iterator end(); +T const_iterator end() const; +T reverse_iterator rbegin(); +T const_reverse_iterator rbegin() const; +T reverse_iterator rend(); +T const_reverse_iterator rend() const; + // _lib.deque.capacity_ capacity: +T size_type size() const; +T size_type max_size() const; +T void resize(size_type sz, T c = T()); +T bool empty() const; + + // element access: +T reference operator[](size_type n); +T const_reference operator[](size_type n) const; +T reference at(size_type n); +T const_reference at(size_type n) const; +T reference front(); +T const_reference front() const; +T reference back(); +T const_reference back() const; + // _lib.deque.modifiers_ modifiers: +T void push_front(const T& x); +T void push_back(const T& x); +T iterator insert(iterator position, const T& x); +T void insert(iterator position, size_type n, const T& x); +T template <class InputIterator> + void insert (iterator position, + InputIterator first, InputIterator last); +T void pop_front(); +T void pop_back(); +T iterator erase(iterator position); +T iterator erase(iterator first, iterator last); +T void swap(deque<T,Allocator>&); +T void clear(); + }; +T template <class T, class Allocator> + bool operator==(const deque<T,Allocator>& x, + const deque<T,Allocator>& y); +T template <class T, class Allocator> + bool operator< (const deque<T,Allocator>& x, + const deque<T,Allocator>& y); +T template <class T, class Allocator> + bool operator!=(const deque<T,Allocator>& x, + const deque<T,Allocator>& y); +T template <class T, class Allocator> + bool operator> (const deque<T,Allocator>& x, + const deque<T,Allocator>& y); +T template <class T, class Allocator> + bool operator>=(const deque<T,Allocator>& x, + const deque<T,Allocator>& y); +T template <class T, class Allocator> + bool operator<=(const deque<T,Allocator>& x, + const deque<T,Allocator>& y); + // specialized algorithms: +T template <class T, class Allocator> + void swap(deque<T,Allocator>& x, deque<T,Allocator>& y); + + + 23.2.2 Template class list [lib.list] + +T template <class T, class Allocator = allocator<T> > + class list { + public: + // types: +T typedef typename Allocator::reference reference; +T typedef typename Allocator::const_reference const_reference; +T typedef implementation defined iterator; +T typedef implementation defined const_iterator; +T typedef implementation defined size_type; +T typedef implementation defined difference_type; +T typedef T value_type; +T typedef Allocator allocator_type; +T typedef typename Allocator::pointer pointer; +T typedef typename Allocator::const_pointer const_pointer; +T typedef std::reverse_iterator<iterator> reverse_iterator; +T typedef std::reverse_iterator<const_iterator> const_reverse_iterator; + + // _lib.list.cons_ construct/copy/destroy: +T explicit list(const Allocator& = Allocator()); +T explicit list(size_type n, const T& value = T(), + const Allocator& = Allocator()); +T template <class InputIterator> + list(InputIterator first, InputIterator last, + const Allocator& = Allocator()); +T list(const list<T,Allocator>& x); +T ~list(); +T list<T,Allocator>& operator=(const list<T,Allocator>& x); +T template <class InputIterator> + void assign(InputIterator first, InputIterator last); +T void assign(size_type n, const T& t); +T allocator_type get_allocator() const; + // iterators: +T iterator begin(); +T const_iterator begin() const; +T iterator end(); +T const_iterator end() const; +T reverse_iterator rbegin(); +T const_reverse_iterator rbegin() const; +T reverse_iterator rend(); +T const_reverse_iterator rend() const; + // _lib.list.capacity_ capacity: +T bool empty() const; +T size_type size() const; +T size_type max_size() const; +T void resize(size_type sz, T c = T()); + // element access: +T reference front(); +T const_reference front() const; +T reference back(); +T const_reference back() const; + // _lib.list.modifiers_ modifiers: +T void push_front(const T& x); +T void pop_front(); +T void push_back(const T& x); +T void pop_back(); +T iterator insert(iterator position, const T& x); +T void insert(iterator position, size_type n, const T& x); +T template <class InputIterator> + void insert(iterator position, InputIterator first, + InputIterator last); +T iterator erase(iterator position); +T iterator erase(iterator position, iterator last); +T void swap(list<T,Allocator>&); +T void clear(); + // _lib.list.ops_ list operations: +T void splice(iterator position, list<T,Allocator>& x); +T void splice(iterator position, list<T,Allocator>& x, iterator i); +T void splice(iterator position, list<T,Allocator>& x, iterator first, + iterator last); +T void remove(const T& value); +T template <class Predicate> void remove_if(Predicate pred); + +T void unique(); +T template <class BinaryPredicate> + void unique(BinaryPredicate binary_pred); +T void merge(list<T,Allocator>& x); +T template <class Compare> void merge(list<T,Allocator>& x, Compare comp); + void sort(); +T template <class Compare> void sort(Compare comp); + void reverse(); + }; +T template <class T, class Allocator> + bool operator==(const list<T,Allocator>& x, const list<T,Allocator>& y); +T template <class T, class Allocator> + bool operator< (const list<T,Allocator>& x, const list<T,Allocator>& y); +T template <class T, class Allocator> + bool operator!=(const list<T,Allocator>& x, const list<T,Allocator>& y); +T template <class T, class Allocator> + bool operator> (const list<T,Allocator>& x, const list<T,Allocator>& y); +T template <class T, class Allocator> + bool operator>=(const list<T,Allocator>& x, const list<T,Allocator>& y); +T template <class T, class Allocator> + bool operator<=(const list<T,Allocator>& x, const list<T,Allocator>& y); + // specialized algorithms: +T template <class T, class Allocator> + void swap(list<T,Allocator>& x, list<T,Allocator>& y); + + + 23.2.3.1 Template class queue [lib.queue] + +T template <class T, class Container = deque<T> > + class queue { + public: +T typedef typename Container::value_type value_type; +T typedef typename Container::size_type size_type; +T typedef Container container_type; + protected: +T Container c; + public: +T explicit queue(const Container& = Container()); + +T bool empty() const { return c.empty(); } +T size_type size() const { return c.size(); } +T value_type& front() { return c.front(); } +T const value_type& front() const { return c.front(); } +T value_type& back() { return c.back(); } +T const value_type& back() const { return c.back(); } +T void push(const value_type& x) { c.push_back(x); } +T void pop() { c.pop_front(); } + }; + +T template <class T, class Container> + bool operator==(const queue<T, Container>& x, + const queue<T, Container>& y); +T template <class T, class Container> + bool operator< (const queue<T, Container>& x, + const queue<T, Container>& y); +T template <class T, class Container> + bool operator!=(const queue<T, Container>& x, + const queue<T, Container>& y); +T template <class T, class Container> + bool operator> (const queue<T, Container>& x, + const queue<T, Container>& y); +T template <class T, class Container> + bool operator>=(const queue<T, Container>& x, + const queue<T, Container>& y); +T template <class T, class Container> + bool operator<=(const queue<T, Container>& x, + const queue<T, Container>& y); + + 23.2.3.2 Template class priority_queue [lib.priority.queue] + +T template <class T, class Container = vector<T>, + class Compare = less<typename Container::value_type> > + class priority_queue { + public: +T typedef typename Container::value_type value_type; +T typedef typename Container::size_type size_type; +T typedef Container container_type; + protected: +T Container c; +T Compare comp; + public: +T explicit priority_queue(const Compare& x = Compare(), + const Container& = Container()); +T template <class InputIterator> + priority_queue(InputIterator first, InputIterator last, + const Compare& x = Compare(), + const Container& = Container()); + +T bool empty() const { return c.empty(); } +T size_type size() const { return c.size(); } +T const value_type& top() const { return c.front(); } +T void push(const value_type& x); +T void pop(); + }; + + 23.2.3.3 Template class stack [lib.stack] + +T template <class T, class Container = deque<T> > + class stack { + public: +T typedef typename Container::value_type value_type; +T typedef typename Container::size_type size_type; +T typedef Container container_type; + protected: +T Container c; + public: +T explicit stack(const Container& = Container()); + +T bool empty() const { return c.empty(); } +T size_type size() const { return c.size(); } +T value_type& top() { return c.back(); } +T const value_type& top() const { return c.back(); } +T void push(const value_type& x) { c.push_back(x); } +T void pop() { c.pop_back(); } + }; +T template <class T, class Container> + bool operator==(const stack<T, Container>& x, + const stack<T, Container>& y); +T template <class T, class Container> + bool operator< (const stack<T, Container>& x, + const stack<T, Container>& y); +T template <class T, class Container> + bool operator!=(const stack<T, Container>& x, + const stack<T, Container>& y); +T template <class T, class Container> + bool operator> (const stack<T, Container>& x, + const stack<T, Container>& y); +T template <class T, class Container> + bool operator>=(const stack<T, Container>& x, + const stack<T, Container>& y); +T template <class T, class Container> + bool operator<=(const stack<T, Container>& x, + const stack<T, Container>& y); + + 23.2.4 Template class vector [lib.vector] + + template <class T, class Allocator = allocator<T> > +T class vector { + public: + // types: +T typedef typename Allocator::reference reference; +T typedef typename Allocator::const_reference const_reference; +T typedef implementation defined iterator; +T typedef implementation defined const_iterator; +T typedef implementation defined size_type; +T typedef implementation defined difference_type; +T typedef T value_type; +T typedef Allocator allocator_type; +T typedef typename Allocator::pointer pointer; +T typedef typename Allocator::const_pointer const_pointer +T typedef std::reverse_iterator<iterator> reverse_iterator; +T typedef std::reverse_iterator<const_iterator> const_reverse_iterator; + // _lib.vector.cons_ construct/copy/destroy: +T explicit vector(const Allocator& = Allocator()); +T explicit vector(size_type n, const T& value = T(), + const Allocator& = Allocator()); +T template <class InputIterator> + vector(InputIterator first, InputIterator last, + const Allocator& = Allocator()); +T vector(const vector<T,Allocator>& x); +T ~vector(); +T vector<T,Allocator>& operator=(const vector<T,Allocator>& x); +T template <class InputIterator> + void assign(InputIterator first, InputIterator last); +T void assign(size_type n, const T& u); +T allocator_type get_allocator() const; + // iterators: +T iterator begin(); +T const_iterator begin() const; +T iterator end(); +T const_iterator end() const; +T reverse_iterator rbegin(); +T const_reverse_iterator rbegin() const; +T reverse_iterator rend(); +T const_reverse_iterator rend() const; + // _lib.vector.capacity_ capacity: +T size_type size() const; +T size_type max_size() const; +T void resize(size_type sz, T c = T()); +T size_type capacity() const; +T bool empty() const; +T void reserve(size_type n); + + // element access: +T reference operator[](size_type n); +T const_reference operator[](size_type n) const; +T const_reference at(size_type n) const; +T reference at(size_type n); +T reference front(); +T const_reference front() const; +T reference back(); +T const_reference back() const; + // _lib.vector.modifiers_ modifiers: +T void push_back(const T& x); +T void pop_back(); +T iterator insert(iterator position, const T& x); +T void insert(iterator position, size_type n, const T& x); +T template <class InputIterator> + void insert(iterator position, + InputIterator first, InputIterator last); +T iterator erase(iterator position); +T iterator erase(iterator first, iterator last); +T void swap(vector<T,Allocator>&); +T void clear(); + }; + +T template <class T, class Allocator> + bool operator==(const vector<T,Allocator>& x, + const vector<T,Allocator>& y); +T template <class T, class Allocator> + bool operator< (const vector<T,Allocator>& x, + const vector<T,Allocator>& y); +T template <class T, class Allocator> + bool operator!=(const vector<T,Allocator>& x, + const vector<T,Allocator>& y); +T template <class T, class Allocator> + bool operator> (const vector<T,Allocator>& x, + const vector<T,Allocator>& y); +T template <class T, class Allocator> + bool operator>=(const vector<T,Allocator>& x, + const vector<T,Allocator>& y); +T template <class T, class Allocator> + bool operator<=(const vector<T,Allocator>& x, + const vector<T,Allocator>& y); + // specialized algorithms: +T template <class T, class Allocator> + void swap(vector<T,Allocator>& x, vector<T,Allocator>& y); + + + 23.2.5 Class vector<bool> [lib.vector.bool] + +T template <class Allocator> class vector<bool, Allocator> { + public: + // types: +T typedef bool const_reference; +T typedef implementation defined iterator; +T typedef implementation defined const_iterator; +T typedef implementation defined size_type; +T typedef implementation defined difference_type; +T typedef bool value_type; +T typedef Allocator allocator_type; +T typedef implementation defined pointer; +T typedef implementation defined const_pointer +T typedef std::reverse_iterator<iterator> reverse_iterator; +T typedef std::reverse_iterator<const_iterator> const_reverse_iterator; + // bit reference: +T class reference { + friend class vector; +T reference(); + public: +T ~reference(); +T operator bool() const; +T reference& operator=(const bool x); +T reference& operator=(const reference& x); +T void flip(); // flips the bit + }; + + // construct/copy/destroy: +T explicit vector(const Allocator& = Allocator()); +T explicit vector(size_type n, const bool& value = bool(), + const Allocator& = Allocator()); +T template <class InputIterator> + vector(InputIterator first, InputIterator last, + const Allocator& = Allocator()); +T vector(const vector<bool,Allocator>& x); +T ~vector(); +T vector<bool,Allocator>& operator=(const vector<bool,Allocator>& x); +T template <class InputIterator> + void assign(InputIterator first, InputIterator last); +T void assign(size_type n, const T& t); +T allocator_type get_allocator() const; + // iterators: +T iterator begin(); +T const_iterator begin() const; +T iterator end(); +T const_iterator end() const; +T reverse_iterator rbegin(); +T const_reverse_iterator rbegin() const; +T reverse_iterator rend(); +T const_reverse_iterator rend() const; + // capacity: +T size_type size() const; +T size_type max_size() const; +T void resize(size_type sz, bool c = false); +T size_type capacity() const; +T bool empty() const; +T void reserve(size_type n); + // element access: +T reference operator[](size_type n); +T const_reference operator[](size_type n) const; +T const_reference at(size_type n) const; +T reference at(size_type n); +T reference front(); +T const_reference front() const; +T reference back(); +T const_reference back() const; + // modifiers: +T void push_back(const bool& x); +T void pop_back(); +T iterator insert(iterator position, const bool& x); +T void insert (iterator position, size_type n, const bool& x); +T template <class InputIterator> + void insert(iterator position, + InputIterator first, InputIterator last); +T iterator erase(iterator position); +T iterator erase(iterator first, iterator last); +T void swap(vector<bool,Allocator>&); +T static void swap(reference x, reference y); +T void flip(); // flips all bits +T void clear(); + }; + +T template <class Allocator> + bool operator==(const vector<bool,Allocator>& x, + const vector<bool,Allocator>& y); +T template <class Allocator> + bool operator< (const vector<bool,Allocator>& x, + const vector<bool,Allocator>& y); +T template <class Allocator> + bool operator!=(const vector<bool,Allocator>& x, + const vector<bool,Allocator>& y); +T template <class Allocator> + bool operator> (const vector<bool,Allocator>& x, + const vector<bool,Allocator>& y); +T template <class Allocator> + bool operator>=(const vector<bool,Allocator>& x, + const vector<bool,Allocator>& y); +T template <class Allocator> + bool operator<=(const vector<bool,Allocator>& x, + const vector<bool,Allocator>& y); + // specialized algorithms: +T template <class Allocator> + void swap(vector<bool,Allocator>& x, vector<bool,Allocator>& y); + + 23.3 Associative containers [lib.associative] + + <map> and <set>: + + Header <map> synopsis + + template <class Key, class T, class Compare = less<Key>, + class Allocator = allocator<pair<const Key, T> > > +T class map; + +T template <class Key, class T, class Compare, class Allocator> + bool operator==(const map<Key,T,Compare,Allocator>& x, + const map<Key,T,Compare,Allocator>& y); +T template <class Key, class T, class Compare, class Allocator> + bool operator< (const map<Key,T,Compare,Allocator>& x, + const map<Key,T,Compare,Allocator>& y); +T template <class Key, class T, class Compare, class Allocator> + bool operator!=(const map<Key,T,Compare,Allocator>& x, + const map<Key,T,Compare,Allocator>& y); +T template <class Key, class T, class Compare, class Allocator> + bool operator> (const map<Key,T,Compare,Allocator>& x, + const map<Key,T,Compare,Allocator>& y); +T template <class Key, class T, class Compare, class Allocator> + bool operator>=(const map<Key,T,Compare,Allocator>& x, + const map<Key,T,Compare,Allocator>& y); +T template <class Key, class T, class Compare, class Allocator> + bool operator<=(const map<Key,T,Compare,Allocator>& x, + const map<Key,T,Compare,Allocator>& y); +T template <class Key, class T, class Compare, class Allocator> + void swap(map<Key,T,Compare,Allocator>& x, + map<Key,T,Compare,Allocator>& y); +T template <class Key, class T, class Compare = less<Key>, + class Allocator = allocator<pair<const Key, T> > > + class multimap; +T template <class Key, class T, class Compare, class Allocator> + bool operator==(const multimap<Key,T,Compare,Allocator>& x, + const multimap<Key,T,Compare,Allocator>& y); +T template <class Key, class T, class Compare, class Allocator> + bool operator< (const multimap<Key,T,Compare,Allocator>& x, + const multimap<Key,T,Compare,Allocator>& y); +T template <class Key, class T, class Compare, class Allocator> + bool operator!=(const multimap<Key,T,Compare,Allocator>& x, + const multimap<Key,T,Compare,Allocator>& y); +T template <class Key, class T, class Compare, class Allocator> + bool operator> (const multimap<Key,T,Compare,Allocator>& x, + const multimap<Key,T,Compare,Allocator>& y); +T template <class Key, class T, class Compare, class Allocator> + bool operator>=(const multimap<Key,T,Compare,Allocator>& x, + const multimap<Key,T,Compare,Allocator>& y); +T template <class Key, class T, class Compare, class Allocator> + bool operator<=(const multimap<Key,T,Compare,Allocator>& x, + const multimap<Key,T,Compare,Allocator>& y); +T template <class Key, class T, class Compare, class Allocator> + void swap(multimap<Key,T,Compare,Allocator>& x, + multimap<Key,T,Compare,Allocator>& y); + } + + Header <set> synopsis + + template <class Key, class Compare = less<Key>, + class Allocator = allocator<Key> > +T class set; + +T template <class Key, class Compare, class Allocator> + bool operator==(const set<Key,Compare,Allocator>& x, + const set<Key,Compare,Allocator>& y); +T template <class Key, class Compare, class Allocator> + bool operator< (const set<Key,Compare,Allocator>& x, + const set<Key,Compare,Allocator>& y); +T template <class Key, class Compare, class Allocator> + bool operator!=(const set<Key,Compare,Allocator>& x, + const set<Key,Compare,Allocator>& y); +T template <class Key, class Compare, class Allocator> + bool operator> (const set<Key,Compare,Allocator>& x, + const set<Key,Compare,Allocator>& y); +T template <class Key, class Compare, class Allocator> + bool operator>=(const set<Key,Compare,Allocator>& x, + const set<Key,Compare,Allocator>& y); +T template <class Key, class Compare, class Allocator> + bool operator<=(const set<Key,Compare,Allocator>& x, + const set<Key,Compare,Allocator>& y); +T template <class Key, class Compare, class Allocator> + void swap(set<Key,Compare,Allocator>& x, + set<Key,Compare,Allocator>& y); +T template <class Key, class Compare = less<Key>, + class Allocator = allocator<Key> > + class multiset; +T template <class Key, class Compare, class Allocator> + bool operator==(const multiset<Key,Compare,Allocator>& x, + const multiset<Key,Compare,Allocator>& y); +T template <class Key, class Compare, class Allocator> + bool operator< (const multiset<Key,Compare,Allocator>& x, + const multiset<Key,Compare,Allocator>& y); +T template <class Key, class Compare, class Allocator> + bool operator!=(const multiset<Key,Compare,Allocator>& x, + const multiset<Key,Compare,Allocator>& y); +T template <class Key, class Compare, class Allocator> + bool operator> (const multiset<Key,Compare,Allocator>& x, + const multiset<Key,Compare,Allocator>& y); +T template <class Key, class Compare, class Allocator> + bool operator>=(const multiset<Key,Compare,Allocator>& x, + const multiset<Key,Compare,Allocator>& y); +T template <class Key, class Compare, class Allocator> + bool operator<=(const multiset<Key,Compare,Allocator>& x, + const multiset<Key,Compare,Allocator>& y); +T template <class Key, class Compare, class Allocator> + void swap(multiset<Key,Compare,Allocator>& x, + multiset<Key,Compare,Allocator>& y); + } + + 23.3.1 Template class map [lib.map] + + template <class Key, class T, class Compare = less<Key>, + class Allocator = allocator<pair<const Key, T> > > +T class map { + public: + // types: +T typedef Key key_type; +T typedef T mapped_type; +T typedef pair<const Key, T> value_type; +T typedef Compare key_compare; +T typedef Allocator allocator_type; +T typedef typename Allocator::reference reference; +T typedef typename Allocator::const_reference const_reference; +T typedef implementation defined iterator; +T typedef implementation defined const_iterator; +T typedef implementation defined size_type; +T typedef implementation defined difference_type; +T typedef typename Allocator::pointer pointer; +T typedef typename Allocator::const_pointer const_pointer; +T typedef std::reverse_iterator<iterator> reverse_iterator; +T typedef std::reverse_iterator<const_iterator> const_reverse_iterator; +T class value_compare + : public binary_function<value_type,value_type,bool> { + friend class map; + protected: +T Compare comp; +T value_compare(Compare c) : comp(c) {} + public: +T bool operator()(const value_type& x, const value_type& y) const { + return comp(x.first, y.first); + } + }; + + // _lib.map.cons_ construct/copy/destroy: +T explicit map(const Compare& comp = Compare(), + const Allocator& = Allocator()); +T template <class InputIterator> + map(InputIterator first, InputIterator last, + const Compare& comp = Compare(), const Allocator& = Allocator()); +T map(const map<Key,T,Compare,Allocator>& x); +T ~map(); +T map<Key,T,Compare,Allocator>& + operator=(const map<Key,T,Compare,Allocator>& x); + // iterators: +T iterator begin(); +T const_iterator begin() const; +T iterator end(); +T const_iterator end() const; +T reverse_iterator rbegin(); +T const_reverse_iterator rbegin() const; +T reverse_iterator rend(); +T const_reverse_iterator rend() const; + // capacity: +T bool empty() const; +T size_type size() const; +T size_type max_size() const; + // _lib.map.access_ element access: +T T& operator[](const key_type& x); + // modifiers: +T pair<iterator, bool> insert(const value_type& x); +T iterator insert(iterator position, const value_type& x); +T template <class InputIterator> + void insert(InputIterator first, InputIterator last); +T void erase(iterator position); +T size_type erase(const key_type& x); +T void erase(iterator first, iterator last); +T void swap(map<Key,T,Compare,Allocator>&); +T void clear(); + // observers: +T key_compare key_comp() const; +T value_compare value_comp() const; + // _lib.map.ops_ map operations: +T iterator find(const key_type& x); +T const_iterator find(const key_type& x) const; +T size_type count(const key_type& x) const; +T iterator lower_bound(const key_type& x); +T const_iterator lower_bound(const key_type& x) const; +T iterator upper_bound(const key_type& x); +T const_iterator upper_bound(const key_type& x) const; +T pair<iterator,iterator> + equal_range(const key_type& x); +T pair<const_iterator,const_iterator> + equal_range(const key_type& x) const; + }; + +T template <class Key, class T, class Compare, class Allocator> + bool operator==(const map<Key,T,Compare,Allocator>& x, + const map<Key,T,Compare,Allocator>& y); +T template <class Key, class T, class Compare, class Allocator> + bool operator< (const map<Key,T,Compare,Allocator>& x, + const map<Key,T,Compare,Allocator>& y); +T template <class Key, class T, class Compare, class Allocator> + bool operator!=(const map<Key,T,Compare,Allocator>& x, + const map<Key,T,Compare,Allocator>& y); +T template <class Key, class T, class Compare, class Allocator> + bool operator> (const map<Key,T,Compare,Allocator>& x, + const map<Key,T,Compare,Allocator>& y); +T template <class Key, class T, class Compare, class Allocator> + bool operator>=(const map<Key,T,Compare,Allocator>& x, + const map<Key,T,Compare,Allocator>& y); +T template <class Key, class T, class Compare, class Allocator> + bool operator<=(const map<Key,T,Compare,Allocator>& x, + const map<Key,T,Compare,Allocator>& y); + // specialized algorithms: +T template <class Key, class T, class Compare, class Allocator> + void swap(map<Key,T,Compare,Allocator>& x, + map<Key,T,Compare,Allocator>& y); + + 23.3.2 Template class multimap [lib.multimap] + + template <class Key, class T, class Compare = less<Key>, + class Allocator = allocator<pair<const Key, T> > > +T class multimap { + public: + // types: +T typedef Key key_type; +T typedef T mapped_type; +T typedef pair<const Key,T> value_type; +T typedef Compare key_compare; +T typedef Allocator allocator_type; +T typedef typename Allocator::reference reference; +T typedef typename Allocator::const_reference const_reference; +T typedef implementation defined iterator; +T typedef implementation defined const_iterator; +T typedef implementation defined size_type; +T typedef implementation defined difference_type +T typedef typename Allocator::pointer pointer; +T typedef typename Allocator::const_pointer const_pointer; +T typedef std::reverse_iterator<iterator> reverse_iterator; +T typedef std::reverse_iterator<const_iterator> const_reverse_iterator; +T class value_compare + : public binary_function<value_type,value_type,bool> { + friend class multimap; + protected: +T Compare comp; +T value_compare(Compare c) : comp(c) {} + public: +T bool operator()(const value_type& x, const value_type& y) const { + return comp(x.first, y.first); + } + }; + // construct/copy/destroy: +T explicit multimap(const Compare& comp = Compare(), + const Allocator& = Allocator()); +T template <class InputIterator> + multimap(InputIterator first, InputIterator last, + const Compare& comp = Compare(), + const Allocator& = Allocator()); +T multimap(const multimap<Key,T,Compare,Allocator>& x); +T ~multimap(); +T multimap<Key,T,Compare,Allocator>& + operator=(const multimap<Key,T,Compare,Allocator>& x); +T allocator_type get_allocator() const; + + // iterators: +T iterator begin(); +T const_iterator begin() const; +T iterator end(); +T const_iterator end() const; +T reverse_iterator rbegin(); +T const_reverse_iterator rbegin() const; +T reverse_iterator rend(); +T const_reverse_iterator rend() const; + // capacity: +T bool empty() const; +T size_type size() const; +T size_type max_size() const; + // modifiers: +T iterator insert(const value_type& x); +T iterator insert(iterator position, const value_type& x); +T template <class InputIterator> + void insert(InputIterator first, InputIterator last); +T void erase(iterator position); +T size_type erase(const key_type& x); +T void erase(iterator first, iterator last); +T void swap(multimap<Key,T,Compare,Allocator>&); +T void clear(); + // observers: +T key_compare key_comp() const; +T value_compare value_comp() const; + // map operations: +T iterator find(const key_type& x); +T const_iterator find(const key_type& x) const; +T size_type count(const key_type& x) const; +T iterator lower_bound(const key_type& x); +T const_iterator lower_bound(const key_type& x) const; +T iterator upper_bound(const key_type& x); +T const_iterator upper_bound(const key_type& x) const; +T pair<iterator,iterator> equal_range(const key_type& x); +T pair<const_iterator,const_iterator> equal_range(const key_type& x) const; + }; + +T template <class Key, class T, class Compare, class Allocator> + bool operator==(const multimap<Key,T,Compare,Allocator>& x, + const multimap<Key,T,Compare,Allocator>& y); +T template <class Key, class T, class Compare, class Allocator> + bool operator< (const multimap<Key,T,Compare,Allocator>& x, + const multimap<Key,T,Compare,Allocator>& y); +T template <class Key, class T, class Compare, class Allocator> + bool operator!=(const multimap<Key,T,Compare,Allocator>& x, + const multimap<Key,T,Compare,Allocator>& y); +T template <class Key, class T, class Compare, class Allocator> + bool operator> (const multimap<Key,T,Compare,Allocator>& x, + const multimap<Key,T,Compare,Allocator>& y); +T template <class Key, class T, class Compare, class Allocator> + bool operator>=(const multimap<Key,T,Compare,Allocator>& x, + const multimap<Key,T,Compare,Allocator>& y); +T template <class Key, class T, class Compare, class Allocator> + bool operator<=(const multimap<Key,T,Compare,Allocator>& x, + const multimap<Key,T,Compare,Allocator>& y); + // specialized algorithms: +T template <class Key, class T, class Compare, class Allocator> + void swap(multimap<Key,T,Compare,Allocator>& x, + multimap<Key,T,Compare,Allocator>& y); + + + 23.3.3 Template class set [lib.set] + + template <class Key, class Compare = less<Key>, + class Allocator = allocator<Key> > +T class set { + public: + // types: +T typedef Key key_type; +T typedef Key value_type; +T typedef Compare key_compare; +T typedef Compare value_compare; +T typedef Allocator allocator_type; +T typedef typename Allocator::reference reference; +T typedef typename Allocator::const_reference const_reference; +T typedef implementation defined iterator; +T typedef implementation defined const_iterator; +T typedef implementation defined size_type; +T typedef implementation defined difference_type; +T typedef typename Allocator::pointer pointer; +T typedef typename Allocator::const_pointer const_pointer; +T typedef std::reverse_iterator<iterator> reverse_iterator; +T typedef std::reverse_iterator<const_iterator> const_reverse_iterator; + // _lib.set.cons_ construct/copy/destroy: +T explicit set(const Compare& comp = Compare(), + const Allocator& = Allocator()); +T template <class InputIterator> + set(InputIterator first, InputIterator last, + const Compare& comp = Compare(), const Allocator& = Allocator()); +T set(const set<Key,Compare,Allocator>& x); +T ~set(); +T set<Key,Compare,Allocator>& + operator=(const set<Key,Compare,Allocator>& x); +T allocator_type get_allocator() const; + // iterators: +T iterator begin(); +T const_iterator begin() const; +T iterator end(); +T const_iterator end() const; +T reverse_iterator rbegin(); +T const_reverse_iterator rbegin() const; +T reverse_iterator rend(); +T const_reverse_iterator rend() const; + // capacity: +T bool empty() const; +T size_type size() const; +T size_type max_size() const; + // modifiers: +T pair<iterator,bool> insert(const value_type& x); +T iterator insert(iterator position, const value_type& x); +T template <class InputIterator> +T void insert(InputIterator first, InputIterator last); +T void erase(iterator position); +T size_type erase(const key_type& x); +T void erase(iterator first, iterator last); +T void swap(set<Key,Compare,Allocator>&); +T void clear(); + + // observers: +T key_compare key_comp() const; +T value_compare value_comp() const; + // set operations: +T iterator find(const key_type& x) const; +T size_type count(const key_type& x) const; +T iterator lower_bound(const key_type& x) const; +T iterator upper_bound(const key_type& x) const; +T pair<iterator,iterator> equal_range(const key_type& x) const; + }; +T template <class Key, class Compare, class Allocator> + bool operator==(const set<Key,Compare,Allocator>& x, + const set<Key,Compare,Allocator>& y); +T template <class Key, class Compare, class Allocator> + bool operator< (const set<Key,Compare,Allocator>& x, + const set<Key,Compare,Allocator>& y); +T template <class Key, class Compare, class Allocator> + bool operator!=(const set<Key,Compare,Allocator>& x, + const set<Key,Compare,Allocator>& y); +T template <class Key, class Compare, class Allocator> + bool operator> (const set<Key,Compare,Allocator>& x, + const set<Key,Compare,Allocator>& y); +T template <class Key, class Compare, class Allocator> + bool operator>=(const set<Key,Compare,Allocator>& x, + const set<Key,Compare,Allocator>& y); +T template <class Key, class Compare, class Allocator> + bool operator<=(const set<Key,Compare,Allocator>& x, + const set<Key,Compare,Allocator>& y); + // specialized algorithms: +T template <class Key, class Compare, class Allocator> + void swap(set<Key,Compare,Allocator>& x, + set<Key,Compare,Allocator>& y); + + 23.3.4 Template class multiset [lib.multiset] + + template <class Key, class Compare = less<Key>, + class Allocator = allocator<Key> > +T class multiset { + public: + // types: +T typedef Key key_type; +T typedef Key value_type; +T typedef Compare key_compare; +T typedef Compare value_compare; +T typedef Allocator allocator_type; +T typedef typename Allocator::reference reference; +T typedef typename Allocator::const_reference const_reference; +T typedef implementation defined iterator; +T typedef implementation defined const_iterator; +T typedef implementation defined size_type; +T typedef implementation defined difference_type +T typedef typename Allocator::pointer pointer; +T typedef typename Allocator::const_pointer const_pointer; +T typedef std::reverse_iterator<iterator> reverse_iterator; +T typedef std::reverse_iterator<const_iterator> const_reverse_iterator; + + // construct/copy/destroy: +T explicit multiset(const Compare& comp = Compare(), + const Allocator& = Allocator()); +T template <class InputIterator> + multiset(InputIterator first, InputIterator last, + const Compare& comp = Compare(), + const Allocator& = Allocator()); +T multiset(const multiset<Key,Compare,Allocator>& x); +T ~multiset(); +T multiset<Key,Compare,Allocator>& + operator=(const multiset<Key,Compare,Allocator>& x); +T allocator_type get_allocator() const; + // iterators: +T iterator begin(); +T const_iterator begin() const; +T iterator end(); +T const_iterator end() const; +T reverse_iterator rbegin(); +T const_reverse_iterator rbegin() const; +T reverse_iterator rend(); +T const_reverse_iterator rend() const; + // capacity: +T bool empty() const; +T size_type size() const; +T size_type max_size() const; + // modifiers: +T iterator insert(const value_type& x); +T iterator insert(iterator position, const value_type& x); +T template <class InputIterator> + void insert(InputIterator first, InputIterator last); +T void erase(iterator position); +T size_type erase(const key_type& x); +T void erase(iterator first, iterator last); +T void swap(multiset<Key,Compare,Allocator>&); +T void clear(); + // observers: +T key_compare key_comp() const; +T value_compare value_comp() const; + // set operations: +T iterator find(const key_type& x) const; +T size_type count(const key_type& x) const; +T iterator lower_bound(const key_type& x) const; +T iterator upper_bound(const key_type& x) const; +T pair<iterator,iterator> equal_range(const key_type& x) const; + }; + +T template <class Key, class Compare, class Allocator> + bool operator==(const multiset<Key,Compare,Allocator>& x, + const multiset<Key,Compare,Allocator>& y); +T template <class Key, class Compare, class Allocator> + bool operator< (const multiset<Key,Compare,Allocator>& x, + const multiset<Key,Compare,Allocator>& y); +T template <class Key, class Compare, class Allocator> + bool operator!=(const multiset<Key,Compare,Allocator>& x, + const multiset<Key,Compare,Allocator>& y); +T template <class Key, class Compare, class Allocator> + bool operator> (const multiset<Key,Compare,Allocator>& x, + const multiset<Key,Compare,Allocator>& y); +T template <class Key, class Compare, class Allocator> + bool operator>=(const multiset<Key,Compare,Allocator>& x, + const multiset<Key,Compare,Allocator>& y); +T template <class Key, class Compare, class Allocator> + bool operator<=(const multiset<Key,Compare,Allocator>& x, + const multiset<Key,Compare,Allocator>& y); + // specialized algorithms: +T template <class Key, class Compare, class Allocator> + void swap(multiset<Key,Compare,Allocator>& x, + multiset<Key,Compare,Allocator>& y); + + 23.3.5 Template class bitset [lib.template.bitset] + + Header <bitset> synopsis + +T template <size_t N> class bitset; + // _lib.bitset.operators_ bitset operations: +T template <size_t N> + bitset<N> operator&(const bitset<N>&, const bitset<N>&); +T template <size_t N> + bitset<N> operator|(const bitset<N>&, const bitset<N>&); +T template <size_t N> + bitset<N> operator^(const bitset<N>&, const bitset<N>&); +T template <class charT, class traits, size_t N> + basic_istream<charT, traits>& + operator>>(basic_istream<charT, traits>& is, bitset<N>& x); +T template <class charT, class traits, size_t N> + basic_ostream<charT, traits>& + operator<<(basic_ostream<charT, traits>& os, const bitset<N>& x); + +T template<size_t N> class bitset { + public: + // bit reference: +T class reference { + friend class bitset; +T reference(); + public: +T ~reference(); +T reference& operator=(bool x); // for b[i] = x; +T reference& operator=(const reference&); // for b[i] = b[j]; +T bool operator~() const; // flips the bit +T operator bool() const; // for x = b[i]; +T reference& flip(); // for b[i].flip(); + }; + + // _lib.bitset.cons_ constructors: +T bitset(); +T bitset(unsigned long val); +T template<class charT, class traits, class Allocator> + explicit bitset( + const basic_string<charT,traits,Allocator>& str, + typename basic_string<charT,traits,Allocator>::size_type pos = 0, + typename basic_string<charT,traits,Allocator>::size_type n = + basic_string<charT,traits,Allocator>::npos); + // _lib.bitset.members_ bitset operations: +T bitset<N>& operator&=(const bitset<N>& rhs); +T bitset<N>& operator|=(const bitset<N>& rhs); +T bitset<N>& operator^=(const bitset<N>& rhs); +T bitset<N>& operator<<=(size_t pos); +T bitset<N>& operator>>=(size_t pos); +T bitset<N>& set(); +T bitset<N>& set(size_t pos, int val = true); +T bitset<N>& reset(); +T bitset<N>& reset(size_t pos); +T bitset<N> operator~() const; +T bitset<N>& flip(); +T bitset<N>& flip(size_t pos); + // element access: +T reference operator[](size_t pos); // for b[i]; +T unsigned long to_ulong() const; +T template <class charT, class traits, class Allocator> + basic_string<charT, traits, Allocator> to_string() const; +T size_t count() const; +T size_t size() const; +T bool operator==(const bitset<N>& rhs) const; +T bool operator!=(const bitset<N>& rhs) const; +T bool test(size_t pos) const; +T bool any() const; +T bool none() const; +T bitset<N> operator<<(size_t pos) const; +T bitset<N> operator>>(size_t pos) const; + }; + + + + + 24.2 Header <iterator> synopsis [lib.iterator.synopsis] + + // _lib.iterator.primitives_, primitives: +T template<class Iterator> struct iterator_traits; +T template<class T> struct iterator_traits<T*>; + +X template<class Category, class T, class Distance = ptrdiff_t, + class Pointer = T*, class Reference = T&> struct iterator; +T struct input_iterator_tag {}; +T struct output_iterator_tag {}; +T struct forward_iterator_tag: public input_iterator_tag {}; +T struct bidirectional_iterator_tag: public forward_iterator_tag {}; +T struct random_access_iterator_tag: public bidirectional_iterator_tag {}; + // _lib.iterator.operations_, iterator operations: +T template <class InputIterator, class Distance> + void advance(InputIterator& i, Distance n); +T template <class InputIterator> + typename iterator_traits<InputIterator>::difference_type + distance(InputIterator first, InputIterator last); + // _lib.predef.iterators_, predefined iterators: +X template <class Iterator> class reverse_iterator; +T template <class Iterator> + bool operator==( + const reverse_iterator<Iterator>& x, + const reverse_iterator<Iterator>& y); +T template <class Iterator> + bool operator<( + const reverse_iterator<Iterator>& x, + const reverse_iterator<Iterator>& y); +T template <class Iterator> + bool operator!=( + const reverse_iterator<Iterator>& x, + const reverse_iterator<Iterator>& y); +T template <class Iterator> + bool operator>( + const reverse_iterator<Iterator>& x, + const reverse_iterator<Iterator>& y); +T template <class Iterator> + bool operator>=( + const reverse_iterator<Iterator>& x, + const reverse_iterator<Iterator>& y); +T template <class Iterator> + bool operator<=( + const reverse_iterator<Iterator>& x, + const reverse_iterator<Iterator>& y); +T template <class Iterator> + typename reverse_iterator<Iterator>::difference_type operator-( + const reverse_iterator<Iterator>& x, + const reverse_iterator<Iterator>& y); +T template <class Iterator> + reverse_iterator<Iterator> + operator+( + typename reverse_iterator<Iterator>::difference_type n, + const reverse_iterator<Iterator>& x); + +X template <class Container> class back_insert_iterator; +T template <class Container> + back_insert_iterator<Container> back_inserter(Container& x); +X template <class Container> class front_insert_iterator; +T template <class Container> + front_insert_iterator<Container> front_inserter(Container& x); +X template <class Container> class insert_iterator; +T template <class Container, class Iterator> + insert_iterator<Container> inserter(Container& x, Iterator i); + // _lib.stream.iterators_, stream iterators: +X template <class T, class charT = char, class traits = char_traits<charT>, + class Distance = ptrdiff_t> + class istream_iterator; + template <class T, class charT, class traits, class Distance> +X bool operator==(const istream_iterator<T,charT,traits,Distance>& x, + const istream_iterator<T,charT,traits,Distance>& y); + template <class T, class charT, class traits, class Distance> +X bool operator!=(const istream_iterator<T,charT,traits,Distance>& x, + const istream_iterator<T,charT,traits,Distance>& y); +X template <class T, class charT = char, class traits = char_traits<charT> > + class ostream_iterator; +X template<class charT, class traits = char_traits<charT> > + class istreambuf_iterator; +X template <class charT, class traits> + bool operator==(const istreambuf_iterator<charT,traits>& a, + const istreambuf_iterator<charT,traits>& b); +X template <class charT, class traits> + bool operator!=(const istreambuf_iterator<charT,traits>& a, + const istreambuf_iterator<charT,traits>& b); +T template <class charT, class traits = char_traits<charT> > + class ostreambuf_iterator; + + 24.3 Iterator primitives [lib.iterator.primitives] + +T template<class Iterator> struct iterator_traits { +T typedef typename Iterator::difference_type difference_type; +T typedef typename Iterator::value_type value_type; +T typedef typename Iterator::pointer pointer; +T typedef typename Iterator::reference reference; +T typedef typename Iterator::iterator_category iterator_category; + }; + +T template<class T> struct iterator_traits<T*> { +T typedef ptrdiff_t difference_type; +T typedef T value_type; +T typedef T* pointer; +T typedef T& reference; +T typedef random_access_iterator_tag iterator_category; + }; + +T template<class T> struct iterator_traits<const T*> { +T typedef ptrdiff_t difference_type; +T typedef T value_type; +T typedef const T* pointer; +T typedef const T& reference; +T typedef random_access_iterator_tag iterator_category; + }; + + 24.3.2 Basic iterator [lib.iterator.basic] + + template<class Category, class T, class Distance = ptrdiff_t, + class Pointer = T*, class Reference = T&> +X struct iterator { +T typedef T value_type; +T typedef Distance difference_type; +T typedef Pointer pointer; +T typedef Reference reference; +T typedef Category iterator_category; + }; + + 24.3.3 Standard iterator tags [lib.std.iterator.tags] + +T struct input_iterator_tag {}; +T struct output_iterator_tag {}; +T struct forward_iterator_tag: public input_iterator_tag {}; +T struct bidirectional_iterator_tag: public forward_iterator_tag {}; +T struct random_access_iterator_tag: public bidirectional_iterator_tag {}; + + + 24.4.1 Reverse iterators [lib.reverse.iterators] + + template <class Iterator> +X class reverse_iterator : public + iterator<typename iterator_traits<Iterator>::iterator_category, + typename iterator_traits<Iterator>::value_type, + typename iterator_traits<Iterator>::difference_type, + typename iterator_traits<Iterator>::pointer, + typename iterator_traits<Iterator>::reference> { + protected: +T Iterator current; + public: +T typedef Iterator + iterator_type; +T typedef typename iterator_traits<Iterator>::difference_type + difference_type; +T typedef typename iterator_traits<Iterator>::reference + reference; +T typedef typename iterator_traits<Iterator>::pointer + pointer; + +T reverse_iterator(); +T explicit reverse_iterator(Iterator x); +T template <class U> reverse_iterator(const reverse_iterator<U>& u); +T Iterator base() const; // explicit +T reference operator*() const; +T pointer operator->() const; +T reverse_iterator& operator++(); +T reverse_iterator operator++(int); +T reverse_iterator& operator--(); +T reverse_iterator operator--(int); + +T reverse_iterator operator+ (difference_type n) const; +T reverse_iterator& operator+=(difference_type n); +T reverse_iterator operator- (difference_type n) const; +T reverse_iterator& operator-=(difference_type n); +T reference operator[](difference_type n) const; + }; +T template <class Iterator> + bool operator==( + const reverse_iterator<Iterator>& x, + const reverse_iterator<Iterator>& y); +T template <class Iterator> + bool operator<( + const reverse_iterator<Iterator>& x, + const reverse_iterator<Iterator>& y); +T template <class Iterator> + bool operator!=( + const reverse_iterator<Iterator>& x, + const reverse_iterator<Iterator>& y); +T template <class Iterator> + bool operator>( + const reverse_iterator<Iterator>& x, + const reverse_iterator<Iterator>& y); +T template <class Iterator> + bool operator>=( + const reverse_iterator<Iterator>& x, + const reverse_iterator<Iterator>& y); +T template <class Iterator> + bool operator<=( + const reverse_iterator<Iterator>& x, + const reverse_iterator<Iterator>& y); +T template <class Iterator> + typename reverse_iterator<Iterator>::difference_type operator-( + const reverse_iterator<Iterator>& x, + const reverse_iterator<Iterator>& y); +T template <class Iterator> + reverse_iterator<Iterator> operator+( + typename reverse_iterator<Iterator>::difference_type n, + const reverse_iterator<Iterator>& x); + + + 24.4.2.1 Template class [lib.back.insert.iterator] + back_insert_iterator + + template <class Container> +X class back_insert_iterator : + public iterator<output_iterator_tag,void,void,void,void> { + protected: +T Container* container; + public: +T typedef Container container_type; +T explicit back_insert_iterator(Container& x); +T back_insert_iterator<Container>& + operator=(typename Container::const_reference value); + +T back_insert_iterator<Container>& operator*(); +T back_insert_iterator<Container>& operator++(); +T back_insert_iterator<Container> operator++(int); + }; +T template <class Container> + back_insert_iterator<Container> back_inserter(Container& x); + + + + 24.4.2.3 Template class [lib.front.insert.iterator] + front_insert_iterator + + template <class Container> +X class front_insert_iterator : + public iterator<output_iterator_tag,void,void,void,void> { + protected: +T Container* container; + public: +T typedef Container container_type; +T explicit front_insert_iterator(Container& x); +T front_insert_iterator<Container>& + operator=(typename Container::const_reference value); +T front_insert_iterator<Container>& operator*(); +T front_insert_iterator<Container>& operator++(); +T front_insert_iterator<Container> operator++(int); + }; +T template <class Container> + front_insert_iterator<Container> front_inserter(Container& x); + + + 24.4.2.5 Template class insert_iterator [lib.insert.iterator] + + template <class Container> +X class insert_iterator : + public iterator<output_iterator_tag,void,void,void,void> { + protected: +T Container* container; +T typename Container::iterator iter; + public: +T typedef Container container_type; +T insert_iterator(Container& x, typename Container::iterator i); +T insert_iterator<Container>& + operator=(typename Container::const_reference value); +T insert_iterator<Container>& operator*(); +T insert_iterator<Container>& operator++(); +T insert_iterator<Container>& operator++(int); + }; +T template <class Container, class Iterator> + insert_iterator<Container> inserter(Container& x, Iterator i); + + 24.5.1 Template class istream_iterator [lib.istream.iterator] + + template <class T, class charT = char, class traits = char_traits<charT>, + class Distance = ptrdiff_t> +X class istream_iterator: + public iterator<input_iterator_tag, T, Distance, const T*, const T&> { + public: +T typedef charT char_type +T typedef traits traits_type; +T typedef basic_istream<charT,traits> istream_type; +T istream_iterator(); +T istream_iterator(istream_type& s); +T istream_iterator(const istream_iterator<T,charT,traits,Distance>& x); +T ~istream_iterator(); + +T const T& operator*() const; +T const T* operator->() const; +T istream_iterator<T,charT,traits,Distance>& operator++(); +T istream_iterator<T,charT,traits,Distance> operator++(int); + }; + +T template <class T, class charT, class traits, class Distance> + bool operator==(const istream_iterator<T,charT,traits,Distance>& x, + const istream_iterator<T,charT,traits,Distance>& y); +T template <class T, class charT, class traits, class Distance> + bool operator!=(const istream_iterator<T,charT,traits,Distance>& x, + const istream_iterator<T,charT,traits,Distance>& y); + + + 24.5.2 Template class ostream_iterator [lib.ostream.iterator] + + template <class T, class charT = char, class traits = char_traits<charT> > +X class ostream_iterator: + public iterator<output_iterator_tag, void, void, void, void> { + public: +T typedef charT char_type; +T typedef traits traits_type; +T typedef basic_ostream<charT,traits> ostream_type; +T ostream_iterator(ostream_type& s); +T ostream_iterator(ostream_type& s, const charT* delimiter); +T ostream_iterator(const ostream_iterator<T,charT,traits>& x); +T ~ostream_iterator(); +T ostream_iterator<T,charT,traits>& operator=(const T& value); + +T ostream_iterator<T,charT,traits>& operator*(); +T ostream_iterator<T,charT,traits>& operator++(); +T ostream_iterator<T,charT,traits>& operator++(int); + }; + + + 24.5.3 Template class [lib.istreambuf.iterator] + istreambuf_iterator + + template<class charT, class traits = char_traits<charT> > +X class istreambuf_iterator + : public iterator<input_iterator_tag, charT, + typename traits::off_type, charT*, charT&> { + public: +T typedef charT char_type; +T typedef traits traits_type; +T typedef typename traits::int_type int_type; +T typedef basic_streambuf<charT,traits> streambuf_type; +T typedef basic_istream<charT,traits> istream_type; +T class proxy; // exposition only +T istreambuf_iterator() throw(); +T istreambuf_iterator(istream_type& s) throw(); +T istreambuf_iterator(streambuf_type* s) throw(); +T istreambuf_iterator(const proxy& p) throw(); +T charT operator*() const; +T istreambuf_iterator<charT,traits>& operator++(); +T proxy operator++(int); +X bool equal(istreambuf_iterator& b); + }; + +T template <class charT, class traits> + bool operator==(const istreambuf_iterator<charT,traits>& a, + const istreambuf_iterator<charT,traits>& b); + +T template <class charT, class traits> + bool operator!=(const istreambuf_iterator<charT,traits>& a, + const istreambuf_iterator<charT,traits>& b); + + 24.5.3.1 Template class [lib.istreambuf.iterator::proxy] + istreambuf_iterator::proxy + + template <class charT, class traits = char_traits<charT> > +T class istreambuf_iterator<charT, traits>::proxy + { +T charT keep_; +T basic_streambuf<charT,traits>* sbuf_; +T proxy(charT c, + basic_streambuf<charT,traits>* sbuf); + : keep_(c), sbuf_(sbuf) {} + public: +T charT operator*() { return keep_; } + }; + + + + 24.5.4 Template class [lib.ostreambuf.iterator] + ostreambuf_iterator + + template <class charT, class traits = char_traits<charT> > +T class ostreambuf_iterator: + public iterator<output_iterator_tag, void, void, void, void> { + public: +T typedef charT char_type; +T typedef traits traits_type; +T typedef basic_streambuf<charT,traits> streambuf_type; +T typedef basic_ostream<charT,traits> ostream_type; + public: +T ostreambuf_iterator(ostream_type& s) throw(); +T ostreambuf_iterator(streambuf_type* s) throw(); +T ostreambuf_iterator& operator=(charT c); +T ostreambuf_iterator& operator*(); +T ostreambuf_iterator& operator++(); +T ostreambuf_iterator& operator++(int); +T bool failed() const throw(); + }; + + + Header <algorithm> synopsis + + + // _lib.alg.nonmodifying_, non-modifying sequence operations: +T template<class InputIterator, class Function> + Function for_each(InputIterator first, InputIterator last, Function f); +T template<class InputIterator, class T> + InputIterator find(InputIterator first, InputIterator last, + const T& value); +T template<class InputIterator, class Predicate> + InputIterator find_if(InputIterator first, InputIterator last, + Predicate pred); +T template<class ForwardIterator1, class ForwardIterator2> + ForwardIterator1 + find_end(ForwardIterator1 first1, ForwardIterator1 last1, + ForwardIterator2 first2, ForwardIterator2 last2); +T template<class ForwardIterator1, class ForwardIterator2, + class BinaryPredicate> + ForwardIterator1 + find_end(ForwardIterator1 first1, ForwardIterator1 last1, + ForwardIterator2 first2, ForwardIterator2 last2, + BinaryPredicate pred); +T template<class ForwardIterator1, class ForwardIterator2> + ForwardIterator1 + find_first_of(ForwardIterator1 first1, ForwardIterator1 last1, + ForwardIterator2 first2, ForwardIterator2 last2); +T template<class ForwardIterator1, class ForwardIterator2, + class BinaryPredicate> + ForwardIterator1 + find_first_of(ForwardIterator1 first1, ForwardIterator1 last1, + ForwardIterator2 first2, ForwardIterator2 last2, + BinaryPredicate pred); +T template<class ForwardIterator> + ForwardIterator adjacent_find(ForwardIterator first, + ForwardIterator last); +T template<class ForwardIterator, class BinaryPredicate> + ForwardIterator adjacent_find(ForwardIterator first, + ForwardIterator last, BinaryPredicate pred); +T template<class InputIterator, class T> + typename iterator_traits<InputIterator>::difference_type + count(InputIterator first, InputIterator last, const T& value); +T template<class InputIterator, class Predicate> + typename iterator_traits<InputIterator>::difference_type + count_if(InputIterator first, InputIterator last, Predicate pred); +T template<class InputIterator1, class InputIterator2> + pair<InputIterator1, InputIterator2> + mismatch(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2); +T template<class InputIterator1, class InputIterator2, class BinaryPredicate> + pair<InputIterator1, InputIterator2> + mismatch(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, BinaryPredicate pred); + +T template<class InputIterator1, class InputIterator2> + bool equal(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2); +T template<class InputIterator1, class InputIterator2, class BinaryPredicate> + bool equal(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, BinaryPredicate pred); +T template<class ForwardIterator1, class ForwardIterator2> + ForwardIterator1 search(ForwardIterator1 first1, ForwardIterator1 last1, + ForwardIterator2 first2, ForwardIterator2 last2); +T template<class ForwardIterator1, class ForwardIterator2, + class BinaryPredicate> + ForwardIterator1 search(ForwardIterator1 first1, ForwardIterator1 last1, + ForwardIterator2 first2, ForwardIterator2 last2, + BinaryPredicate pred); +T template<class ForwardIterator, class Size, class T> + ForwardIterator search_n(ForwardIterator first, ForwardIterator last, + Size count, const T& value); +T template<class ForwardIterator, class Size, class T, class BinaryPredicate> + ForwardIterator1 search_n(ForwardIterator first, ForwardIterator last, + Size count, const T& value, + BinaryPredicate pred); + // _lib.alg.modifying.operations_, modifying sequence operations: + // _lib.alg.copy_, copy: +T template<class InputIterator, class OutputIterator> + OutputIterator copy(InputIterator first, InputIterator last, + OutputIterator result); +T template<class BidirectionalIterator1, class BidirectionalIterator2> + BidirectionalIterator2 + copy_backward(BidirectionalIterator1 first, BidirectionalIterator1 last, + BidirectionalIterator2 result); + // _lib.alg.swap_, swap: +T template<class T> void swap(T& a, T& b); +T template<class ForwardIterator1, class ForwardIterator2> + ForwardIterator2 swap_ranges(ForwardIterator1 first1, + ForwardIterator1 last1, ForwardIterator2 first2); +T template<class ForwardIterator1, class ForwardIterator2> + void iter_swap(ForwardIterator1 a, ForwardIterator2 b); +T template<class InputIterator, class OutputIterator, class UnaryOperation> + OutputIterator transform(InputIterator first, InputIterator last, + OutputIterator result, UnaryOperation op); +T template<class InputIterator1, class InputIterator2, class OutputIterator, + class BinaryOperation> + OutputIterator transform(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, OutputIterator result, + BinaryOperation binary_op); + +T template<class ForwardIterator, class T> + void replace(ForwardIterator first, ForwardIterator last, + const T& old_value, const T& new_value); +T template<class ForwardIterator, class Predicate, class T> + void replace_if(ForwardIterator first, ForwardIterator last, + Predicate pred, const T& new_value); +T template<class InputIterator, class OutputIterator, class T> + OutputIterator replace_copy(InputIterator first, InputIterator last, + OutputIterator result, + const T& old_value, const T& new_value); +T template<class Iterator, class OutputIterator, class Predicate, class T> + OutputIterator replace_copy_if(Iterator first, Iterator last, + OutputIterator result, + Predicate pred, const T& new_value); +T template<class ForwardIterator, class T> + void fill(ForwardIterator first, ForwardIterator last, const T& value); +T template<class OutputIterator, class Size, class T> + void fill_n(OutputIterator first, Size n, const T& value); +T template<class ForwardIterator, class Generator> + void generate(ForwardIterator first, ForwardIterator last, Generator gen); +T template<class OutputIterator, class Size, class Generator> + void generate_n(OutputIterator first, Size n, Generator gen); +T template<class ForwardIterator, class T> + ForwardIterator remove(ForwardIterator first, ForwardIterator last, + const T& value); +T template<class ForwardIterator, class Predicate> + ForwardIterator remove_if(ForwardIterator first, ForwardIterator last, + Predicate pred); +T template<class InputIterator, class OutputIterator, class T> + OutputIterator remove_copy(InputIterator first, InputIterator last, + OutputIterator result, const T& value); +T template<class InputIterator, class OutputIterator, class Predicate> + OutputIterator remove_copy_if(InputIterator first, InputIterator last, + OutputIterator result, Predicate pred); +T template<class ForwardIterator> + ForwardIterator unique(ForwardIterator first, ForwardIterator last); +T template<class ForwardIterator, class BinaryPredicate> + ForwardIterator unique(ForwardIterator first, ForwardIterator last, + BinaryPredicate pred); +T template<class InputIterator, class OutputIterator> + OutputIterator unique_copy(InputIterator first, InputIterator last, + OutputIterator result); +T template<class InputIterator, class OutputIterator, class BinaryPredicate> + OutputIterator unique_copy(InputIterator first, InputIterator last, + OutputIterator result, BinaryPredicate pred); +T template<class BidirectionalIterator> + void reverse(BidirectionalIterator first, BidirectionalIterator last); +T template<class BidirectionalIterator, class OutputIterator> + OutputIterator reverse_copy(BidirectionalIterator first, + BidirectionalIterator last, + OutputIterator result); + +T template<class ForwardIterator> + void rotate(ForwardIterator first, ForwardIterator middle, + ForwardIterator last); +T template<class ForwardIterator, class OutputIterator> + OutputIterator rotate_copy(ForwardIterator first, ForwardIterator middle, + ForwardIterator last, OutputIterator result); +T template<class RandomAccessIterator> + void random_shuffle(RandomAccessIterator first, + RandomAccessIterator last); +T template<class RandomAccessIterator, class RandomNumberGenerator> + void random_shuffle(RandomAccessIterator first, + RandomAccessIterator last, + RandomNumberGenerator& rand); + // _lib.alg.partitions_, partitions: +T template<class BidirectionalIterator, class Predicate> + BidirectionalIterator partition(BidirectionalIterator first, + BidirectionalIterator last, + Predicate pred); +T template<class BidirectionalIterator, class Predicate> + BidirectionalIterator stable_partition(BidirectionalIterator first, + BidirectionalIterator last, + Predicate pred); + // _lib.alg.sorting_, sorting and related operations: + // _lib.alg.sort_, sorting: +T template<class RandomAccessIterator> + void sort(RandomAccessIterator first, RandomAccessIterator last); +T template<class RandomAccessIterator, class Compare> + void sort(RandomAccessIterator first, RandomAccessIterator last, + Compare comp); +T template<class RandomAccessIterator> + void stable_sort(RandomAccessIterator first, RandomAccessIterator last); +T template<class RandomAccessIterator, class Compare> + void stable_sort(RandomAccessIterator first, RandomAccessIterator last, + Compare comp); +T template<class RandomAccessIterator> + void partial_sort(RandomAccessIterator first, + RandomAccessIterator middle, + RandomAccessIterator last); +T template<class RandomAccessIterator, class Compare> + void partial_sort(RandomAccessIterator first, + RandomAccessIterator middle, + RandomAccessIterator last, Compare comp); +T template<class InputIterator, class RandomAccessIterator> + RandomAccessIterator + partial_sort_copy(InputIterator first, InputIterator last, + RandomAccessIterator result_first, + RandomAccessIterator result_last); +T template<class InputIterator, class RandomAccessIterator, class Compare> + RandomAccessIterator + partial_sort_copy(InputIterator first, InputIterator last, + RandomAccessIterator result_first, + RandomAccessIterator result_last, + Compare comp); + +T template<class RandomAccessIterator> + void nth_element(RandomAccessIterator first, RandomAccessIterator nth, + RandomAccessIterator last); +T template<class RandomAccessIterator, class Compare> + void nth_element(RandomAccessIterator first, RandomAccessIterator nth, + RandomAccessIterator last, Compare comp); + // _lib.alg.binary.search_, binary search: +T template<class ForwardIterator, class T> + ForwardIterator lower_bound(ForwardIterator first, ForwardIterator last, + const T& value); +T template<class ForwardIterator, class T, class Compare> + ForwardIterator lower_bound(ForwardIterator first, ForwardIterator last, + const T& value, Compare comp); +T template<class ForwardIterator, class T> + ForwardIterator upper_bound(ForwardIterator first, ForwardIterator last, + const T& value); +T template<class ForwardIterator, class T, class Compare> + ForwardIterator upper_bound(ForwardIterator first, ForwardIterator last, + const T& value, Compare comp); +T template<class ForwardIterator, class T> + pair<ForwardIterator, ForwardIterator> + equal_range(ForwardIterator first, ForwardIterator last, + const T& value); +T template<class ForwardIterator, class T, class Compare> + pair<ForwardIterator, ForwardIterator> + equal_range(ForwardIterator first, ForwardIterator last, + const T& value, Compare comp); +T template<class ForwardIterator, class T> + bool binary_search(ForwardIterator first, ForwardIterator last, + const T& value); +T template<class ForwardIterator, class T, class Compare> + bool binary_search(ForwardIterator first, ForwardIterator last, + const T& value, Compare comp); + // _lib.alg.merge_, merge: +T template<class InputIterator1, class InputIterator2, class OutputIterator> + OutputIterator merge(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2, + OutputIterator result); +T template<class InputIterator1, class InputIterator2, class OutputIterator, + class Compare> + OutputIterator merge(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2, + OutputIterator result, Compare comp); +T template<class BidirectionalIterator> + void inplace_merge(BidirectionalIterator first, + BidirectionalIterator middle, + BidirectionalIterator last); +T template<class BidirectionalIterator, class Compare> + void inplace_merge(BidirectionalIterator first, + BidirectionalIterator middle, + BidirectionalIterator last, Compare comp); + + // _lib.alg.set.operations_, set operations: +T template<class InputIterator1, class InputIterator2> + bool includes(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2); +T template<class InputIterator1, class InputIterator2, class Compare> + bool includes(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2, Compare comp); +T template<class InputIterator1, class InputIterator2, class OutputIterator> + OutputIterator set_union(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2, + OutputIterator result); +T template<class InputIterator1, class InputIterator2, class OutputIterator, + class Compare> + OutputIterator set_union(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2, + OutputIterator result, Compare comp); +T template<class InputIterator1, class InputIterator2, class OutputIterator> + OutputIterator set_intersection + (InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2, + OutputIterator result); +T template<class InputIterator1, class InputIterator2, class OutputIterator, + class Compare> + OutputIterator set_intersection + (InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2, + OutputIterator result, Compare comp); +T template<class InputIterator1, class InputIterator2, class OutputIterator> + OutputIterator set_difference + (InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2, + OutputIterator result); +T template<class InputIterator1, class InputIterator2, class OutputIterator, + class Compare> + OutputIterator set_difference(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2, + OutputIterator result, Compare comp); +T template<class InputIterator1, class InputIterator2, class OutputIterator> + OutputIterator + set_symmetric_difference(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2, + OutputIterator result); +T template<class InputIterator1, class InputIterator2, class OutputIterator, + class Compare> + OutputIterator + set_symmetric_difference(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2, + OutputIterator result, Compare comp); + // _lib.alg.heap.operations_, heap operations: +T template<class RandomAccessIterator> + void push_heap(RandomAccessIterator first, RandomAccessIterator last); +T template<class RandomAccessIterator, class Compare> + void push_heap(RandomAccessIterator first, RandomAccessIterator last, + Compare comp); + +T template<class RandomAccessIterator> + void pop_heap(RandomAccessIterator first, RandomAccessIterator last); +T template<class RandomAccessIterator, class Compare> + void pop_heap(RandomAccessIterator first, RandomAccessIterator last, + Compare comp); +T template<class RandomAccessIterator> + void make_heap(RandomAccessIterator first, RandomAccessIterator last); +T template<class RandomAccessIterator, class Compare> + void make_heap(RandomAccessIterator first, RandomAccessIterator last, + Compare comp); +T template<class RandomAccessIterator> + void sort_heap(RandomAccessIterator first, RandomAccessIterator last); +T template<class RandomAccessIterator, class Compare> + void sort_heap(RandomAccessIterator first, RandomAccessIterator last, + Compare comp); + // _lib.alg.min.max_, minimum and maximum: +T template<class T> const T& min(const T& a, const T& b); +T template<class T, class Compare> + const T& min(const T& a, const T& b, Compare comp); +T template<class T> const T& max(const T& a, const T& b); +T template<class T, class Compare> + const T& max(const T& a, const T& b, Compare comp); +T template<class ForwardIterator> + ForwardIterator min_element(ForwardIterator first, ForwardIterator last); +T template<class ForwardIterator, class Compare> + ForwardIterator min_element(ForwardIterator first, ForwardIterator last, + Compare comp); +T template<class ForwardIterator> + ForwardIterator max_element(ForwardIterator first, ForwardIterator last); +T template<class ForwardIterator, class Compare> + ForwardIterator max_element(ForwardIterator first, ForwardIterator last, + Compare comp); +T template<class InputIterator1, class InputIterator2> + bool lexicographical_compare + (InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2); +T template<class InputIterator1, class InputIterator2, class Compare> + bool lexicographical_compare + (InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2, + Compare comp); + + // _lib.alg.permutation.generators_, permutations +T template<class BidirectionalIterator> + bool next_permutation(BidirectionalIterator first, + BidirectionalIterator last); +T template<class BidirectionalIterator, class Compare> + bool next_permutation(BidirectionalIterator first, + BidirectionalIterator last, Compare comp); +T template<class BidirectionalIterator> + bool prev_permutation(BidirectionalIterator first, + BidirectionalIterator last); +T template<class BidirectionalIterator, class Compare> + bool prev_permutation(BidirectionalIterator first, + BidirectionalIterator last, Compare comp); + + + 25.4 C library algorithms [lib.alg.c.library] + + 1 Header <cstdlib> (partial, Table 2): + + Table 2--Header <cstdlib> synopsis + + Functions: bsearch qsort + + +X extern "C" void *bsearch(const void *key, const void *base, + size_t nmemb, size_t size, + int (*compar)(const void *, const void *)); +X extern "C++" void *bsearch(const void *key, const void *base, + size_t nmemb, size_t size, + int (*compar)(const void *, const void *)); + +X extern "C" void qsort(void* base, size_t nmemb, size_t size, + int (*compar)(const void*, const void*)); +X extern "C++" void qsort(void* base, size_t nmemb, size_t size, + int (*compar)(const void*, const void*)); + + + + 26.2 Complex numbers [lib.complex.numbers] + + + 26.2.1 Header <complex> synopsis [lib.complex.synopsis] + +T template<class T> class complex; +T template<> class complex<float>; +T template<> class complex<double>; +T template<> class complex<long double>; + // _lib.complex.ops_ operators: +T template<class T> + complex<T> operator+(const complex<T>&, const complex<T>&); +T template<class T> complex<T> operator+(const complex<T>&, const T&); +T template<class T> complex<T> operator+(const T&, const complex<T>&); +T template<class T> complex<T> operator- + (const complex<T>&, const complex<T>&); +T template<class T> complex<T> operator-(const complex<T>&, const T&); +T template<class T> complex<T> operator-(const T&, const complex<T>&); +T template<class T> complex<T> operator* + (const complex<T>&, const complex<T>&); +T template<class T> complex<T> operator*(const complex<T>&, const T&); +T template<class T> complex<T> operator*(const T&, const complex<T>&); +T template<class T> complex<T> operator/ + (const complex<T>&, const complex<T>&); +T template<class T> complex<T> operator/(const complex<T>&, const T&); +T template<class T> complex<T> operator/(const T&, const complex<T>&); +T template<class T> complex<T> operator+(const complex<T>&); +T template<class T> complex<T> operator-(const complex<T>&); +T template<class T> bool operator== + (const complex<T>&, const complex<T>&); +T template<class T> bool operator==(const complex<T>&, const T&); +T template<class T> bool operator==(const T&, const complex<T>&); +T template<class T> bool operator!=(const complex<T>&, const complex<T>&); +T template<class T> bool operator!=(const complex<T>&, const T&); +T template<class T> bool operator!=(const T&, const complex<T>&); +T template<class T, class charT, class traits> + basic_istream<charT, traits>& + operator>>(basic_istream<charT, traits>&, complex<T>&); + +T template<class T, class charT, class traits> + basic_ostream<charT, traits>& + operator<<(basic_ostream<charT, traits>&, const complex<T>&); + // _lib.complex.value.ops_ values: +T template<class T> T real(const complex<T>&); +T template<class T> T imag(const complex<T>&); + +T template<class T> T abs(const complex<T>&); +T template<class T> T arg(const complex<T>&); +T template<class T> T norm(const complex<T>&); +T template<class T> complex<T> conj(const complex<T>&); +T template<class T> complex<T> polar(const T&, const T&); + // _lib.complex.transcendentals_ transcendentals: +T template<class T> complex<T> cos (const complex<T>&); +T template<class T> complex<T> cosh (const complex<T>&); +T template<class T> complex<T> exp (const complex<T>&); +T template<class T> complex<T> log (const complex<T>&); +T template<class T> complex<T> log10(const complex<T>&); +T template<class T> complex<T> pow(const complex<T>&, int); +T template<class T> complex<T> pow(const complex<T>&, const T&); +T template<class T> complex<T> pow(const complex<T>&, const complex<T>&); +T template<class T> complex<T> pow(const T&, const complex<T>&); +T template<class T> complex<T> sin (const complex<T>&); +T template<class T> complex<T> sinh (const complex<T>&); +T template<class T> complex<T> sqrt (const complex<T>&); +T template<class T> complex<T> tan (const complex<T>&); +T template<class T> complex<T> tanh (const complex<T>&); + } + + 26.2.2 Template class complex [lib.complex] + + template<class T> +T class complex { + public: +T typedef T value_type; + +T complex(const T& re = T(), const T& im = T()); +T complex(const complex&); +T template<class X> complex(const complex<X>&); + +T T real() const; +T T imag() const; + +T complex<T>& operator= (const T&); +T complex<T>& operator+=(const T&); +T complex<T>& operator-=(const T&); +T complex<T>& operator*=(const T&); +T complex<T>& operator/=(const T&); + +T complex& operator=(const complex&); +T template<class X> complex<T>& operator= (const complex<X>&); +T template<class X> complex<T>& operator+=(const complex<X>&); +T template<class X> complex<T>& operator-=(const complex<X>&); +T template<class X> complex<T>& operator*=(const complex<X>&); +T template<class X> complex<T>& operator/=(const complex<X>&); + }; + +T template<class T> complex<T> operator+ + (const complex<T>&, const complex<T>&); +T template<class T> complex<T> operator+(const complex<T>&, const T&); +T template<class T> complex<T> operator+(const T&, const complex<T>&); + +T template<class T> complex<T> operator- + (const complex<T>&, const complex<T>&); +T template<class T> complex<T> operator-(const complex<T>&, const T&); +T template<class T> complex<T> operator-(const T&, const complex<T>&); + +T template<class T> complex<T> operator* + (const complex<T>&, const complex<T>&); +T template<class T> complex<T> operator*(const complex<T>&, const T&); +T template<class T> complex<T> operator*(const T&, const complex<T>&); + +T template<class T> complex<T> operator/ + (const complex<T>&, const complex<T>&); +T template<class T> complex<T> operator/(const complex<T>&, const T&); +T template<class T> complex<T> operator/(const T&, const complex<T>&); + +T template<class T> complex<T> operator+(const complex<T>&); +T template<class T> complex<T> operator-(const complex<T>&); + +T template<class T> bool operator==(const complex<T>&, const complex<T>&); +T template<class T> bool operator==(const complex<T>&, const T&); +T template<class T> bool operator==(const T&, const complex<T>&); + +T template<class T> bool operator!=(const complex<T>&, const complex<T>&); +T template<class T> bool operator!=(const complex<T>&, const T&); +T template<class T> bool operator!=(const T&, const complex<T>&); + +T template<class T, class charT, class traits> + basic_istream<charT, traits>& + operator>>(basic_istream<charT, traits>&, complex<T>&); + +T template<class T, class charT, class traits> + basic_ostream<charT, traits>& + operator<<(basic_ostream<charT, traits>&, const complex<T>&); + + + 26.2.3 complex specializations [lib.complex.special] + +T template<> class complex<float> { + public: +T typedef float value_type; + +T complex(float re = 0.0f, float im = 0.0f); +T explicit complex(const complex<double>&); +T explicit complex(const complex<long double>&); +T float real() const; +T float imag() const; + +T complex<float>& operator= (float); +T complex<float>& operator+=(float); +T complex<float>& operator-=(float); +T complex<float>& operator*=(float); +T complex<float>& operator/=(float); + +T complex<float>& operator=(const complex<float>&); +T template<class X> complex<float>& operator= (const complex<X>&); +T template<class X> complex<float>& operator+=(const complex<X>&); +T template<class X> complex<float>& operator-=(const complex<X>&); +T template<class X> complex<float>& operator*=(const complex<X>&); +T template<class X> complex<float>& operator/=(const complex<X>&); + }; +T template<> class complex<double> { + public: +T typedef double value_type; + +T complex(double re = 0.0, double im = 0.0); +T complex(const complex<float>&); +T explicit complex(const complex<long double>&); +T double real() const; +T double imag() const; + +T complex<double>& operator= (double); +T complex<double>& operator+=(double); +T complex<double>& operator-=(double); +T complex<double>& operator*=(double); +T complex<double>& operator/=(double); + +T complex<double>& operator=(const complex<double>&); +T template<class X> complex<double>& operator= (const complex<X>&); +T template<class X> complex<double>& operator+=(const complex<X>&); +T template<class X> complex<double>& operator-=(const complex<X>&); +T template<class X> complex<double>& operator*=(const complex<X>&); +T template<class X> complex<double>& operator/=(const complex<X>&); + }; + +T template<> class complex<long double> { + public: +T typedef long double value_type; + +T complex(long double re = 0.0L, long double im = 0.0L); +T complex(const complex<float>&); +T complex(const complex<double>&); +T long double real() const; +T long double imag() const; + +T complex<long double>& operator=(const complex<long double>&); +T complex<long double>& operator= (long double); +T complex<long double>& operator+=(long double); +T complex<long double>& operator-=(long double); +T complex<long double>& operator*=(long double); +T complex<long double>& operator/=(long double); + +T template<class X> complex<long double>& operator= (const complex<X>&); +T template<class X> complex<long double>& operator+=(const complex<X>&); +T template<class X> complex<long double>& operator-=(const complex<X>&); +T template<class X> complex<long double>& operator*=(const complex<X>&); +T template<class X> complex<long double>& operator/=(const complex<X>&); + }; + + 26.3 Numeric arrays [lib.numarray] + + 26.3.1 Header <valarray> synopsis [lib.valarray.synopsis] + +T template<class T> class valarray; // An array of type T +T class slice; +T template<class T> class slice_array; +T class gslice; +T template<class T> class gslice_array; +T template<class T> class mask_array; // a masked array +T template<class T> class indirect_array; // an indirected array + +T template<class T> valarray<T> operator* + (const valarray<T>&, const valarray<T>&); +T template<class T> valarray<T> operator* (const valarray<T>&, const T&); +T template<class T> valarray<T> operator* (const T&, const valarray<T>&); +T template<class T> valarray<T> operator/ + (const valarray<T>&, const valarray<T>&); +T template<class T> valarray<T> operator/ (const valarray<T>&, const T&); +T template<class T> valarray<T> operator/ (const T&, const valarray<T>&); +T template<class T> valarray<T> operator% + (const valarray<T>&, const valarray<T>&); +T template<class T> valarray<T> operator% (const valarray<T>&, const T&); +T template<class T> valarray<T> operator% (const T&, const valarray<T>&); +T template<class T> valarray<T> operator+ + (const valarray<T>&, const valarray<T>&); +T template<class T> valarray<T> operator+ (const valarray<T>&, const T&); +T template<class T> valarray<T> operator+ (const T&, const valarray<T>&); +T template<class T> valarray<T> operator- + (const valarray<T>&, const valarray<T>&); +T template<class T> valarray<T> operator- (const valarray<T>&, const T&); +T template<class T> valarray<T> operator- (const T&, const valarray<T>&); +T template<class T> valarray<T> operator^ + (const valarray<T>&, const valarray<T>&); +T template<class T> valarray<T> operator^ (const valarray<T>&, const T&); +T template<class T> valarray<T> operator^ (const T&, const valarray<T>&); +T template<class T> valarray<T> operator& + (const valarray<T>&, const valarray<T>&); +T template<class T> valarray<T> operator& (const valarray<T>&, const T&); +T template<class T> valarray<T> operator& (const T&, const valarray<T>&); +T template<class T> valarray<T> operator| + (const valarray<T>&, const valarray<T>&); +T template<class T> valarray<T> operator| (const valarray<T>&, const T&); +T template<class T> valarray<T> operator| (const T&, const valarray<T>&); +T template<class T> valarray<T> operator<< + (const valarray<T>&, const valarray<T>&); +T template<class T> valarray<T> operator<<(const valarray<T>&, const T&); +T template<class T> valarray<T> operator<<(const T&, const valarray<T>&); +T template<class T> valarray<T> operator>> + (const valarray<T>&, const valarray<T>&); +T template<class T> valarray<T> operator>>(const valarray<T>&, const T&); +T template<class T> valarray<T> operator>>(const T&, const valarray<T>&); +T template<class T> valarray<bool> operator&& + (const valarray<T>&, const valarray<T>&); +T template<class T> valarray<bool> operator&&(const valarray<T>&, const T&); +T template<class T> valarray<bool> operator&&(const T&, const valarray<T>&); +T template<class T> valarray<bool> operator|| + (const valarray<T>&, const valarray<T>&); +T template<class T> valarray<bool> operator||(const valarray<T>&, const T&); +T template<class T> valarray<bool> operator||(const T&, const valarray<T>&); + +T template<class T> + valarray<bool> operator==(const valarray<T>&, const valarray<T>&); +T template<class T> valarray<bool> operator==(const valarray<T>&, const T&); +T template<class T> valarray<bool> operator==(const T&, const valarray<T>&); +T template<class T> + valarray<bool> operator!=(const valarray<T>&, const valarray<T>&); +T template<class T> valarray<bool> operator!=(const valarray<T>&, const T&); +T template<class T> valarray<bool> operator!=(const T&, const valarray<T>&); +T template<class T> + valarray<bool> operator< (const valarray<T>&, const valarray<T>&); +T template<class T> valarray<bool> operator< (const valarray<T>&, const T&); +T template<class T> valarray<bool> operator< (const T&, const valarray<T>&); +T template<class T> + valarray<bool> operator> (const valarray<T>&, const valarray<T>&); +T template<class T> valarray<bool> operator> (const valarray<T>&, const T&); +T template<class T> valarray<bool> operator> (const T&, const valarray<T>&); +T template<class T> + valarray<bool> operator<=(const valarray<T>&, const valarray<T>&); +T template<class T> valarray<bool> operator<=(const valarray<T>&, const T&); +T template<class T> valarray<bool> operator<=(const T&, const valarray<T>&); +T template<class T> + valarray<bool> operator>=(const valarray<T>&, const valarray<T>&); +T template<class T> valarray<bool> operator>=(const valarray<T>&, const T&); +T template<class T> valarray<bool> operator>=(const T&, const valarray<T>&); +T template<class T> valarray<T> abs (const valarray<T>&); +T template<class T> valarray<T> acos (const valarray<T>&); +T template<class T> valarray<T> asin (const valarray<T>&); +T template<class T> valarray<T> atan (const valarray<T>&); +T template<class T> valarray<T> atan2 + (const valarray<T>&, const valarray<T>&); +T template<class T> valarray<T> atan2(const valarray<T>&, const T&); +T template<class T> valarray<T> atan2(const T&, const valarray<T>&); +T template<class T> valarray<T> cos (const valarray<T>&); +T template<class T> valarray<T> cosh (const valarray<T>&); +T template<class T> valarray<T> exp (const valarray<T>&); +T template<class T> valarray<T> log (const valarray<T>&); +T template<class T> valarray<T> log10(const valarray<T>&); +T template<class T> valarray<T> pow(const valarray<T>&, const valarray<T>&); +T template<class T> valarray<T> pow(const valarray<T>&, const T&); +T template<class T> valarray<T> pow(const T&, const valarray<T>&); +T template<class T> valarray<T> sin (const valarray<T>&); +T template<class T> valarray<T> sinh (const valarray<T>&); +T template<class T> valarray<T> sqrt (const valarray<T>&); +T template<class T> valarray<T> tan (const valarray<T>&); +T template<class T> valarray<T> tanh (const valarray<T>&); + } + + + 26.3.2 Template class valarray [lib.template.valarray] + +T template<class T> class valarray { + public: +T typedef T value_type; + + // _lib.valarray.cons_ construct/destroy: +T valarray(); +T explicit valarray(size_t); +T valarray(const T&, size_t); +T valarray(const T*, size_t); +T valarray(const valarray&); +T valarray(const slice_array<T>&); +T valarray(const gslice_array<T>&); +T valarray(const mask_array<T>&); +T valarray(const indirect_array<T>&); +T ~valarray(); + + // _lib.valarray.assign_ assignment: +T valarray<T>& operator=(const valarray<T>&); +T valarray<T>& operator=(const T&); +T valarray<T>& operator=(const slice_array<T>&); +T valarray<T>& operator=(const gslice_array<T>&); +T valarray<T>& operator=(const mask_array<T>&); +T valarray<T>& operator=(const indirect_array<T>&); + // _lib.valarray.access_ element access: +T T operator[](size_t) const; +T T& operator[](size_t); + // _lib.valarray.sub_ subset operations: +T valarray<T> operator[](slice) const; +T slice_array<T> operator[](slice); +T valarray<T> operator[](const gslice&) const; +T gslice_array<T> operator[](const gslice&); +T valarray<T> operator[](const valarray<bool>&) const; +T mask_array<T> operator[](const valarray<bool>&); +T valarray<T> operator[](const valarray<size_t>&) const; +T indirect_array<T> operator[](const valarray<size_t>&); + // _lib.valarray.unary_ unary operators: +T valarray<T> operator+() const; +T valarray<T> operator-() const; +T valarray<T> operator~() const; +T valarray<T> operator!() const; + // _lib.valarray.cassign_ computed assignment: +T valarray<T>& operator*= (const T&); +T valarray<T>& operator/= (const T&); +T valarray<T>& operator%= (const T&); +T valarray<T>& operator+= (const T&); +T valarray<T>& operator-= (const T&); +T valarray<T>& operator^= (const T&); +T valarray<T>& operator&= (const T&); +T valarray<T>& operator|= (const T&); +T valarray<T>& operator<<=(const T&); +T valarray<T>& operator>>=(const T&); +T valarray<T>& operator*= (const valarray<T>&); +T valarray<T>& operator/= (const valarray<T>&); +T valarray<T>& operator%= (const valarray<T>&); +T valarray<T>& operator+= (const valarray<T>&); +T valarray<T>& operator-= (const valarray<T>&); +T valarray<T>& operator^= (const valarray<T>&); +T valarray<T>& operator|= (const valarray<T>&); +T valarray<T>& operator&= (const valarray<T>&); +T valarray<T>& operator<<=(const valarray<T>&); +T valarray<T>& operator>>=(const valarray<T>&); + // _lib.valarray.members_ member functions: +T size_t size() const; +T T sum() const; +T T min() const; +T T max() const; + +T valarray<T> shift (int) const; +T valarray<T> cshift(int) const; +T valarray<T> apply(T func(T)) const; +T valarray<T> apply(T func(const T&)) const; +T void resize(size_t sz, T c = T()); + }; + } + + + + 26.3.4 Class slice [lib.class.slice] + +T class slice { + public: +T slice(); +T slice(size_t, size_t, size_t); + +T size_t start() const; +T size_t size() const; +T size_t stride() const; + }; + } + + + + 26.3.5 Template class slice_array [lib.template.slice.array] + +T template <class T> class slice_array { + public: +T typedef T value_type; + +T void operator= (const valarray<T>&) const; +T void operator*= (const valarray<T>&) const; +T void operator/= (const valarray<T>&) const; +T void operator%= (const valarray<T>&) const; +T void operator+= (const valarray<T>&) const; +T void operator-= (const valarray<T>&) const; +T void operator^= (const valarray<T>&) const; +T void operator&= (const valarray<T>&) const; +T void operator|= (const valarray<T>&) const; +T void operator<<=(const valarray<T>&) const; +T void operator>>=(const valarray<T>&) const; +T void operator=(const T&); +T ~slice_array(); + private: +T slice_array(); +T slice_array(const slice_array&); +T slice_array& operator=(const slice_array&); + }; + } + + + + 26.3.6 The gslice class [lib.class.gslice] + +T class gslice { + public: +T gslice(); +T gslice(size_t s, const valarray<size_t>& l, const valarray<size_t>& d); + +T size_t start() const; +T valarray<size_t> size() const; +T valarray<size_t> stride() const; + }; + + + 26.3.7 Template class gslice_array [lib.template.gslice.array] + +T template <class T> class gslice_array { + public: +T typedef T value_type; + +T void operator= (const valarray<T>&) const; +T void operator*= (const valarray<T>&) const; +T void operator/= (const valarray<T>&) const; +T void operator%= (const valarray<T>&) const; +T void operator+= (const valarray<T>&) const; +T void operator-= (const valarray<T>&) const; +T void operator^= (const valarray<T>&) const; +T void operator&= (const valarray<T>&) const; +T void operator|= (const valarray<T>&) const; +T void operator<<=(const valarray<T>&) const; +T void operator>>=(const valarray<T>&) const; +T void operator=(const T&); +T ~gslice_array(); + private: +T gslice_array(); +T gslice_array(const gslice_array&); +T gslice_array& operator=(const gslice_array&); + }; + + + 26.3.8 Template class mask_array [lib.template.mask.array] + +T template <class T> class mask_array { + public: +T typedef T value_type; + +T void operator= (const valarray<T>&) const; +T void operator*= (const valarray<T>&) const; +T void operator/= (const valarray<T>&) const; +T void operator%= (const valarray<T>&) const; +T void operator+= (const valarray<T>&) const; +T void operator-= (const valarray<T>&) const; +T void operator^= (const valarray<T>&) const; +T void operator&= (const valarray<T>&) const; +T void operator|= (const valarray<T>&) const; +T void operator<<=(const valarray<T>&) const; +T void operator>>=(const valarray<T>&) const; +T void operator=(const T&); +T ~mask_array(); + private: +T mask_array(); +T mask_array(const mask_array&); +T mask_array& operator=(const mask_array&); + // remainder implementation defined + }; + + + 26.3.9 Template class [lib.template.indirect.array] + indirect_array + +T template <class T> class indirect_array { + public: +T typedef T value_type; + +T void operator= (const valarray<T>&) const; +T void operator*= (const valarray<T>&) const; +T void operator/= (const valarray<T>&) const; +T void operator%= (const valarray<T>&) const; +T void operator+= (const valarray<T>&) const; +T void operator-= (const valarray<T>&) const; +T void operator^= (const valarray<T>&) const; +T void operator&= (const valarray<T>&) const; +T void operator|= (const valarray<T>&) const; +T void operator<<=(const valarray<T>&) const; +T void operator>>=(const valarray<T>&) const; +T void operator=(const T&); +T ~indirect_array(); + private: +T indirect_array(); +T indirect_array(const indirect_array&); +T indirect_array& operator=(const indirect_array&); + // remainder implementation defined + }; + + 26.4 Generalized numeric operations [lib.numeric.ops] + + Header <numeric> synopsis + +T template <class InputIterator, class T> + T accumulate(InputIterator first, InputIterator last, T init); + +T template <class InputIterator, class T, class BinaryOperation> + T accumulate(InputIterator first, InputIterator last, T init, + BinaryOperation binary_op); + +T template <class InputIterator1, class InputIterator2, class T> + T inner_product(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, T init); + +T template <class InputIterator1, class InputIterator2, class T, + class BinaryOperation1, class BinaryOperation2> + T inner_product(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, T init, + BinaryOperation1 binary_op1, + BinaryOperation2 binary_op2); + +T template <class InputIterator, class OutputIterator> + OutputIterator partial_sum(InputIterator first, + InputIterator last, + OutputIterator result); + +T template <class InputIterator, class OutputIterator, + class BinaryOperation> + OutputIterator partial_sum(InputIterator first, + InputIterator last, + OutputIterator result, + BinaryOperation binary_op); + +T template <class InputIterator, class OutputIterator> + OutputIterator adjacent_difference(InputIterator first, + InputIterator last, + OutputIterator result); + +T template <class InputIterator, class OutputIterator, + class BinaryOperation> + OutputIterator adjacent_difference(InputIterator first, + InputIterator last, + OutputIterator result, + BinaryOperation binary_op); + + + 26.5 C Library [lib.c.math] + + Table 2--Header <cmath> synopsis +X Macro: HUGE_VAL + Functions: +X acos cos fmod modf tan +X asin cosh frexp pow tanh +X atan exp ldexp sin +X atan2 fabs log sinh +X ceil floor log10 sqrt + + Table 3--Header <cstdlib> synopsis +X Macros: RAND_MAX +X Types: div_t ldiv_t + Functions: +X abs labs srand +X div ldiv rand + +X long abs(long); // labs() +X ldiv_t div(long, long); // ldiv() + +X float abs (float); +X float acos (float); +X float asin (float); +X float atan (float); +X float atan2(float, float); +X float ceil (float); +X float cos (float); +X float cosh (float); +X float exp (float); +X float fabs (float); +X float floor(float); +X float fmod (float, float); +X float frexp(float, int*); +X float ldexp(float, int); +X float log (float); +X float log10(float); +X float modf (float, float*); +X float pow (float, float); +X float pow (float, int); +X float sin (float); +X float sinh (float); +X float sqrt (float); +X float tan (float); +X float tanh (float); + +X double abs(double); // fabs() +X double pow(double, int); + +X long double abs (long double); +X long double acos (long double); +X long double asin (long double); +X long double atan (long double); +X long double atan2(long double, long double); +X long double ceil (long double); +X long double cos (long double); +X long double cosh (long double); +X long double exp (long double); +X long double fabs (long double); +X long double floor(long double); +X long double fmod (long double, long double); +X long double frexp(long double, int*); +X long double ldexp(long double, int); +X long double log (long double); +X long double log10(long double); +X long double modf (long double, long double*); +X long double pow (long double, long double); +X long double pow (long double, int); +X long double sin (long double); +X long double sinh (long double); +X long double sqrt (long double); +X long double tan (long double); +X long double tanh (long double); + + Header <iosfwd> synopsis + +X template<class charT> class char_traits; +X template<> class char_traits<char>; +X template<> class char_traits<wchar_t>; +X template<class T> class allocator; +X template <class charT, class traits = char_traits<charT> > + class basic_ios; + +X template <class charT, class traits = char_traits<charT> > + class basic_streambuf; + +X template <class charT, class traits = char_traits<charT> > + class basic_istream; + +X template <class charT, class traits = char_traits<charT> > + class basic_ostream; + +X template <class charT, class traits = char_traits<charT> > + class basic_iostream; + +X template <class charT, class traits = char_traits<charT>, + class Allocator = allocator<charT> > + class basic_stringbuf; + +X template <class charT, class traits = char_traits<charT>, + class Allocator = allocator<charT> > + class basic_istringstream; + +X template <class charT, class traits = char_traits<charT>, + class Allocator = allocator<charT> > + class basic_ostringstream; + +X template <class charT, class traits = char_traits<charT>, + class Allocator = allocator<charT> > + class basic_stringstream; + +X template <class charT, class traits = char_traits<charT> > + class basic_filebuf; + +X template <class charT, class traits = char_traits<charT> > + class basic_ifstream; + +X template <class charT, class traits = char_traits<charT> > + class basic_ofstream; + +X template <class charT, class traits = char_traits<charT> > + class basic_fstream; +X template <class charT, class traits = char_traits<charT> > + class istreambuf_iterator; + +X template <class charT, class traits = char_traits<charT> > + class ostreambuf_iterator; +X typedef basic_ios<char> ios; +X typedef basic_ios<wchar_t> wios; +X typedef basic_streambuf<char> streambuf; +X typedef basic_istream<char> istream; +X typedef basic_ostream<char> ostream; +X typedef basic_iostream<char> iostream; +X typedef basic_stringbuf<char> stringbuf; +X typedef basic_istringstream<char> istringstream; +X typedef basic_ostringstream<char> ostringstream; +X typedef basic_stringstream<char> stringstream; +X typedef basic_filebuf<char> filebuf; +X typedef basic_ifstream<char> ifstream; +X typedef basic_ofstream<char> ofstream; +X typedef basic_fstream<char> fstream; +X typedef basic_streambuf<wchar_t> wstreambuf; +X typedef basic_istream<wchar_t> wistream; +X typedef basic_ostream<wchar_t> wostream; +X typedef basic_iostream<wchar_t> wiostream; +X typedef basic_stringbuf<wchar_t> wstringbuf; +X typedef basic_istringstream<wchar_t> wistringstream; +X typedef basic_ostringstream<wchar_t> wostringstream; +X typedef basic_stringstream<wchar_t> wstringstream; + +X typedef basic_filebuf<wchar_t> wfilebuf; +X typedef basic_ifstream<wchar_t> wifstream; +X typedef basic_ofstream<wchar_t> wofstream; +X typedef basic_fstream<wchar_t> wfstream; +X template <class state> class fpos; +X typedef fpos<char_traits<char>::state_type> streampos; +X typedef fpos<char_traits<wchar_t>::state_type> wstreampos; + + 27.3 Standard iostream objects [lib.iostream.objects] + + Header <iostream> synopsis + +T [must also include <istream> and <ostream>] +T extern istream cin; +T extern ostream cout; +T extern ostream cerr; +T extern ostream clog; + +T extern wistream wcin; +T extern wostream wcout; +T extern wostream wcerr; +T extern wostream wclog; + + 27.4 Iostreams base classes [lib.iostreams.base] + + Header <ios> synopsis + + #include <iosfwd> + +T typedef OFF_T streamoff; +T typedef SZ_T streamsize; +T template <class stateT> class fpos; + + class ios_base; + template <class charT, class traits = char_traits<charT> > + class basic_ios; + // _lib.std.ios.manip_, manipulators: +T ios_base& boolalpha (ios_base& str); +T ios_base& noboolalpha(ios_base& str); +T ios_base& showbase (ios_base& str); +T ios_base& noshowbase (ios_base& str); +T ios_base& showpoint (ios_base& str); +T ios_base& noshowpoint(ios_base& str); +T ios_base& showpos (ios_base& str); +T ios_base& noshowpos (ios_base& str); +T ios_base& skipws (ios_base& str); +T ios_base& noskipws (ios_base& str); +T ios_base& nouppercase(ios_base& str); +T ios_base& uppercase (ios_base& str); +M ios_base& unitbuf (ios_base& str); +M ios_base& nounitbuf (ios_base& str); + // _lib.adjustfield.manip_ adjustfield: +T ios_base& internal (ios_base& str); +T ios_base& left (ios_base& str); +T ios_base& right (ios_base& str); + // _lib.basefield.manip_ basefield: +T ios_base& dec (ios_base& str); +T ios_base& hex (ios_base& str); +T ios_base& oct (ios_base& str); + + // _lib.floatfield.manip_ floatfield: +T ios_base& fixed (ios_base& str); +T ios_base& scientific (ios_base& str); + + + 27.4.2 Class ios_base [lib.ios.base] + +T class ios_base { + public: + class failure; +T typedef T1 fmtflags; +T static const fmtflags boolalpha; +T static const fmtflags dec; +T static const fmtflags fixed; +T static const fmtflags hex; +T static const fmtflags internal; +T static const fmtflags left; +T static const fmtflags oct; +T static const fmtflags right; +T static const fmtflags scientific; +T static const fmtflags showbase; +T static const fmtflags showpoint; +T static const fmtflags showpos; +T static const fmtflags skipws; +X static const fmtflags unitbuf; +T static const fmtflags uppercase; +T static const fmtflags adjustfield; +T static const fmtflags basefield; +T static const fmtflags floatfield; + + typedef T2 iostate; +T static const iostate badbit; +T static const iostate eofbit; +T static const iostate failbit; +T static const iostate goodbit; +T typedef T3 openmode; +T static const openmode app; +T static const openmode ate; +T static const openmode binary; +T static const openmode in; +T static const openmode out; +T static const openmode trunc; +T typedef T4 seekdir; +T static const seekdir beg; +T static const seekdir cur; +T static const seekdir end; +T class Init; + // _lib.fmtflags.state_ fmtflags state: +T fmtflags flags() const; +T fmtflags flags(fmtflags fmtfl); +T fmtflags setf(fmtflags fmtfl); +T fmtflags setf(fmtflags fmtfl, fmtflags mask); +T void unsetf(fmtflags mask); +T streamsize precision() const; +T streamsize precision(streamsize prec); +T streamsize width() const; +T streamsize width(streamsize wide); + // _lib.ios.base.locales_ locales: +T locale imbue(const locale& loc); +T locale getloc() const; + // _lib.ios.base.storage_ storage: +T static int xalloc(); +T long& iword(int index); +T void*& pword(int index); + // destructor +T virtual ~ios_base(); + // _lib.ios.base.callback_ callbacks; +T enum event { erase_event, imbue_event, copyfmt_event }; +T typedef void (*event_callback)(event, ios_base&, int index); +T void register_callback(event_call_back fn, int index); +T static bool sync_with_stdio(bool sync = true); + protected: +T ios_base(); + }; + + 27.4.2.1.1 Class ios_base::failure [lib.ios::failure] + +T class ios_base::failure : public exception { + public: +T explicit failure(const string& msg); +T virtual ~failure(); +T virtual const char* what() const throw(); + }; + + + 27.4.2.1.6 Class ios_base::Init [lib.ios::Init] + +T class ios_base::Init { + public: +T Init(); +T ~Init(); + }; + + + 27.4.3 Template class fpos [lib.fpos] + +X template <class stateT> class fpos { + public: + // _lib.fpos.members_ Members +T stateT state() const; +T void state(stateT); + private; +T stateT st; // exposition only + }; + + + 27.4.5 Template class basic_ios [lib.ios] + + template <class charT, class traits = char_traits<charT> > +X class basic_ios : public ios_base { + public: + + // Types: +T typedef charT char_type; +T typedef typename traits::int_type int_type; +T typedef typename traits::pos_type pos_type; +T typedef typename traits::off_type off_type; +T typedef traits traits_type; +T operator void*() const +T bool operator!() const +T iostate rdstate() const; +T void clear(iostate state = goodbit); +T void setstate(iostate state); +T bool good() const; +T bool eof() const; +T bool fail() const; +T bool bad() const; +T iostate exceptions() const; +T void exceptions(iostate except); + // _lib.basic.ios.cons_ Constructor/destructor: +T explicit basic_ios(basic_streambuf<charT,traits>* sb); +T virtual ~basic_ios(); + // _lib.basic.ios.members_ Members: +T basic_ostream<charT,traits>* tie() const; +T basic_ostream<charT,traits>* tie(basic_ostream<charT,traits>* tiestr); +T basic_streambuf<charT,traits>* rdbuf() const; +T basic_streambuf<charT,traits>* rdbuf(basic_streambuf<charT,traits>* sb); +X basic_ios& copyfmt(const basic_ios& rhs); +T char_type fill() const; +T char_type fill(char_type ch); + // _lib.ios.base.locales_ locales: +T locale imbue(const locale& loc); +X char narrow(char_type c, char dfault) const; +X char_type widen(char c) const; + protected: + basic_ios(); +T void init(basic_streambuf<charT,traits>* sb); + private: +T basic_ios(const basic_ios& ); // not defined +T basic_ios& operator=(const basic_ios&); // not defined + }; + + + 27.5 Stream buffers [lib.stream.buffers] + + Header <streambuf> synopsis + +X template <class charT, class traits = char_traits<charT> > + class basic_streambuf; +T typedef basic_streambuf<char> streambuf; +T typedef basic_streambuf<wchar_t> wstreambuf; + + 27.5.2 Template class [lib.streambuf] + basic_streambuf<charT,traits> + + template <class charT, class traits = char_traits<charT> > +X class basic_streambuf { + public: + + // Types: +T typedef charT char_type; +T typedef typename traits::int_type int_type; +T typedef typename traits::pos_type pos_type; +T typedef typename traits::off_type off_type; +T typedef traits traits_type; +T virtual ~basic_streambuf(); + // _lib.streambuf.locales_ locales: +T locale pubimbue(const locale &loc); +T locale getloc() const; + // _lib.streambuf.buffer_ buffer and positioning: +T basic_streambuf<char_type,traits>* + pubsetbuf(char_type* s, streamsize n); +T pos_type pubseekoff(off_type off, ios_base::seekdir way, + ios_base::openmode which = + ios_base::in | ios_base::out); +T pos_type pubseekpos(pos_type sp, + ios_base::openmode which = + ios_base::in | ios_base::out); +T int pubsync(); + + // Get and put areas: + // _lib.streambuf.pub.get_ Get area: +T streamsize in_avail(); +T int_type snextc(); +T int_type sbumpc(); +T int_type sgetc(); +T streamsize sgetn(char_type* s, streamsize n); + // _lib.streambuf.pub.pback_ Putback: +X int_type sputbackc(char_type c); +X int_type sungetc(); + // _lib.streambuf.pub.put_ Put area: +T int_type sputc(char_type c); +X streamsize sputn(const char_type* s, streamsize n); + protected: +T basic_streambuf(); + // _lib.streambuf.get.area_ Get area: +T char_type* eback() const; +T char_type* gptr() const; +T char_type* egptr() const; +T void gbump(int n); +T void setg(char_type* gbeg, char_type* gnext, char_type* gend); + // _lib.streambuf.put.area_ Put area: +T char_type* pbase() const; +T char_type* pptr() const; +T char_type* epptr() const; +T void pbump(int n); +T void setp(char_type* pbeg, char_type* pend); + // _lib.streambuf.virtuals_ virtual functions: + // _lib.streambuf.virt.locales_ Locales: +T virtual void imbue(const locale &loc); + // _lib.streambuf.virt.buffer_ Buffer management and positioning: +T virtual basic_streambuf<char_type,traits>* + setbuf(char_type* s, streamsize n); +T virtual pos_type seekoff(off_type off, ios_base::seekdir way, + ios_base::openmode which = ios_base::in | ios_base::out); +T virtual pos_type seekpos(pos_type sp, + ios_base::openmode which = ios_base::in | ios_base::out); +T virtual int sync(); + // _lib.streambuf.virt.get_ Get area: +T virtual int showmanyc(); +T virtual streamsize xsgetn(char_type* s, streamsize n); +T virtual int_type underflow(); +T virtual int_type uflow(); + // _lib.streambuf.virt.pback_ Putback: +T virtual int_type pbackfail(int_type c = traits::eof()); + // _lib.streambuf.virt.put_ Put area: +X virtual streamsize xsputn(const char_type* s, streamsize n); +T virtual int_type overflow (int_type c = traits::eof()); + }; + + 27.6 Formatting and manipulators [lib.iostream.format] + + Header <istream> synopsis + +T template <class charT, class traits = char_traits<charT> > + class basic_istream; +T typedef basic_istream<char> istream; +T typedef basic_istream<wchar_t> wistream; + +T template <class charT, class traits = char_traits<charT> > + class basic_iostream; +T typedef basic_iostream<char> iostream; +T typedef basic_iostream<wchar_t> wiostream; + +X template <class charT, class traits> + basic_istream<charT,traits>& ws(basic_istream<charT,traits>& is); + + Header <ostream> synopsis + +X template <class charT, class traits = char_traits<charT> > + class basic_ostream; +T typedef basic_ostream<char> ostream; +T typedef basic_ostream<wchar_t> wostream; + +T template <class charT, class traits> + basic_ostream<charT,traits>& endl(basic_ostream<charT,traits>& os); +T template <class charT, class traits> + basic_ostream<charT,traits>& ends(basic_ostream<charT,traits>& os); +T template <class charT, class traits> + basic_ostream<charT,traits>& flush(basic_ostream<charT,traits>& os); + + Header <iomanip> synopsis + + // Types T1, T2, ... are unspecified implementation types +T T1 resetiosflags(ios_base::fmtflags mask); +T T2 setiosflags (ios_base::fmtflags mask); +T T3 setbase(int base); +T template<charT> T4 setfill(charT c); +T T5 setprecision(int n); +T T6 setw(int n); + + + 27.6.1.1 Template class basic_istream [lib.istream] + + template <class charT, class traits = char_traits<charT> > +T class basic_istream : virtual public basic_ios<charT,traits> { + public: + // Types (inherited from basic_ios (_lib.ios_)): +T typedef charT char_type; +T typedef typename traits::int_type int_type; +T typedef typename traits::pos_type pos_type; +T typedef typename traits::off_type off_type; +T typedef traits traits_type; + // _lib.istream.cons_ Constructor/destructor: +T explicit basic_istream(basic_streambuf<charT,traits>* sb); +T virtual ~basic_istream(); + // _lib.istream::sentry_ Prefix/suffix: +T class sentry; + + // _lib.istream.formatted_ Formatted input: +T basic_istream<charT,traits>& operator>> + (basic_istream<charT,traits>& (*pf)(basic_istream<charT,traits>&)) +T basic_istream<charT,traits>& operator>> + (basic_ios<charT,traits>& (*pf)(basic_ios<charT,traits>&)) +T basic_istream<charT,traits>& operator>> + (ios_base& (*pf)(ios_base&)) +S basic_istream<charT,traits>& operator>>(bool& n); +S basic_istream<charT,traits>& operator>>(short& n); +S basic_istream<charT,traits>& operator>>(unsigned short& n); +S basic_istream<charT,traits>& operator>>(int& n); +S basic_istream<charT,traits>& operator>>(unsigned int& n); +S basic_istream<charT,traits>& operator>>(long& n); +S basic_istream<charT,traits>& operator>>(unsigned long& n); +S basic_istream<charT,traits>& operator>>(float& f); +S basic_istream<charT,traits>& operator>>(double& f); +S basic_istream<charT,traits>& operator>>(long double& f); +S basic_istream<charT,traits>& operator>>(void*& p); +S basic_istream<charT,traits>& operator>> + (basic_streambuf<char_type,traits>* sb); + // _lib.istream.unformatted_ Unformatted input: +T streamsize gcount() const; +S int_type get(); +S basic_istream<charT,traits>& get(char_type& c); +S basic_istream<charT,traits>& get(char_type* s, streamsize n); +S basic_istream<charT,traits>& get(char_type* s, streamsize n, + char_type delim); +S basic_istream<charT,traits>& get(basic_streambuf<char_type,traits>& sb); +S basic_istream<charT,traits>& get(basic_streambuf<char_type,traits>& sb, + char_type delim); +S basic_istream<charT,traits>& getline(char_type* s, streamsize n); +S basic_istream<charT,traits>& getline(char_type* s, streamsize n, + char_type delim); +S basic_istream<charT,traits>& ignore + (streamsize n = 1, int_type delim = traits::eof()); +S int_type peek(); +S basic_istream<charT,traits>& read (char_type* s, streamsize n); +S streamsize readsome(char_type* s, streamsize n); +S basic_istream<charT,traits>& putback(char_type c); +S basic_istream<charT,traits>& unget(); +S int sync(); + +S pos_type tellg(); +S basic_istream<charT,traits>& seekg(pos_type); +S basic_istream<charT,traits>& seekg(off_type, ios_base::seekdir); + }; + + // _lib.istream::extractors_ character extraction templates: +S template<class charT, class traits> + basic_istream<charT,traits>& operator>>(basic_istream<charT,traits>&, + charT&); +S template<class traits> + basic_istream<char,traits>& operator>>(basic_istream<char,traits>&, + unsigned char&); +S template<class traits> + basic_istream<char,traits>& operator>>(basic_istream<char,traits>&, + signed char&); + +S template<class charT, class traits> + basic_istream<charT,traits>& operator>>(basic_istream<charT,traits>&, + charT*); +S template<class traits> + basic_istream<char,traits>& operator>>(basic_istream<char,traits>&, + unsigned char*); +S template<class traits> + basic_istream<char,traits>& operator>>(basic_istream<char,traits>&, + signed char*); + + 27.6.1.1.2 Class basic_istream::sentry [lib.istream::sentry] + + + template <class charT,class traits = char_traits<charT> > +S class basic_istream<charT,traits>::sentry { + typedef traits traits_type; +S bool ok_; // exposition only + public: +S explicit sentry(basic_istream<charT,traits>& is, bool noskipws = false); +S ~sentry(); +S operator bool() const { return ok_; } + private: +T sentry(const sentry&); // not defined +T sentry& operator=(const sentry&); // not defined + }; + + + 27.6.1.5 Template class basic_iostream [lib.iostreamclass] + + template <class charT, class traits = char_traits<charT> > +T class basic_iostream : + public basic_istream<charT,traits>, + public basic_ostream<charT,traits> { + public: + // constructor/destructor +T explicit basic_iostream(basic_streambuf<charT,traits>* sb); +T virtual ~basic_iostream(); + }; + + + 27.6.2.1 Template class basic_ostream [lib.ostream] + + template <class charT, class traits = char_traits<charT> > +X class basic_ostream : virtual public basic_ios<charT,traits> { + public: + // Types (inherited from basic_ios (_lib.ios_)): +T typedef charT char_type; +T typedef typename traits::int_type int_type; +T typedef typename traits::pos_type pos_type; +T typedef typename traits::off_type off_type; +T typedef traits traits_type; + // _lib.ostream.cons_ Constructor/destructor: +T explicit basic_ostream(basic_streambuf<char_type,traits>* sb); +T virtual ~basic_ostream(); + // _lib.ostream::sentry_ Prefix/suffix: +T class sentry; + // _lib.ostream.formatted_ Formatted output: +T basic_ostream<charT,traits>& operator<< + (basic_ostream<charT,traits>& (*pf)(basic_ostream<charT,traits>&)); +T basic_ostream<charT,traits>& operator<< + (basic_ios<charT,traits>& (*pf)(basic_ios<charT,traits>&)); +T basic_ostream<charT,traits>& operator<< + (ios_base& (*pf)(ios_base&)); +T basic_ostream<charT,traits>& operator<<(bool n); +T basic_ostream<charT,traits>& operator<<(short n); +T basic_ostream<charT,traits>& operator<<(unsigned short n); +T basic_ostream<charT,traits>& operator<<(int n); +T basic_ostream<charT,traits>& operator<<(unsigned int n); +T basic_ostream<charT,traits>& operator<<(long n); +T basic_ostream<charT,traits>& operator<<(unsigned long n); +S basic_ostream<charT,traits>& operator<<(float f); +S basic_ostream<charT,traits>& operator<<(double f); +S basic_ostream<charT,traits>& operator<<(long double f); +T basic_ostream<charT,traits>& operator<<(const void* p); +X basic_ostream<charT,traits>& operator<< + (basic_streambuf<char_type,traits>* sb); + // _lib.ostream.unformatted_ Unformatted output: +T basic_ostream<charT,traits>& put(char_type c); +T basic_ostream<charT,traits>& write(const char_type* s, streamsize n); +X basic_ostream<charT,traits>& flush(); + + // _lib.ostream.seeks_ seeks: +S pos_type tellp(); +S basic_ostream<charT,traits>& seekp(pos_type); +S basic_ostream<charT,traits>& seekp(off_type, ios_base::seekdir); + }; + // _lib.ostream.inserters.character_ character inserters +X template<class charT, class traits> + basic_ostream<charT,traits>& operator<<(basic_ostream<charT,traits>&, + charT); +X template<class charT, class traits> + basic_ostream<charT,traits>& operator<<(basic_ostream<charT,traits>&, + char); + // specialization +X template<class traits> + basic_ostream<char,traits>& operator<<(basic_ostream<char,traits>&, + char); + // signed and unsigned +X template<class traits> + basic_ostream<char,traits>& operator<<(basic_ostream<char,traits>&, + signed char); +X template<class traits> + basic_ostream<char,traits>& operator<<(basic_ostream<char,traits>&, + unsigned char) +X template<class charT, class traits> + basic_ostream<charT,traits>& operator<<(basic_ostream<charT,traits>&, + const charT*); +X template<class charT, class traits> + basic_ostream<charT,traits>& operator<<(basic_ostream<charT,traits>&, + const char*); + // partial specializationss +X template<class traits> + basic_ostream<char,traits>& operator<<(basic_ostream<char,traits>&, + const char*); + // signed and unsigned +X template<class traits> + basic_ostream<char,traits>& operator<<(basic_ostream<char,traits>&, + const signed char*); +X template<class traits> + basic_ostream<char,traits>& operator<<(basic_ostream<char,traits>&, + const unsigned char*); + + + 27.6.2.3 Class basic_ostream::sentry [lib.ostream::sentry] + + template <class charT,class traits = char_traits<charT> > +X class basic_ostream<charT,traits>::sentry { + bool ok_; // exposition only + public: +X explicit sentry(basic_ostream<charT,traits>& os); +X ~sentry(); +X operator bool() const { return ok_; } + private +X sentry(const sentry&); // not defined +X sentry& operator=(const sentry&); // not defined + }; + + 27.7 String-based streams [lib.string.streams] + + Header <sstream> synopsis + +X template <class charT, class traits = char_traits<charT>, + class Allocator = allocator<charT> > + class basic_stringbuf; + +T typedef basic_stringbuf<char> stringbuf; +T typedef basic_stringbuf<wchar_t> wstringbuf; + + template <class charT, class traits = char_traits<charT>, + class Allocator = allocator<charT> > +X class basic_istringstream; + +T typedef basic_istringstream<char> istringstream; +T typedef basic_istringstream<wchar_t> wistringstream; + + template <class charT, class traits = char_traits<charT>, + class Allocator = allocator<charT> > +X class basic_ostringstream; +T typedef basic_ostringstream<char> ostringstream; +T typedef basic_ostringstream<wchar_t> wostringstream; + + template <class charT, class traits = char_traits<charT>, + class Allocator = allocator<charT> > +X class basic_stringstream; +T typedef basic_stringstream<char> stringstream; +T typedef basic_stringstream<wchar_t> wstringstream; + + 27.7.1 Template class basic_stringbuf [lib.stringbuf] + + template <class charT, class traits = char_traits<charT>, + class Allocator = allocator<charT> > +X class basic_stringbuf : public basic_streambuf<charT,traits> { + public: +T typedef charT char_type; +T typedef typename traits::int_type int_type; +T typedef typename traits::pos_type pos_type; +T typedef typename traits::off_type off_type; +T typedef traits traits_type; + // _lib.stringbuf.cons_ Constructors: +S explicit basic_stringbuf(ios_base::openmode which + = ios_base::in | ios_base::out); +S explicit basic_stringbuf + (const basic_string<charT,traits,Allocator>& str, + ios_base::openmode which = ios_base::in | ios_base::out); + // _lib.stringbuf.members_ Get and set: +S basic_string<charT,traits,Allocator> str() const; +S void str(const basic_string<charT,traits,Allocator>& s); + + protected: + // _lib.stringbuf.virtuals_ Overridden virtual functions: +S virtual int_type underflow(); +S virtual int_type pbackfail(int_type c = traits::eof()); +S virtual int_type overflow (int_type c = traits::eof()); +S virtual basic_streambuf<charT,traits>* setbuf(charT*, streamsize); + +S virtual pos_type seekoff(off_type off, ios_base::seekdir way, + ios_base::openmode which + = ios_base::in | ios_base::out); +S virtual pos_type seekpos(pos_type sp, + ios_base::openmode which + = ios_base::in | ios_base::out); + }; + + + 27.7.2 Template class basic_istringstream [lib.istringstream] + + template <class charT, class traits = char_traits<charT>, + class Allocator = allocator<charT> > +X class basic_istringstream : public basic_istream<charT,traits> { + public: +T typedef charT char_type; +T typedef typename traits::int_type int_type; +T typedef typename traits::pos_type pos_type; +T typedef typename traits::off_type off_type; +T typedef traits traits_type; + // _lib.istringstream.cons_ Constructors: +S explicit basic_istringstream(ios_base::openmode which = ios_base::in); +S explicit basic_istringstream( + const basic_string<charT,traits,Allocator>& str, + ios_base::openmode which = ios_base::in); + + // _lib.istringstream.members_ Members: +S basic_stringbuf<charT,traits,Allocator>* rdbuf() const; +S basic_string<charT,traits,Allocator> str() const; +S void str(const basic_string<charT,traits,Allocator>& s); + private: + // basic_stringbuf<charT,traits,Allocator> sb; exposition only + }; + + 27.7.3 Class basic_ostringstream [lib.ostringstream] + + template <class charT, class traits = char_traits<charT>, + class Allocator = allocator<charT> > +X class basic_ostringstream : public basic_ostream<charT,traits> { + public: + + // Types: +T typedef charT char_type; +T typedef typename traits::int_type int_type; +T typedef typename traits::pos_type pos_type; +T typedef typename traits::off_type off_type; + // _lib.ostringstream.cons_ Constructors/destructor: +S explicit basic_ostringstream(ios_base::openmode which = ios_base::out); +S explicit basic_ostringstream( + const basic_string<charT,traits,Allocator>& str, + ios_base::openmode which = ios_base::out); + // _lib.ostringstream.members_ Members: +S basic_stringbuf<charT,traits,Allocator>* rdbuf() const; +S basic_string<charT,traits,Allocator> str() const; +S void str(const basic_string<charT,traits,Allocator>& s); + }; + + + 27.7.4 Template class basic_stringstream [lib.stringstream] + + template <class charT, class traits = char_traits<charT>, + class Allocator = allocator<charT> > +X class basic_stringstream + : public basic_iostream<charT,traits> { + public: + // Types +T typedef charT char_type; +T typedef typename traits::int_type int_type; +T typedef typename traits::pos_type pos_type; +T typedef typename traits::off_type off_type; + // constructors/destructors +S explicit basic_stringstream( + ios_base::openmode which = ios_base::out|ios_base::in); +S explicit basic_stringstream( + const basic_string<charT,traits,Allocator>& str, + ios_base::openmode which = ios_base::out|ios_base::in); + // Members: +S basic_stringbuf<charT,traits,Allocator>* rdbuf() const; +S basic_string<charT,traits,Allocator> str() const; +S void str(const basic_string<charT,traits,Allocator>& str); + }; + + + + 27.8.1 File streams [lib.fstreams] + + + Header <fstream> synopsis + +X template <class charT, class traits = char_traits<charT> > + class basic_filebuf; +T typedef basic_filebuf<char> filebuf; +T typedef basic_filebuf<wchar_t> wfilebuf; + +X template <class charT, class traits = char_traits<charT> > + class basic_ifstream; +T typedef basic_ifstream<char> ifstream; +T typedef basic_ifstream<wchar_t> wifstream; + +X template <class charT, class traits = char_traits<charT> > + class basic_ofstream; +T typedef basic_ofstream<char> ofstream; +T typedef basic_ofstream<wchar_t> wofstream; + +X template <class charT, class traits = char_traits<charT> > + class basic_fstream; +T typedef basic_fstream<char> fstream; +T typedef basic_fstream<wchar_t> wfstream; + + 27.8.1.1 Template class basic_filebuf [lib.filebuf] + + template <class charT, class traits = char_traits<charT> > +X class basic_filebuf : public basic_streambuf<charT,traits> { + public: +T typedef charT char_type; +T typedef typename traits::int_type int_type; +T typedef typename traits::pos_type pos_type; +T typedef typename traits::off_type off_type; +T typedef traits traits_type; + // _lib.filebuf.cons_ Constructors/destructor: +X basic_filebuf(); +X virtual ~basic_filebuf(); + // _lib.filebuf.members_ Members: +T bool is_open() const; +X basic_filebuf<charT,traits>* open + (const char* s, ios_base::openmode mode); +X basic_filebuf<charT,traits>* close(); + protected: + // _lib.filebuf.virtuals_ Overridden virtual functions: +X virtual streamsize showmanyc(); +X virtual int_type underflow(); +X virtual int_type uflow(); +X virtual int_type pbackfail(int_type c = traits::eof()); +X virtual int_type overflow (int_type c = traits::eof()); +S virtual basic_streambuf<charT,traits>* + setbuf(char_type* s, streamsize n); +S virtual pos_type seekoff(off_type off, ios_base::seekdir way, + ios_base::openmode which + = ios_base::in | ios_base::out); +S virtual pos_type seekpos(pos_type sp, ios_base::openmode which + = ios_base::in | ios_base::out); +S virtual int sync(); +S virtual void imbue(const locale& loc); + }; + + + + 27.8.1.5 Template class basic_ifstream [lib.ifstream] + + template <class charT, class traits = char_traits<charT> > +X class basic_ifstream : public basic_istream<charT,traits> { + public: +T typedef charT char_type; +T typedef typename traits::int_type int_type; +T typedef typename traits::pos_type pos_type; +T typedef typename traits::off_type off_type; +T typedef traits traits_type; + // _lib.ifstream.cons_ Constructors: +S basic_ifstream(); +S explicit basic_ifstream(const char* s, + ios_base::openmode mode = ios_base::in); + // _lib.ifstream.members_ Members: +S basic_filebuf<charT,traits>* rdbuf() const; +S bool is_open(); +S void open(const char* s, ios_base::openmode mode = ios_base::in); +S void close(); + }; + + + 27.8.1.8 Template class basic_ofstream [lib.ofstream] + + template <class charT, class traits = char_traits<charT> > +X class basic_ofstream : public basic_ostream<charT,traits> { + public: +T typedef charT char_type; +T typedef typename traits::int_type int_type; +T typedef typename traits::pos_type pos_type; +T typedef typename traits::off_type off_type; +T typedef traits traits_type; + // _lib.ofstream.cons_ Constructors: +X basic_ofstream(); +X explicit basic_ofstream(const char* s, + ios_base::openmode mode + = ios_base::out); + // _lib.ofstream.members_ Members: +X basic_filebuf<charT,traits>* rdbuf() const; +T bool is_open(); +X void open(const char* s, ios_base::openmode mode = ios_base::out); +X void close(); + }; + + + 27.8.1.11 Template class basic_fstream [lib.fstream] + + template <class charT, class traits=char_traits<charT> > +X class basic_fstream + : public basic_iostream<charT,traits> { + public: +T typedef charT char_type; +T typedef typename traits::int_type int_type; +T typedef typename traits::pos_type pos_type; +T typedef typename traits::off_type off_type; +T typedef traits traits_type; + // constructors/destructor +S basic_fstream(); +S explicit basic_fstream( + const char* s, + ios_base::openmode mode = ios_base::in|ios_base::out); + + // Members: +S basic_filebuf<charT,traits>* rdbuf() const; +S bool is_open(); +S void open( + const char* s, + ios_base::openmode mode = ios_base::in|ios_base::out); +S void close(); + }; + + + + 27.8.2 C Library files [lib.c.files] + + + Table 13--Header <cstdio> synopsis + Macros: +X BUFSIZ L_tmpnam SEEK_SET TMP_MAX +X EOF NULL <cstdio> stderr _IOFBF +X FILENAME_MAX SEEK_CUR stdin _IOLBF +X FOPEN_MAX SEEK_END stdout _IONBF + +X Types: FILE fpos_t size_t <cstdio> + Functions: +X clearerr fgets fscanf gets rewind +X fclose fopen fseek perror scanf tmpnam +X feof fprintf fsetpos printf setbuf ungetc +X ferror fputc ftell putc setvbuf vprintf +X fflush fputs fwrite puts sprintf vfprintf +X fgetc fread getc remove sscanf vsprintf +X fgetpos freopen getchar putchar rename tmpfile + + + + + 1.5 Standard C library headers [depr.c.headers] + +X <assert.h> <iso646.h> <setjmp.h> <stdio.h> <wchar.h> + <ctype.h> <limits.h> <signal.h> <stdlib.h> <wctype.h> + <errno.h> <locale.h> <stdarg.h> <string.h> + <float.h> <math.h> <stddef.h> <time.h> + + 1.6 Old iostreams members [depr.ios.members] + + [Note: these should be #ifdef'd to permit diagnostics if used.] + namespace std { + class ios_base { + public: +T typedef T1 io_state; +T typedef T2 open_mode; +T typedef T3 seek_dir; +T typedef OFF_T streamoff; +T typedef OFF_T streampos; + // remainder unchanged + }; + } + + [Note: these should be #ifdef'd to permit diagnostics if used.] + namespace std { + template<class charT, class traits = char_traits<charT> > + class basic_streambuf { + public: +T void stossc(); + // remainder unchanged + }; + } + + 8 An implementation may provide the following member functions that + overload signatures specified in clause _lib.iostreams_: + + [Note: the following overloads should be #ifdef'd to permit + diagnostics to be emitted, by default, if used.] + + template<class charT, class Traits> class basic_ios { + public: +M void clear(io_state state); +M void setstate(io_state state); + // remainder unchanged + }; + class ios_base { + public: +M void exceptions(io_state); + // remainder unchanged + }; + template<class charT, class traits = char_traits<charT> > + class basic_streambuf { + public: +M pos_type pubseekoff(off_type off, ios_base::seek_dir way, + ios_base::open_mode which = ios_base::in | ios_base::out); +M pos_type pubseekpos(pos_type sp, + ios_base::open_mode which = ios_base::in | ios_base::out); + // remainder unchanged + }; + template <class charT, class traits = char_traits<charT> > + class basic_filebuf : public basic_streambuf<charT,traits> { + public: +M basic_filebuf<charT,traits>* open + (const char* s, ios_base::open_mode mode); + // remainder unchanged + }; + template <class charT, class traits = char_traits<charT> > + class basic_ifstream : public basic_istream<charT,traits> { + public: +M void open(const char* s, ios_base::open_mode mode = in); + // remainder unchanged + }; + template <class charT, class traits = char_traits<charT> > + class basic_ofstream : public basic_ostream<charT,traits> { + public: +M void open(const char* s, ios_base::open_mode mode = out | trunc); + // remainder unchanged + }; + } + + + + 1.7.1 Class strstreambuf [depr.strstreambuf] + + [Note: It should be possible to adopt these components with only + minor changes from the 2.8 version of the library.] + +M class strstreambuf : public basic_streambuf<char> { + public: +M explicit strstreambuf(streamsize alsize_arg = 0); +M strstreambuf(void* (*palloc_arg)(size_t), void (*pfree_arg)(void*)); +M strstreambuf(char* gnext_arg, streamsize n, char* pbeg_arg = 0); +M strstreambuf(const char* gnext_arg, streamsize n); +M strstreambuf(signed char* gnext_arg, streamsize n, + signed char* pbeg_arg = 0); +M strstreambuf(const signed char* gnext_arg, streamsize n); +M strstreambuf(unsigned char* gnext_arg, streamsize n, + unsigned char* pbeg_arg = 0); +M strstreambuf(const unsigned char* gnext_arg, streamsize n); +M virtual ~strstreambuf(); +M void freeze(bool freezefl = true); +M char* str(); +M int pcount(); + protected: +M virtual int_type overflow (int_type c = EOF); +M virtual int_type pbackfail(int_type c = EOF); +M virtual int_type underflow(); +M virtual pos_type seekoff(off_type off, ios_base::seekdir way, + ios_base::openmode which + = ios_base::in | ios_base::out); +M virtual pos_type seekpos(pos_type sp, ios_base::openmode which + = ios_base::in | ios_base::out); +M virtual streambuf<char>* setbuf(char* s, streamsize n); + } + + 1.7.4 Class strstream [depr.strstream] + +M class strstream + : public basic_iostream<char> { + public: + // Types +M typedef char char_type; +M typedef typename char_traits<char>::int_type int_type +M typedef typename char_traits<char>::pos_type pos_type; +M typedef typename char_traits<char>::off_type off_type; + // consturctors/destructor +M strstream(); +M strstream(char* s, int n, + ios_base::openmode mode = ios_base::in|ios_base::out); +M virtual ~strstream(); + // Members: +M strstreambuf* rdbuf() const; +M void freeze(bool freezefl = true); +M int pcount() const; +M char* str(); + }; + + + + + + + Implementation Specific Behavior + + + The ISO standard defines the following phrase: + +
+ + + + [1.3.5] implementation-defined behavior + + + + Behavior, for a well-formed program construct and correct data, that + depends on the implementation and that each implementation + shall document. + + + + +
+ + We do so here, for the C++ library only. Behavior of the + compiler, linker, runtime loader, and other elements of "the + implementation" are documented elsewhere. Everything listed + in Annex B, Implementation Qualities, are also part of the + compiler, not the library. + + + For each entry, we give the section number of the standard, when + applicable. This list is probably incomplet and inkorrekt. + + + [1.9]/11 #3 If isatty(3) is true, then + interactive stream support is implied. + + + [17.4.4.5] Non-reentrant functions are probably best + discussed in the various sections on multithreading (see above). + + + [18.1]/4 The type of NULL is described + here. + + [18.3]/8 Even though it's listed in the library + sections, libstdc++ has zero control over what the cleanup code hands + back to the runtime loader. Talk to the compiler people. :-) + + [18.4.2.1]/5 (bad_alloc), + [18.5.2]/5 (bad_cast), + [18.5.3]/5 (bad_typeid), + [18.6.1]/8 (exception), + [18.6.2.1]/5 (bad_exception): The what() + member function of class std::exception, and these other + classes publicly derived from it, simply returns the name of the + class. But they are the mangled names; you will need to call + c++filt and pass the names as command-line parameters to + demangle them, or call a + runtime demangler function. + (The classes in <stdexcept> have constructors which + require an argument to use later for what() calls, so the + problem of what()'s value does not arise in most + user-defined exceptions.) + + [18.5.1]/7 The return value of + std::type_info::name() is the mangled type name (see the + previous entry for more). + + [20.1.5]/5 "Implementors are encouraged to + supply libraries that can accept allocators that encapsulate more + general memory models and that support non-equal instances. In such + implementations, any requirements imposed on allocators by containers + beyond those requirements that appear in Table 32, and the semantics + of containers and algorithms when allocator instances compare + non-equal, are implementation-defined." As yet we don't + have any allocators which compare non-equal, so we can't describe how + they behave. + + [21.1.3.1]/3,4, + [21.1.3.2]/2, + [23.*]'s foo::iterator, + [27.*]'s foo::*_type, + others... + Nope, these types are called implementation-defined because you + shouldn't be taking advantage of their underlying types. Listing them + here would defeat the purpose. :-) + + [21.1.3.1]/5 I don't really know about the mbstate_t + stuff... see the chapter 22 notes + for what does exist. + + [22.*] Anything and everything we have on locale + implementation will be described + over here. + + [26.2.8]/9 I have no idea what + complex<T>'s pow(0,0) returns. + + [27.4.2.4]/2 Calling + std::ios_base::sync_with_stdio after I/O has already been + performed on the standard stream objects will + flush the buffers, and + destroy and recreate the underlying buffer instances. Whether or not + the previously-written I/O is destroyed in this process depends mostly + on the --enable-libio choice: for stdio, if the written data is + already in the stdio buffer, the data may be completely safe! + + [27.6.1.1.2], + [27.6.2.3] The I/O sentry ctor and dtor can perform + additional work than the minimum required. We are not currently taking + advantage of this yet. + + [27.7.1.3]/16, + [27.8.1.4]/10 + The effects of pubsetbuf/setbuf are described + in this chapter. + + [27.8.1.4]/16 Calling fstream::sync when + a get area exists will... whatever fflush() does, I think. + + + + + diff --git a/libstdc++-v3/doc/xml/manual/status_cxx200x.xml b/libstdc++-v3/doc/xml/manual/status_cxx200x.xml new file mode 100644 index 00000000000..1c6460a5544 --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/status_cxx200x.xml @@ -0,0 +1,2241 @@ + + + + + + + ISO C++ + + + 200x + + + + +C++ 200x + + +This table is based on the table of contents of ISO/IEC +Doc No: N2461=07-0331 Date: 2007-10-22 +Working Draft, Standard for Programming Language C++ + + + +In this implementation -std=gnu++0x or +-std=c++0x flags must be used to enable language and +library features. The pre-defined symbol +__GXX_EXPERIMENTAL_CXX0X__ is used to check for the +presence of the required flag. + + + +This page describes the C++0x support in mainline GCC SVN, not in any +particular release. + + + +C++ 200x Implementation Status + + + + + + + + + + + Section + Description + Done + Broken + Missing + Comments + + + + + + 20 + General Utilities + + + 20.2 + Utility Components + + + incomplete + + + + 20.2.1 + Operators + + + partial + + + + 20.2.2 + forward/move helpers + + + partial + + + + 20.2.3 + Pairs + done + + + + + + + 20.3 + Header <tuple> synopsis + done + + + + + + 20.3.1 + Class template tuple + done + + + + + + 20.3.1.1 + Construction + done + + + + + + 20.3.1.2 + Tuple creation functions + done + + + + + + 20.3.1.3 + Tuple helper classes + done + + + + + + 20.3.1.4 + Element access + done + + + + + + 20.3.1.5 + Relational operators + done + + + + + + + 20.4 + Metaprogramming and type traits + + + 20.4.1 + Requirements + done + + + + + + 20.4.2 + Header <type_traits> synopsis + done + + + + + + 20.4.3 + Helper classes + done + + + + + + 20.4.4 + General Requirements + done + + + + + + 20.4.5 + Unary Type Traits + done + + + + + + 20.4.5.1 + Primary Type Categories + done + + + + + + 20.4.5.2 + Composite type traits + done + + + + + + 20.4.5.3 + Type properties + done + + + + + + 20.4.6 + Relationships between types + done + + + + + + 20.4.7 + Transformations between types + done + + + + + + 20.4.7.1 + Const-volatile modifications + done + + + + + + 20.4.7.2 + Reference modifications + done + + + + + + 20.4.7.3 + Array modifications + done + + + + + + 20.4.7.4 + Pointer modifications + done + + + + + + 20.4.8 + Other transformations + done + + + + + + 20.4.9 + Implementation requirements + done + + + + + + 20.5 + Function Objects + done + + + + + + 20.5 + Additions to header <functional> synopsis + done + + + + + + 20.5.1 + Definitions + done + + + + + + 20.5.2 + Requirements + done + + + + + + 20.5.3 + Base + done + + + + + + 20.5.4 + Function return types + done + + + + + + 20.5.5 + Class template reference_wrapper + done + + + + + + 20.5.5.1 + reference_wrapper construct/copy/destroy + done + + + + + + 20.5.5.2 + reference_wrapper assignment + done + + + + + + 20.5.5.3 + reference_wrapper access + done + + + + + + 20.5.5.4 + reference_wrapper invocation + done + + + + + + 20.5.5.5 + reference_wrapper helper functions + done + + + + + + 20.5.14 + Function template mem_fn + done + + + + + + 20.5.11 + Template function bind + done + + + + + + + 20.5.11.1 + Function object binders + done + + + + + + 20.5.11.1.1 + Class template is_bind_expression + done + + + + + + 20.5.11.1.2 + Class template is_placeholder + done + + + + + + 20.5.11.1.3 + Function template bind + done + + + + + + 20.5.11.1.4 + Placeholders + done + + + + + + 20.5.15 + Polymorphic function wrappers + done + + + + + + 20.5.15.1 + Class bad_function_call + done + + + + + + 20.5.15.1.1 + bad_function_call constructor + done + + + + + + 20.5.15.2 + Class template function + done + + + + + + 20.5.15.2.1 + function construct/copy/destroy + done + + + + + + 20.5.15.2.2 + function modifiers + done + + + + + + 20.5.15.2.3 + function capacity + done + + + + + + 20.5.15.2.4 + function invocation + done + + + + + + 20.5.15.2.5 + function target access + done + + + + + + 20.5.15.2.7 + null pointer comparison operators + done + + + + + + 20.5.15.2.8 + specialized algorithms + done + + + + + + 20.5.16 + Class template hash + done + + + + + + 20.6 + Additions to header <memory> synopsis + + + partial + missing unique_ptr + + + 20.6.5 + Class template unique_ptr + + + missing + + + + 20.6.6 + Smart pointers + done + + + + + + 20.6.6.1 + Class bad_weak_ptr + done + + + + + + 20.6.6.2 + Class template shared_ptr + done + + + See Footnotes. + + + 20.6.6.2.1 + shared_ptr constructors + done + + + + + + 20.6.6.2.2 + shared_ptr destructor + done + + + + + + 20.6.6.2.3 + shared_ptr assignment + done + + + + + + 20.6.6.2.4 + shared_ptr modifiers + done + + + + + + 20.6.6.2.5 + shared_ptr observers + done + + + + + + 20.6.6.2.6 + shared_ptr creation + done + + + + N2351 + + + + 20.6.6.2.7 + shared_ptr comparison + done + + + + + + 20.6.6.2.8 + shared_ptr I/O + done + + + + + + 20.6.6.2.9 + shared_ptr specialized algorithms + done + + + + + + 20.6.6.2.10 + shared_ptr casts + done + + + + + + 20.6.6.2.11 + get_deleter + done + + + + + + 20.6.6.3 + Class template weak_ptr + done + + + + + + 20.6.6.3.1 + weak_ptr constructors + done + + + + + + 20.6.6.3.2 + weak_ptr destructor + done + + + + + + 20.6.6.3.3 + weak_ptr assignment + done + + + + + + 20.6.6.3.4 + weak_ptr modifiers + done + + + + + + 20.6.6.3.5 + weak_ptr observers + done + + + + + + 20.6.6.3.6 + weak_ptr comparison + done + + + + + + 20.6.6.3.7 + weak_ptr specialized algorithms + done + + + + + + 20.6.6.4 + Class template enable_shared_from_this + done + + + + + + + + + 23 + Containers + + + 23.2.1 + Header <array> synopsis + done + + + + + + 23.2.1 + Class template array + done + + + + + + 23.2.1.1 + array constructors, copy, and assignment + done + + + + + + 23.2.1.2 + array specialized algorithms + done + + + + + + 23.2.1.3 + array size + done + + + + + + 23.2.1.4 + array data + done + + + + + + 23.2.1.5 + Zero sized arrays + done + + + + + + 23.2.1.6 + Tuple interface to class template array + done + + + + + + + 23.4 + Unordered associative containers + done + + + + + + 23.4.1 + Class template unordered_map + done + + + + + + 23.4.1.1 + unordered_map constructors + done + + + + + + 23.4.1.2 + unordered_map element access + done + + + + + + 23.4.1.3 + unordered_map swap + done + + + + + + 23.4.2 + Class template unordered_multimap + done + + + + + + 23.4.2.1 + unordered_multimap constructors + done + + + + + + 23.4.2.2 + unordered_multimap swap + done + + + + + + 23.4.3 + Class template unordered_set + done + + + + + + 23.4.3.1 + unordered_set constructors + done + + + + + + 23.4.3.2 + unordered_set swap + done + + + + + + 23.4.4 + Class template unordered_multiset + done + + + + + + 23.4.4.1 + unordered_multiset constructors + done + + + + + + 23.4.4.2 + unordered_multiset swap + done + + + + + + + 26 + Numerics + + + 26.4 + Random number generation + done + + + + + + 26.4.1 + Requirements + done + + + + + + 26.4.2 + Header <random> synopsis + + + partial + + + + 26.4.3 + Random number engine class templates + done + + + + + + 26.4.3.1 + Class template linear_congruential_engine + done + + + + + + 26.4.3.2 + Class template mersenne_twister_engine + done + + + + + + 26.4.3.3 + Class template subtract_with_carry_engine + done + + + + + + 26.4.4 + Random number engine adaptor class templates + done + + + + + + + 26.4.4.1 + Class template discard_block_engine + done + + + + + + 26.4.4.2 + Class template independent_bits_engine + done + + + + + + 26.4.4.3 + Class template shuffle_order_engine + done + + + + + + 26.4.4.4 + Class template xor_combine_engine + done + + + operator()() per N2079 + + + 26.4.5 + Engines and engine adaptors with predefined parameters + done + + + + + + 26.4.6 + Class random_device + done + + + + + + 26.4.7 + Utilities + done + + + + + + 26.4.7.1 + Class seed_seq + + + missing + + + + 26.4.7.2 + Function template generate_cannonical + + + missing + + + + 26.4.8 + Random number generation class templates + done + + + + + + 26.4.8.1 + Uniform distributions + + + partial + + + + 26.4.8.1 + Class template uniform_int_distribution + + + missing + + + + 26.4.8.1 + Class template uniform_real_distribution + + + missing + + + + 26.4.8.2 + Bernoulli distributions + + + partial + + + + + 26.4.8.2.1 + Class bernoulli_distribution + done + + + + + + 26.4.8.2.2 + Class template binomial_distribution + done + + + + + + 26.4.8.2.3 + Class template geometric_distribution + done + + + + + + 26.4.8.2.4 + Class template negative_binomial_distribution + + + missing + + + + 26.4.8.3 + Poisson distributions + + + partial + + + + 26.4.8.3.1 + Class template poisson_distribution + done + + + + + + 26.4.8.3.2 + Class template exponential_distribution + done + + + + + + 26.4.8.3.3 + Class template gamma_distribution + done + + + + + + 26.4.8.3.4 + Class template weibull_distribution + + + missing + + + + 26.4.8.3.5 + Class template extreme_value_distribution + + + missing + + + + 26.4.8.4 + Normal distributions + + + partial + + + + 26.4.8.4.1 + Class template normal_distribution + done + + + + + + 26.4.8.4.2 + Class template lognormal_distribution + + + missing + + + + 26.4.8.4.3 + Class template chi_squared_distribution + + + missing + + + + 26.4.8.4.4 + Class template cauchy_distribution + + + missing + + + + 26.4.8.4.5 + Class template fisher_f_distribution + + + missing + + + + 26.4.8.4.6 + Class template student_t_distribution + + + missing + + + + 26.4.8.5 + Sampling distributions + + + missing + + + + 26.4.8.5.1 + Class template discrete_distribution + + + missing + + + + 26.4.8.5.1 + Class template piecewise_constant_distribution + + + missing + + + + 26.4.8.5.1 + Class template general_pdf_distribution + + + missing + + + + + 28 + Regular Expressions + + + 28.1 + Definitions + + + missing + + + + 28.2 + Requirements + + + missing + + + + 28.3 + Regular expressions summary + + + missing + + + + 28.4 + Header <regex> synopsis + + + missing + + + + 28.5 + Namespace tr1::regex_constants + + + missing + + + + 28.5.1 + Bitmask Type syntax_option_type + + + missing + + + + 28.5.2 + Bitmask Type regex_constants::match_flag_type + + + missing + + + + 28.5.3 + Implementation defined error_type + + + missing + + + + 28.6 + Class regex_error + + + missing + + + + 28.7 + Class template regex_traits + + + missing + + + + 28.8 + Class template basic_regex + + + missing + + + + 28.8.1 + basic_regex constants + + + missing + + + + 28.8.2 + basic_regex constructors + + + missing + + + + 28.8.3 + basic_regex assign + + + missing + + + + 28.8.4 + basic_regex constant operations + + + missing + + + + 28.8.5 + basic_regex locale + + + missing + + + + 28.8.6 + basic_regex swap + + + missing + + + + 28.8.7 + basic_regex non-member functions + + + missing + + + + 28.8.7.1 + basic_regex non-member swap + + + missing + + + + 28.9 + Class template sub_match + + + missing + + + + 28.9.1 + sub_match members + + + missing + + + + 28.9.2 + sub_match non-member operators + + + missing + + + + 28.10 + Class template match_results + + + missing + + + + 28.10.1 + match_results constructors + + + missing + + + + 28.10.2 + match_results size + + + missing + + + + 28.10.3 + match_results element access + + + missing + + + + 28.10.4 + match_results formatting + + + missing + + + + 28.10.5 + match_results allocator + + + missing + + + + 28.10.6 + match_results swap + + + missing + + + + 28.11 + Regular expression algorithms + + + missing + + + + 28.11.1 + exceptions + + + missing + + + + 28.11.2 + regex_match + + + missing + + + + 28.11.3 + regex_search + + + missing + + + + 28.11.4 + regex_replace + + + missing + + + + 28.12 + Regular expression Iterators + + + missing + + + + 28.12.1 + Class template regex_iterator + + + missing + + + + 28.12.1.1 + regex_iterator constructors + + + missing + + + + 28.12.1.2 + regex_iterator comparisons + + + missing + + + + 28.12.1.3 + regex_iterator dereference + + + missing + + + + 28.12.1.4 + regex_iterator increment + + + missing + + + + 28.12.2 + Class template regex_token_iterator + + + missing + + + + 28.12.2.1 + regex_token_iterator constructors + + + missing + + + + 28.12.2.2 + regex_token_iterator comparisons + + + missing + + + + 28.12.2.3 + regex_token_iterator dereference + + + missing + + + + 28.12.2.4 + regex_token_iterator increment + + + missing + + + + 28.13 + Modified ECMAScript regular expression grammar + + + missing + + + + C + C Compatibility + + + C2.1 + Additions to header <complex> + done + + + + + + C2.1.1 + Synopsis + done + + + + + + C2.1.2 + Function acos + done + + + + + + C2.1.3 + Function asin + done + + + + + + C2.1.4 + Function atan + done + + + + + + C2.1.5 + Function acosh + done + + + + + + C2.1.6 + Function asinh + done + + + + + + C2.1.7 + Function atanh + done + + + + + + C2.1.8 + Function fabs + done + + + + + + C2.1.9 + Additional Overloads + done + + + + + + C2.2 + Header <ccomplex> + + + missing + DR 551 + + + C2.3 + Header <complex.h> + + + missing + DR 551 + + + C2.4 + Additions to header <cctype> + done + + + + + + C2.4.1 + Synopsis + done + + + + + + C2.4.2 + Function isblank + done + + + + + + C2.5 + Additions to header <ctype.h> + done + + + + + + C2.6 + Header <cfenv> + done + + + + + + C2.6.1 + Synopsis + done + + + + + + C2.6.2 + Definitions + done + + + + + + C2.7 + Header <fenv.h> + done + + + + + + C2.8 + Additions to header <cfloat> + done + + + + + + C2.9 + Additions to header <float.h> + done + + + + + + C2.10 + Additions to header <ios> + + + missing + + + + C2.10.1 + Synopsis + + + missing + + + + C2.10.2 + Function hexfloat + + + missing + + + + C2.11 + Header <cinttypes> + done + + + + + + C2.11.1 + Synopsis + done + + + DR 557 + + + C2.11.2 + Definitions + done + + + + + + C2.12 + Header <inttypes.h> + done + + + + + + C2.13 + Additions to header <climits> + done + + + + + + C2.14 + Additions to header <limits.h> + done + + + + + + C2.15 + Additions to header <locale> + + + missing + + + + C2.16 + Additions to header <cmath> + done + + + + + + C2.16.1 + Synopsis + done + + + + + + C2.16.2 + Definitions + done + + + + + + C2.16.3 + Function template definitions + done + + + + + + C2.16.4 + Additional overloads + done + + + DR 568; DR 550 + + + C2.17 + Additions to header <math.h> + done + + + + + + C2.18 + Additions to header <cstdarg> + done + + + + + + C2.19 + Additions to header <stdarg.h> + done + + + + + + C2.20 + The header <cstdbool> + done + + + + + + C2.21 + The header <stdbool.h> + done + + + + + + C2.22 + The header <cstdint> + done + + + + + + C2.22.1 + Synopsis + done + + + + + + C2.22.2 + Definitions + done + + + + + + C2.23 + The header <stdint.h> + done + + + + + + C2.24 + Additions to header <cstdio> + done + + + + + + C2.24.1 + Synopsis + done + + + + + + C2.24.2 + Definitions + done + + + + + + C2.24.3 + Additional format specifiers + done + + + C library responsibility + + + C2.24.4 + Additions to header <stdio.h> + done + + + + + + C2.25 + Additions to header <cstdlib> + done + + + + + + C2.25.1 + Synopsis + done + + + + + + C2.25.2 + Definitions + done + + + + + + C2.25.3 + Function abs + done + + + + + + C2.25.4 + Function div + done + + + + + + C2.26 + Additions to header <stdlib.h> + done + + + + + + C2.27 + Header <ctgmath> + done + + + DR 551 + + + C2.28 + Header <tgmath.h> + done + + + DR 551 + + + C2.29 + Additions to header <ctime> + done + + + C library responsibility + + + C2.30 + Additions to header <cwchar> + done + + + + + + C2.30.1 + Synopsis + done + + + + + + C2.30.2 + Definitions + done + + + + + + C2.30.3 + Additional wide format specifiers + done + + + C library responsibility + + + C2.31 + Additions to header <wchar.h> + done + + + + + + C2.32 + Additions to header <cwctype> + done + + + + + + C2.32.1 + Synopsis + done + + + + + + C2.32.2 + Function iswblank + done + + + + + + C2.33 + Additions to header <wctype.h> + done + + + + + + D + Compatibility Features + + + D.6 + Old iostream members + done + + + + + + D.8 + Binders + done + + + 33911 + + + D.9 + Class template auto_ptr + done + + + 33911 + + + +
+ + +Footnotes + + + + The shared_ptr implementation uses some code from the + Boost + shared_ptr library. + + + \ No newline at end of file diff --git a/libstdc++-v3/doc/xml/manual/status_cxxtr1.xml b/libstdc++-v3/doc/xml/manual/status_cxxtr1.xml new file mode 100644 index 00000000000..092a78af458 --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/status_cxxtr1.xml @@ -0,0 +1,2273 @@ + + + + + + + ISO C++ + + + tr1 + + + + +C++ TR1 + + +This table is based on the table of contents of ISO/IEC DTR 19768 +Doc No: N1836=05-0096 Date: 2005-06-24 +Draft Technical Report on C++ Library Extensions + + + +In this implementation the header names are prefixed by +tr1/, for instance <tr1/functional>, +<tr1/memory>, and so on. + + + +This page describes the TR1 support in mainline GCC SVN, not in any particular +release. + + + +C++ TR1 Implementation Status + + + + + + + + + + + Section + Description + Done + Broken + Missing + Comments + + + + + 2 + General Utilities + + + 2.1 + Reference wrappers + done + + + + + + 2.1.1 + Additions to header <functional> synopsis + done + + + + + + 2.1.2 + Class template reference_wrapper + done + + + + + + 2.1.2.1 + reference_wrapper construct/copy/destroy + done + + + + + + 2.1.2.2 + reference_wrapper assignment + done + + + + + + 2.1.2.3 + reference_wrapper access + done + + + + + + 2.1.2.4 + reference_wrapper invocation + done + + + + + + 2.1.2.5 + reference_wrapper helper functions + done + + + + + + 2.2 + Smart pointers + done + + + + + + 2.2.1 + Additions to header <memory> synopsis + done + + + + + + 2.2.2 + Class bad_weak_ptr + done + + + + + + 2.2.3 + Class template shared_ptr + done + + + See Footnotes + + + 2.2.3.1 + shared_ptr constructors + done + + + + + + 2.2.3.2 + shared_ptr destructor + done + + + + + + 2.2.3.3 + shared_ptr assignment + done + + + + + + 2.2.3.4 + shared_ptr modifiers + done + + + + + + 2.2.3.5 + shared_ptr observers + done + + + + + + 2.2.3.6 + shared_ptr comparison + done + + + + + + 2.2.3.7 + shared_ptr I/O + done + + + + + + 2.2.3.8 + shared_ptr specialized algorithms + done + + + + + + 2.2.3.9 + shared_ptr casts + done + + + + + + 2.2.3.10 + get_deleter + done + + + + + + 2.2.4 + Class template weak_ptr + done + + + + + + 2.2.4.1 + weak_ptr constructors + done + + + + + + 2.2.4.2 + weak_ptr destructor + done + + + + + + 2.2.4.3 + weak_ptr assignment + done + + + + + + 2.2.4.4 + weak_ptr modifiers + done + + + + + + 2.2.4.5 + weak_ptr observers + done + + + + + + 2.2.4.6 + weak_ptr comparison + done + + + + + + 2.2.4.7 + weak_ptr specialized algorithms + done + + + + + + 2.2.5 + Class template enable_shared_from_this + done + + + + + + 3 + Function Objects + + + 3.1 + Definitions + done + + + + + + 3.2 + Additions to <functional> synopsis + done + + + + + + 3.3 + Requirements + done + + + + + + 3.4 + Function return types + done + + + + + + 3.5 + Function template mem_fn + done + + + + + + 3.6 + Function object binders + done + + + + + + 3.6.1 + Class template is_bind_expression + done + + + + + + 3.6.2 + Class template is_placeholder + done + + + + + + 3.6.3 + Function template bind + done + + + + + + 3.6.4 + Placeholders + done + + + + + + 3.7 + Polymorphic function wrappers + done + + + + + + 3.7.1 + Class bad_function_call + done + + + + + + 3.7.1.1 + bad_function_call constructor + done + + + + + + 3.7.2 + Class template function + done + + + + + + 3.7.2.1 + function construct/copy/destroy + done + + + + + + 3.7.2.2 + function modifiers + done + + + + + + 3.7.2.3 + function capacity + done + + + + + + 3.7.2.4 + function invocation + done + + + + + + 3.7.2.5 + function target access + done + + + + + + 3.7.2.6 + undefined operators + done + + + + + + 3.7.2.7 + null pointer comparison operators + done + + + + + + 3.7.2.8 + specialized algorithms + done + + + + + + 4 + Metaprogramming and type traits + + + 4.1 + Requirements + done + + + + + + 4.2 + Header <type_traits> synopsis + done + + + + + + 4.3 + Helper classes + done + + + + + + 4.4 + General Requirements + done + + + + + + 4.5 + Unary Type Traits + done + + + + + + 4.5.1 + Primary Type Categories + done + + + + + + 4.5.2 + Composite type traits + done + + + + + + 4.5.3 + Type properties + done + + + + + + 4.6 + Relationships between types + done + + + + + + 4.7 + Transformations between types + done + + + + + + 4.7.1 + Const-volatile modifications + done + + + + + + 4.7.2 + Reference modifications + done + + + + + + 4.7.3 + Array modifications + done + + + + + + 4.7.4 + Pointer modifications + done + + + + + + 4.8 + Other transformations + done + + + + + + 4.9 + Implementation requirements + done + + + + + + 5 + Numerical Facilities + + + 5.1 + Random number generation + done + + + + + + 5.1.1 + Requirements + done + + + + + + 5.1.2 + Header <random> synopsis + done + + + + + + 5.1.3 + Class template variate_generator + done + + + + + + 5.1.4 + Random number engine class templates + done + + + + + + 5.1.4.1 + Class template linear_congruential + done + + + + + + 5.1.4.2 + Class template mersenne_twister + done + + + + + + 5.1.4.3 + Class template subtract_with_carry + done + + + + + + 5.1.4.4 + Class template subtract_with_carry_01 + done + + + + + + 5.1.4.5 + Class template discard_block + done + + + + + + 5.1.4.6 + Class template xor_combine + done + + + operator()() per N2079 + + + 5.1.5 + Engines with predefined parameters + done + + + + + + 5.1.6 + Class random_device + done + + + + + + 5.1.7 + Random distribution class templates + done + + + + + + 5.1.7.1 + Class template uniform_int + done + + + + + + 5.1.7.2 + Class bernoulli_distribution + done + + + + + + 5.1.7.3 + Class template geometric_distribution + done + + + + + + 5.1.7.4 + Class template poisson_distribution + done + + + + + + 5.1.7.5 + Class template binomial_distribution + done + + + + + + 5.1.7.6 + Class template uniform_real + done + + + + + + 5.1.7.7 + Class template exponential_distribution + done + + + + + + 5.1.7.8 + Class template normal_distribution + done + + + + + + 5.1.7.9 + Class template gamma_distribution + done + + + + + + 5.2 + Mathematical special functions + done + + + + + + 5.2.1 + Additions to header <cmath> synopsis + done + + + + + + 5.2.1.1 + associated Laguerre polynomials + done + + + + + + 5.2.1.2 + associated Legendre functions + done + + + + + + 5.2.1.3 + beta function + done + + + + + + 5.2.1.4 + (complete) elliptic integral of the first kind + done + + + + + + 5.2.1.5 + (complete) elliptic integral of the second kind + done + + + + + + 5.2.1.6 + (complete) elliptic integral of the third kind + done + + + + + + 5.2.1.7 + confluent hypergeometric functions + done + + + + + + 5.2.1.8 + regular modified cylindrical Bessel functions + done + + + + + + 5.2.1.9 + cylindrical Bessel functions (of the first kind) + done + + + + + + 5.2.1.10 + irregular modified cylindrical Bessel functions + done + + + + + + 5.2.1.11 + cylindrical Neumann functions + done + + + + + + 5.2.1.12 + (incomplete) elliptic integral of the first kind + done + + + + + + 5.2.1.13 + (incomplete) elliptic integral of the second kind + done + + + + + + 5.2.1.14 + (incomplete) elliptic integral of the third kind + done + + + + + + 5.2.1.15 + exponential integral + done + + + + + + 5.2.1.16 + Hermite polynomials + done + + + + + + 5.2.1.17 + hypergeometric functions + done + + + + + + 5.2.1.18 + Laguerre polynomials + done + + + + + + 5.2.1.19 + Legendre polynomials + done + + + + + + 5.2.1.20 + Riemann zeta function + done + + + + + + 5.2.1.21 + spherical Bessel functions (of the first kind) + done + + + + + + 5.2.1.22 + spherical associated Legendre functions + done + + + + + + 5.2.1.23 + spherical Neumann functions + done + + + + + + 5.2.2 + Additions to header <math.h> synopsis + done + + + + + + 6 + Containers + + + 6.1 + Tuple types + done + + + + + + 6.1.1 + Header <tuple> synopsis + done + + + + + + 6.1.2 + Additions to header <utility> synopsis + done + + + + + + 6.1.3 + Class template tuple + done + + + + + + 6.1.3.1 + Construction + done + + + + + + 6.1.3.2 + Tuple creation functions + done + + + + + + 6.1.3.3 + Tuple helper classes + done + + + + + + 6.1.3.4 + Element access + done + + + + + + 6.1.3.5 + Relational operators + done + + + + + + 6.1.4 + Pairs + done + + + + + + 6.2 + Fixed size array + done + + + + + + 6.2.1 + Header <array> synopsis + done + + + + + + 6.2.2 + Class template array + done + + + + + + 6.2.2.1 + array constructors, copy, and assignment + done + + + + + + 6.2.2.2 + array specialized algorithms + done + + + + + + 6.2.2.3 + array size + done + + + + + + 6.2.2.4 + Zero sized arrays + done + + + + + + 6.2.2.5 + Tuple interface to class template array + done + + + + + + 6.3 + Unordered associative containers + done + + + + + + 6.3.1 + Unordered associative container requirements + done + + + + + + 6.3.1.1 + Exception safety guarantees + done + + + + + + 6.3.2 + Additions to header <functional> synopsis + done + + + + + + 6.3.3 + Class template hash + done + + + + + + 6.3.4 + Unordered associative container classes + done + + + + + + 6.3.4.1 + Header <unordered_set> synopsis + done + + + + + + 6.3.4.2 + Header <unordered_map> synopsis + done + + + + + + 6.3.4.3 + Class template unordered_set + done + + + + + + 6.3.4.3.1 + unordered_set constructors + done + + + + + + 6.3.4.3.2 + unordered_set swap + done + + + + + + 6.3.4.4 + Class template unordered_map + done + + + + + + 6.3.4.4.1 + unordered_map constructors + done + + + + + + 6.3.4.4.2 + unordered_map element access + done + + + + + + 6.3.4.4.3 + unordered_map swap + done + + + + + + 6.3.4.5 + Class template unordered_multiset + done + + + + + + 6.3.4.5.1 + unordered_multiset constructors + done + + + + + + 6.3.4.5.2 + unordered_multiset swap + done + + + + + + 6.3.4.6 + Class template unordered_multimap + done + + + + + + 6.3.4.6.1 + unordered_multimap constructors + done + + + + + + 6.3.4.6.2 + unordered_multimap swap + done + + + + + + 7 + Regular Expressions + + + 7.1 + Definitions + + + missing + + + + 7.2 + Requirements + + + missing + + + + 7.3 + Regular expressions summary + + + missing + + + + 7.4 + Header <regex> synopsis + + + missing + + + + 7.5 + Namespace tr1::regex_constants + + + missing + + + + 7.5.1 + Bitmask Type syntax_option_type + + + missing + + + + 7.5.2 + Bitmask Type regex_constants::match_flag_type + + + missing + + + + 7.5.3 + Implementation defined error_type + + + missing + + + + 7.6 + Class regex_error + + + missing + + + + 7.7 + Class template regex_traits + + + missing + + + + 7.8 + Class template basic_regex + + + missing + + + + 7.8.1 + basic_regex constants + + + missing + + + + 7.8.2 + basic_regex constructors + + + missing + + + + 7.8.3 + basic_regex assign + + + missing + + + + 7.8.4 + basic_regex constant operations + + + missing + + + + 7.8.5 + basic_regex locale + + + missing + + + + 7.8.6 + basic_regex swap + + + missing + + + + 7.8.7 + basic_regex non-member functions + + + missing + + + + 7.8.7.1 + basic_regex non-member swap + + + missing + + + + 7.9 + Class template sub_match + + + missing + + + + 7.9.1 + sub_match members + + + missing + + + + 7.9.2 + sub_match non-member operators + + + missing + + + + 7.10 + Class template match_results + + + missing + + + + 7.10.1 + match_results constructors + + + missing + + + + 7.10.2 + match_results size + + + missing + + + + 7.10.3 + match_results element access + + + missing + + + + 7.10.4 + match_results formatting + + + missing + + + + 7.10.5 + match_results allocator + + + missing + + + + 7.10.6 + match_results swap + + + missing + + + + 7.11 + Regular expression algorithms + + + missing + + + + 7.11.1 + exceptions + + + missing + + + + 7.11.2 + regex_match + + + missing + + + + 7.11.3 + regex_search + + + missing + + + + 7.11.4 + regex_replace + + + missing + + + + 7.12 + Regular expression Iterators + + + missing + + + + 7.12.1 + Class template regex_iterator + + + missing + + + + 7.12.1.1 + regex_iterator constructors + + + missing + + + + 7.12.1.2 + regex_iterator comparisons + + + missing + + + + 7.12.1.3 + regex_iterator dereference + + + missing + + + + 7.12.1.4 + regex_iterator increment + + + missing + + + + 7.12.2 + Class template regex_token_iterator + + + missing + + + + 7.12.2.1 + regex_token_iterator constructors + + + missing + + + + 7.12.2.2 + regex_token_iterator comparisons + + + missing + + + + 7.12.2.3 + regex_token_iterator dereference + + + missing + + + + 7.12.2.4 + regex_token_iterator increment + + + missing + + + + 7.13 + Modified ECMAScript regular expression grammar + + + missing + + + + 8 + C Compatibility + + + 8.1 + Additions to header <complex> + done + + + + + + 8.1.1 + Synopsis + done + + + + + + 8.1.2 + Function acos + done + + + + + + 8.1.3 + Function asin + done + + + + + + 8.1.4 + Function atan + done + + + + + + 8.1.5 + Function acosh + done + + + + + + 8.1.6 + Function asinh + done + + + + + + 8.1.7 + Function atanh + done + + + + + + 8.1.8 + Function fabs + done + + + + + + 8.1.9 + Additional Overloads + done + + + + + + 8.2 + Header <ccomplex> + + + missing + DR 551 + + + 8.3 + Header <complex.h> + + + missing + DR 551 + + + 8.4 + Additions to header <cctype> + done + + + + + + 8.4.1 + Synopsis + done + + + + + + 8.4.2 + Function isblank + done + + + + + + 8.5 + Additions to header <ctype.h> + done + + + + + + 8.6 + Header <cfenv> + done + + + + + + 8.6.1 + Synopsis + done + + + + + + 8.6.2 + Definitions + done + + + + + + 8.7 + Header <fenv.h> + done + + + + + + 8.8 + Additions to header <cfloat> + done + + + + + + 8.9 + Additions to header <float.h> + done + + + + + + 8.10 + Additions to header <ios> + + + missing + + + + 8.10.1 + Synopsis + + + missing + + + + 8.10.2 + Function hexfloat + + + missing + + + + 8.11 + Header <cinttypes> + done + + + + + + 8.11.1 + Synopsis + done + + + DR 557 + + + 8.11.2 + Definitions + done + + + + + + 8.12 + Header <inttypes.h> + done + + + + + + 8.13 + Additions to header <climits> + done + + + + + + 8.14 + Additions to header <limits.h> + done + + + + + + 8.15 + Additions to header <locale> + + + missing + + + + 8.16 + Additions to header <cmath> + done + + + + + + 8.16.1 + Synopsis + done + + + + + + 8.16.2 + Definitions + done + + + + + + 8.16.3 + Function template definitions + done + + + + + + 8.16.4 + Additional overloads + done + + + DR 568; DR 550 + + + 8.17 + Additions to header <math.h> + done + + + + + + 8.18 + Additions to header <cstdarg> + done + + + + + + 8.19 + Additions to header <stdarg.h> + done + + + + + + 8.20 + The header <cstdbool> + done + + + + + + 8.21 + The header <stdbool.h> + done + + + + + + 8.22 + The header <cstdint> + done + + + + + + 8.22.1 + Synopsis + done + + + + + + 8.22.2 + Definitions + done + + + + + + 8.23 + The header <stdint.h> + done + + + + + + 8.24 + Additions to header <cstdio> + done + + + + + + 8.24.1 + Synopsis + done + + + + + + 8.24.2 + Definitions + done + + + + + + 8.24.3 + Additional format specifiers + done + + + C library responsibility + + + 8.24.4 + Additions to header <stdio.h> + done + + + + + + 8.25 + Additions to header <cstdlib> + done + + + + + + 8.25.1 + Synopsis + done + + + + + + 8.25.2 + Definitions + done + + + + + + 8.25.3 + Function abs + done + + + + + + 8.25.4 + Function div + done + + + + + + 8.26 + Additions to header <stdlib.h> + done + + + + + + 8.27 + Header <ctgmath> + done + + + DR 551 + + + 8.28 + Header <tgmath.h> + done + + + DR 551 + + + 8.29 + Additions to header <ctime> + done + + + C library responsibility + + + 8.30 + Additions to header <cwchar> + done + + + + + + 8.30.1 + Synopsis + done + + + + + + 8.30.2 + Definitions + done + + + + + + 8.30.3 + Additional wide format specifiers + done + + + C library responsibility + + + 8.31 + Additions to header <wchar.h> + done + + + + + + 8.32 + Additions to header <cwctype> + done + + + + + + 8.32.1 + Synopsis + done + + + + + + 8.32.2 + Function iswblank + done + + + + + + 8.33 + Additions to header <wctype.h> + done + + + + + + +
+ + +Footnotes + + + + The shared_ptr implementation uses some code from the + Boost + shared_ptr library. + + + \ No newline at end of file diff --git a/libstdc++-v3/doc/xml/manual/strings.xml b/libstdc++-v3/doc/xml/manual/strings.xml new file mode 100644 index 00000000000..d8f2035cb6d --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/strings.xml @@ -0,0 +1,495 @@ + + + + + + + + + + ISO C++ + + + library + + + + +Strings + + + + + + String Classes + + + Simple Transformations + + Here are Standard, simple, and portable ways to perform common + transformations on a string instance, such as + "convert to all upper case." The word transformations + is especially apt, because the standard template function + transform<> is used. + + + This code will go through some iterations. Here's a simiple + version: + + + #include <string> + #include <algorithm> + #include <cctype> // old <ctype.h> + + struct ToLower + { + char operator() (char c) const { return std::tolower(c); } + }; + + struct ToUpper + { + char operator() (char c) const { return std::toupper(c); } + }; + + int main() + { + std::string s ("Some Kind Of Initial Input Goes Here"); + + // Change everything into upper case + std::transform (s.begin(), s.end(), s.begin(), ToUpper()); + + // Change everything into lower case + std::transform (s.begin(), s.end(), s.begin(), ToLower()); + + // Change everything back into upper case, but store the + // result in a different string + std::string capital_s; + capital_s.resize(s.size()); + std::transform (s.begin(), s.end(), capital_s.begin(), ToUpper()); + } + + + Note that these calls all + involve the global C locale through the use of the C functions + toupper/tolower. This is absolutely guaranteed to work -- + but only if the string contains only characters + from the basic source character set, and there are only + 96 of those. Which means that not even all English text can be + represented (certain British spellings, proper names, and so forth). + So, if all your input forevermore consists of only those 96 + characters (hahahahahaha), then you're done. + + Note that the + ToUpper and ToLower function objects + are needed because toupper and tolower + are overloaded names (declared in <cctype> and + <locale>) so the template-arguments for + transform<> cannot be deduced, as explained in + this + message. + + At minimum, you can write short wrappers like + + + char toLower (char c) + { + return std::tolower(c); + } + The correct method is to use a facet for a particular locale + and call its conversion functions. These are discussed more in + Chapter 22; the specific part is + Correct Transformations, + which shows the final version of this code. (Thanks to James Kanze + for assistance and suggestions on all of this.) + + Another common operation is trimming off excess whitespace. Much + like transformations, this task is trivial with the use of string's + find family. These examples are broken into multiple + statements for readability: + + + std::string str (" \t blah blah blah \n "); + + // trim leading whitespace + string::size_type notwhite = str.find_first_not_of(" \t\n"); + str.erase(0,notwhite); + + // trim trailing whitespace + notwhite = str.find_last_not_of(" \t\n"); + str.erase(notwhite+1); + Obviously, the calls to find could be inserted directly + into the calls to erase, in case your compiler does not + optimize named temporaries out of existence. + + + + + Case Sensivitity + + + + The well-known-and-if-it-isn't-well-known-it-ought-to-be + Guru of the Week + discussions held on Usenet covered this topic in January of 1998. + Briefly, the challenge was, write a 'ci_string' class which + is identical to the standard 'string' class, but is + case-insensitive in the same way as the (common but nonstandard) + C function stricmp(). + + + ci_string s( "AbCdE" ); + + // case insensitive + assert( s == "abcde" ); + assert( s == "ABCDE" ); + + // still case-preserving, of course + assert( strcmp( s.c_str(), "AbCdE" ) == 0 ); + assert( strcmp( s.c_str(), "abcde" ) != 0 ); + + The solution is surprisingly easy. The original answer was + posted on Usenet, and a revised version appears in Herb Sutter's + book Exceptional C++ and on his website as GotW 29. + + See? Told you it was easy! + + Added June 2000: The May 2000 issue of C++ + Report contains a fascinating article by + Matt Austern (yes, the Matt Austern) on why + case-insensitive comparisons are not as easy as they seem, and + why creating a class is the wrong way to go + about it in production code. (The GotW answer mentions one of + the principle difficulties; his article mentions more.) + + Basically, this is "easy" only if you ignore some things, + things which may be too important to your program to ignore. (I chose + to ignore them when originally writing this entry, and am surprised + that nobody ever called me on it...) The GotW question and answer + remain useful instructional tools, however. + + Added September 2000: James Kanze provided a link to a + Unicode + Technical Report discussing case handling, which provides some + very good information. + + + + + Arbitrary Character Types + + + + The std::basic_string is tantalizingly general, in that + it is parameterized on the type of the characters which it holds. + In theory, you could whip up a Unicode character class and instantiate + std::basic_string<my_unicode_char>, or assuming + that integers are wider than characters on your platform, maybe just + declare variables of type std::basic_string<int>. + + That's the theory. Remember however that basic_string has additional + type parameters, which take default arguments based on the character + type (called CharT here): + + + template <typename CharT, + typename Traits = char_traits<CharT>, + typename Alloc = allocator<CharT> > + class basic_string { .... }; + Now, allocator<CharT> will probably Do The Right + Thing by default, unless you need to implement your own allocator + for your characters. + + But char_traits takes more work. The char_traits + template is declared but not defined. + That means there is only + + + template <typename CharT> + struct char_traits + { + static void foo (type1 x, type2 y); + ... + }; + and functions such as char_traits<CharT>::foo() are not + actually defined anywhere for the general case. The C++ standard + permits this, because writing such a definition to fit all possible + CharT's cannot be done. + + The C++ standard also requires that char_traits be specialized for + instantiations of char and wchar_t, and it + is these template specializations that permit entities like + basic_string<char,char_traits<char>> to work. + + If you want to use character types other than char and wchar_t, + such as unsigned char and int, you will + need suitable specializations for them. For a time, in earlier + versions of GCC, there was a mostly-correct implementation that + let programmers be lazy but it broke under many situations, so it + was removed. GCC 3.4 introduced a new implementation that mostly + works and can be specialized even for int and other + built-in types. + + If you want to use your own special character class, then you have + a lot + of work to do, especially if you with to use i18n features + (facets require traits information but don't have a traits argument). + + Another example of how to specialize char_traits was given on the + mailing list and at a later date was put into the file + include/ext/pod_char_traits.h. We agree + that the way it's used with basic_string (scroll down to main()) + doesn't look nice, but that's because the + nice-looking first attempt turned out to not + be conforming C++, due to the rule that CharT must be a POD. + (See how tricky this is?) + + + + + + Tokenizing + + + The Standard C (and C++) function strtok() leaves a lot to + be desired in terms of user-friendliness. It's unintuitive, it + destroys the character string on which it operates, and it requires + you to handle all the memory problems. But it does let the client + code decide what to use to break the string into pieces; it allows + you to choose the "whitespace," so to speak. + + A C++ implementation lets us keep the good things and fix those + annoyances. The implementation here is more intuitive (you only + call it once, not in a loop with varying argument), it does not + affect the original string at all, and all the memory allocation + is handled for you. + + It's called stringtok, and it's a template function. Sources are + as below, in a less-portable form than it could be, to keep this + example simple (for example, see the comments on what kind of + string it will accept). + + + +#include <string> +template <typename Container> +void +stringtok(Container &container, string const &in, + const char * const delimiters = " \t\n") +{ + const string::size_type len = in.length(); + string::size_type i = 0; + + while (i < len) + { + // Eat leading whitespace + i = in.find_first_not_of(delimiters, i); + if (i == string::npos) + return; // Nothing left but white space + + // Find the end of the token + string::size_type j = in.find_first_of(delimiters, i); + + // Push token + if (j == string::npos) + { + container.push_back(in.substr(i)); + return; + } + else + container.push_back(in.substr(i, j-i)); + + // Set up for next loop + i = j + 1; + } +} + + + + + The author uses a more general (but less readable) form of it for + parsing command strings and the like. If you compiled and ran this + code using it: + + + + + std::list<string> ls; + stringtok (ls, " this \t is\t\n a test "); + for (std::list<string>const_iterator i = ls.begin(); + i != ls.end(); ++i) + { + std::cerr << ':' << (*i) << ":\n"; + } + You would see this as output: + + + :this: + :is: + :a: + :test: + with all the whitespace removed. The original s is still + available for use, ls will clean up after itself, and + ls.size() will return how many tokens there were. + + As always, there is a price paid here, in that stringtok is not + as fast as strtok. The other benefits usually outweigh that, however. + Another version of stringtok is given + here, suggested by Chris King and tweaked by Petr Prikryl, + and this one uses the + transformation functions mentioned below. If you are comfortable + with reading the new function names, this version is recommended + as an example. + + Added February 2001: Mark Wilden pointed out that the + standard std::getline() function can be used with standard + istringstreams to perform + tokenizing as well. Build an istringstream from the input text, + and then use std::getline with varying delimiters (the three-argument + signature) to extract tokens into a string. + + + + + + Shrink to Fit + + + From GCC 3.4 calling s.reserve(res) on a + string s with res < s.capacity() will + reduce the string's capacity to std::max(s.size(), res). + + This behaviour is suggested, but not required by the standard. Prior + to GCC 3.4 the following alternative can be used instead + + + std::string(str.data(), str.size()).swap(str); + + This is similar to the idiom for reducing a vector's + memory usage (see FAQ 5.9) but + the regular copy constructor cannot be used because libstdc++'s + string is Copy-On-Write. + + + + + + + CString (MFC) + + + + A common lament seen in various newsgroups deals with the Standard + string class as opposed to the Microsoft Foundation Class called + CString. Often programmers realize that a standard portable + answer is better than a proprietary nonportable one, but in porting + their application from a Win32 platform, they discover that they + are relying on special functions offered by the CString class. + + Things are not as bad as they seem. In + this + message, Joe Buck points out a few very important things: + + + The Standard string supports all the operations + that CString does, with three exceptions. + + Two of those exceptions (whitespace trimming and case + conversion) are trivial to implement. In fact, we do so + on this page. + + The third is CString::Format, which allows formatting + in the style of sprintf. This deserves some mention: + + + + The old libg++ library had a function called form(), which did much + the same thing. But for a Standard solution, you should use the + stringstream classes. These are the bridge between the iostream + hierarchy and the string class, and they operate with regular + streams seamlessly because they inherit from the iostream + hierarchy. An quick example: + + + #include <iostream> + #include <string> + #include <sstream> + + string f (string& incoming) // incoming is "foo N" + { + istringstream incoming_stream(incoming); + string the_word; + int the_number; + + incoming_stream >> the_word // extract "foo" + >> the_number; // extract N + + ostringstream output_stream; + output_stream << "The word was " << the_word + << " and 3*N was " << (3*the_number); + + return output_stream.str(); + } + A serious problem with CString is a design bug in its memory + allocation. Specifically, quoting from that same message: + + + CString suffers from a common programming error that results in + poor performance. Consider the following code: + + CString n_copies_of (const CString& foo, unsigned n) + { + CString tmp; + for (unsigned i = 0; i < n; i++) + tmp += foo; + return tmp; + } + + This function is O(n^2), not O(n). The reason is that each += + causes a reallocation and copy of the existing string. Microsoft + applications are full of this kind of thing (quadratic performance + on tasks that can be done in linear time) -- on the other hand, + we should be thankful, as it's created such a big market for high-end + ix86 hardware. :-) + + If you replace CString with string in the above function, the + performance is O(n). + + Joe Buck also pointed out some other things to keep in mind when + comparing CString and the Standard string class: + + + CString permits access to its internal representation; coders + who exploited that may have problems moving to string. + + Microsoft ships the source to CString (in the files + MFC\SRC\Str{core,ex}.cpp), so you could fix the allocation + bug and rebuild your MFC libraries. + Note: It looks like the CString shipped + with VC++6.0 has fixed this, although it may in fact have been + one of the VC++ SPs that did it. + + string operations like this have O(n) complexity + if the implementors do it correctly. The libstdc++ + implementors did it correctly. Other vendors might not. + + While parts of the SGI STL are used in libstdc++, their + string class is not. The SGI string is essentially + vector<char> and does not do any reference + counting like libstdc++'s does. (It is O(n), though.) + So if you're thinking about SGI's string or rope classes, + you're now looking at four possibilities: CString, the + libstdc++ string, the SGI string, and the SGI rope, and this + is all before any allocator or traits customizations! (More + choices than you can shake a stick at -- want fries with that?) + + + + + + + + + diff --git a/libstdc++-v3/doc/xml/manual/support.xml b/libstdc++-v3/doc/xml/manual/support.xml new file mode 100644 index 00000000000..55169590028 --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/support.xml @@ -0,0 +1,448 @@ + + + + + + + + + + ISO C++ + + + library + + + + +Support + + + + + This part deals with the functions called and objects created + automatically during the course of a program's existence. + + + + While we can't reproduce the contents of the Standard here (you + need to get your own copy from your nation's member body; see our + homepage for help), we can mention a couple of changes in what + kind of support a C++ program gets from the Standard Library. + + + + + Types + + Fundamental Types + + C++ has the following builtin types: + + + + char + + + signed char + + + unsigned char + + + signed short + + + signed int + + + signed long + + + unsigned short + + + unsigned int + + + unsigned long + + + bool + + + wchar_t + + + float + + + double + + + long double + + + + + These fundamental types are always available, without having to + include a header file. These types are exactly the same in + either C++ or in C. + + + + Specializing parts of the library on these types is prohibited: + instead, use a POD. + + + + + Numeric Properties + + + + The header limits defines + traits classes to give access to various implementation + defined-aspects of the fundamental types. The traits classes -- + fourteen in total -- are all specializations of the template class + numeric_limits, documented here + and defined as follows: + + + + template<typename T> + struct class + { + static const bool is_specialized; + static T max() throw(); + static T min() throw(); + + static const int digits; + static const int digits10; + static const bool is_signed; + static const bool is_integer; + static const bool is_exact; + static const int radix; + static T epsilon() throw(); + static T round_error() throw(); + + static const int min_exponent; + static const int min_exponent10; + static const int max_exponent; + static const int max_exponent10; + + static const bool has_infinity; + static const bool has_quiet_NaN; + static const bool has_signaling_NaN; + static const float_denorm_style has_denorm; + static const bool has_denorm_loss; + static T infinity() throw(); + static T quiet_NaN() throw(); + static T denorm_min() throw(); + + static const bool is_iec559; + static const bool is_bounded; + static const bool is_modulo; + + static const bool traps; + static const bool tinyness_before; + static const float_round_style round_style; + }; + + + + + NULL + + The only change that might affect people is the type of + NULL: while it is required to be a macro, + the definition of that macro is not allowed + to be (void*)0, which is often used in C. + + + + For g++, NULL is + #define'd to be + __null, a magic keyword extension of + g++. + + + + The biggest problem of #defining NULL to be + something like 0L is that the compiler will view + that as a long integer before it views it as a pointer, so + overloading won't do what you expect. (This is why + g++ has a magic extension, so that + NULL is always a pointer.) + + + In his book Effective + C++, Scott Meyers points out that the best way + to solve this problem is to not overload on pointer-vs-integer + types to begin with. He also offers a way to make your own magic + NULL that will match pointers before it + matches integers. + + See + the + Effective C++ CD example + + + + + + + Dynamic Memory + + There are six flavors each of new and + delete, so make certain that you're using the right + ones. Here are quickie descriptions of new: + + + + single object form, throwing a + bad_alloc on errors; this is what most + people are used to using + + + Single object "nothrow" form, returning NULL on errors + + + Array new, throwing + bad_alloc on errors + + + Array nothrow new, returning + NULL on errors + + + Placement new, which does nothing (like + it's supposed to) + + + Placement array new, which also does + nothing + + + + They are distinguished by the parameters that you pass to them, like + any other overloaded function. The six flavors of delete + are distinguished the same way, but none of them are allowed to throw + an exception under any circumstances anyhow. (They match up for + completeness' sake.) + + + Remember that it is perfectly okay to call delete on a + NULL pointer! Nothing happens, by definition. That is not the + same thing as deleting a pointer twice. + + + By default, if one of the throwing news can't + allocate the memory requested, it tosses an instance of a + bad_alloc exception (or, technically, some class derived + from it). You can change this by writing your own function (called a + new-handler) and then registering it with set_new_handler(): + + + typedef void (*PFV)(void); + + static char* safety; + static PFV old_handler; + + void my_new_handler () + { + delete[] safety; + popup_window ("Dude, you are running low on heap memory. You + should, like, close some windows, or something. + The next time you run out, we're gonna burn!"); + set_new_handler (old_handler); + return; + } + + int main () + { + safety = new char[500000]; + old_handler = set_new_handler (&my_new_handler); + ... + } + + + bad_alloc is derived from the base exception + class defined in Chapter 19. + + + + + Termination + + Termination Handlers + + Not many changes here to cstdlib. You should note that the + abort() function does not call the + destructors of automatic nor static objects, so if you're + depending on those to do cleanup, it isn't going to happen. + (The functions registered with atexit() + don't get called either, so you can forget about that + possibility, too.) + + + The good old exit() function can be a bit + funky, too, until you look closer. Basically, three points to + remember are: + + + + + Static objects are destroyed in reverse order of their creation. + + + + + Functions registered with atexit() are called in + reverse order of registration, once per registration call. + (This isn't actually new.) + + + + + The previous two actions are interleaved, that is, + given this pseudocode: + + + extern "C or C++" void f1 (void); + extern "C or C++" void f2 (void); + + static Thing obj1; + atexit(f1); + static Thing obj2; + atexit(f2); + + + then at a call of exit(), + f2 will be called, then + obj2 will be destroyed, then + f1 will be called, and finally + obj1 will be destroyed. If + f1 or f2 allow an + exception to propagate out of them, Bad Things happen. + + + + + Note also that atexit() is only required to store 32 + functions, and the compiler/library might already be using some of + those slots. If you think you may run out, we recommend using + the xatexit/xexit combination from libiberty, which has no such limit. + + + + + Verbose Terminate Handler + + If you are having difficulty with uncaught exceptions and want a + little bit of help debugging the causes of the core dumps, you can + make use of a GNU extension, the verbose terminate handler. + + + +#include <exception> + +int main() +{ + std::set_terminate(__gnu_cxx::__verbose_terminate_handler); + ... + + throw anything; +} + + + + The __verbose_terminate_handler function + obtains the name of the current exception, attempts to demangle + it, and prints it to stderr. If the exception is derived from + exception then the output from + what() will be included. + + + + Any replacement termination function is required to kill the + program without returning; this one calls abort. + + + + For example: + + + +#include <exception> +#include <stdexcept> + +struct argument_error : public std::runtime_error +{ + argument_error(const std::string& s): std::runtime_error(s) { } +}; + +int main(int argc) +{ + std::set_terminate(__gnu_cxx::__verbose_terminate_handler); + if (argc > 5) + throw argument_error(argc is greater than 5!); + else + throw argc; +} + + + + With the verbose terminate handler active, this gives: + + + + + % ./a.out + terminate called after throwing a `int' + Aborted + % ./a.out f f f f f f f f f f f + terminate called after throwing an instance of `argument_error' + what(): argc is greater than 5! + Aborted + + + + + The 'Aborted' line comes from the call to + abort(), of course. + + + + This is the default termination handler; nothing need be done to + use it. To go back to the previous silent death + method, simply include exception and + cstdlib, and call + + + + std::set_terminate(std::abort); + + + + After this, all calls to terminate will use + abort as the terminate handler. + + + + Note: the verbose terminate handler will attempt to write to + stderr. If your application closes stderr or redirects it to an + inappropriate location, + __verbose_terminate_handler will behave in + an unspecified manner. + + + + + + diff --git a/libstdc++-v3/doc/xml/manual/test.xml b/libstdc++-v3/doc/xml/manual/test.xml new file mode 100644 index 00000000000..076138d10da --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/test.xml @@ -0,0 +1,823 @@ + + + + + + + ISO C++ + + + test + + + testsuite + + + + +Test + + +Organization + + The directory libsrcdir/testsuite contains the + individual test cases organized in sub-directories corresponding to + chapters of the C++ standard (detailed below), the dejagnu test + harness support files, and sources to various testsuite utilities + that are packaged in a separate testing library. + + + + All test cases for functionality required by the runtime components + of the C++ standard (ISO 14882) are files within the following + directories. + + + +17_intro +18_support +19_diagnostics +20_util +21_strings +22_locale +23_containers +25_algorithms +26_numerics +27_io + + + + In addition, the following directories include test files: + + + +tr1 Tests for components as described by the Technical Report on Standard Library Extensions (TR1). +backward Tests for backwards compatibility and deprecated features. +demangle Tests for __cxa_demangle, the IA 64 C++ ABI demangler +ext Tests for extensions. +performance Tests for performance analysis, and performance regressions. +thread Tests for threads. + + + + Some directories don't have test files, but instead contain + auxiliary information (more information): + + + +config Files for the dejagnu test harness. +lib Files for the dejagnu test harness. +libstdc++* Files for the dejagnu test harness. +data Sample text files for testing input and output. +util Files for libtestc++, utilities and testing routines. + + + + Within a directory that includes test files, there may be + additional subdirectories, or files. Originally, test cases + were appended to one file that represented a particular section + of the chapter under test, and was named accordingly. For + instance, to test items related to 21.3.6.1 - + basic_string::find [lib.string::find] in the standard, + the following was used: + + +21_strings/find.cc + + + However, that practice soon became a liability as the test cases + became huge and unwieldy, and testing new or extended + functionality (like wide characters or named locales) became + frustrating, leading to aggressive pruning of test cases on some + platforms that covered up implementation errors. Now, the test + suite has a policy of one file, one test case, which solves the + above issues and gives finer grained results and more manageable + error debugging. As an example, the test case quoted above + becomes: + + +21_strings/basic_string/find/char/1.cc +21_strings/basic_string/find/char/2.cc +21_strings/basic_string/find/char/3.cc +21_strings/basic_string/find/wchar_t/1.cc +21_strings/basic_string/find/wchar_t/2.cc +21_strings/basic_string/find/wchar_t/3.cc + + + + All new tests should be written with the policy of one test + case, one file in mind. + + + + + +Naming Conventions + + + + + In addition, there are some special names and suffixes that are + used within the testsuite to designate particular kinds of + tests. + + + + + + _xin.cc + + + This test case expects some kind of interactive input in order + to finish or pass. At the moment, the interactive tests are not + run by default. Instead, they are run by hand, like: + + +g++ 27_io/objects/char/3_xin.cc +cat 27_io/objects/char/3_xin.in | a.out + + + + + .in + + + This file contains the expected input for the corresponding + _xin.cc test case. + + + + + _neg.cc + + + This test case is expected to fail: it's a negative test. At the + moment, these are almost always compile time errors. + + + + + char + + + This can either be a directory name or part of a longer file + name, and indicates that this file, or the files within this + directory are testing the char instantiation of a + template. + + + + + wchar_t + + + This can either be a directory name or part of a longer file + name, and indicates that this file, or the files within this + directory are testing the wchar_t instantiation of + a template. Some hosts do not support wchar_t + functionality, so for these targets, all of these tests will not + be run. + + + + + thread + + + This can either be a directory name or part of a longer file + name, and indicates that this file, or the files within this + directory are testing situations where multiple threads are + being used. + + + + + performance + + + This can either be an enclosing directory name or part of a + specific file name. This indicates a test that is used to + analyze runtime performance, for performance regression testing, + or for other optimization related analysis. At the moment, these + test cases are not run by default. + + + + + + + +Utilities + + + + The testsuite directory also contains some files that implement + functionality that is intended to make writing test cases easier, + or to avoid duplication, or to provide error checking in a way that + is consistent across platforms and test harnesses. A stand-alone + executable, called abi_check, and a static + library called libtestc++ are + constructed. Both of these items are not installed, and only used + during testing. + + + + These files include the following functionality: + + + + + + testsuite_abi.h, + testsuite_abi.cc, + testsuite_abi_check.cc + + + Creates the executable abi_check. + Used to check correctness of symbol versioning, visibility of + exported symbols, and compatibility on symbols in the shared + library, for hosts that support this feature. More information + can be found in the ABI documentation here + + + + + testsuite_allocator.h, + testsuite_allocator.cc + + + Contains specialized allocators that keep track of construction + and destruction. Also, support for overriding global new and + delete operators, including verification that new and delete + are called during execution, and that allocation over max_size + fails. + + + + + testsuite_character.h + + + Contains std::char_traits and + std::codecvt specializations for a user-defined + POD. + + + + + testsuite_hooks.h, + testsuite_hooks.cc + + + A large number of utilities, including: + + + VERIFY + set_memory_limits + verify_demangle + run_tests_wrapped_locale + run_tests_wrapped_env + try_named_locale + try_mkfifo + func_callback + counter + copy_tracker + copy_constructor + assignment_operator + destructor + + pod_char, pod_int and associated char_traits specializations + + + + + + testsuite_io.h + + + Error, exception, and constraint checking for + std::streambuf, std::basic_stringbuf, std::basic_filebuf. + + + + + testsuite_iterators.h + + + Wrappers for various iterators. + + + + + testsuite_performance.h + + + A number of class abstractions for performance counters, and + reporting functions including: + + + time_counter + resource_counter + report_performance + + + + + + + +Running the Testsuite + + + Basic Results + + There are several options for running tests, including testing + the regression tests, testing a subset of the regression tests, + testing the performance tests, testing just compilation, testing + installed tools, etc. In addition, there is a special rule for + checking the exported symbols of the shared library. + + + + You can check the status of the build without installing it + using the dejagnu harness, much like the rest of the gcc + tools. + make check + in the libbuilddir directory. + or + make check-target-libstdc++-v3 + in the gccbuilddir directory. + + + + These commands are functionally equivalent and will create a + 'testsuite' directory underneath + libbuilddir containing the results of the + tests. Two results files will be generated: + libstdc++.sum, which is a PASS/FAIL summary for each + test, and libstdc++.log which is a log of + the exact command line passed to the compiler, the compiler + output, and the executable output (if any). + + + + Archives of test results for various versions and platforms are + available on the GCC website in the build + status section of each individual release, and are also + archived on a daily basis on the gcc-testresults + mailing list. Please check either of these places for a similar + combination of source version, operating system, and host CPU. + + + + + Options + + To debug the dejagnu test harness during runs, try invoking with a + specific argument to the variable RUNTESTFLAGS, as below. + + + +make check-target-libstdc++-v3 RUNTESTFLAGS="-v" + + + + or + + + +make check-target-libstdc++-v3 RUNTESTFLAGS="-v -v" + + + + To run a subset of the library tests, you will need to generate + the testsuite_files file by running + make testsuite_files in the + libbuilddir/testsuite directory, described + below. Edit the file to remove the tests you don't want and + then run the testsuite as normal. + + + + There are two ways to run on a simulator: set up DEJAGNU to point to a + specially crafted site.exp, or pass down --target_board flags. + + + + Example flags to pass down for various embedded builds are as follows: + + + + --target=powerpc-eabism (libgloss/sim) +make check-target-libstdc++-v3 RUNTESTFLAGS="--target_board=powerpc-sim" + +--target=calmrisc32 (libgloss/sid) +make check-target-libstdc++-v3 RUNTESTFLAGS="--target_board=calmrisc32-sid" + +--target=xscale-elf (newlib/sim) +make check-target-libstdc++-v3 RUNTESTFLAGS="--target_board=arm-sim" + + + + Also, here is an example of how to run the libstdc++ testsuite + for a multilibed build directory with different ABI settings: + + + +make check-target-libstdc++-v3 RUNTESTFLAGS='--target_board \"unix{-mabi=32,,-mabi=64}\"' + + + + You can run the tests with a compiler and library that have + already been installed. Make sure that the compiler (e.g., + g++) is in your PATH. If you are + using shared libraries, then you must also ensure that the + directory containing the shared version of libstdc++ is in your + LD_LIBRARY_PATH, or equivalent. If your GCC source + tree is at /path/to/gcc, then you can run the tests + as follows: + + + +runtest --tool libstdc++ --srcdir=/path/to/gcc/libstdc++-v3/testsuite + + + + The testsuite will create a number of files in the directory in + which you run this command,. Some of those files might use the + same name as files created by other testsuites (like the ones + for GCC and G++), so you should not try to run all the + testsuites in parallel from the same directory. + + + + In addition, there are some testing options that are mostly of + interest to library maintainers and system integrators. As such, + these tests may not work on all cpu and host combinations, and + may need to be executed in the + libbuilddir/testsuite directory. These + options include, but are not necessarily limited to, the + following: + + + + make testsuite_files + + + + Five files are generated that determine what test files + are run. These files are: + + + + + + testsuite_files + + + This is a list of all the test cases that will be run. Each + test case is on a separate line, given with an absolute path + from the libsrcdir/testsuite directory. + + + + + + testsuite_files_interactive + + + This is a list of all the interactive test cases, using the + same format as the file list above. These tests are not run + by default. + + + + + + testsuite_files_performance + + + This is a list of all the performance test cases, using the + same format as the file list above. These tests are not run + by default. + + + + + + testsuite_thread + + + This file indicates that the host system can run tests which + incolved multiple threads. + + + + + + testsuite_wchar_t + + + This file indicates that the host system can run the wchar_t + tests, and corresponds to the macro definition + _GLIBCXX_USE_WCHAR_T in the file c++config.h. + + + + + + make check-abi + + + + The library ABI can be tested. This involves testing the shared + library against an ABI-defining previous version of symbol + exports. + + + + make check-compile + + + + This rule compiles, but does not link or execute, the + testsuite_files test cases and displays the + output on stdout. + + + + make check-performance + + + + This rule runs through the + testsuite_files_performance test cases and + collects information for performance analysis and can be used to + spot performance regressions. Various timing information is + collected, as well as number of hard page faults, and memory + used. This is not run by default, and the implementation is in + flux. + + + + We are interested in any strange failures of the testsuite; + please email the main libstdc++ mainling list if you see + something odd or have questions. + + + + + Test Permutations + + To run the libstdc++ test suite under the debug mode, edit + libstdc++-v3/scripts/testsuite_flags to add the + compile-time flag -D_GLIBCXX_DEBUG to the + result printed by the --build-cxx + option. Additionally, add the + -D_GLIBCXX_DEBUG_PEDANTIC flag to turn on + pedantic checking. The libstdc++ test suite should produce + precisely the same results under debug mode that it does under + release mode: any deviation indicates an error in either the + library or the test suite. + + + + Or, just run the testsuites with CXXFLAGS + set to -D_GLIBCXX_DEBUG. + + + + + +New Test Cases + + + The first step in making a new test case is to choose the correct + directory and file name, given the organization as previously + described. + + + + All files are copyright the FSF, and GPL'd: this is very + important. The first copyright year should correspond to the date + the file was checked in to SVN. + + + + As per the dejagnu instructions, always return 0 from main to + indicate success. + + + + A bunch of utility functions and classes have already been + abstracted out into the testsuite utility library, + libtestc++. To use this functionality, just include the + appropriate header file: the library or specific object files will + automatically be linked in as part of the testsuite run. + + + + For a test that needs to take advantage of the dejagnu test + harness, what follows below is a list of special keyword that + harness uses. Basically, a test case contains dg-keywords (see + dg.exp) indicating what to do and what kinds of behavior are to be + expected. New test cases should be written with the new style + DejaGnu framework in mind. + + + + To ease transition, here is the list of dg-keyword documentation + lifted from dg.exp. + + + +# The currently supported options are: +# +# dg-prms-id N +# set prms_id to N +# +# dg-options "options ..." [{ target selector }] +# specify special options to pass to the tool (eg: compiler) +# +# dg-do do-what-keyword [{ target/xfail selector }] +# `do-what-keyword' is tool specific and is passed unchanged to +# ${tool}-dg-test. An example is gcc where `keyword' can be any of: +# preprocess|compile|assemble|link|run +# and will do one of: produce a .i, produce a .s, produce a .o, +# produce an a.out, or produce an a.out and run it (the default is +# compile). +# +# dg-error regexp comment [{ target/xfail selector } [{.|0|linenum}]] +# indicate an error message <regexp> is expected on this line +# (the test fails if it doesn't occur) +# Linenum=0 for general tool messages (eg: -V arg missing). +# "." means the current line. +# +# dg-warning regexp comment [{ target/xfail selector } [{.|0|linenum}]] +# indicate a warning message <regexp> is expected on this line +# (the test fails if it doesn't occur) +# +# dg-bogus regexp comment [{ target/xfail selector } [{.|0|linenum}]] +# indicate a bogus error message <regexp> use to occur here +# (the test fails if it does occur) +# +# dg-build regexp comment [{ target/xfail selector }] +# indicate the build use to fail for some reason +# (errors covered here include bad assembler generated, tool crashes, +# and link failures) +# (the test fails if it does occur) +# +# dg-excess-errors comment [{ target/xfail selector }] +# indicate excess errors are expected (any line) +# (this should only be used sparingly and temporarily) +# +# dg-output regexp [{ target selector }] +# indicate the expected output of the program is <regexp> +# (there may be multiple occurrences of this, they are concatenated) +# +# dg-final { tcl code } +# add some tcl code to be run at the end +# (there may be multiple occurrences of this, they are concatenated) +# (unbalanced braces must be \-escaped) +# +# "{ target selector }" is a list of expressions that determine whether the +# test succeeds or fails for a particular target, or in some cases whether the +# option applies for a particular target. If the case of `dg-do' it specifies +# whether the test case is even attempted on the specified target. +# +# The target selector is always optional. The format is one of: +# +# { xfail *-*-* ... } - the test is expected to fail for the given targets +# { target *-*-* ... } - the option only applies to the given targets +# +# At least one target must be specified, use *-*-* for "all targets". +# At present it is not possible to specify both `xfail' and `target'. +# "native" may be used in place of "*-*-*". + +Example 1: Testing compilation only +// { dg-do compile } + +Example 2: Testing for expected warnings on line 36, which all targets fail +// { dg-warning "string literals" "" { xfail *-*-* } 36 + +Example 3: Testing for expected warnings on line 36 +// { dg-warning "string literals" "" { target *-*-* } 36 + +Example 4: Testing for compilation errors on line 41 +// { dg-do compile } +// { dg-error "no match for" "" { target *-*-* } 41 } + +Example 5: Testing with special command line settings, or without the +use of pre-compiled headers, in particular the stdc++.h.gch file. Any +options here will override the DEFAULT_CXXFLAGS and PCH_CXXFLAGS set +up in the normal.exp file. +// { dg-options "-O0" { target *-*-* } } + + + + More examples can be found in the libstdc++-v3/testsuite/*/*.cc files. + + + + + + +Test Harness Details + + Underlying details of testing are abstracted via the GNU Dejagnu package. + + + +This is information for those looking at making changes to the testsuite +structure, and/or needing to trace dejagnu's actions with --verbose. This +will not be useful to people who are "merely" adding new tests to the existing +structure. + + +The first key point when working with dejagnu is the idea of a "tool". +Files, directories, and functions are all implicitly used when they are +named after the tool in use. Here, the tool will always be "libstdc++". + + +The lib subdir contains support routines. The +lib/libstdc++.exp file ("support library") is loaded +automagically, and must explicitly load the others. For example, files can +be copied from the core compiler's support directory into lib. + + +Some routines in lib/libstdc++.exp are callbacks, some are +our own. Callbacks must be prefixed with the name of the tool. To easily +distinguish the others, by convention our own routines are named "v3-*". + + +The next key point when working with dejagnu is "test files". Any +directory whose name starts with the tool name will be searched for test files. +(We have only one.) In those directories, any .exp file is +considered a test file, and will be run in turn. Our main test file is called +normal.exp; it runs all the tests in testsuite_files using the +callbacks loaded from the support library. + + +The config directory is searched for any particular "target +board" information unique to this library. This is currently unused and sets +only default variables. + + + + + +Future + + + + + +Shared runs need to be implemented, for targets that support shared libraries. + + + +Diffing of expected output to standard streams needs to be finished off. + + + +The V3 testing framework supports, or will eventually support, +additional keywords for the purpose of easing the job of writing +test cases. All V3-keywords are of the form @xxx@. +Currently plans for supported keywords include: + + + + @require@ <files> + + + The existence of <files> is essential for the test to complete + successfully. For example, a test case foo.C using bar.baz as + input file could say + + + // @require@ bar.baz + + The special variable % stands for the rootname, e.g. the + file-name without its `.C' extension. Example of use (taken + verbatim from 27_io/filebuf.cc) + + + // @require@ %-*.tst %-*.txt + + @diff@ <first-list> <second-list> + + + After the test case compiles and ran successfully, diff + <first-list> against <second-list>, these lists should + have the same length. The test fails if diff returns non-zero a + pair of files. + + + + + + + \ No newline at end of file diff --git a/libstdc++-v3/doc/xml/manual/using.xml b/libstdc++-v3/doc/xml/manual/using.xml new file mode 100644 index 00000000000..2782596201f --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/using.xml @@ -0,0 +1,1024 @@ + + + + + + +Using + + + Linking Library Binary Files + + + If you only built a static library (libstdc++.a), or if you + specified static linking, you don't have to worry about this. + But if you built a shared library (libstdc++.so) and linked + against it, then you will need to find that library when you run + the executable. + + + Methods vary for different platforms and different styles, but + the usual ones are printed to the screen during installation. + They include: + + + + + At runtime set LD_LIBRARY_PATH in your environment + correctly, so that the shared library for libstdc++ can be + found and loaded. Be certain that you understand all of the + other implications and behavior of LD_LIBRARY_PATH first + (few people do, and they get into trouble). + + + + + Compile the path to find the library at runtime into the + program. This can be done by passing certain options to + g++, which will in turn pass them on to the linker. The + exact format of the options is dependent on which linker you + use: + + + + + GNU ld (default on Linux):-Wl,--rpath,destdir/lib + + + + + IRIX ld: + -Wl,-rpath,destdir/lib + + + + + Solaris ld:-Wl,-Rdestdir/lib + + + + + More...? Let us know! + + + + + + + Use the ldd utility to show which library the + system thinks it will get at runtime. + + + A libstdc++.la file is also installed, for use with Libtool. If + you use Libtool to create your executables, these details are + taken care of for you. + + + + + Headers + + + Header Files + + + The C++ standard specifies the entire set of header files that + must be available to all hosted implementations. Actually, the + word "files" is a misnomer, since the contents of the + headers don't necessarily have to be in any kind of external + file. The only rule is that when one #include's a + header, the contents of that header become available, no matter + how. + + + + That said, in practice files are used. + + + + There are two main types of include files: header files related + to a specific version of the ISO C++ standard (called Standard + Headers), and all others (TR1, C++ ABI, and Extensions). + + + + Two dialects of standard headers are supported, corresponding to + the 1998 standard as updated for 2003, and the draft of the + upcoming 200x standard. + + + + C++98/03 include files. These are available in the default compilation mode, ie -std=c++98 or -std=gnu++98. + + + +C++ 1998 Library Headers + + + + + + +algorithmiomaniplistostreamstreambuf +bitsetioslocalequeuestring +complexiosfwdmapsettypeinfo +dequeiostreammemorysstreamutility +exceptionistreamnewstackvalarray +fstreamiteratornumericstdexceptvector +functionallimits + + +
+ + + +C++ 1998 Library Headers for C Library Facilities + + + + + + +cassertciso646csetjmpcstdioctime +cctypeclimitscsignalcstdlibcwchar +cerrnoclocalecstdargcstringcwctype +cfloatcmathcstddef + + +
+ +C++0x include files. These are only available in C++0x compilation mode, ie -std=c++0x or -std=gnu++0x. + + + + +C++ 200x Library Headers + + + + + + +algorithmiomaniplocaleregextuple +arrayiosmapsettypeinfo +bitsetiosfwdmemorysstreamtype_traits +complexiostreamnewstackunordered_map +dequeistreamnumericstdexceptunordered_set +exceptioniteratorostreamstreambufutility +fstreamlimitsqueuestringvalarray +functionallistrandomsystem_errorvector + + +
+ + + + +C++ 200x Library Headers for C Library Facilities + + + + + + + +cassertcfloatcmathcstddefctgmath +ccomplexcinttypescsetjmpcstdintctime +cctypeciso646csignalcstdiocuchar +cerrnoclimitscstdargcstdlibcwchar +cfenvclocalecstdboolcstringcwctype + + +
+ + + + In addition, TR1 includes as: + + + +C++ TR1 Library Headers + + + + + + + + +tr1/arraytr1/memorytr1/regextr1/type_traitstr1/unordered_set +tr1/complextr1/randomtr1/tupletr1/unordered_maptr1/utility +tr1/functional + + +
+ + + + + +C++ TR1 Library Headers for C Library Facilities + + + + + + + + +tr1/cmathtr1/cfloattr1/cstdargtr1/cstdiotr1/ctime +tr1/ccomplextr1/cinttypestr1/cstdbooltr1/cstdlibtr1/cwchar +tr1/cfenvtr1/climitstr1/cstdinttr1/ctgmathtr1/cwctype + + +
+ + + Also included are files for the C++ ABI interface: + + + +C++ ABI Headers + + + + +cxxabi.hcxxabi_forced.h + + +
+ + + And a large variety of extensions. + + + +Extension Headers + + + + + + + + +ext/algorithmext/debug_allocator.hext/mt_allocator.hext/pod_char_traits.hext/stdio_sync_filebuf.h +ext/array_allocator.hext/enc_filebuf.hext/new_allocator.hext/pool_allocator.hext/throw_allocator.h +ext/atomicity.hext/functionalext/numericext/rb_treeext/typelist.h +ext/bitmap_allocator.hext/iteratorext/numeric_traits.hext/ropeext/type_traits.h +ext/codecvt_specializations.hext/malloc_allocator.hext/pb_ds/assoc_container.hext/slistext/vstring.h +ext/concurrence.hext/memoryext/pb_ds/priority_queue.hext/stdio_filebuf.h + + +
+ + + + +Extension Debug Headers + + + + + + + + +debug/bitsetdebug/listdebug/setdebug/unordered_mapdebug/vector +debug/dequedebug/mapdebug/stringdebug/unordered_set + + +
+ + + + +Extension Parallel Headers + + + + +parallel/algorithmparallel/numeric + + +
+ + + + + Mixing Headers + + A few simple rules. + + +First, mixing different dialects of the standard headers is not +possible. It's an all-or-nothing affair. Thus, code like + + + +#include <array> +#include <functional> + + +Implies C++0x mode. To use the entities in <array>, the C++0x +compilation mode must be used, which implies the C++0x functionality +(and deprecations) in <functional> will be present. + + +Second, the other headers can be included with either dialect of +the standard headers, although features and types specific to C++0x +are still only enabled when in C++0x compilation mode. So, to use +rvalue references with __gnu_cxx::vstring, or to use the +debug-mode versions of std::unordered_map, one must use +the std=gnu++0x compiler flag. (Or std=c++0x, of course.) + + +A special case of the second rule is the mixing of TR1 and C++0x +facilities. It is possible (although not especially prudent) to +include both the TR1 version and the C++0x version of header in the +same translation unit: + + + +#include <tr1/type_traits> +#include <type_traits> + + + Several parts of C++0x diverge quite substantially from TR1 predecessors. + + + + + The C Headers and <code>namespace std</code> + + + The standard specifies that if one includes the C-style header + (<math.h> in this case), the symbols will be available + in the global namespace and perhaps in + namespace std:: (but this is no longer a firm + requirement.) One the other hand, including the C++-style + header (<cmath>) guarantees that the entities will be + found in namespace std and perhaps in the global namespace. + + + +Usage of C++-style headers is recommended, as then +C-linkage names can be disambiguated by explicit qualification, such +as by std::abort. In addition, the C++-style headers can +use function overloading to provide a simpler interface to certain +families of C-functions. For instance in <cmath>, the +function std::sin has overloads for all the builtin +floating-point types. This means that std::sin can be +used uniformly, instead of a combination +of std::sinf, std::sin, +and std::sinl. + + + + + Precompiled Headers + + +There are three base header files that are provided. They can be +used to precompile the standard headers and extensions into binary +files that may the be used to speed compiles that use these headers. + + + + + + stdc++.h +Includes all standard headers. Actual content varies depending on +language dialect. + + + + + stdtr1c++.h +Includes all of <stdc++.h>, and adds all the TR1 headers. + + + +extc++.h +Includes all of <stdtr1c++.h>, and adds all the Extension headers. + + + +How to construct a .gch file from one of these base header files. + +First, find the include directory for the compiler. One way to do +this is: + + +g++ -v hello.cc + +#include <...> search starts here: + /mnt/share/bld/H-x86-gcc.20071201/include/c++/4.3.0 +... +End of search list. + + + +Then, create a precompiled header file with the same flags that +will be used to compile other projects. + + +g++ -Winvalid-pch -x c++-header -g -O2 -o ./stdc++.h.gch /mnt/share/bld/H-x86-gcc.20071201/include/c++/4.3.0/x86_64-unknown-linux-gnu/bits/stdc++.h + + +The resulting file will be quite large: the current size is around +thirty megabytes. + +How to use the resulting file. + + +g++ -I. -include stdc++.h -H -g -O2 hello.cc + + +Verification that the PCH file is being used is easy: + + +g++ -Winvalid-pch -I. -include stdc++.h -H -g -O2 hello.cc -o test.exe +! ./stdc++.h.gch +. /mnt/share/bld/H-x86-gcc.20071201/include/c++/4.3.0/iostream +. /mnt/share/bld/H-x86-gcc.20071201include/c++/4.3.0/string + + +The exclamation point to the left of the stdc++.h.gch listing means that the generated PCH file was used, and thus the + + + Detailed information about creating precompiled header files can be found in the GCC documentation. + + + + + + + + Namespaces + + + Available Namespaces + + + + There are three main namespaces. + + + + std +The ISO C++ standards specify that "all library entities are defined +within namespace std." This includes namepaces nested +within namespace std, such as namespace +std::tr1. + + +abi +Specified by the C++ ABI. This ABI specifies a number of type and +function APIs supplemental to those required by the ISO C++ Standard, +but necessary for interoperability. + + + +__gnu_ +Indicating one of several GNU extensions. Choices +include __gnu_cxx, __gnu_debug, __gnu_parallel, +and __gnu_pbds. + + + + A complete list of implementation namespaces (including namespace contents) is available in the generated source documentation. + + + + + + + namespace std + + + + One standard requirement is that the library components are defined + in namespace std::. Thus, in order to use these types or + functions, one must do one of two things: + + + + put a kind of using-declaration in your source +(either using namespace std; or i.e. using +std::string;) This approach works well for individual source files, but +should not be used in a global context, like header files. + use a fully +qualified namefor each library symbol +(i.e. std::string, std::cout) Always can be +used, and usually enhanced, by strategic use of typedefs. (In the +cases where the qualified verbiage becomes unwieldy.) + + + + + + + + Using Namespace Composition + + +Best practice in programming suggests sequestering new data or +functionality in a sanely-named, unique namespace whenever +possible. This is considered an advantage over dumping everything in +the global namespace, as then name look-up can be explicitly enabled or +disabled as above, symbols are consistently mangled without repetitive +naming prefixes or macros, etc. + + +For instance, consider a project that defines most of its classes in namespace gtk. It is possible to + adapt namespace gtk to namespace std by using a C++-feature called + namespace composition. This is what happens if + a using-declaration is put into a + namespace-definition: the imported symbol(s) gets imported into the + currently active namespace(s). For example: + + +namespace gtk +{ + using std::string; + using std::tr1::array; + + class Window { ... }; +} + + + In this example, std::string gets imported into + namespace gtk. The result is that use of + std::string inside namespace gtk can just use string, without the explicit qualification. + As an added bonus, + std::string does not get imported into + the global namespace. Additionally, a more elaborate arrangement can be made for backwards compatibility and portability, whereby the + using-declarations can wrapped in macros that + are set based on autoconf-tests to either "" or i.e. using + std::string; (depending on whether the system has + libstdc++ in std:: or not). (ideas from + llewelly@dbritsch.dsl.xmission.com, Karl Nelson kenelson@ece.ucdavis.edu) + + + + + + + + Macros + + All pre-processor switches and configurations are all gathered + in the file c++config.h, which is generated during + the libstdc++ configuration and build process, and included by + files part of the public libstdc++ API. Most of these macros + should not be used by consumers of libstdc++, and are reserved + for internal implementation use. These macros cannot be + redefined. However, a select handful of these macro + control libstdc++ extensions and extra features, or provide + versioning information for the API, and are able to be used. + + + All library macros begin with _GLIBCXX_ (except for + versions 3.1.x to 3.3.x, which use _GLIBCPP_). + + + Below is the macro which users may check for library version + information. + + + + __GLIBCXX__ + + The current version of + libstdc++ in compressed ISO date format, form of an unsigned + long. For details on the value of this particular macro for a + particular release, please consult this + document. + + + + + + Below are the macros which users may change with #define/#undef or + with -D/-U compiler flags. The default state of the symbol is + listed. + + Configurable (or Not configurable) means + that the symbol is initially chosen (or not) based on + --enable/--disable options at library build and configure time + (documented here), with the + various --enable/--disable choices being translated to + #define/#undef). + + + ABI means that changing from the default value may + mean changing the ABI of compiled code. In other words, these + choices control code which has already been compiled (i.e., in a + binary such as libstdc++.a/.so). If you explicitly #define or + #undef these macros, the headers may see different code + paths, but the libraries which you link against will not. + Experimenting with different values with the expectation of + consistent linkage requires changing the config headers before + building/installing the library. + + + + _GLIBCXX_DEPRECATED + + + Defined by default. Not configurable. ABI-changing. Turning this off + removes older ARM-style iostreams code, and other anachronisms + from the API. This macro is dependent on the version of the + standard being tracked, and as a result may give different results for + -std=c++98 and -std=c++0x. This may + be useful in updating old C++ code which no longer meet the + requirements of the language, or for checking current code + against new language standards. + + + + _GLIBCXX_FORCE_NEW + + + Undefined by default. When defined, memory allocation and + allocators controlled by libstdc++ call operator new/delete + without caching and pooling. Configurable via + --enable-libstdcxx-allocator. ABI-changing. + + + + + _GLIBCXX_CONCEPT_CHECKS + + + Undefined by default. Configurable via + --enable-concept-checks. When defined, performs + compile-time checking on certain template instantiations to + detect violations of the requirements of the standard. This + is described in more detail here. + + + + _GLIBCXX_DEBUG + + + Undefined by default. When defined, compiles + user code using the libstdc++ debug + mode. + + + _GLIBCXX_DEBUG_PEDANTIC + + + Undefined by default. When defined while + compiling with the libstdc++ debug + mode, makes the debug mode extremely picky by making the use + of libstdc++ extensions and libstdc++-specific behavior into + errors. + + + _GLIBCXX_PARALLEL + + Undefined by default. When defined, compiles + user code using the libstdc++ parallel + mode. + + + + + + + + + Concurrency + + This section discusses issues surrounding the proper compilation + of multithreaded applications which use the Standard C++ + library. This information is GCC-specific since the C++ + standard does not address matters of multithreaded applications. + + + + Prerequisites + + All normal disclaimers aside, multithreaded C++ application are + only supported when libstdc++ and all user code was built with + compilers which report (via gcc/g++ -v ) the same thread + model and that model is not single. As long as your + final application is actually single-threaded, then it should be + safe to mix user code built with a thread model of + single with a libstdc++ and other C++ libraries built + with another thread model useful on the platform. Other mixes + may or may not work but are not considered supported. (Thus, if + you distribute a shared C++ library in binary form only, it may + be best to compile it with a GCC configured with + --enable-threads for maximal interchangeability and usefulness + with a user population that may have built GCC with either + --enable-threads or --disable-threads.) + + When you link a multithreaded application, you will probably + need to add a library or flag to g++. This is a very + non-standardized area of GCC across ports. Some ports support a + special flag (the spelling isn't even standardized yet) to add + all required macros to a compilation (if any such flags are + required then you must provide the flag for all compilations not + just linking) and link-library additions and/or replacements at + link time. The documentation is weak. Here is a quick summary + to display how ad hoc this is: On Solaris, both -pthreads and + -threads (with subtly different meanings) are honored. On OSF, + -pthread and -threads (with subtly different meanings) are + honored. On Linux/i386, -pthread is honored. On FreeBSD, + -pthread is honored. Some other ports use other switches. + AFAIK, none of this is properly documented anywhere other than + in ``gcc -dumpspecs'' (look at lib and cpp entries). + + + + + + Thread Safety + + + +We currently use the SGI STL definition of thread safety. + + + + The library strives to be thread-safe when all of the following + conditions are met: + + + + The system's libc is itself thread-safe, + + + + + The compiler in use reports a thread model other than + 'single'. This can be tested via output from gcc + -v. Multi-thread capable versions of gcc output + something like this: + + +%gcc -v +Using built-in specs. +... +Thread model: posix +gcc version 4.1.2 20070925 (Red Hat 4.1.2-33) + + +Look for "Thread model" lines that aren't equal to "single." + + + + Requisite command-line flags are used for atomic operations + and threading. Examples of this include -pthread + and -march=native, although specifics vary + depending on the host environment. See Machine + Dependent Options. + + + + + An implementation of atomicity.h functions + exists for the architecture in question. See the internals documentation for more details. + + + + + The user-code must guard against concurrent method calls which may + access any particular library object's state. Typically, the + application programmer may infer what object locks must be held + based on the objects referenced in a method call. Without getting + into great detail, here is an example which requires user-level + locks: + + + library_class_a shared_object_a; + + thread_main () { + library_class_b *object_b = new library_class_b; + shared_object_a.add_b (object_b); // must hold lock for shared_object_a + shared_object_a.mutate (); // must hold lock for shared_object_a + } + + // Multiple copies of thread_main() are started in independent threads. + Under the assumption that object_a and object_b are never exposed to + another thread, here is an example that should not require any + user-level locks: + + + thread_main () { + library_class_a object_a; + library_class_b *object_b = new library_class_b; + object_a.add_b (object_b); + object_a.mutate (); + } + All library objects are safe to use in a multithreaded program as + long as each thread carefully locks out access by any other + thread while it uses any object visible to another thread, i.e., + treat library objects like any other shared resource. In general, + this requirement includes both read and write access to objects; + unless otherwise documented as safe, do not assume that two threads + may access a shared standard library object at the same time. + + See chapters 17 (library + introduction), 23 + (containers), and 27 (I/O) for + more information. + + + + + + Atomics + + + + + + IO + I'll assume that you have already read the + general notes on library threads, + and the + notes on threaded container + access (you might not think of an I/O stream as a container, but + the points made there also hold here). If you have not read them, + please do so first. + + This gets a bit tricky. Please read carefully, and bear with me. + + + + Structure + A wrapper + type called __basic_file provides our abstraction layer + for the std::filebuf classes. Nearly all decisions dealing + with actual input and output must be made in __basic_file. + + A generic locking mechanism is somewhat in place at the filebuf layer, + but is not used in the current code. Providing locking at any higher + level is akin to providing locking within containers, and is not done + for the same reasons (see the links above). + + + + + Defaults + The __basic_file type is simply a collection of small wrappers around + the C stdio layer (again, see the link under Structure). We do no + locking ourselves, but simply pass through to calls to fopen, + fwrite, and so forth. + + So, for 3.0, the question of "is multithreading safe for I/O" + must be answered with, "is your platform's C library threadsafe + for I/O?" Some are by default, some are not; many offer multiple + implementations of the C library with varying tradeoffs of threadsafety + and efficiency. You, the programmer, are always required to take care + with multiple threads. + + (As an example, the POSIX standard requires that C stdio FILE* + operations are atomic. POSIX-conforming C libraries (e.g, on Solaris + and GNU/Linux) have an internal mutex to serialize operations on + FILE*s. However, you still need to not do stupid things like calling + fclose(fs) in one thread followed by an access of + fs in another.) + + So, if your platform's C library is threadsafe, then your + fstream I/O operations will be threadsafe at the lowest + level. For higher-level operations, such as manipulating the data + contained in the stream formatting classes (e.g., setting up callbacks + inside an std::ofstream), you need to guard such accesses + like any other critical shared resource. + + + + + Future + A + second choice may be available for I/O implementations: libio. This is + disabled by default, and in fact will not currently work due to other + issues. It will be revisited, however. + + The libio code is a subset of the guts of the GNU libc (glibc) I/O + implementation. When libio is in use, the __basic_file + type is basically derived from FILE. (The real situation is more + complex than that... it's derived from an internal type used to + implement FILE. See libio/libioP.h to see scary things done with + vtbls.) The result is that there is no "layer" of C stdio + to go through; the filebuf makes calls directly into the same + functions used to implement fread, fwrite, + and so forth, using internal data structures. (And when I say + "makes calls directly," I mean the function is literally + replaced by a jump into an internal function. Fast but frightening. + *grin*) + + Also, the libio internal locks are used. This requires pulling in + large chunks of glibc, such as a pthreads implementation, and is one + of the issues preventing widespread use of libio as the libstdc++ + cstdio implementation. + + But we plan to make this work, at least as an option if not a future + default. Platforms running a copy of glibc with a recent-enough + version will see calls from libstdc++ directly into the glibc already + installed. For other platforms, a copy of the libio subsection will + be built and included in libstdc++. + + + + + Alternatives + Don't forget that other cstdio implementations are possible. You could + easily write one to perform your own forms of locking, to solve your + "interesting" problems. + + + + + + + Containers + + This section discusses issues surrounding the design of + multithreaded applications which use Standard C++ containers. + All information in this section is current as of the gcc 3.0 + release and all later point releases. Although earlier gcc + releases had a different approach to threading configuration and + proper compilation, the basic code design rules presented here + were similar. For information on all other aspects of + multithreading as it relates to libstdc++, including details on + the proper compilation of threaded code (and compatibility between + threaded and non-threaded code), see Chapter 17. + + Two excellent pages to read when working with the Standard C++ + containers and threads are + SGI's + http://www.sgi.com/tech/stl/thread_safety.html and + SGI's + http://www.sgi.com/tech/stl/Allocators.html. + + However, please ignore all discussions about the user-level + configuration of the lock implementation inside the STL + container-memory allocator on those pages. For the sake of this + discussion, libstdc++ configures the SGI STL implementation, + not you. This is quite different from how gcc pre-3.0 worked. + In particular, past advice was for people using g++ to + explicitly define _PTHREADS or other macros or port-specific + compilation options on the command line to get a thread-safe + STL. This is no longer required for any port and should no + longer be done unless you really know what you are doing and + assume all responsibility. + + Since the container implementation of libstdc++ uses the SGI + code, we use the same definition of thread safety as SGI when + discussing design. A key point that beginners may miss is the + fourth major paragraph of the first page mentioned above + ("For most clients,"...), which points out that + locking must nearly always be done outside the container, by + client code (that'd be you, not us). There is a notable + exceptions to this rule. Allocators called while a container or + element is constructed uses an internal lock obtained and + released solely within libstdc++ code (in fact, this is the + reason STL requires any knowledge of the thread configuration). + + For implementing a container which does its own locking, it is + trivial to provide a wrapper class which obtains the lock (as + SGI suggests), performs the container operation, and then + releases the lock. This could be templatized to a certain + extent, on the underlying container and/or a locking + mechanism. Trying to provide a catch-all general template + solution would probably be more trouble than it's worth. + + The STL implementation is currently configured to use the + high-speed caching memory allocator. Some people like to + test and/or normally run threaded programs with a different + default. For all details about how to globally override this + at application run-time see here. + + There is a better way (not standardized yet): It is possible to + force the malloc-based allocator on a per-case-basis for some + application code. The library team generally believes that this + is a better way to tune an application for high-speed using this + implementation of the STL. There is + more information on allocators here. + + + + + + + Exception Safety + + + + + + + + diff --git a/libstdc++-v3/doc/xml/manual/utilities.xml b/libstdc++-v3/doc/xml/manual/utilities.xml new file mode 100644 index 00000000000..77cdb6427eb --- /dev/null +++ b/libstdc++-v3/doc/xml/manual/utilities.xml @@ -0,0 +1,125 @@ + + + + + + + + + + ISO C++ + + + library + + + + +Utilities + + + + Functors + If you don't know what functors are, you're not alone. Many people + get slightly the wrong idea. In the interest of not reinventing + the wheel, we will refer you to the introduction to the functor + concept written by SGI as part of their STL, in + their + http://www.sgi.com/tech/stl/functors.html. + + + + + + Pairs + The pair<T1,T2> is a simple and handy way to + carry around a pair of objects. One is of type T1, and another of + type T2; they may be the same type, but you don't get anything + extra if they are. The two members can be accessed directly, as + .first and .second. + + Construction is simple. The default ctor initializes each member + with its respective default ctor. The other simple ctor, + + + pair (const T1& x, const T2& y); + + does what you think it does, first getting x + and second getting y. + + There is a copy constructor, but it requires that your compiler + handle member function templates: + + + template <class U, class V> pair (const pair<U,V>& p); + + The compiler will convert as necessary from U to T1 and from + V to T2 in order to perform the respective initializations. + + The comparison operators are done for you. Equality + of two pair<T1,T2>s is defined as both first + members comparing equal and both second members comparing + equal; this simply delegates responsibility to the respective + operator== functions (for types like MyClass) or builtin + comparisons (for types like int, char, etc). + + + The less-than operator is a bit odd the first time you see it. It + is defined as evaluating to: + + + x.first < y.first || + ( !(y.first < x.first) && x.second < y.second ) + + The other operators are not defined using the rel_ops + functions above, but their semantics are the same. + + Finally, there is a template function called make_pair + that takes two references-to-const objects and returns an + instance of a pair instantiated on their respective types: + + + pair<int,MyClass> p = make_pair(4,myobject); + + + + + + + + Memory + + Memory contains three general areas. First, function and operator + calls via new and delete + operator or member function calls. Second, allocation via + allocator. And finally, smart pointer and + intelligent pointer abstractions. + + + + + + + + + + + + + + + + + + + Traits + + + + + diff --git a/libstdc++-v3/doc/xml/spine.xml b/libstdc++-v3/doc/xml/spine.xml new file mode 100644 index 00000000000..df30ad93dc4 --- /dev/null +++ b/libstdc++-v3/doc/xml/spine.xml @@ -0,0 +1,47 @@ + + + +]> + + + +The GNU C++ Library Documentation + + + + 2000 + 2001 + 2002 + 2003 + 2004 + 2005 + 2006 + 2007 + 2008 + + FSF + + + &authors; + + + + + + + + + + + + + + + + -- cgit v1.2.3