From d42c44ded246e97e1019967866b78ac8ecbebbfd Mon Sep 17 00:00:00 2001 From: Phil Edwards Date: Sun, 10 Dec 2000 04:04:56 +0000 Subject: 2000-12-09 Phil Edwards Move the HTML-containing subdirs from 'docs' to 'docs/html'. * README: Update the locations of instructions. * docs/doxygen/run_doxygen: New file, stub. * docs/Makefile: Moved... * docs/configopts.html: Likewise. * docs/documentation.html: Likewise. * docs/install.html: Likewise. * docs/lib3styles.css: Likewise. * docs/17_intro/BADNAMES: Likewise. * docs/17_intro/BUGS: Likewise. * docs/17_intro/C++STYLE: Likewise. * docs/17_intro/CHECKLIST: Likewise. * docs/17_intro/COPYING: Likewise. * docs/17_intro/DESIGN: Likewise. * docs/17_intro/HEADER_POLICY: Likewise. * docs/17_intro/PROBLEMS: Likewise. * docs/17_intro/RELEASE-NOTES: Likewise. * docs/17_intro/TODO: Likewise. * docs/17_intro/contribute.html: Likewise. * docs/17_intro/headers_cc.txt: Likewise. * docs/17_intro/howto.html: Likewise. * docs/17_intro/libstdc++-assign.txt: Likewise. * docs/17_intro/organization: Likewise. * docs/17_intro/porting-howto.html: Likewise. * docs/18_support/howto.html: Likewise. * docs/19_diagnostics/howto.html: Likewise. * docs/20_util/howto.html: Likewise. * docs/21_strings/gotw29a.txt: Likewise. * docs/21_strings/howto.html: Likewise. * docs/21_strings/stringtok_h.txt: Likewise. * docs/21_strings/stringtok_std_h.txt: Likewise. * docs/22_locale/codecvt.html: Likewise. * docs/22_locale/ctype.html: Likewise. * docs/22_locale/howto.html: Likewise. * docs/22_locale/locale.html: Likewise. * docs/23_containers/howto.html: Likewise. * docs/23_containers/wrappers_h.txt: Likewise. * docs/24_iterators/howto.html: Likewise. * docs/25_algorithms/howto.html: Likewise. * docs/26_numerics/howto.html: Likewise. * docs/27_io/howto.html: Likewise. * docs/27_io/iostreams_hierarchy.pdf: Likewise. * docs/ext/howto.html: Likewise. * docs/faq/index.html: Likewise. * docs/faq/index.txt: Likewise. * docs/html/Makefile: ...to here. * docs/html/configopts.html: Likewise. * docs/html/documentation.html: Likewise. * docs/html/install.html: Likewise. * docs/html/lib3styles.css: Likewise. * docs/html/17_intro/BADNAMES: Likewise. * docs/html/17_intro/BUGS: Likewise. * docs/html/17_intro/C++STYLE: Likewise. * docs/html/17_intro/CHECKLIST: Likewise. * docs/html/17_intro/COPYING: Likewise. * docs/html/17_intro/DESIGN: Likewise. * docs/html/17_intro/HEADER_POLICY: Likewise. * docs/html/17_intro/PROBLEMS: Likewise. * docs/html/17_intro/RELEASE-NOTES: Likewise. * docs/html/17_intro/TODO: Likewise. * docs/html/17_intro/contribute.html: Likewise. * docs/html/17_intro/headers_cc.txt: Likewise. * docs/html/17_intro/howto.html: Likewise. * docs/html/17_intro/libstdc++-assign.txt: Likewise. * docs/html/17_intro/organization: Likewise. * docs/html/17_intro/porting-howto.html: Likewise. * docs/html/18_support/howto.html: Likewise. * docs/html/19_diagnostics/howto.html: Likewise. * docs/html/20_util/howto.html: Likewise. * docs/html/21_strings/gotw29a.txt: Likewise. * docs/html/21_strings/howto.html: Likewise. * docs/html/21_strings/stringtok_h.txt: Likewise. * docs/html/21_strings/stringtok_std_h.txt: Likewise. * docs/html/22_locale/codecvt.html: Likewise. * docs/html/22_locale/ctype.html: Likewise. * docs/html/22_locale/howto.html: Likewise. * docs/html/22_locale/locale.html: Likewise. * docs/html/23_containers/howto.html: Likewise. * docs/html/23_containers/wrappers_h.txt: Likewise. * docs/html/24_iterators/howto.html: Likewise. * docs/html/25_algorithms/howto.html: Likewise. * docs/html/26_numerics/howto.html: Likewise. * docs/html/27_io/howto.html: Likewise. * docs/html/27_io/iostreams_hierarchy.pdf: Likewise. * docs/html/ext/howto.html: Likewise. * docs/html/faq/index.html: Likewise. * docs/html/faq/index.txt: Likewise. git-svn-id: https://gcc.gnu.org/svn/gcc/trunk@38166 138bc75d-0d04-0410-961f-82ee72b054a4 --- libstdc++-v3/ChangeLog | 91 + libstdc++-v3/README | 8 +- libstdc++-v3/docs/17_intro/BADNAMES | 162 - libstdc++-v3/docs/17_intro/BUGS | 31 - libstdc++-v3/docs/17_intro/C++STYLE | 318 -- libstdc++-v3/docs/17_intro/CHECKLIST | 6014 -------------------- libstdc++-v3/docs/17_intro/COPYING | 340 -- libstdc++-v3/docs/17_intro/DESIGN | 859 --- libstdc++-v3/docs/17_intro/HEADER_POLICY | 164 - libstdc++-v3/docs/17_intro/PROBLEMS | 8 - libstdc++-v3/docs/17_intro/RELEASE-NOTES | 118 - libstdc++-v3/docs/17_intro/TODO | 177 - libstdc++-v3/docs/17_intro/contribute.html | 95 - libstdc++-v3/docs/17_intro/headers_cc.txt | 83 - libstdc++-v3/docs/17_intro/howto.html | 156 - libstdc++-v3/docs/17_intro/libstdc++-assign.txt | 129 - libstdc++-v3/docs/17_intro/organization | 84 - libstdc++-v3/docs/17_intro/porting-howto.html | 726 --- libstdc++-v3/docs/18_support/howto.html | 269 - libstdc++-v3/docs/19_diagnostics/howto.html | 107 - libstdc++-v3/docs/20_util/howto.html | 193 - libstdc++-v3/docs/21_strings/gotw29a.txt | 155 - libstdc++-v3/docs/21_strings/howto.html | 332 -- libstdc++-v3/docs/21_strings/stringtok_h.txt | 102 - libstdc++-v3/docs/21_strings/stringtok_std_h.txt | 39 - libstdc++-v3/docs/22_locale/codecvt.html | 522 -- libstdc++-v3/docs/22_locale/ctype.html | 146 - libstdc++-v3/docs/22_locale/howto.html | 235 - libstdc++-v3/docs/22_locale/locale.html | 103 - libstdc++-v3/docs/23_containers/howto.html | 245 - libstdc++-v3/docs/23_containers/wrappers_h.txt | 48 - libstdc++-v3/docs/24_iterators/howto.html | 94 - libstdc++-v3/docs/25_algorithms/howto.html | 96 - libstdc++-v3/docs/26_numerics/howto.html | 142 - libstdc++-v3/docs/27_io/howto.html | 345 -- libstdc++-v3/docs/27_io/iostreams_hierarchy.pdf | 1 - libstdc++-v3/docs/Makefile | 5 - libstdc++-v3/docs/configopts.html | 175 - libstdc++-v3/docs/documentation.html | 76 - libstdc++-v3/docs/doxygen/run_doxygen | 6 + libstdc++-v3/docs/ext/howto.html | 156 - libstdc++-v3/docs/faq/index.html | 660 --- libstdc++-v3/docs/faq/index.txt | 603 -- libstdc++-v3/docs/html/17_intro/BADNAMES | 162 + libstdc++-v3/docs/html/17_intro/BUGS | 31 + libstdc++-v3/docs/html/17_intro/C++STYLE | 318 ++ libstdc++-v3/docs/html/17_intro/CHECKLIST | 6014 ++++++++++++++++++++ libstdc++-v3/docs/html/17_intro/COPYING | 340 ++ libstdc++-v3/docs/html/17_intro/DESIGN | 859 +++ libstdc++-v3/docs/html/17_intro/HEADER_POLICY | 164 + libstdc++-v3/docs/html/17_intro/PROBLEMS | 8 + libstdc++-v3/docs/html/17_intro/RELEASE-NOTES | 118 + libstdc++-v3/docs/html/17_intro/TODO | 177 + libstdc++-v3/docs/html/17_intro/contribute.html | 95 + libstdc++-v3/docs/html/17_intro/headers_cc.txt | 83 + libstdc++-v3/docs/html/17_intro/howto.html | 156 + .../docs/html/17_intro/libstdc++-assign.txt | 129 + libstdc++-v3/docs/html/17_intro/organization | 84 + libstdc++-v3/docs/html/17_intro/porting-howto.html | 726 +++ libstdc++-v3/docs/html/18_support/howto.html | 269 + libstdc++-v3/docs/html/19_diagnostics/howto.html | 107 + libstdc++-v3/docs/html/20_util/howto.html | 193 + libstdc++-v3/docs/html/21_strings/gotw29a.txt | 155 + libstdc++-v3/docs/html/21_strings/howto.html | 332 ++ libstdc++-v3/docs/html/21_strings/stringtok_h.txt | 102 + .../docs/html/21_strings/stringtok_std_h.txt | 39 + libstdc++-v3/docs/html/22_locale/codecvt.html | 522 ++ libstdc++-v3/docs/html/22_locale/ctype.html | 146 + libstdc++-v3/docs/html/22_locale/howto.html | 235 + libstdc++-v3/docs/html/22_locale/locale.html | 103 + libstdc++-v3/docs/html/23_containers/howto.html | 245 + .../docs/html/23_containers/wrappers_h.txt | 48 + libstdc++-v3/docs/html/24_iterators/howto.html | 94 + libstdc++-v3/docs/html/25_algorithms/howto.html | 96 + libstdc++-v3/docs/html/26_numerics/howto.html | 142 + libstdc++-v3/docs/html/27_io/howto.html | 345 ++ .../docs/html/27_io/iostreams_hierarchy.pdf | 1 + libstdc++-v3/docs/html/Makefile | 5 + libstdc++-v3/docs/html/configopts.html | 175 + libstdc++-v3/docs/html/documentation.html | 74 + libstdc++-v3/docs/html/ext/howto.html | 156 + libstdc++-v3/docs/html/faq/index.html | 660 +++ libstdc++-v3/docs/html/faq/index.txt | 603 ++ libstdc++-v3/docs/html/install.html | 411 ++ libstdc++-v3/docs/html/lib3styles.css | 6 + libstdc++-v3/docs/install.html | 411 -- libstdc++-v3/docs/lib3styles.css | 6 - 87 files changed, 14829 insertions(+), 14734 deletions(-) delete mode 100644 libstdc++-v3/docs/17_intro/BADNAMES delete mode 100644 libstdc++-v3/docs/17_intro/BUGS delete mode 100644 libstdc++-v3/docs/17_intro/C++STYLE delete mode 100644 libstdc++-v3/docs/17_intro/CHECKLIST delete mode 100644 libstdc++-v3/docs/17_intro/COPYING delete mode 100644 libstdc++-v3/docs/17_intro/DESIGN delete mode 100644 libstdc++-v3/docs/17_intro/HEADER_POLICY delete mode 100644 libstdc++-v3/docs/17_intro/PROBLEMS delete mode 100644 libstdc++-v3/docs/17_intro/RELEASE-NOTES delete mode 100644 libstdc++-v3/docs/17_intro/TODO delete mode 100644 libstdc++-v3/docs/17_intro/contribute.html delete mode 100644 libstdc++-v3/docs/17_intro/headers_cc.txt delete mode 100644 libstdc++-v3/docs/17_intro/howto.html delete mode 100644 libstdc++-v3/docs/17_intro/libstdc++-assign.txt delete mode 100644 libstdc++-v3/docs/17_intro/organization delete mode 100644 libstdc++-v3/docs/17_intro/porting-howto.html delete mode 100644 libstdc++-v3/docs/18_support/howto.html delete mode 100644 libstdc++-v3/docs/19_diagnostics/howto.html delete mode 100644 libstdc++-v3/docs/20_util/howto.html delete mode 100644 libstdc++-v3/docs/21_strings/gotw29a.txt delete mode 100644 libstdc++-v3/docs/21_strings/howto.html delete mode 100644 libstdc++-v3/docs/21_strings/stringtok_h.txt delete mode 100644 libstdc++-v3/docs/21_strings/stringtok_std_h.txt delete mode 100644 libstdc++-v3/docs/22_locale/codecvt.html delete mode 100644 libstdc++-v3/docs/22_locale/ctype.html delete mode 100644 libstdc++-v3/docs/22_locale/howto.html delete mode 100644 libstdc++-v3/docs/22_locale/locale.html delete mode 100644 libstdc++-v3/docs/23_containers/howto.html delete mode 100644 libstdc++-v3/docs/23_containers/wrappers_h.txt delete mode 100644 libstdc++-v3/docs/24_iterators/howto.html delete mode 100644 libstdc++-v3/docs/25_algorithms/howto.html delete mode 100644 libstdc++-v3/docs/26_numerics/howto.html delete mode 100644 libstdc++-v3/docs/27_io/howto.html delete mode 100644 libstdc++-v3/docs/27_io/iostreams_hierarchy.pdf delete mode 100644 libstdc++-v3/docs/Makefile delete mode 100644 libstdc++-v3/docs/configopts.html delete mode 100644 libstdc++-v3/docs/documentation.html create mode 100644 libstdc++-v3/docs/doxygen/run_doxygen delete mode 100644 libstdc++-v3/docs/ext/howto.html delete mode 100644 libstdc++-v3/docs/faq/index.html delete mode 100644 libstdc++-v3/docs/faq/index.txt create mode 100644 libstdc++-v3/docs/html/17_intro/BADNAMES create mode 100644 libstdc++-v3/docs/html/17_intro/BUGS create mode 100644 libstdc++-v3/docs/html/17_intro/C++STYLE create mode 100644 libstdc++-v3/docs/html/17_intro/CHECKLIST create mode 100644 libstdc++-v3/docs/html/17_intro/COPYING create mode 100644 libstdc++-v3/docs/html/17_intro/DESIGN create mode 100644 libstdc++-v3/docs/html/17_intro/HEADER_POLICY create mode 100644 libstdc++-v3/docs/html/17_intro/PROBLEMS create mode 100644 libstdc++-v3/docs/html/17_intro/RELEASE-NOTES create mode 100644 libstdc++-v3/docs/html/17_intro/TODO create mode 100644 libstdc++-v3/docs/html/17_intro/contribute.html create mode 100644 libstdc++-v3/docs/html/17_intro/headers_cc.txt create mode 100644 libstdc++-v3/docs/html/17_intro/howto.html create mode 100644 libstdc++-v3/docs/html/17_intro/libstdc++-assign.txt create mode 100644 libstdc++-v3/docs/html/17_intro/organization create mode 100644 libstdc++-v3/docs/html/17_intro/porting-howto.html create mode 100644 libstdc++-v3/docs/html/18_support/howto.html create mode 100644 libstdc++-v3/docs/html/19_diagnostics/howto.html create mode 100644 libstdc++-v3/docs/html/20_util/howto.html create mode 100644 libstdc++-v3/docs/html/21_strings/gotw29a.txt create mode 100644 libstdc++-v3/docs/html/21_strings/howto.html create mode 100644 libstdc++-v3/docs/html/21_strings/stringtok_h.txt create mode 100644 libstdc++-v3/docs/html/21_strings/stringtok_std_h.txt create mode 100644 libstdc++-v3/docs/html/22_locale/codecvt.html create mode 100644 libstdc++-v3/docs/html/22_locale/ctype.html create mode 100644 libstdc++-v3/docs/html/22_locale/howto.html create mode 100644 libstdc++-v3/docs/html/22_locale/locale.html create mode 100644 libstdc++-v3/docs/html/23_containers/howto.html create mode 100644 libstdc++-v3/docs/html/23_containers/wrappers_h.txt create mode 100644 libstdc++-v3/docs/html/24_iterators/howto.html create mode 100644 libstdc++-v3/docs/html/25_algorithms/howto.html create mode 100644 libstdc++-v3/docs/html/26_numerics/howto.html create mode 100644 libstdc++-v3/docs/html/27_io/howto.html create mode 100644 libstdc++-v3/docs/html/27_io/iostreams_hierarchy.pdf create mode 100644 libstdc++-v3/docs/html/Makefile create mode 100644 libstdc++-v3/docs/html/configopts.html create mode 100644 libstdc++-v3/docs/html/documentation.html create mode 100644 libstdc++-v3/docs/html/ext/howto.html create mode 100644 libstdc++-v3/docs/html/faq/index.html create mode 100644 libstdc++-v3/docs/html/faq/index.txt create mode 100644 libstdc++-v3/docs/html/install.html create mode 100644 libstdc++-v3/docs/html/lib3styles.css delete mode 100644 libstdc++-v3/docs/install.html delete mode 100644 libstdc++-v3/docs/lib3styles.css diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog index eae31116d84..24427f60fed 100644 --- a/libstdc++-v3/ChangeLog +++ b/libstdc++-v3/ChangeLog @@ -1,3 +1,94 @@ +2000-12-09 Phil Edwards + + Move the HTML-containing subdirs from 'docs' to 'docs/html'. + * README: Update the locations of instructions. + * docs/doxygen/run_doxygen: New file, stub. + + * docs/Makefile: Moved... + * docs/configopts.html: Likewise. + * docs/documentation.html: Likewise. + * docs/install.html: Likewise. + * docs/lib3styles.css: Likewise. + * docs/17_intro/BADNAMES: Likewise. + * docs/17_intro/BUGS: Likewise. + * docs/17_intro/C++STYLE: Likewise. + * docs/17_intro/CHECKLIST: Likewise. + * docs/17_intro/COPYING: Likewise. + * docs/17_intro/DESIGN: Likewise. + * docs/17_intro/HEADER_POLICY: Likewise. + * docs/17_intro/PROBLEMS: Likewise. + * docs/17_intro/RELEASE-NOTES: Likewise. + * docs/17_intro/TODO: Likewise. + * docs/17_intro/contribute.html: Likewise. + * docs/17_intro/headers_cc.txt: Likewise. + * docs/17_intro/howto.html: Likewise. + * docs/17_intro/libstdc++-assign.txt: Likewise. + * docs/17_intro/organization: Likewise. + * docs/17_intro/porting-howto.html: Likewise. + * docs/18_support/howto.html: Likewise. + * docs/19_diagnostics/howto.html: Likewise. + * docs/20_util/howto.html: Likewise. + * docs/21_strings/gotw29a.txt: Likewise. + * docs/21_strings/howto.html: Likewise. + * docs/21_strings/stringtok_h.txt: Likewise. + * docs/21_strings/stringtok_std_h.txt: Likewise. + * docs/22_locale/codecvt.html: Likewise. + * docs/22_locale/ctype.html: Likewise. + * docs/22_locale/howto.html: Likewise. + * docs/22_locale/locale.html: Likewise. + * docs/23_containers/howto.html: Likewise. + * docs/23_containers/wrappers_h.txt: Likewise. + * docs/24_iterators/howto.html: Likewise. + * docs/25_algorithms/howto.html: Likewise. + * docs/26_numerics/howto.html: Likewise. + * docs/27_io/howto.html: Likewise. + * docs/27_io/iostreams_hierarchy.pdf: Likewise. + * docs/ext/howto.html: Likewise. + * docs/faq/index.html: Likewise. + * docs/faq/index.txt: Likewise. + * docs/html/Makefile: ...to here. + * docs/html/configopts.html: Likewise. + * docs/html/documentation.html: Likewise. + * docs/html/install.html: Likewise. + * docs/html/lib3styles.css: Likewise. + * docs/html/17_intro/BADNAMES: Likewise. + * docs/html/17_intro/BUGS: Likewise. + * docs/html/17_intro/C++STYLE: Likewise. + * docs/html/17_intro/CHECKLIST: Likewise. + * docs/html/17_intro/COPYING: Likewise. + * docs/html/17_intro/DESIGN: Likewise. + * docs/html/17_intro/HEADER_POLICY: Likewise. + * docs/html/17_intro/PROBLEMS: Likewise. + * docs/html/17_intro/RELEASE-NOTES: Likewise. + * docs/html/17_intro/TODO: Likewise. + * docs/html/17_intro/contribute.html: Likewise. + * docs/html/17_intro/headers_cc.txt: Likewise. + * docs/html/17_intro/howto.html: Likewise. + * docs/html/17_intro/libstdc++-assign.txt: Likewise. + * docs/html/17_intro/organization: Likewise. + * docs/html/17_intro/porting-howto.html: Likewise. + * docs/html/18_support/howto.html: Likewise. + * docs/html/19_diagnostics/howto.html: Likewise. + * docs/html/20_util/howto.html: Likewise. + * docs/html/21_strings/gotw29a.txt: Likewise. + * docs/html/21_strings/howto.html: Likewise. + * docs/html/21_strings/stringtok_h.txt: Likewise. + * docs/html/21_strings/stringtok_std_h.txt: Likewise. + * docs/html/22_locale/codecvt.html: Likewise. + * docs/html/22_locale/ctype.html: Likewise. + * docs/html/22_locale/howto.html: Likewise. + * docs/html/22_locale/locale.html: Likewise. + * docs/html/23_containers/howto.html: Likewise. + * docs/html/23_containers/wrappers_h.txt: Likewise. + * docs/html/24_iterators/howto.html: Likewise. + * docs/html/25_algorithms/howto.html: Likewise. + * docs/html/26_numerics/howto.html: Likewise. + * docs/html/27_io/howto.html: Likewise. + * docs/html/27_io/iostreams_hierarchy.pdf: Likewise. + * docs/html/ext/howto.html: Likewise. + * docs/html/faq/index.html: Likewise. + * docs/html/faq/index.txt: Likewise. + 2000-12-08 Phil Edwards * acinclude.m4 (GLIBCPP_ENABLE_CSTDIO): New conditional, diff --git a/libstdc++-v3/README b/libstdc++-v3/README index 7516e5c425e..d795882518c 100644 --- a/libstdc++-v3/README +++ b/libstdc++-v3/README @@ -1,12 +1,12 @@ file: libstdc++-v3/README -New users may wish to point their web browsers to the file index.html -in the 'docs' subdirectory. It contains brief building instructions -and notes on how to configure the library in interesting ways. +New users may wish to point their web browsers to the file documentation.html +in the 'docs/html' subdirectory. It contains brief building instructions and +notes on how to configure the library in interesting ways. Instructions for configuring and building this snapshot appear -in install.html. +in docs/html/install.html. This directory contains the files needed to create [a still broken subset of] an ISO Standard C++ Library. diff --git a/libstdc++-v3/docs/17_intro/BADNAMES b/libstdc++-v3/docs/17_intro/BADNAMES deleted file mode 100644 index 3e9557bc8d9..00000000000 --- a/libstdc++-v3/docs/17_intro/BADNAMES +++ /dev/null @@ -1,162 +0,0 @@ - -This is the list of names "reserved to the implementation" -that have been claimed by certain compilers 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 - -For egcs: - - 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 diff --git a/libstdc++-v3/docs/17_intro/BUGS b/libstdc++-v3/docs/17_intro/BUGS deleted file mode 100644 index 150503593fe..00000000000 --- a/libstdc++-v3/docs/17_intro/BUGS +++ /dev/null @@ -1,31 +0,0 @@ -2000-03-24 libstdc++2.90.8 - -- testsuite/27_io/istream_extractors_char.cc: - Failing on all platforms with -O2, working with -O. Need to look at this. - -- _GLIBCPP_HAS_BUILTIN_SINF: We should still hold out for a cleaner solution the is currenly the case in bits/std_cmath.h. - -- there may be one set of remaining string bugs, dependant on final -clarification of the string::find technicalities when finding in an -empty string or using an empty string for an argument. At the very -least, v-3 has interpreted the standard in a way that is in opposition -to other libraries on other platforms. - -- trigraphs and keywords a la the iso646 header are not correctly -implemented. It looks like the compiler recognizes them as keywords -but then doesn't translate into the correct bit ops. It is a mystery. - -- wide strings have not been tested, and may therefore be unusable. - -- Chapter 27 io functionality is not finished. As such, there are -known bugs in: filebuf::putbackfail - -- Many facet implementations are stubs. (22) - -- Almost no optimizations for small-footprint/low-overhead. (22,27) - -- There has been some work to wrap the C headers in namespace std::, but - it may not be complete yet, and C macros are not shadowed. Please consult - the mailing list archives for more information. - - diff --git a/libstdc++-v3/docs/17_intro/C++STYLE b/libstdc++-v3/docs/17_intro/C++STYLE deleted file mode 100644 index f4f84372403..00000000000 --- a/libstdc++-v3/docs/17_intro/C++STYLE +++ /dev/null @@ -1,318 +0,0 @@ - -C++ Standard Library Style Guidelines DRAFT 1999-02-26 -------------------------------------- - -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 here: - -http://www.gnu.ai.mit.edu/prep/standards_toc.html - -ChangeLog entries for member functions should use the -classname::member function name syntax as follows: - -1999-04-15 Dennis Ritchie - - * 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 - void - template_function(args) - { } - -NOT- - template - 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 - class basic_ios : public ios_base - { - public: - // Types: - }; - -NOT- - template - class basic_ios : public ios_base - { - public: - // Types: - }; - -NOT- - template - 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 defintions - 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: ??? - -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: - // ctor, op=, dtor - gribble() throw(); - - gribble(const gribble&); - - explicit - gribble(int __howmany); - - gribble& - operator=(const gribble&); - - virtual - ~gribble() throw (); - - // argument - 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 - void - public_template() const throw(); - - template - 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 // notice: "typename", not "class", no space - long_return_value_type - 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. - } - -} - - - - diff --git a/libstdc++-v3/docs/17_intro/CHECKLIST b/libstdc++-v3/docs/17_intro/CHECKLIST deleted file mode 100644 index bef9635e850..00000000000 --- a/libstdc++-v3/docs/17_intro/CHECKLIST +++ /dev/null @@ -1,6014 +0,0 @@ - - Completion Checklist for the Standard C++ Library - Updated: 1999-05-18 - - 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: (restricted site) - http://www.cygnus.com/iso/wp/html/fdis/lwg-issues.html - The LWG has announced its intention to release a public version - of the issues list, URL to be added here. XXX - - 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. - - ---------------------------------------------------------------------- - - - -X - - - - - [C header names must be in std:: to qualify. Related to shadow/ dir.] - - -X - - - Macro: -X errno, declared or defined in . - - Macro fn: -X setjmp(jmp_buf), declared or defined in -X va_end(va_list), declared or defined in - - 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 -X NULL -X offsetof -X ptrdiff_t -X size_t - - 18.2 Implementation properties [lib.support.limits] - - , , and - - 18.2.1 Numeric limits [lib.limits] - - [Note: the numeric_limits templates are now automatically - generated. ] - -X template class numeric_limits; - -T enum float_round_style; -T enum float_denorm_style; - -T template<> class numeric_limits; - -T template<> class numeric_limits; -T template<> class numeric_limits; -T template<> class numeric_limits; -T template<> class numeric_limits; - -T template<> class numeric_limits; -T template<> class numeric_limits; -T template<> class numeric_limits; -T template<> class numeric_limits; -T template<> class numeric_limits; -T template<> class numeric_limits; - -X template<> class numeric_limits; -X template<> class numeric_limits; -X template<> class numeric_limits; - - 18.2.1.1 Template class numeric_limits [lib.numeric.limits] -T template 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 (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 (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 (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 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 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 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 (variable arguments), (nonlocal jumps), - (system clock clock(), time()), (signal handling), - and (runtime environment getenv(), system()). - - Table 6--Header synopsis - Macros: va_arg va_end va_start -X Type: va_list - - Table 7--Header synopsis - - Macro: setjmp | -X Type: jmp_buf - Function: longjmp - - Table 8--Header synopsis - - Macros: CLOCKS_PER_SEC -X Types: clock_t - Functions: clock - - Table 9--Header 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 synopsis - -X Functions: getenv system - - 19.1 Exception classes [lib.std.exceptions] - - Header 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 synopsis - -X Macro: assert - - 19.3 Error numbers [lib.errno] - - Table 3--Header synopsis - -X |Macros: EDOM ERANGE errno | - - - 20.2 Utility components [lib.utility] - - Header synopsis - - // _lib.operators_, operators: -X namespace rel_ops { -T template bool operator!=(const T&, const T&); -T template bool operator> (const T&, const T&); -T template bool operator<=(const T&, const T&); -T template bool operator>=(const T&, const T&); - } - // _lib.pairs_, pairs: -T template struct pair; -T template - bool operator==(const pair&, const pair&); -T template - bool operator< (const pair&, const pair&); -T template - bool operator!=(const pair&, const pair&); -T template - bool operator> (const pair&, const pair&); -T template - bool operator>=(const pair&, const pair&); -T template - bool operator<=(const pair&, const pair&); -T template pair make_pair(const T1&, const T2&); - - - 20.2.2 Pairs [lib.pairs] - -T template - 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 pair(const pair &p); - }; - - 20.3 Function objects [lib.function.objects] - - Header synopsis - - // _lib.base_, base: -V template struct unary_function; -V template struct binary_function; - - // _lib.arithmetic.operations_, arithmetic operations: -V template struct plus; -V template struct minus; -V template struct multiplies; -V template struct divides; -V template struct modulus; -V template struct negate; - // _lib.comparisons_, comparisons: -V template struct equal_to; -V template struct not_equal_to; -V template struct greater; -V template struct less; -V template struct greater_equal; -V template struct less_equal; - // _lib.logical.operations_, logical operations: -V template struct logical_and; -V template struct logical_or; -V template struct logical_not; - // _lib.negators_, negators: - template struct unary_negate; -V template - unary_negate not1(const Predicate&); -V template struct binary_negate; -V template - binary_negate not2(const Predicate&); - // _lib.binders_, binders: -V template class binder1st; -V template - binder1st bind1st(const Operation&, const T&); -V template class binder2nd; -V template - binder2nd bind2nd(const Operation&, const T&); - // _lib.function.pointer.adaptors_, adaptors: -V template class pointer_to_unary_function; -V template - pointer_to_unary_function ptr_fun(Result (*)(Arg)); -V template - class pointer_to_binary_function; -V template - pointer_to_binary_function - ptr_fun(Result (*)(Arg1,Arg2)); - - // _lib.member.pointer.adaptors_, adaptors: -V template class mem_fun_t; -V template class mem_fun1_t; -V template - mem_fun_t mem_fun(S (T::*f)()); -V template - mem_fun1_t mem_fun(S (T::*f)(A)); -V template class mem_fun_ref_t; -V template class mem_fun1_ref_t; -V template - mem_fun_ref_t mem_fun_ref(S (T::*f)()); -V template - mem_fun1_ref_t mem_fun_ref(S (T::*f)(A)); - -V template class const_mem_fun_t; -V template class const_mem_fun1_t; -V template - const_mem_fun_t mem_fun(S (T::*f)() const); -V template - const_mem_fun1_t mem_fun(S (T::*f)(A) const); -V template class const_mem_fun_ref_t; -V template class const_mem_fun1_ref_t; -V template - const_mem_fun_ref_t mem_fun_ref(S (T::*f)() const); -V template - const_mem_fun1_ref_t mem_fun_ref(S (T::*f)(A) const); - } - - 20.3.1 Base [lib.base] - -V template - struct unary_function { -V typedef Arg argument_type; -V typedef Result result_type; - }; -V template - 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 struct plus : binary_function { -V T operator()(const T& x, const T& y) const; - }; - -T template struct minus : binary_function { -V T operator()(const T& x, const T& y) const; - }; - -T template struct multiplies : binary_function { -V T operator()(const T& x, const T& y) const; - }; - -T template struct divides : binary_function { -V T operator()(const T& x, const T& y) const; - }; - -T template struct modulus : binary_function { -V T operator()(const T& x, const T& y) const; - }; - -T template struct negate : unary_function { -V T operator()(const T& x) const; - }; - - 20.3.3 Comparisons [lib.comparisons] - -T template struct equal_to : binary_function { -V bool operator()(const T& x, const T& y) const; - }; - -T template struct not_equal_to : binary_function { -V bool operator()(const T& x, const T& y) const; - }; - -T template struct greater : binary_function { -V bool operator()(const T& x, const T& y) const; - }; - -T template struct less : binary_function { -V bool operator()(const T& x, const T& y) const; - }; - -T template struct greater_equal : binary_function { -V bool operator()(const T& x, const T& y) const; - }; - -T template struct less_equal : binary_function { -V bool operator()(const T& x, const T& y) const; - }; - - 20.3.4 Logical operations [lib.logical.operations] - -T template struct logical_and : binary_function { -V bool operator()(const T& x, const T& y) const; - }; - -T template struct logical_or : binary_function { -V bool operator()(const T& x, const T& y) const; - }; - -T template struct logical_not : unary_function { -V bool operator()(const T& x) const; - }; - - 20.3.5 Negators [lib.negators] - -T template - class unary_negate - : public unary_function { - public: -T explicit unary_negate(const Predicate& pred); -V bool operator()(const typename Predicate::argument_type& x) const; - }; - -T template - class binary_negate - : public binary_function { - 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 binder1st - : public unary_function { - 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 - binder1st bind1st(const Operation& op, const T& x); - - 20.3.6.3 Template class binder2nd [lib.binder.2nd] -T template - class binder2nd - : public unary_function { - 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 - binder2nd 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 pointer_to_unary_function : public unary_function { - public: -T explicit pointer_to_unary_function(Result (*f)(Arg)); -V Result operator()(Arg x) const; - }; - -T template - pointer_to_unary_function ptr_fun(Result (*f)(Arg)); - -T template - class pointer_to_binary_function : - public binary_function { - 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 mem_fun_t - : public unary_function { - public: -T explicit mem_fun_t(S (T::*p)()); -V S operator()(T* p) const; - }; - -T template class mem_fun1_t - : public binary_function { - public: -T explicit mem_fun1_t(S (T::*p)(A)); -V S operator()(T* p, A x) const; - }; - -V template mem_fun_t - mem_fun(S (T::*f)()); -V template mem_fun1_t - mem_fun(S (T::*f)(A)); - -T template class mem_fun_ref_t - : public unary_function { - public: -T explicit mem_fun_ref_t(S (T::*p)()); -V S operator()(T& p) const; - }; - -T template class mem_fun1_ref_t - : public binary_function { - public: -T explicit mem_fun1_ref_t(S (T::*p)(A)); -V S operator()(T& p, A x) const; - }; - -T template mem_fun_ref_t - mem_fun_ref(S (T::*f)()); - -T template mem_fun1_ref_t - mem_fun_ref(S (T::*f)(A)); - -T template class const_mem_fun_t - : public unary_function { - public: -T explicit const_mem_fun_t(S (T::*p)() const); -V S operator()(const T* p) const; - }; - -T template class const_mem_fun1_t - : public binary_function { - public: -T explicit const mem_fun1_t(S (T::*p)(A) const); -V S operator()(const T* p, A x) const; - }; - -V template const_mem_fun_t - mem_fun(S (T::*f)() const); -V template const_mem_fun1_t - mem_fun(S (T::*f)(A) const); - -T template class const_mem_fun_ref_t - : public unary_function { - public: -T explicit const_mem_fun_ref_t(S (T::*p)() const); -V S operator()(const T& p) const; - }; - -T template class const_mem_fun1_ref_t - : public binary_function { - public: -T explicit const_mem_fun1_ref_t(S (T::*p)(A) const); -V S operator()(const T& p, A x) const; - }; - -T template const_mem_fun_ref_t - mem_fun_ref(S (T::*f)() const); - -T template const_mem_fun1_ref_t - mem_fun_ref(S (T::*f)(A) const); - - 20.4 Memory [lib.memory] - - Header synopsis - - // _lib.default.allocator_, the default allocator: -T template class allocator; -T template <> class allocator; -T template - bool operator==(const allocator&, const allocator&) throw(); -T template - bool operator!=(const allocator&, const allocator&) throw(); - // _lib.storage.iterator_, raw storage iterator: -T template class raw_storage_iterator; - // _lib.temporary.buffer_, temporary buffers: -T template - pair get_temporary_buffer(ptrdiff_t n); -T template - void return_temporary_buffer(T* p); - // _lib.specialized.algorithms_, specialized algorithms: -T template - ForwardIterator - uninitialized_copy(InputIterator first, InputIterator last, - ForwardIterator result); -T template - void uninitialized_fill(ForwardIterator first, ForwardIterator last, - const T& x); -T template - void uninitialized_fill_n(ForwardIterator first, Size n, const T& x); - // _lib.auto.ptr_, pointers: -X template class auto_ptr; - } - - 20.4.1 The default allocator [lib.default.allocator] - -T template class allocator; - // specialize for void: -T template <> class allocator { - public: -T typedef void* pointer; -T typedef const void* const_pointer; - // reference-to-void members are impossible. -T typedef void value_type; -T template struct rebind { typedef allocator other; }; - }; - -T template 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 struct rebind { typedef allocator other; }; -T allocator() throw(); -T allocator(const allocator&) throw(); -T template allocator(const allocator&) throw(); -T ~allocator() throw(); -T pointer address(reference x) const; -T const_pointer address(const_reference x) const; -T pointer allocate( - size_type, allocator::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 - bool operator==(const allocator&, const allocator&) throw(); -T template - bool operator!=(const allocator&, const allocator&) throw(); - - 20.4.2 Raw storage iterator [lib.storage.iterator] - -T template - class raw_storage_iterator - : public iterator { - public: -T explicit raw_storage_iterator(OutputIterator x); -T raw_storage_iterator& operator*(); -T raw_storage_iterator& operator=(const T& element); -T raw_storage_iterator& operator++(); -T raw_storage_iterator operator++(int); - }; - - 20.4.3 Temporary buffers [lib.temporary.buffer] - -T template - pair get_temporary_buffer(ptrdiff_t n); - -T template 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 - ForwardIterator - uninitialized_copy(InputIterator first, InputIterator last, - ForwardIterator result); - - 20.4.4.2 uninitialized_fill [lib.uninitialized.fill] - -V template - void uninitialized_fill(ForwardIterator first, ForwardIterator last, - const T& x); - - 20.4.4.3 uninitialized_fill_n [lib.uninitialized.fill.n] - -V template - void uninitialized_fill_n(ForwardIterator first, Size n, const T& x); - - 20.4.5 Template class auto_ptr [lib.auto.ptr] - -X template class auto_ptr { - template 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 auto_ptr(auto_ptr&) throw(); -T auto_ptr& operator=(auto_ptr&) throw(); -T template auto_ptr& operator=(auto_ptr&) 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_ converions: -X auto_ptr(auto_ptr_ref) throw(); -X template operator auto_ptr_ref() throw(); -X template operator auto_ptr() throw(); - }; - - 20.4.6 C Library [lib.c.malloc] - - Table 7--Header synopsis - -X Functions: calloc malloc - free realloc - - - Table 8--Header synopsis - -X Macro: NULL -X Type: size_t -X Functions: memchr memcmp -X memcpy memmove memset - - Table 9--Header 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 struct char_traits; - shall be provided in the header as a basis for explicit spe- - cializations. - - - 21.1.3.1 struct [lib.char.traits.specializations.char] - char_traits - -T template<> - struct char_traits { -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 - -V template<> - struct char_traits { -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 - struct char_traits; -V template <> struct char_traits; -V template <> struct char_traits; - - // _lib.basic.string_, basic_string: -V template, - class Allocator = allocator > - class basic_string; -V template - basic_string - operator+(const basic_string& lhs, - const basic_string& rhs); -V template - basic_string - operator+(const charT* lhs, - const basic_string& rhs); -V template - basic_string - operator+(charT lhs, const basic_string& rhs); -V template - basic_string - operator+(const basic_string& lhs, - const charT* rhs); -V template - basic_string - operator+(const basic_string& lhs, charT rhs); - -V template - bool operator==(const basic_string& lhs, - const basic_string& rhs); -V template - bool operator==(const charT* lhs, - const basic_string& rhs); -V template - bool operator==(const basic_string& lhs, - const charT* rhs); -V template - bool operator!=(const basic_string& lhs, - const basic_string& rhs); -V template - bool operator!=(const charT* lhs, - const basic_string& rhs); -V template - bool operator!=(const basic_string& lhs, - const charT* rhs); -V template - bool operator< (const basic_string& lhs, - const basic_string& rhs); -V template - bool operator< (const basic_string& lhs, - const charT* rhs); -V template - bool operator< (const charT* lhs, - const basic_string& rhs); -V template - bool operator> (const basic_string& lhs, - const basic_string& rhs); -V template - bool operator> (const basic_string& lhs, - const charT* rhs); -V template - bool operator> (const charT* lhs, - const basic_string& rhs); -V template - bool operator<=(const basic_string& lhs, - const basic_string& rhs); -V template - bool operator<=(const basic_string& lhs, - const charT* rhs); -V template - bool operator<=(const charT* lhs, - const basic_string& rhs); -V template - bool operator>=(const basic_string& lhs, - const basic_string& rhs); -V template - bool operator>=(const basic_string& lhs, - const charT* rhs); -V template - bool operator>=(const charT* lhs, - const basic_string& rhs); - - // _lib.string.special_: -V template - void swap(basic_string& lhs, - basic_string& rhs); -V template - basic_istream& - operator>>(basic_istream& is, - basic_string& str); -T template - basic_ostream& - operator<<(basic_ostream& os, - const basic_string& str); -V template - basic_istream& - getline(basic_istream& is, - basic_string& str, - charT delim); -V template - basic_istream& - getline(basic_istream& is, - basic_string& str); -V typedef basic_string string; -T typedef basic_string wstring; - } - - 21.3 Template class basic_string [lib.basic.string] - -V namespace std { - template, - class Allocator = allocator > - 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 reverse_iterator; - typedef std::reverse_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 - 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 - 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 - 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 - 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 - 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&); - // _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 synopsis - - isalnum isdigit isprint isupper tolower -X isalpha isgraph ispunct isxdigit toupper - iscntrl islower isspace - - Table 11--Header synopsis - -X Macro: WEOF -X Types: wctrans_t wctype_t wint_t - Functions: -X iswalnum iswctype iswlower iswspace towctrans wctrans -X iswalpha iswdigit iswprint iswupper towlower wctype -X iswcntrl iswgraph iswpunct iswxdigit towupper - - Table 12--Header synopsis - -X Macro: NULL -X Type: size_t - 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 synopsis - Macros: NULL WCHAR_MAX WCHAR_MIN WEOF - Types: mbstate_t wint_t 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 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 synopsis - - // _lib.locale_, locale: -T class locale; -T template const Facet& use_facet(const locale&); -T template bool has_facet(const locale&) throw(); - - // _lib.locale.convenience_, convenience interfaces: -T template bool isspace (charT c, const locale& loc); -T template bool isprint (charT c, const locale& loc); -T template bool iscntrl (charT c, const locale& loc); -T template bool isupper (charT c, const locale& loc); -T template bool islower (charT c, const locale& loc); -T template bool isalpha (charT c, const locale& loc); -T template bool isdigit (charT c, const locale& loc); -T template bool ispunct (charT c, const locale& loc); -T template bool isxdigit(charT c, const locale& loc); -T template bool isalnum (charT c, const locale& loc); -T template bool isgraph (charT c, const locale& loc); -T template charT toupper(charT c, const locale& loc); -T template charT tolower(charT c, const locale& loc); - // _lib.category.ctype_ and _lib.facet.ctype.special_, ctype: - class ctype_base; -T template class ctype; -T template <> class ctype; // specialization -S template class ctype_byname; -S template <> class ctype_byname; // specialization -T class codecvt_base; -X template class codecvt; -S template class codecvt_byname; - // _lib.category.numeric_ and _lib.facet.numpunct_, numeric: -X template class num_get; -X template class num_put; -T template class numpunct; -S template class numpunct_byname; - // _lib.category.collate_, collation: -T template class collate; -S template class collate_byname; - // _lib.category.time_, date and time: -T class time_base; -S template class time_get; -S template class time_get_byname; -S template class time_put; -S template class time_put_byname; - // _lib.category.monetary_, money: -T class money_base; -S template class money_get; -S template class money_put; -S template class moneypunct; -S template class moneypunct_byname; - // _lib.category.messages_, message retrieval: -T class messages_base; -S template class messages; -S template 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 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 locale combine(const locale& other) const; - // locale operations: -X basic_string name() const; -T bool operator==(const locale& other) const; -T bool operator!=(const locale& other) const; -T template - bool operator()(const basic_string& s1, - const basic_string& 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, collate -T ctype, ctype -T codecvt, -S codecvt -T moneypunct, moneypunct -T moneypunct, moneypunct, -S money_get, money_get, money_put -T numpunct, numpunct, -X num_get, num_get -X num_put, num_put -S time_get, time_get, -S time_put, time_put -S messages, messages - - [required instantiations] -S collate_byname, collate_byname -S ctype_byname, ctype_byname -S codecvt_byname, -S codecvt_byname -S moneypunct_byname, -S moneypunct_byname, -S money_get, -S money_put -S numpunct_byname, numpunct_byname -X num_get, num_put -S time_get, -S time_get_byname, -S time_get, -S time_get_byname, -S time_put, -S time_put_byname, -S time_put -S time_put_byname -S messages_byname, messages_byname - - - 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 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 ctype_byname : public ctype { - public: -T typedef ctype::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 - : 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 - -X template <> class ctype_byname : public ctype { - 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 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 codecvt_byname : public codecvt { - 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 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 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 numpunct : public locale::facet { - public: -T typedef charT char_type; -T typedef basic_string 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 numpunct_byname : public numpunct { - // this class is specialized for char and wchar_t. - public: -T typedef charT char_type; -T typedef basic_string 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 collate : public locale::facet { - public: -T typedef charT char_type; -T typedef basic_string 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 collate_byname : public collate { - public: -T typedef basic_string 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 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 time_get_byname : public time_get { - 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 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 time_put_byname : public time_put - { - 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 money_get : public locale::facet { - public: -T typedef charT char_type; -T typedef InputIterator iter_type; -T typedef basic_string 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 money_put : public locale::facet { - public: -T typedef charT char_type; -T typedef OutputIterator iter_type; -T typedef basic_string 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 moneypunct : public locale::facet, public money_base { - public: -T typedef charT char_type; -T typedef basic_string 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 moneypunct_byname : public moneypunct { - public: -T typedef money_base::pattern pattern; -T typedef basic_string 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 messages : public locale::facet, public messages_base { - public: -T typedef charT char_type; -T typedef basic_string string_type; -T explicit messages(size_t refs = 0); -T catalog open(const basic_string& 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&, 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 messages_byname : public messages { - public: -T typedef messages_base::catalog catalog; -T typedef basic_string 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&, 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 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] - - , , , , and . - - Header synopsis - -X template > class deque; -T template - bool operator==(const deque& x, const deque& y); -T template - bool operator< (const deque& x, const deque& y); -T template - bool operator!=(const deque& x, const deque& y); -T template - bool operator> (const deque& x, const deque& y); -T template - bool operator>=(const deque& x, const deque& y); -T template - bool operator<=(const deque& x, const deque& y); -T template - void swap(deque& x, deque& y); - } - - Header synopsis - -X template > class list; -T template - bool operator==(const list& x, const list& y); -T template - bool operator< (const list& x, const list& y); -T template - bool operator!=(const list& x, const list& y); -T template - bool operator> (const list& x, const list& y); -T template - bool operator>=(const list& x, const list& y); -T template - bool operator<=(const list& x, const list& y); -T template - void swap(list& x, list& y); - } - - Header synopsis - - namespace std { -X template > class queue; -T template - bool operator==(const queue& x, - const queue& y); -T template - bool operator< (const queue& x, - const queue& y); -T template - bool operator!=(const queue& x, - const queue& y); -T template - bool operator> (const queue& x, - const queue& y); -T template - bool operator>=(const queue& x, - const queue& y); -T template - bool operator<=(const queue& x, - const queue& y); -T template , - class Compare = less > -T class priority_queue; - } - - Header synopsis - - namespace std { -T template > class stack; -T template - bool operator==(const stack& x, - const stack& y); -T template - bool operator< (const stack& x, - const stack& y); -T template - bool operator!=(const stack& x, - const stack& y); -T template - bool operator> (const stack& x, - const stack& y); -T template - bool operator>=(const stack& x, - const stack& y); -T template - bool operator<=(const stack& x, - const stack& y); - } - - Header synopsis - -T template > class vector; - -T template - bool operator==(const vector& x, - const vector& y); -T template - bool operator< (const vector& x, - const vector& y); -T template - bool operator!=(const vector& x, - const vector& y); -T template - bool operator> (const vector& x, - const vector& y); -T template - bool operator>=(const vector& x, - const vector& y); -T template - bool operator<=(const vector& x, - const vector& y); -T template - void swap(vector& x, vector& y); - -T template class vector; -T template - bool operator==(const vector& x, - const vector& y); -T template - bool operator< (const vector& x, - const vector& y); -T template - bool operator!=(const vector& x, - const vector& y); -T template - bool operator> (const vector& x, - const vector& y); -T template - bool operator>=(const vector& x, - const vector& y); -T template - bool operator<=(const vector& x, - const vector& y); -T template - void swap(vector& x, vector& y); - } - - 23.2.1 Template class deque [lib.deque] - - template > -X class deque { - public: - // types: -T typedef typename Allocator::reference reference; -T typedef typename Allocator::const_reference const_reference; -X typedef implementation defined iterator; -X 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 reverse_iterator; -T typedef std::reverse_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 - deque(InputIterator first, InputIterator last, - const Allocator& = Allocator()); -T deque(const deque& x); -T ~deque(); -T deque& operator=(const deque& x); -T template - 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 - 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 void clear(); - }; -T template - bool operator==(const deque& x, - const deque& y); -T template - bool operator< (const deque& x, - const deque& y); -T template - bool operator!=(const deque& x, - const deque& y); -T template - bool operator> (const deque& x, - const deque& y); -T template - bool operator>=(const deque& x, - const deque& y); -T template - bool operator<=(const deque& x, - const deque& y); - // specialized algorithms: -T template - void swap(deque& x, deque& y); - - - 23.2.2 Template class list [lib.list] - -X template > - class list { - public: - // types: -T typedef typename Allocator::reference reference; -T typedef typename Allocator::const_reference const_reference; -X typedef implementation defined iterator; -X 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 reverse_iterator; -T typedef std::reverse_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 - list(InputIterator first, InputIterator last, - const Allocator& = Allocator()); -T list(const list& x); -T ~list(); -T list& operator=(const list& x); -T template - 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 - 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 void clear(); - // _lib.list.ops_ list operations: -T void splice(iterator position, list& x); -T void splice(iterator position, list& x, iterator i); -T void splice(iterator position, list& x, iterator first, - iterator last); -T void remove(const T& value); -T template void remove_if(Predicate pred); - -T void unique(); -T template - void unique(BinaryPredicate binary_pred); -T void merge(list& x); -T template void merge(list& x, Compare comp); - void sort(); -T template void sort(Compare comp); - void reverse(); - }; -T template - bool operator==(const list& x, const list& y); -T template - bool operator< (const list& x, const list& y); -T template - bool operator!=(const list& x, const list& y); -T template - bool operator> (const list& x, const list& y); -T template - bool operator>=(const list& x, const list& y); -T template - bool operator<=(const list& x, const list& y); - // specialized algorithms: -T template - void swap(list& x, list& y); - - - 23.2.3.1 Template class queue [lib.queue] - -T template > - 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 - bool operator==(const queue& x, - const queue& y); -T template - bool operator< (const queue& x, - const queue& y); -T template - bool operator!=(const queue& x, - const queue& y); -T template - bool operator> (const queue& x, - const queue& y); -T template - bool operator>=(const queue& x, - const queue& y); -T template - bool operator<=(const queue& x, - const queue& y); - - 23.2.3.2 Template class priority_queue [lib.priority.queue] - -T template , - class Compare = less > - 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 - 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 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 - bool operator==(const stack& x, - const stack& y); -T template - bool operator< (const stack& x, - const stack& y); -T template - bool operator!=(const stack& x, - const stack& y); -T template - bool operator> (const stack& x, - const stack& y); -T template - bool operator>=(const stack& x, - const stack& y); -T template - bool operator<=(const stack& x, - const stack& y); - - 23.2.4 Template class vector [lib.vector] - - template > -X class vector { - public: - // types: -T typedef typename Allocator::reference reference; -T typedef typename Allocator::const_reference const_reference; -X typedef implementation defined iterator; -X 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 reverse_iterator; -T typedef std::reverse_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 - vector(InputIterator first, InputIterator last, - const Allocator& = Allocator()); -T vector(const vector& x); -T ~vector(); -T vector& operator=(const vector& x); -T template - 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 - 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 void clear(); - }; - -T template - bool operator==(const vector& x, - const vector& y); -T template - bool operator< (const vector& x, - const vector& y); -T template - bool operator!=(const vector& x, - const vector& y); -T template - bool operator> (const vector& x, - const vector& y); -T template - bool operator>=(const vector& x, - const vector& y); -T template - bool operator<=(const vector& x, - const vector& y); - // specialized algorithms: -T template - void swap(vector& x, vector& y); - - - 23.2.5 Class vector [lib.vector.bool] - -X template class vector { - public: - // types: -T typedef bool const_reference; -X typedef implementation defined iterator; -X 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 reverse_iterator; -T typedef std::reverse_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 - vector(InputIterator first, InputIterator last, - const Allocator& = Allocator()); -T vector(const vector& x); -T ~vector(); -T vector& operator=(const vector& x); -T template - 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 - 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 static void swap(reference x, reference y); -T void flip(); // flips all bits -T void clear(); - }; - -T template - bool operator==(const vector& x, - const vector& y); -T template - bool operator< (const vector& x, - const vector& y); -T template - bool operator!=(const vector& x, - const vector& y); -T template - bool operator> (const vector& x, - const vector& y); -T template - bool operator>=(const vector& x, - const vector& y); -T template - bool operator<=(const vector& x, - const vector& y); - // specialized algorithms: -T template - void swap(vector& x, vector& y); - - 23.3 Associative containers [lib.associative] - - and : - - Header synopsis - - template , - class Allocator = allocator > > -X class map; - -T template - bool operator==(const map& x, - const map& y); -T template - bool operator< (const map& x, - const map& y); -T template - bool operator!=(const map& x, - const map& y); -T template - bool operator> (const map& x, - const map& y); -T template - bool operator>=(const map& x, - const map& y); -T template - bool operator<=(const map& x, - const map& y); -T template - void swap(map& x, - map& y); -T template , - class Allocator = allocator > > - class multimap; -T template - bool operator==(const multimap& x, - const multimap& y); -T template - bool operator< (const multimap& x, - const multimap& y); -T template - bool operator!=(const multimap& x, - const multimap& y); -T template - bool operator> (const multimap& x, - const multimap& y); -T template - bool operator>=(const multimap& x, - const multimap& y); -T template - bool operator<=(const multimap& x, - const multimap& y); -T template - void swap(multimap& x, - multimap& y); - } - - Header synopsis - - template , - class Allocator = allocator > -X class set; - -T template - bool operator==(const set& x, - const set& y); -T template - bool operator< (const set& x, - const set& y); -T template - bool operator!=(const set& x, - const set& y); -T template - bool operator> (const set& x, - const set& y); -T template - bool operator>=(const set& x, - const set& y); -T template - bool operator<=(const set& x, - const set& y); -T template - void swap(set& x, - set& y); -T template , - class Allocator = allocator > - class multiset; -T template - bool operator==(const multiset& x, - const multiset& y); -T template - bool operator< (const multiset& x, - const multiset& y); -T template - bool operator!=(const multiset& x, - const multiset& y); -T template - bool operator> (const multiset& x, - const multiset& y); -T template - bool operator>=(const multiset& x, - const multiset& y); -T template - bool operator<=(const multiset& x, - const multiset& y); -T template - void swap(multiset& x, - multiset& y); - } - - 23.3.1 Template class map [lib.map] - - template , - class Allocator = allocator > > -X class map { - public: - // types: -T typedef Key key_type; -T typedef T mapped_type; -T typedef pair 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; -X typedef implementation defined iterator; -X 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 reverse_iterator; -T typedef std::reverse_iterator const_reverse_iterator; -T class value_compare - : public binary_function { - 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 - map(InputIterator first, InputIterator last, - const Compare& comp = Compare(), const Allocator& = Allocator()); -T map(const map& x); -T ~map(); -T map& - operator=(const map& 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 insert(const value_type& x); -T iterator insert(iterator position, const value_type& x); -T template - 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&); -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 - equal_range(const key_type& x); -T pair - equal_range(const key_type& x) const; - }; - -T template - bool operator==(const map& x, - const map& y); -T template - bool operator< (const map& x, - const map& y); -T template - bool operator!=(const map& x, - const map& y); -T template - bool operator> (const map& x, - const map& y); -T template - bool operator>=(const map& x, - const map& y); -T template - bool operator<=(const map& x, - const map& y); - // specialized algorithms: -T template - void swap(map& x, - map& y); - - 23.3.2 Template class multimap [lib.multimap] - - template , - class Allocator = allocator > > -X class multimap { - public: - // types: -T typedef Key key_type; -T typedef T mapped_type; -T typedef pair 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; -X typedef implementation defined iterator; -X 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 reverse_iterator; -T typedef std::reverse_iterator const_reverse_iterator; -T class value_compare - : public binary_function { - 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 - multimap(InputIterator first, InputIterator last, - const Compare& comp = Compare(), - const Allocator& = Allocator()); -T multimap(const multimap& x); -T ~multimap(); -T multimap& - operator=(const multimap& 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 - 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&); -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 equal_range(const key_type& x); -T pair equal_range(const key_type& x) const; - }; - -T template - bool operator==(const multimap& x, - const multimap& y); -T template - bool operator< (const multimap& x, - const multimap& y); -T template - bool operator!=(const multimap& x, - const multimap& y); -T template - bool operator> (const multimap& x, - const multimap& y); -T template - bool operator>=(const multimap& x, - const multimap& y); -T template - bool operator<=(const multimap& x, - const multimap& y); - // specialized algorithms: -T template - void swap(multimap& x, - multimap& y); - - - 23.3.3 Template class set [lib.set] - - template , - class Allocator = allocator > -X 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; -X typedef implementation defined iterator; -X 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 reverse_iterator; -T typedef std::reverse_iterator const_reverse_iterator; - // _lib.set.cons_ construct/copy/destroy: -T explicit set(const Compare& comp = Compare(), - const Allocator& = Allocator()); -T template - set(InputIterator first, InputIterator last, - const Compare& comp = Compare(), const Allocator& = Allocator()); -T set(const set& x); -T ~set(); -T set& - operator=(const set& 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 insert(const value_type& x); -T iterator insert(iterator position, const value_type& x); -T template -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&); -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 equal_range(const key_type& x) const; - }; -T template - bool operator==(const set& x, - const set& y); -T template - bool operator< (const set& x, - const set& y); -T template - bool operator!=(const set& x, - const set& y); -T template - bool operator> (const set& x, - const set& y); -T template - bool operator>=(const set& x, - const set& y); -T template - bool operator<=(const set& x, - const set& y); - // specialized algorithms: -T template - void swap(set& x, - set& y); - - 23.3.4 Template class multiset [lib.multiset] - - template , - class Allocator = allocator > -X 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; -X typedef implementation defined iterator; -X 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 reverse_iterator; -T typedef std::reverse_iterator const_reverse_iterator; - - // construct/copy/destroy: -T explicit multiset(const Compare& comp = Compare(), - const Allocator& = Allocator()); -T template - multiset(InputIterator first, InputIterator last, - const Compare& comp = Compare(), - const Allocator& = Allocator()); -T multiset(const multiset& x); -T ~multiset(); -T multiset& - operator=(const multiset& 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 - 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&); -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 equal_range(const key_type& x) const; - }; - -T template - bool operator==(const multiset& x, - const multiset& y); -T template - bool operator< (const multiset& x, - const multiset& y); -T template - bool operator!=(const multiset& x, - const multiset& y); -T template - bool operator> (const multiset& x, - const multiset& y); -T template - bool operator>=(const multiset& x, - const multiset& y); -T template - bool operator<=(const multiset& x, - const multiset& y); - // specialized algorithms: -T template - void swap(multiset& x, - multiset& y); - - 23.3.5 Template class bitset [lib.template.bitset] - - Header synopsis - - [What's this stuff? - #include // for size_t - #include - #include // for invalid_argument, - // out_of_range, overflow_error - #include // for istream, ostream - ] -X template class bitset; - // _lib.bitset.operators_ bitset operations: -T template - bitset operator&(const bitset&, const bitset&); -T template - bitset operator|(const bitset&, const bitset&); -T template - bitset operator^(const bitset&, const bitset&); -T template - basic_istream& - operator>>(basic_istream& is, bitset& x); -T template - basic_ostream& - operator<<(basic_ostream& os, const bitset& x); - -X template 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 - explicit bitset( - const basic_string& str, - typename basic_string::size_type pos = 0, - typename basic_string::size_type n = - basic_string::npos); - // _lib.bitset.members_ bitset operations: -T bitset& operator&=(const bitset& rhs); -T bitset& operator|=(const bitset& rhs); -T bitset& operator^=(const bitset& rhs); -T bitset& operator<<=(size_t pos); -T bitset& operator>>=(size_t pos); -T bitset& set(); -T bitset& set(size_t pos, int val = true); -T bitset& reset(); -T bitset& reset(size_t pos); -T bitset operator~() const; -T bitset& flip(); -T bitset& flip(size_t pos); - // element access: -T reference operator[](size_t pos); // for b[i]; -T unsigned long to_ulong() const; -T template - basic_string to_string() const; -T size_t count() const; -T size_t size() const; -T bool operator==(const bitset& rhs) const; -T bool operator!=(const bitset& rhs) const; -T bool test(size_t pos) const; -T bool any() const; -T bool none() const; -T bitset operator<<(size_t pos) const; -T bitset operator>>(size_t pos) const; - }; - - - - - 24.2 Header synopsis [lib.iterator.synopsis] - - // _lib.iterator.primitives_, primitives: -T template struct iterator_traits; -T template struct iterator_traits; - -X template 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 - void advance(InputIterator& i, Distance n); -T template - typename iterator_traits::difference_type - distance(InputIterator first, InputIterator last); - // _lib.predef.iterators_, predefined iterators: -X template class reverse_iterator; -T template - bool operator==( - const reverse_iterator& x, - const reverse_iterator& y); -T template - bool operator<( - const reverse_iterator& x, - const reverse_iterator& y); -T template - bool operator!=( - const reverse_iterator& x, - const reverse_iterator& y); -T template - bool operator>( - const reverse_iterator& x, - const reverse_iterator& y); -T template - bool operator>=( - const reverse_iterator& x, - const reverse_iterator& y); -T template - bool operator<=( - const reverse_iterator& x, - const reverse_iterator& y); -T template - typename reverse_iterator::difference_type operator-( - const reverse_iterator& x, - const reverse_iterator& y); -T template - reverse_iterator - operator+( - typename reverse_iterator::difference_type n, - const reverse_iterator& x); - -X template class back_insert_iterator; -T template - back_insert_iterator back_inserter(Container& x); -X template class front_insert_iterator; -T template - front_insert_iterator front_inserter(Container& x); -X template class insert_iterator; -T template - insert_iterator inserter(Container& x, Iterator i); - // _lib.stream.iterators_, stream iterators: -X template , - class Distance = ptrdiff_t> - class istream_iterator; - template -X bool operator==(const istream_iterator& x, - const istream_iterator& y); - template -X bool operator!=(const istream_iterator& x, - const istream_iterator& y); -X template > - class ostream_iterator; -X template > - class istreambuf_iterator; -X template - bool operator==(const istreambuf_iterator& a, - const istreambuf_iterator& b); -X template - bool operator!=(const istreambuf_iterator& a, - const istreambuf_iterator& b); -T template > - class ostreambuf_iterator; - - 24.3 Iterator primitives [lib.iterator.primitives] - -T template 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 struct iterator_traits { -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 struct iterator_traits { -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 -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 -X class reverse_iterator : public - iterator::iterator_category, - typename iterator_traits::value_type, - typename iterator_traits::difference_type, - typename iterator_traits::pointer, - typename iterator_traits::reference> { - protected: -T Iterator current; - public: -T typedef Iterator - iterator_type; -T typedef typename iterator_traits::difference_type - difference_type; -T typedef typename iterator_traits::reference - reference; -T typedef typename iterator_traits::pointer - pointer; - -T reverse_iterator(); -T explicit reverse_iterator(Iterator x); -T template reverse_iterator(const reverse_iterator& 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 - bool operator==( - const reverse_iterator& x, - const reverse_iterator& y); -T template - bool operator<( - const reverse_iterator& x, - const reverse_iterator& y); -T template - bool operator!=( - const reverse_iterator& x, - const reverse_iterator& y); -T template - bool operator>( - const reverse_iterator& x, - const reverse_iterator& y); -T template - bool operator>=( - const reverse_iterator& x, - const reverse_iterator& y); -T template - bool operator<=( - const reverse_iterator& x, - const reverse_iterator& y); -T template - typename reverse_iterator::difference_type operator-( - const reverse_iterator& x, - const reverse_iterator& y); -T template - reverse_iterator operator+( - typename reverse_iterator::difference_type n, - const reverse_iterator& x); - - - 24.4.2.1 Template class [lib.back.insert.iterator] - back_insert_iterator - - template -X class back_insert_iterator : - public iterator { - protected: -T Container* container; - public: -T typedef Container container_type; -T explicit back_insert_iterator(Container& x); -T back_insert_iterator& - operator=(typename Container::const_reference value); - -T back_insert_iterator& operator*(); -T back_insert_iterator& operator++(); -T back_insert_iterator operator++(int); - }; -T template - back_insert_iterator back_inserter(Container& x); - - - - 24.4.2.3 Template class [lib.front.insert.iterator] - front_insert_iterator - - template -X class front_insert_iterator : - public iterator { - protected: -T Container* container; - public: -T typedef Container container_type; -T explicit front_insert_iterator(Container& x); -T front_insert_iterator& - operator=(typename Container::const_reference value); -T front_insert_iterator& operator*(); -T front_insert_iterator& operator++(); -T front_insert_iterator operator++(int); - }; -T template - front_insert_iterator front_inserter(Container& x); - - - 24.4.2.5 Template class insert_iterator [lib.insert.iterator] - - template -X class insert_iterator : - public iterator { - 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& - operator=(typename Container::const_reference value); -T insert_iterator& operator*(); -T insert_iterator& operator++(); -T insert_iterator& operator++(int); - }; -T template - insert_iterator inserter(Container& x, Iterator i); - - 24.5.1 Template class istream_iterator [lib.istream.iterator] - - template , - class Distance = ptrdiff_t> -X class istream_iterator: - public iterator { - public: -T typedef charT char_type -T typedef traits traits_type; -T typedef basic_istream istream_type; -T istream_iterator(); -T istream_iterator(istream_type& s); -T istream_iterator(const istream_iterator& x); -T ~istream_iterator(); - -T const T& operator*() const; -T const T* operator->() const; -T istream_iterator& operator++(); -T istream_iterator operator++(int); - }; - -T template - bool operator==(const istream_iterator& x, - const istream_iterator& y); -T template - bool operator!=(const istream_iterator& x, - const istream_iterator& y); - - - 24.5.2 Template class ostream_iterator [lib.ostream.iterator] - - template > -X class ostream_iterator: - public iterator { - public: -T typedef charT char_type; -T typedef traits traits_type; -T typedef basic_ostream ostream_type; -T ostream_iterator(ostream_type& s); -T ostream_iterator(ostream_type& s, const charT* delimiter); -T ostream_iterator(const ostream_iterator& x); -T ~ostream_iterator(); -T ostream_iterator& operator=(const T& value); - -T ostream_iterator& operator*(); -T ostream_iterator& operator++(); -T ostream_iterator& operator++(int); - }; - - - 24.5.3 Template class [lib.istreambuf.iterator] - istreambuf_iterator - - template > -X class istreambuf_iterator - : public iterator { - public: -T typedef charT char_type; -T typedef traits traits_type; -T typedef typename traits::int_type int_type; -T typedef basic_streambuf streambuf_type; -T typedef basic_istream 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& operator++(); -T proxy operator++(int); -X bool equal(istreambuf_iterator& b); - }; - -T template - bool operator==(const istreambuf_iterator& a, - const istreambuf_iterator& b); - -T template - bool operator!=(const istreambuf_iterator& a, - const istreambuf_iterator& b); - - 24.5.3.1 Template class [lib.istreambuf.iterator::proxy] - istreambuf_iterator::proxy - - template > -T class istreambuf_iterator::proxy - { -T charT keep_; -T basic_streambuf* sbuf_; -T proxy(charT c, - basic_streambuf* sbuf); - : keep_(c), sbuf_(sbuf) {} - public: -T charT operator*() { return keep_; } - }; - - - - 24.5.4 Template class [lib.ostreambuf.iterator] - ostreambuf_iterator - - template > -T class ostreambuf_iterator: - public iterator { - public: -T typedef charT char_type; -T typedef traits traits_type; -T typedef basic_streambuf streambuf_type; -T typedef basic_ostream 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 synopsis - - - // _lib.alg.nonmodifying_, non-modifying sequence operations: -T template - Function for_each(InputIterator first, InputIterator last, Function f); -T template - InputIterator find(InputIterator first, InputIterator last, - const T& value); -T template - InputIterator find_if(InputIterator first, InputIterator last, - Predicate pred); -T template - ForwardIterator1 - find_end(ForwardIterator1 first1, ForwardIterator1 last1, - ForwardIterator2 first2, ForwardIterator2 last2); -T template - ForwardIterator1 - find_end(ForwardIterator1 first1, ForwardIterator1 last1, - ForwardIterator2 first2, ForwardIterator2 last2, - BinaryPredicate pred); -T template - ForwardIterator1 - find_first_of(ForwardIterator1 first1, ForwardIterator1 last1, - ForwardIterator2 first2, ForwardIterator2 last2); -T template - ForwardIterator1 - find_first_of(ForwardIterator1 first1, ForwardIterator1 last1, - ForwardIterator2 first2, ForwardIterator2 last2, - BinaryPredicate pred); -T template - ForwardIterator adjacent_find(ForwardIterator first, - ForwardIterator last); -T template - ForwardIterator adjacent_find(ForwardIterator first, - ForwardIterator last, BinaryPredicate pred); -T template - typename iterator_traits::difference_type - count(InputIterator first, InputIterator last, const T& value); -T template - typename iterator_traits::difference_type - count_if(InputIterator first, InputIterator last, Predicate pred); -T template - pair - mismatch(InputIterator1 first1, InputIterator1 last1, - InputIterator2 first2); -T template - pair - mismatch(InputIterator1 first1, InputIterator1 last1, - InputIterator2 first2, BinaryPredicate pred); - -T template - bool equal(InputIterator1 first1, InputIterator1 last1, - InputIterator2 first2); -T template - bool equal(InputIterator1 first1, InputIterator1 last1, - InputIterator2 first2, BinaryPredicate pred); -T template - ForwardIterator1 search(ForwardIterator1 first1, ForwardIterator1 last1, - ForwardIterator2 first2, ForwardIterator2 last2); -T template - ForwardIterator1 search(ForwardIterator1 first1, ForwardIterator1 last1, - ForwardIterator2 first2, ForwardIterator2 last2, - BinaryPredicate pred); -T template - ForwardIterator search_n(ForwardIterator first, ForwardIterator last, - Size count, const T& value); -T template - 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 - OutputIterator copy(InputIterator first, InputIterator last, - OutputIterator result); -T template - BidirectionalIterator2 - copy_backward(BidirectionalIterator1 first, BidirectionalIterator1 last, - BidirectionalIterator2 result); - // _lib.alg.swap_, swap: -T template void swap(T& a, T& b); -T template - ForwardIterator2 swap_ranges(ForwardIterator1 first1, - ForwardIterator1 last1, ForwardIterator2 first2); -T template - void iter_swap(ForwardIterator1 a, ForwardIterator2 b); -T template - OutputIterator transform(InputIterator first, InputIterator last, - OutputIterator result, UnaryOperation op); -T template - OutputIterator transform(InputIterator1 first1, InputIterator1 last1, - InputIterator2 first2, OutputIterator result, - BinaryOperation binary_op); - -T template - void replace(ForwardIterator first, ForwardIterator last, - const T& old_value, const T& new_value); -T template - void replace_if(ForwardIterator first, ForwardIterator last, - Predicate pred, const T& new_value); -T template - OutputIterator replace_copy(InputIterator first, InputIterator last, - OutputIterator result, - const T& old_value, const T& new_value); -T template - OutputIterator replace_copy_if(Iterator first, Iterator last, - OutputIterator result, - Predicate pred, const T& new_value); -T template - void fill(ForwardIterator first, ForwardIterator last, const T& value); -T template - void fill_n(OutputIterator first, Size n, const T& value); -T template - void generate(ForwardIterator first, ForwardIterator last, Generator gen); -T template - void generate_n(OutputIterator first, Size n, Generator gen); -T template - ForwardIterator remove(ForwardIterator first, ForwardIterator last, - const T& value); -T template - ForwardIterator remove_if(ForwardIterator first, ForwardIterator last, - Predicate pred); -T template - OutputIterator remove_copy(InputIterator first, InputIterator last, - OutputIterator result, const T& value); -T template - OutputIterator remove_copy_if(InputIterator first, InputIterator last, - OutputIterator result, Predicate pred); -T template - ForwardIterator unique(ForwardIterator first, ForwardIterator last); -T template - ForwardIterator unique(ForwardIterator first, ForwardIterator last, - BinaryPredicate pred); -T template - OutputIterator unique_copy(InputIterator first, InputIterator last, - OutputIterator result); -T template - OutputIterator unique_copy(InputIterator first, InputIterator last, - OutputIterator result, BinaryPredicate pred); -T template - void reverse(BidirectionalIterator first, BidirectionalIterator last); -T template - OutputIterator reverse_copy(BidirectionalIterator first, - BidirectionalIterator last, - OutputIterator result); - -T template - void rotate(ForwardIterator first, ForwardIterator middle, - ForwardIterator last); -T template - OutputIterator rotate_copy(ForwardIterator first, ForwardIterator middle, - ForwardIterator last, OutputIterator result); -T template - void random_shuffle(RandomAccessIterator first, - RandomAccessIterator last); -T template - void random_shuffle(RandomAccessIterator first, - RandomAccessIterator last, - RandomNumberGenerator& rand); - // _lib.alg.partitions_, partitions: -T template - BidirectionalIterator partition(BidirectionalIterator first, - BidirectionalIterator last, - Predicate pred); -T template - BidirectionalIterator stable_partition(BidirectionalIterator first, - BidirectionalIterator last, - Predicate pred); - // _lib.alg.sorting_, sorting and related operations: - // _lib.alg.sort_, sorting: -T template - void sort(RandomAccessIterator first, RandomAccessIterator last); -T template - void sort(RandomAccessIterator first, RandomAccessIterator last, - Compare comp); -T template - void stable_sort(RandomAccessIterator first, RandomAccessIterator last); -T template - void stable_sort(RandomAccessIterator first, RandomAccessIterator last, - Compare comp); -T template - void partial_sort(RandomAccessIterator first, - RandomAccessIterator middle, - RandomAccessIterator last); -T template - void partial_sort(RandomAccessIterator first, - RandomAccessIterator middle, - RandomAccessIterator last, Compare comp); -T template - RandomAccessIterator - partial_sort_copy(InputIterator first, InputIterator last, - RandomAccessIterator result_first, - RandomAccessIterator result_last); -T template - RandomAccessIterator - partial_sort_copy(InputIterator first, InputIterator last, - RandomAccessIterator result_first, - RandomAccessIterator result_last, - Compare comp); - -T template - void nth_element(RandomAccessIterator first, RandomAccessIterator nth, - RandomAccessIterator last); -T template - void nth_element(RandomAccessIterator first, RandomAccessIterator nth, - RandomAccessIterator last, Compare comp); - // _lib.alg.binary.search_, binary search: -T template - ForwardIterator lower_bound(ForwardIterator first, ForwardIterator last, - const T& value); -T template - ForwardIterator lower_bound(ForwardIterator first, ForwardIterator last, - const T& value, Compare comp); -T template - ForwardIterator upper_bound(ForwardIterator first, ForwardIterator last, - const T& value); -T template - ForwardIterator upper_bound(ForwardIterator first, ForwardIterator last, - const T& value, Compare comp); -T template - pair - equal_range(ForwardIterator first, ForwardIterator last, - const T& value); -T template - pair - equal_range(ForwardIterator first, ForwardIterator last, - const T& value, Compare comp); -T template - bool binary_search(ForwardIterator first, ForwardIterator last, - const T& value); -T template - bool binary_search(ForwardIterator first, ForwardIterator last, - const T& value, Compare comp); - // _lib.alg.merge_, merge: -T template - OutputIterator merge(InputIterator1 first1, InputIterator1 last1, - InputIterator2 first2, InputIterator2 last2, - OutputIterator result); -T template - OutputIterator merge(InputIterator1 first1, InputIterator1 last1, - InputIterator2 first2, InputIterator2 last2, - OutputIterator result, Compare comp); -T template - void inplace_merge(BidirectionalIterator first, - BidirectionalIterator middle, - BidirectionalIterator last); -T template - void inplace_merge(BidirectionalIterator first, - BidirectionalIterator middle, - BidirectionalIterator last, Compare comp); - - // _lib.alg.set.operations_, set operations: -T template - bool includes(InputIterator1 first1, InputIterator1 last1, - InputIterator2 first2, InputIterator2 last2); -T template - bool includes(InputIterator1 first1, InputIterator1 last1, - InputIterator2 first2, InputIterator2 last2, Compare comp); -T template - OutputIterator set_union(InputIterator1 first1, InputIterator1 last1, - InputIterator2 first2, InputIterator2 last2, - OutputIterator result); -T template - OutputIterator set_union(InputIterator1 first1, InputIterator1 last1, - InputIterator2 first2, InputIterator2 last2, - OutputIterator result, Compare comp); -T template - OutputIterator set_intersection - (InputIterator1 first1, InputIterator1 last1, - InputIterator2 first2, InputIterator2 last2, - OutputIterator result); -T template - OutputIterator set_intersection - (InputIterator1 first1, InputIterator1 last1, - InputIterator2 first2, InputIterator2 last2, - OutputIterator result, Compare comp); -T template - OutputIterator set_difference - (InputIterator1 first1, InputIterator1 last1, - InputIterator2 first2, InputIterator2 last2, - OutputIterator result); -T template - OutputIterator set_difference(InputIterator1 first1, InputIterator1 last1, - InputIterator2 first2, InputIterator2 last2, - OutputIterator result, Compare comp); -T template - OutputIterator - set_symmetric_difference(InputIterator1 first1, InputIterator1 last1, - InputIterator2 first2, InputIterator2 last2, - OutputIterator result); -T template - OutputIterator - set_symmetric_difference(InputIterator1 first1, InputIterator1 last1, - InputIterator2 first2, InputIterator2 last2, - OutputIterator result, Compare comp); - // _lib.alg.heap.operations_, heap operations: -T template - void push_heap(RandomAccessIterator first, RandomAccessIterator last); -T template - void push_heap(RandomAccessIterator first, RandomAccessIterator last, - Compare comp); - -T template - void pop_heap(RandomAccessIterator first, RandomAccessIterator last); -T template - void pop_heap(RandomAccessIterator first, RandomAccessIterator last, - Compare comp); -T template - void make_heap(RandomAccessIterator first, RandomAccessIterator last); -T template - void make_heap(RandomAccessIterator first, RandomAccessIterator last, - Compare comp); -T template - void sort_heap(RandomAccessIterator first, RandomAccessIterator last); -T template - void sort_heap(RandomAccessIterator first, RandomAccessIterator last, - Compare comp); - // _lib.alg.min.max_, minimum and maximum: -T template const T& min(const T& a, const T& b); -T template - const T& min(const T& a, const T& b, Compare comp); -T template const T& max(const T& a, const T& b); -T template - const T& max(const T& a, const T& b, Compare comp); -T template - ForwardIterator min_element(ForwardIterator first, ForwardIterator last); -T template - ForwardIterator min_element(ForwardIterator first, ForwardIterator last, - Compare comp); -T template - ForwardIterator max_element(ForwardIterator first, ForwardIterator last); -T template - ForwardIterator max_element(ForwardIterator first, ForwardIterator last, - Compare comp); -T template - bool lexicographical_compare - (InputIterator1 first1, InputIterator1 last1, - InputIterator2 first2, InputIterator2 last2); -T template - bool lexicographical_compare - (InputIterator1 first1, InputIterator1 last1, - InputIterator2 first2, InputIterator2 last2, - Compare comp); - - // _lib.alg.permutation.generators_, permutations -T template - bool next_permutation(BidirectionalIterator first, - BidirectionalIterator last); -T template - bool next_permutation(BidirectionalIterator first, - BidirectionalIterator last, Compare comp); -T template - bool prev_permutation(BidirectionalIterator first, - BidirectionalIterator last); -T template - bool prev_permutation(BidirectionalIterator first, - BidirectionalIterator last, Compare comp); - - - 25.4 C library algorithms [lib.alg.c.library] - - 1 Header (partial, Table 2): - - Table 2--Header 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 synopsis [lib.complex.synopsis] - -T template class complex; -T template<> class complex; -T template<> class complex; -T template<> class complex; - // _lib.complex.ops_ operators: -T template - complex operator+(const complex&, const complex&); -T template complex operator+(const complex&, const T&); -T template complex operator+(const T&, const complex&); -T template complex operator- - (const complex&, const complex&); -T template complex operator-(const complex&, const T&); -T template complex operator-(const T&, const complex&); -T template complex operator* - (const complex&, const complex&); -T template complex operator*(const complex&, const T&); -T template complex operator*(const T&, const complex&); -T template complex operator/ - (const complex&, const complex&); -T template complex operator/(const complex&, const T&); -T template complex operator/(const T&, const complex&); -T template complex operator+(const complex&); -T template complex operator-(const complex&); -T template bool operator== - (const complex&, const complex&); -T template bool operator==(const complex&, const T&); -T template bool operator==(const T&, const complex&); -T template bool operator!=(const complex&, const complex&); -T template bool operator!=(const complex&, const T&); -T template bool operator!=(const T&, const complex&); -T template - basic_istream& - operator>>(basic_istream&, complex&); - -T template - basic_ostream& - operator<<(basic_ostream&, const complex&); - // _lib.complex.value.ops_ values: -T template T real(const complex&); -T template T imag(const complex&); - -T template T abs(const complex&); -T template T arg(const complex&); -T template T norm(const complex&); -T template complex conj(const complex&); -T template complex polar(const T&, const T&); - // _lib.complex.transcendentals_ transcendentals: -T template complex cos (const complex&); -T template complex cosh (const complex&); -T template complex exp (const complex&); -T template complex log (const complex&); -T template complex log10(const complex&); -T template complex pow(const complex&, int); -T template complex pow(const complex&, const T&); -T template complex pow(const complex&, const complex&); -T template complex pow(const T&, const complex&); -T template complex sin (const complex&); -T template complex sinh (const complex&); -T template complex sqrt (const complex&); -T template complex tan (const complex&); -T template complex tanh (const complex&); - } - - 26.2.2 Template class complex [lib.complex] - - template -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 complex(const complex&); - -T T real() const; -T T imag() const; - -T complex& operator= (const T&); -T complex& operator+=(const T&); -T complex& operator-=(const T&); -T complex& operator*=(const T&); -T complex& operator/=(const T&); - -T complex& operator=(const complex&); -T template complex& operator= (const complex&); -T template complex& operator+=(const complex&); -T template complex& operator-=(const complex&); -T template complex& operator*=(const complex&); -T template complex& operator/=(const complex&); - }; - -T template complex operator+ - (const complex&, const complex&); -T template complex operator+(const complex&, const T&); -T template complex operator+(const T&, const complex&); - -T template complex operator- - (const complex&, const complex&); -T template complex operator-(const complex&, const T&); -T template complex operator-(const T&, const complex&); - -T template complex operator* - (const complex&, const complex&); -T template complex operator*(const complex&, const T&); -T template complex operator*(const T&, const complex&); - -T template complex operator/ - (const complex&, const complex&); -T template complex operator/(const complex&, const T&); -T template complex operator/(const T&, const complex&); - -T template complex operator+(const complex&); -T template complex operator-(const complex&); - -T template bool operator==(const complex&, const complex&); -T template bool operator==(const complex&, const T&); -T template bool operator==(const T&, const complex&); - -T template bool operator!=(const complex&, const complex&); -T template bool operator!=(const complex&, const T&); -T template bool operator!=(const T&, const complex&); - -T template - basic_istream& - operator>>(basic_istream&, complex&); - -T template - basic_ostream& - operator<<(basic_ostream&, const complex&); - - - 26.2.3 complex specializations [lib.complex.special] - -T template<> class complex { - public: -T typedef float value_type; - -T complex(float re = 0.0f, float im = 0.0f); -T explicit complex(const complex&); -T explicit complex(const complex&); -T float real() const; -T float imag() const; - -T complex& operator= (float); -T complex& operator+=(float); -T complex& operator-=(float); -T complex& operator*=(float); -T complex& operator/=(float); - -T complex& operator=(const complex&); -T template complex& operator= (const complex&); -T template complex& operator+=(const complex&); -T template complex& operator-=(const complex&); -T template complex& operator*=(const complex&); -T template complex& operator/=(const complex&); - }; -T template<> class complex { - public: -T typedef double value_type; - -T complex(double re = 0.0, double im = 0.0); -T complex(const complex&); -T explicit complex(const complex&); -T double real() const; -T double imag() const; - -T complex& operator= (double); -T complex& operator+=(double); -T complex& operator-=(double); -T complex& operator*=(double); -T complex& operator/=(double); - -T complex& operator=(const complex&); -T template complex& operator= (const complex&); -T template complex& operator+=(const complex&); -T template complex& operator-=(const complex&); -T template complex& operator*=(const complex&); -T template complex& operator/=(const complex&); - }; - -T template<> class complex { - public: -T typedef long double value_type; - -T complex(long double re = 0.0L, long double im = 0.0L); -T complex(const complex&); -T complex(const complex&); -T long double real() const; -T long double imag() const; - -T complex& operator=(const complex&); -T complex& operator= (long double); -T complex& operator+=(long double); -T complex& operator-=(long double); -T complex& operator*=(long double); -T complex& operator/=(long double); - -T template complex& operator= (const complex&); -T template complex& operator+=(const complex&); -T template complex& operator-=(const complex&); -T template complex& operator*=(const complex&); -T template complex& operator/=(const complex&); - }; - - 26.3 Numeric arrays [lib.numarray] - - 26.3.1 Header synopsis [lib.valarray.synopsis] - -T template class valarray; // An array of type T -T class slice; -T template class slice_array; -T class gslice; -T template class gslice_array; -T template class mask_array; // a masked array -T template class indirect_array; // an indirected array - -T template valarray operator* - (const valarray&, const valarray&); -T template valarray operator* (const valarray&, const T&); -T template valarray operator* (const T&, const valarray&); -T template valarray operator/ - (const valarray&, const valarray&); -T template valarray operator/ (const valarray&, const T&); -T template valarray operator/ (const T&, const valarray&); -T template valarray operator% - (const valarray&, const valarray&); -T template valarray operator% (const valarray&, const T&); -T template valarray operator% (const T&, const valarray&); -T template valarray operator+ - (const valarray&, const valarray&); -T template valarray operator+ (const valarray&, const T&); -T template valarray operator+ (const T&, const valarray&); -T template valarray operator- - (const valarray&, const valarray&); -T template valarray operator- (const valarray&, const T&); -T template valarray operator- (const T&, const valarray&); -T template valarray operator^ - (const valarray&, const valarray&); -T template valarray operator^ (const valarray&, const T&); -T template valarray operator^ (const T&, const valarray&); -T template valarray operator& - (const valarray&, const valarray&); -T template valarray operator& (const valarray&, const T&); -T template valarray operator& (const T&, const valarray&); -T template valarray operator| - (const valarray&, const valarray&); -T template valarray operator| (const valarray&, const T&); -T template valarray operator| (const T&, const valarray&); -T template valarray operator<< - (const valarray&, const valarray&); -T template valarray operator<<(const valarray&, const T&); -T template valarray operator<<(const T&, const valarray&); -T template valarray operator>> - (const valarray&, const valarray&); -T template valarray operator>>(const valarray&, const T&); -T template valarray operator>>(const T&, const valarray&); -T template valarray operator&& - (const valarray&, const valarray&); -T template valarray operator&&(const valarray&, const T&); -T template valarray operator&&(const T&, const valarray&); -T template valarray operator|| - (const valarray&, const valarray&); -T template valarray operator||(const valarray&, const T&); -T template valarray operator||(const T&, const valarray&); - -T template - valarray operator==(const valarray&, const valarray&); -T template valarray operator==(const valarray&, const T&); -T template valarray operator==(const T&, const valarray&); -T template - valarray operator!=(const valarray&, const valarray&); -T template valarray operator!=(const valarray&, const T&); -T template valarray operator!=(const T&, const valarray&); -T template - valarray operator< (const valarray&, const valarray&); -T template valarray operator< (const valarray&, const T&); -T template valarray operator< (const T&, const valarray&); -T template - valarray operator> (const valarray&, const valarray&); -T template valarray operator> (const valarray&, const T&); -T template valarray operator> (const T&, const valarray&); -T template - valarray operator<=(const valarray&, const valarray&); -T template valarray operator<=(const valarray&, const T&); -T template valarray operator<=(const T&, const valarray&); -T template - valarray operator>=(const valarray&, const valarray&); -T template valarray operator>=(const valarray&, const T&); -T template valarray operator>=(const T&, const valarray&); -T template valarray abs (const valarray&); -T template valarray acos (const valarray&); -T template valarray asin (const valarray&); -T template valarray atan (const valarray&); -T template valarray atan2 - (const valarray&, const valarray&); -T template valarray atan2(const valarray&, const T&); -T template valarray atan2(const T&, const valarray&); -T template valarray cos (const valarray&); -T template valarray cosh (const valarray&); -T template valarray exp (const valarray&); -T template valarray log (const valarray&); -T template valarray log10(const valarray&); -T template valarray pow(const valarray&, const valarray&); -T template valarray pow(const valarray&, const T&); -T template valarray pow(const T&, const valarray&); -T template valarray sin (const valarray&); -T template valarray sinh (const valarray&); -T template valarray sqrt (const valarray&); -T template valarray tan (const valarray&); -T template valarray tanh (const valarray&); - } - - - 26.3.2 Template class valarray [lib.template.valarray] - -T template 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 valarray(const gslice_array&); -T valarray(const mask_array&); -T valarray(const indirect_array&); -T ~valarray(); - - // _lib.valarray.assign_ assignment: -T valarray& operator=(const valarray&); -T valarray& operator=(const T&); -T valarray& operator=(const slice_array&); -T valarray& operator=(const gslice_array&); -T valarray& operator=(const mask_array&); -T valarray& operator=(const indirect_array&); - // _lib.valarray.access_ element access: -T T operator[](size_t) const; -T T& operator[](size_t); - // _lib.valarray.sub_ subset operations: -T valarray operator[](slice) const; -T slice_array operator[](slice); -T valarray operator[](const gslice&) const; -T gslice_array operator[](const gslice&); -T valarray operator[](const valarray&) const; -T mask_array operator[](const valarray&); -T valarray operator[](const valarray&) const; -T indirect_array operator[](const valarray&); - // _lib.valarray.unary_ unary operators: -T valarray operator+() const; -T valarray operator-() const; -T valarray operator~() const; -T valarray operator!() const; - // _lib.valarray.cassign_ computed assignment: -T valarray& operator*= (const T&); -T valarray& operator/= (const T&); -T valarray& operator%= (const T&); -T valarray& operator+= (const T&); -T valarray& operator-= (const T&); -T valarray& operator^= (const T&); -T valarray& operator&= (const T&); -T valarray& operator|= (const T&); -T valarray& operator<<=(const T&); -T valarray& operator>>=(const T&); -T valarray& operator*= (const valarray&); -T valarray& operator/= (const valarray&); -T valarray& operator%= (const valarray&); -T valarray& operator+= (const valarray&); -T valarray& operator-= (const valarray&); -T valarray& operator^= (const valarray&); -T valarray& operator|= (const valarray&); -T valarray& operator&= (const valarray&); -T valarray& operator<<=(const valarray&); -T valarray& operator>>=(const valarray&); - // _lib.valarray.members_ member functions: -T size_t size() const; -T T sum() const; -T T min() const; -T T max() const; - -T valarray shift (int) const; -T valarray cshift(int) const; -T valarray apply(T func(T)) const; -T valarray 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 slice_array { - public: -T typedef T value_type; - -T void operator= (const valarray&) const; -T void operator*= (const valarray&) const; -T void operator/= (const valarray&) const; -T void operator%= (const valarray&) const; -T void operator+= (const valarray&) const; -T void operator-= (const valarray&) const; -T void operator^= (const valarray&) const; -T void operator&= (const valarray&) const; -T void operator|= (const valarray&) const; -T void operator<<=(const valarray&) const; -T void operator>>=(const valarray&) 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& l, const valarray& d); - -T size_t start() const; -T valarray size() const; -T valarray stride() const; - }; - - - 26.3.7 Template class gslice_array [lib.template.gslice.array] - -T template class gslice_array { - public: -T typedef T value_type; - -T void operator= (const valarray&) const; -T void operator*= (const valarray&) const; -T void operator/= (const valarray&) const; -T void operator%= (const valarray&) const; -T void operator+= (const valarray&) const; -T void operator-= (const valarray&) const; -T void operator^= (const valarray&) const; -T void operator&= (const valarray&) const; -T void operator|= (const valarray&) const; -T void operator<<=(const valarray&) const; -T void operator>>=(const valarray&) 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 mask_array { - public: -T typedef T value_type; - -T void operator= (const valarray&) const; -T void operator*= (const valarray&) const; -T void operator/= (const valarray&) const; -T void operator%= (const valarray&) const; -T void operator+= (const valarray&) const; -T void operator-= (const valarray&) const; -T void operator^= (const valarray&) const; -T void operator&= (const valarray&) const; -T void operator|= (const valarray&) const; -T void operator<<=(const valarray&) const; -T void operator>>=(const valarray&) 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 indirect_array { - public: -T typedef T value_type; - -T void operator= (const valarray&) const; -T void operator*= (const valarray&) const; -T void operator/= (const valarray&) const; -T void operator%= (const valarray&) const; -T void operator+= (const valarray&) const; -T void operator-= (const valarray&) const; -T void operator^= (const valarray&) const; -T void operator&= (const valarray&) const; -T void operator|= (const valarray&) const; -T void operator<<=(const valarray&) const; -T void operator>>=(const valarray&) 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 synopsis - -T template - T accumulate(InputIterator first, InputIterator last, T init); - -T template - T accumulate(InputIterator first, InputIterator last, T init, - BinaryOperation binary_op); - -T template - T inner_product(InputIterator1 first1, InputIterator1 last1, - InputIterator2 first2, T init); - -T template - T inner_product(InputIterator1 first1, InputIterator1 last1, - InputIterator2 first2, T init, - BinaryOperation1 binary_op1, - BinaryOperation2 binary_op2); - -T template - OutputIterator partial_sum(InputIterator first, - InputIterator last, - OutputIterator result); - -T template - OutputIterator partial_sum(InputIterator first, - InputIterator last, - OutputIterator result, - BinaryOperation binary_op); - -T template - OutputIterator adjacent_difference(InputIterator first, - InputIterator last, - OutputIterator result); - -T template - OutputIterator adjacent_difference(InputIterator first, - InputIterator last, - OutputIterator result, - BinaryOperation binary_op); - - - 26.5 C Library [lib.c.math] - - Table 2--Header 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 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 synopsis - -X template class char_traits; -X template<> class char_traits; -X template<> class char_traits; -X template class allocator; -X template > - class basic_ios; - -X template > - class basic_streambuf; - -X template > - class basic_istream; - -X template > - class basic_ostream; - -X template > - class basic_iostream; - -X template , - class Allocator = allocator > - class basic_stringbuf; - -X template , - class Allocator = allocator > - class basic_istringstream; - -X template , - class Allocator = allocator > - class basic_ostringstream; - -X template , - class Allocator = allocator > - class basic_stringstream; - -X template > - class basic_filebuf; - -X template > - class basic_ifstream; - -X template > - class basic_ofstream; - -X template > - class basic_fstream; -X template > - class istreambuf_iterator; - -X template > - class ostreambuf_iterator; -X typedef basic_ios ios; -X typedef basic_ios wios; -X typedef basic_streambuf streambuf; -X typedef basic_istream istream; -X typedef basic_ostream ostream; -X typedef basic_iostream iostream; -X typedef basic_stringbuf stringbuf; -X typedef basic_istringstream istringstream; -X typedef basic_ostringstream ostringstream; -X typedef basic_stringstream stringstream; -X typedef basic_filebuf filebuf; -X typedef basic_ifstream ifstream; -X typedef basic_ofstream ofstream; -X typedef basic_fstream fstream; -X typedef basic_streambuf wstreambuf; -X typedef basic_istream wistream; -X typedef basic_ostream wostream; -X typedef basic_iostream wiostream; -X typedef basic_stringbuf wstringbuf; -X typedef basic_istringstream wistringstream; -X typedef basic_ostringstream wostringstream; -X typedef basic_stringstream wstringstream; - -X typedef basic_filebuf wfilebuf; -X typedef basic_ifstream wifstream; -X typedef basic_ofstream wofstream; -X typedef basic_fstream wfstream; -X template class fpos; -X typedef fpos::state_type> streampos; -X typedef fpos::state_type> wstreampos; - - 27.3 Standard iostream objects [lib.iostream.objects] - - Header synopsis - -T [must also include and ] -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 synopsis - - #include - -T typedef OFF_T streamoff; -T typedef SZ_T streamsize; -T template class fpos; - - class ios_base; - template > - 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 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 > -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* sb); -T virtual ~basic_ios(); - // _lib.basic.ios.members_ Members: -T basic_ostream* tie() const; -T basic_ostream* tie(basic_ostream* tiestr); -T basic_streambuf* rdbuf() const; -T basic_streambuf* rdbuf(basic_streambuf* 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* 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 synopsis - -X template > - class basic_streambuf; -T typedef basic_streambuf streambuf; -T typedef basic_streambuf wstreambuf; - - 27.5.2 Template class [lib.streambuf] - basic_streambuf - - template > -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* - 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* - 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 synopsis - -T template > - class basic_istream; -T typedef basic_istream istream; -T typedef basic_istream wistream; - -T template > - class basic_iostream; -T typedef basic_iostream iostream; -T typedef basic_iostream wiostream; - -X template - basic_istream& ws(basic_istream& is); - - Header synopsis - -X template > - class basic_ostream; -T typedef basic_ostream ostream; -T typedef basic_ostream wostream; - -T template - basic_ostream& endl(basic_ostream& os); -T template - basic_ostream& ends(basic_ostream& os); -T template - basic_ostream& flush(basic_ostream& os); - - Header 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 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 > -T class basic_istream : virtual public basic_ios { - 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* sb); -T virtual ~basic_istream(); - // _lib.istream::sentry_ Prefix/suffix: -T class sentry; - - // _lib.istream.formatted_ Formatted input: -T basic_istream& operator>> - (basic_istream& (*pf)(basic_istream&)) -T basic_istream& operator>> - (basic_ios& (*pf)(basic_ios&)) -T basic_istream& operator>> - (ios_base& (*pf)(ios_base&)) -S basic_istream& operator>>(bool& n); -S basic_istream& operator>>(short& n); -S basic_istream& operator>>(unsigned short& n); -S basic_istream& operator>>(int& n); -S basic_istream& operator>>(unsigned int& n); -S basic_istream& operator>>(long& n); -S basic_istream& operator>>(unsigned long& n); -S basic_istream& operator>>(float& f); -S basic_istream& operator>>(double& f); -S basic_istream& operator>>(long double& f); -S basic_istream& operator>>(void*& p); -S basic_istream& operator>> - (basic_streambuf* sb); - // _lib.istream.unformatted_ Unformatted input: -T streamsize gcount() const; -S int_type get(); -S basic_istream& get(char_type& c); -S basic_istream& get(char_type* s, streamsize n); -S basic_istream& get(char_type* s, streamsize n, - char_type delim); -S basic_istream& get(basic_streambuf& sb); -S basic_istream& get(basic_streambuf& sb, - char_type delim); -S basic_istream& getline(char_type* s, streamsize n); -S basic_istream& getline(char_type* s, streamsize n, - char_type delim); -S basic_istream& ignore - (streamsize n = 1, int_type delim = traits::eof()); -S int_type peek(); -S basic_istream& read (char_type* s, streamsize n); -S streamsize readsome(char_type* s, streamsize n); -S basic_istream& putback(char_type c); -S basic_istream& unget(); -S int sync(); - -S pos_type tellg(); -S basic_istream& seekg(pos_type); -S basic_istream& seekg(off_type, ios_base::seekdir); - }; - - // _lib.istream::extractors_ character extraction templates: -S template - basic_istream& operator>>(basic_istream&, - charT&); -S template - basic_istream& operator>>(basic_istream&, - unsigned char&); -S template - basic_istream& operator>>(basic_istream&, - signed char&); - -S template - basic_istream& operator>>(basic_istream&, - charT*); -S template - basic_istream& operator>>(basic_istream&, - unsigned char*); -S template - basic_istream& operator>>(basic_istream&, - signed char*); - - 27.6.1.1.2 Class basic_istream::sentry [lib.istream::sentry] - - - template > -S class basic_istream::sentry { - typedef traits traits_type; -S bool ok_; // exposition only - public: -S explicit sentry(basic_istream& 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 > -T class basic_iostream : - public basic_istream, - public basic_ostream { - public: - // constructor/destructor -T explicit basic_iostream(basic_streambuf* sb); -T virtual ~basic_iostream(); - }; - - - 27.6.2.1 Template class basic_ostream [lib.ostream] - - template > -X class basic_ostream : virtual public basic_ios { - 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* sb); -T virtual ~basic_ostream(); - // _lib.ostream::sentry_ Prefix/suffix: -T class sentry; - // _lib.ostream.formatted_ Formatted output: -T basic_ostream& operator<< - (basic_ostream& (*pf)(basic_ostream&)); -T basic_ostream& operator<< - (basic_ios& (*pf)(basic_ios&)); -T basic_ostream& operator<< - (ios_base& (*pf)(ios_base&)); -T basic_ostream& operator<<(bool n); -T basic_ostream& operator<<(short n); -T basic_ostream& operator<<(unsigned short n); -T basic_ostream& operator<<(int n); -T basic_ostream& operator<<(unsigned int n); -T basic_ostream& operator<<(long n); -T basic_ostream& operator<<(unsigned long n); -S basic_ostream& operator<<(float f); -S basic_ostream& operator<<(double f); -S basic_ostream& operator<<(long double f); -T basic_ostream& operator<<(const void* p); -X basic_ostream& operator<< - (basic_streambuf* sb); - // _lib.ostream.unformatted_ Unformatted output: -T basic_ostream& put(char_type c); -T basic_ostream& write(const char_type* s, streamsize n); -X basic_ostream& flush(); - - // _lib.ostream.seeks_ seeks: -S pos_type tellp(); -S basic_ostream& seekp(pos_type); -S basic_ostream& seekp(off_type, ios_base::seekdir); - }; - // _lib.ostream.inserters.character_ character inserters -X template - basic_ostream& operator<<(basic_ostream&, - charT); -X template - basic_ostream& operator<<(basic_ostream&, - char); - // specialization -X template - basic_ostream& operator<<(basic_ostream&, - char); - // signed and unsigned -X template - basic_ostream& operator<<(basic_ostream&, - signed char); -X template - basic_ostream& operator<<(basic_ostream&, - unsigned char) -X template - basic_ostream& operator<<(basic_ostream&, - const charT*); -X template - basic_ostream& operator<<(basic_ostream&, - const char*); - // partial specializationss -X template - basic_ostream& operator<<(basic_ostream&, - const char*); - // signed and unsigned -X template - basic_ostream& operator<<(basic_ostream&, - const signed char*); -X template - basic_ostream& operator<<(basic_ostream&, - const unsigned char*); - - - 27.6.2.3 Class basic_ostream::sentry [lib.ostream::sentry] - - template > -X class basic_ostream::sentry { - bool ok_; // exposition only - public: -X explicit sentry(basic_ostream& 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 synopsis - -X template , - class Allocator = allocator > - class basic_stringbuf; - -T typedef basic_stringbuf stringbuf; -T typedef basic_stringbuf wstringbuf; - - template , - class Allocator = allocator > -X class basic_istringstream; - -T typedef basic_istringstream istringstream; -T typedef basic_istringstream wistringstream; - - template , - class Allocator = allocator > -X class basic_ostringstream; -T typedef basic_ostringstream ostringstream; -T typedef basic_ostringstream wostringstream; - - template , - class Allocator = allocator > -X class basic_stringstream; -T typedef basic_stringstream stringstream; -T typedef basic_stringstream wstringstream; - - 27.7.1 Template class basic_stringbuf [lib.stringbuf] - - template , - class Allocator = allocator > -X class basic_stringbuf : public basic_streambuf { - 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& str, - ios_base::openmode which = ios_base::in | ios_base::out); - // _lib.stringbuf.members_ Get and set: -S basic_string str() const; -S void str(const basic_string& 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* 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 Allocator = allocator > -X class basic_istringstream : public basic_istream { - 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& str, - ios_base::openmode which = ios_base::in); - - // _lib.istringstream.members_ Members: -S basic_stringbuf* rdbuf() const; -S basic_string str() const; -S void str(const basic_string& s); - private: - // basic_stringbuf sb; exposition only - }; - - 27.7.3 Class basic_ostringstream [lib.ostringstream] - - template , - class Allocator = allocator > -X class basic_ostringstream : public basic_ostream { - 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& str, - ios_base::openmode which = ios_base::out); - // _lib.ostringstream.members_ Members: -S basic_stringbuf* rdbuf() const; -S basic_string str() const; -S void str(const basic_string& s); - }; - - - 27.7.4 Template class basic_stringstream [lib.stringstream] - - template , - class Allocator = allocator > -X class basic_stringstream - : public basic_iostream { - 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& str, - ios_base::openmode which = ios_base::out|ios_base::in); - // Members: -S basic_stringbuf* rdbuf() const; -S basic_string str() const; -S void str(const basic_string& str); - }; - - - - 27.8.1 File streams [lib.fstreams] - - - Header synopsis - -X template > - class basic_filebuf; -T typedef basic_filebuf filebuf; -T typedef basic_filebuf wfilebuf; - -X template > - class basic_ifstream; -T typedef basic_ifstream ifstream; -T typedef basic_ifstream wifstream; - -X template > - class basic_ofstream; -T typedef basic_ofstream ofstream; -T typedef basic_ofstream wofstream; - -X template > - class basic_fstream; -T typedef basic_fstream fstream; -T typedef basic_fstream wfstream; - - 27.8.1.1 Template class basic_filebuf [lib.filebuf] - - template > -X class basic_filebuf : public basic_streambuf { - 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* open - (const char* s, ios_base::openmode mode); -X basic_filebuf* 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* - 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 > -X class basic_ifstream : public basic_istream { - 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* 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 > -X class basic_ofstream : public basic_ostream { - 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* 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 > -X class basic_fstream - : public basic_iostream { - 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* 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 synopsis - Macros: -X BUFSIZ L_tmpnam SEEK_SET TMP_MAX -X EOF NULL stderr _IOFBF -X FILENAME_MAX SEEK_CUR stdin _IOLBF -X FOPEN_MAX SEEK_END stdout _IONBF - -X Types: FILE fpos_t size_t - 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 - - - - - 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 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 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 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 basic_filebuf : public basic_streambuf { - public: -M basic_filebuf* open - (const char* s, ios_base::open_mode mode); - // remainder unchanged - }; - template > - class basic_ifstream : public basic_istream { - public: -M void open(const char* s, ios_base::open_mode mode = in); - // remainder unchanged - }; - template > - class basic_ofstream : public basic_ostream { - 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 { - 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* setbuf(char* s, streamsize n); - } - - 1.7.4 Class strstream [depr.strstream] - -M class strstream - : public basic_iostream { - public: - // Types -M typedef char char_type; -M typedef typename char_traits::int_type int_type -M typedef typename char_traits::pos_type pos_type; -M typedef typename char_traits::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(); - }; - diff --git a/libstdc++-v3/docs/17_intro/COPYING b/libstdc++-v3/docs/17_intro/COPYING deleted file mode 100644 index 60549be514a..00000000000 --- a/libstdc++-v3/docs/17_intro/COPYING +++ /dev/null @@ -1,340 +0,0 @@ - GNU GENERAL PUBLIC LICENSE - Version 2, June 1991 - - Copyright (C) 1989, 1991 Free Software Foundation, Inc. - 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - Everyone is permitted to copy and distribute verbatim copies - of this license document, but changing it is not allowed. - - 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: (1) copyright the software, and -(2) 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. - - GNU GENERAL PUBLIC LICENSE - TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION - - 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. - - 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. - - 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: - - a) You must cause the modified files to carry prominent notices - stating that you changed the files and the date of any change. - - b) 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. - - c) 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. - - 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: - - a) 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, - - b) 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, - - c) 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. - - 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. - - 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. - - 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. - - 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. - - 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. - - 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. - - 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 - - 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. - - 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. - - - Copyright (C) 19yy - - 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 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) 19yy 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. - - , 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/docs/17_intro/DESIGN b/libstdc++-v3/docs/17_intro/DESIGN deleted file mode 100644 index 6979bc40f80..00000000000 --- a/libstdc++-v3/docs/17_intro/DESIGN +++ /dev/null @@ -1,859 +0,0 @@ - -Standard C++ Library Design Document ------------------------------------- - -This is an overview of libstdc++-v3, with particular attention -to projects to be done and how they fit into the whole. - -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 -, we might have: - - template class basic_string { - ... // member declarations - }; - ... // operator declarations - - #ifdef _STRICT_ISO_ - # if _G_NO_TEMPLATE_EXPORT - # include // headers needed by definitions - # ... - # include // 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 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, 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 contructs), 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 -). 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: -C headers: - (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 -, 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. - -, 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: -C headers: - -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: -C header: (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: -C headers: (also in 27) - (also in 18, 25, 26) - -We have "mostly-complete" char_traits<> implementations. Many of the -char_traits 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 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 are different from the C version. -generally overloaded on const and non-const argument pointers. For -example, in strchr is overloaded. The functions isupper -etc. in typically implemented as macros in C are functions -in C++, because they are overloaded with others of the same name -defined in . - -Many of the functions required in and cannot be -implemented using underlying C facilities on intended targets because -such facilities only partly exist. - -Chapter 22 Locale ------------------- -Headers: -C headers: - -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 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 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 , , -and , and the codecvt<> facet is used by basic_filebuf<> -in , 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: - -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: - -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: -C headers: (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: -C headers: , (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: - -C headers: (also in 21) - -Iostream is currently in a very incomplete state. , , -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, and 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<::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 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, 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 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: - -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 -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: - (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 -, , and various SGI extensions such -as . Many of these are already placed in the -subdirectories ext/ and backward/. (Note that it is better to -include them via "" or "" than -to search the subdirectory itself via a "-I" directive. - diff --git a/libstdc++-v3/docs/17_intro/HEADER_POLICY b/libstdc++-v3/docs/17_intro/HEADER_POLICY deleted file mode 100644 index c6fa6d38b54..00000000000 --- a/libstdc++-v3/docs/17_intro/HEADER_POLICY +++ /dev/null @@ -1,164 +0,0 @@ - -Header Policy -------------- - -The C++ Standard specifies many mutual dependencies among the -headers it defines. It offers no advice on how to arrange headers -to avoid problems. The worst such problem is circular references. -Most simply this is "A includes B, B includes A": - - // file // file - #ifndef A #ifndef B - #define A 1 #define B 1 - #include #include - typedef int A_type; typedef int B_type; - extern B_type g(A_type); extern A_type f(B_type); - #endif /* A */ #endif /* B */ - - // file C.cc - #include - -The typical effect of such an "include loop" may be seen by tracing -the preprocessor activity: - - C // file C.cc - C #include - A // file - A #ifndef A - A #define A 1 - A #include - B // file - B #ifndef B - B #define B 1 - B #include - A // file - A #ifndef A <-- oops, cpp symbol A defined already - A ... <-- skip contents - A #endif - B typedef int B_type; - B extern A_type f(B_type); <-- error, A_type not defined yet. - B #endif /* B */ - A typedef int A_type; - A extern B_type g(A_type); - A #endif /* A */ - -The main symptom of #include loops is that definitions from file -are not available after the #include for certain include orders. -The number of standard headers makes testing all permutations of -include order impractical, so a policy is needed to prevent chaos. -In any case, for some standard headers (as for the above) no ordering -can eliminate the loop. - -Other factors influence the policy. Typical implementations of -Make (unfortunately including GNU make) have bugs relating to file -names with no suffix, that lead to such problems as failure to track -dependencies on such files and an inclination to _delete_ them. -Therefore, headers used in building the library are always of the -form generally, or specifically for -an equivalent to the standard header . - -Standard headers are all placed under directory std/, and -are ignored except during installation. These headers simply -#include the corresponding header . - -Standard substitute headers that have any complexity -may sub-include other headers. When they sub-include non-standard -headers, they first include all the headers required for that -non-standard header. - -Mutual dependencies are handled by splitting up the declarations -intended for standard headers among two or more files, and then -interleaving them as needed. For example, we replace and -above, as follows: - - // file - #ifndef _CPP_A - #define _CPP_A - # include - # include - # include - #endif - - // file - #ifndef _CPP_B - #define _CPP_B - # include - # include - # include - #endif - - // file - #ifndef _CPP_BITS_A_TYPES_H - #define _CPP_BITS_A_TYPES_H - typedef int A_type; - #endif - - // file - #ifndef _CPP_BITS_B_TYPES_H - #define _CPP_BITS_B_TYPES_H - typedef int B_type; - #endif - - // file - #ifndef _CPP_BITS_A_FUNS_H - #define _CPP_BITS_A_FUNS_H - extern B_type g(A_type); - #endif - - // file - #ifndef _CPP_BITS_B_FUNS_H - #define _CPP_BITS_B_FUNS_H - extern A_type f(B_type); - #endif - -Of course we have the standard headers under their mandated names: - - // file - #ifndef _CPP_A - #define _CPP_A - # include - #endif - - // file - #ifndef _CPP_B - #define _CPP_B - # include - #endif - -Notice that the include guards are named uniformly except that -the guard for standard header is just _CPP_A, -identically as the header in std/. - -At installation the files std/* can be replaced by symbolic links, -or simply copied into place as is. The result is: - - include/ - include/A -> bits/std_A.h - include/B -> bits/std_A.h - include/bits/ - include/bits/std_A.h - include/bits/std_B.h - include/bits/A_types.h - include/bits/B_types.h - include/bits/A_funs.h - include/bits/B_funs.h - - -Of course splitting up standard headers this way creates -complexity, so it is not done routinely, but only in response -to discovered needs. - -Another reason to split up headers is for support of separate -compilation of templates. This interacts with the foregoing -because template definitions typically have many more dependencies -on other headers than do pure declarations. Non-inline template -definitions are placed in a separate ".tcc" file that is included -by the standard header, and any other standard header that -requires definitions from it for its implementation. - -The key to preventing chaos, given the above structure, is: - - Only standard headers should sub-include - other headers. - - diff --git a/libstdc++-v3/docs/17_intro/PROBLEMS b/libstdc++-v3/docs/17_intro/PROBLEMS deleted file mode 100644 index 52223911295..00000000000 --- a/libstdc++-v3/docs/17_intro/PROBLEMS +++ /dev/null @@ -1,8 +0,0 @@ -Irix 6.2: -- math.h: defines extern long double hypotl( long double ); i.e., only - one argument. They've fixed this in 6.3. - -DES OSF 3.2 & 4.0: -- libm define sincos, sincosf, and sincosl but there are no prototypes and - especially the return type is nowhere defined. The functions are - documented in the man pages, though. diff --git a/libstdc++-v3/docs/17_intro/RELEASE-NOTES b/libstdc++-v3/docs/17_intro/RELEASE-NOTES deleted file mode 100644 index 1ebaf66d829..00000000000 --- a/libstdc++-v3/docs/17_intro/RELEASE-NOTES +++ /dev/null @@ -1,118 +0,0 @@ -2000-11-29 - -Release Notes -------------- -The Standard C++ Library v3, or libstdc++-2.90.x, is an ongoing -project to implement the ISO 14882 Standard C++ library as described -in chapters 17 through 27 and annex D, as a drop-in replacement -for the current (ARM-conformant) library. - -This is the tenth snapshot of the libstdc++ rewrite. It is still -incomplet and incorrekt. It's a lot less incomplete and incorrect than -some of the earlier snapshots though, and quite usable. - -The Standard C++ Library v3, or libstdc++-2.9x, follows an open -development model, attempting to be fully buzzword, bazaar, and GNU -compliant. Full details on participating, including contributor -guidelines, mailing list subscription, mailing list archives, -up-to-date documentation, and various and sundry other details can be -found at the following URL: - - http://gcc.gnu.org/libstdc++/ - - -New: ---- -- namespace std:: is now on by default. -- choice of "C" include strategies, including the shadow header work, - or generic global to std mapping of required "C" types. -- cpu/atomicity.h tweaks, additions of ia64 and arm support. -- abstraction of atomicity.h header to support notion of os/atomicity.h files. -- addition of backward header bits -- use of system_header pragma -- Conditional use of -Werror -- preliminary support for new g++ diagnostics capabilities, including - -fdiagnostics-show-location=once -- pedantic and shadow argument warning fixes -- Ugly, yet correct mechanism for dealing with "C" math adopted, - including the use of builtins. -- updates and configure/build work to support new libtool -- addition of strstream -- valarray work -- complex work -- update to SGI STL 3.3 -- libio sync between glibc/libstdc++-v3. Some divergence since initial - merge, but sources remain quite close. -- IO fixes for alpha -- wide character work for IO when using libio -- addition of c_io_stdio and "C" IO abstraction layer. -- auto_ptr fixes, testsuite additions -- Attempts to use -ffunction-sections -fdata-sections and - --gc-sections, depending on use of GNU ld and specific features. As of - late, --gc-sections has been disabled due to problems with it throwing - away initialization sections. This work is ongoing. -- long double support -- sub directory removal, coherent organization of cpu and os-specific - files, consolidation of include directories, integration of the C++ - support bits for operator new/delete,exceptions, etc. All includes - are now either in the include/* hierarchy or in libsupc++'s sub directory. -- Support for more platforms, including irix and bsd variants. -- filebuf tweaks to deal with variable-size buffers. -- filebuf implementation for putbackc, etc. al. -- ctype rewritten. Includes ctype, ctype, and others. -- codecvt rewritten. Includes codecvt, - codecvt. In addition, - implementation-defined conversions using iconv are now supported with - the __enc_traits partial-specialization of the State template - parameter of the codecvt class. In this manner, conversions between - encodings such as UCS4, USC2, UNICODE, UNICODEBIG, UNICODELITTLE, etc - can be performed. -- preliminary work on named locales -- preliminary documentation for locale implementation has been established. -- Many, many bug fixes. -- Many, many testsuite additions and consistent VERIFY usage. -- work on mkcheck to make it more flexible, use libtool, etc. - -What doesn't: -------------- -- see BUGS. - - -Build and Install ------------------ -Up to date build and install directions can be found at: -http://gcc.gnu.org/libstdc++/install.html - - -Contact: --------- -Places have changed from previous snapshots. The web page, which has -information about joining the mailing list and searching its archives, -CVS access, and contribution information is now at: - - http://gcc.gnu.org/libstdc++/ - -Please note that the mailing list has recently moved, and is now -hosted on gcc.gnu.org. (The web site above has the most -up-to-date info.) - -Obtain the library snapshot via ftp (including these release notes) from - - ftp://gcc.gnu.org/pub/libstdc++/ - -The library is maintained by Benjamin Kosnik, Gabriel -Dos Reis, Phil Edwards, and Ulrich Drepper. - - -Development tools: ------------------- - -You will need a recent version of gcc to compile the snapshot of -libstdc++. The use of CVS g++ is strongly recommended. In addition, -you may need up-to-date tools for modifying Makefiles and regenerating -configure scripts: automake (version 1.4), autoconf (version 2.13 and -higher), and libtool. - - - - diff --git a/libstdc++-v3/docs/17_intro/TODO b/libstdc++-v3/docs/17_intro/TODO deleted file mode 100644 index 4da846277d6..00000000000 --- a/libstdc++-v3/docs/17_intro/TODO +++ /dev/null @@ -1,177 +0,0 @@ -- exception specifications need to be reviewed for all parts of the -library support and utility areas, particularly . - -- exception/stdexcept headers will do, but are not cleanly -implemented. Also, some kind of consensus needs to be established on -if the presence of stdexcept should be assumed in iostreams -headers. V3 currently takes the position that references to stdexcept -classes necessitates the inclusion of stdexcept, other library vendors -seem less inclined. - -- scoping/linking issues WRT to C structs need to be worked out. See -Nathan's commentary on cantrip, http://www.cantrip.org/cheaders.html - -- triglyphs/ciso646: and, and_eq, bitand, bitor, compl, not, not_eq, -or, or_eq, xor, xor_eq, true && 45, true and false, true or 45, etc. -(bool and int), etc. - -- operator!= and utility/rel_ops operators need to be made safe with -string and vector iterator classes. basic_string::reverse_iterator may -be implemented incorrectly, or need things like -operator==(__normal_iterator, const char*&), and swap(vector) - -- SGI iterator/allocator classes are not strictly conforming. In -particular, raw_storage_iterator, mem_fun1_ref_t are all problem -areas. - -- auto_ptr: seems to be some disagreement on what is -standards-conformant behavior, specially on conversion operators. - -- vswprintf, vwprintf, wprintf, wscanf, wcsftime, swscanf, fgetws, -fputwc, fputws, fwide, fwprintf, fwscanf, getwc, getwchar, putwc, etc: -C library wchar_t functionality. - -- facets heirarchies seem on occasion give odd errors to conformace -tests. Need to test that they are constructed in a strictly-conforming -manner. - -- stuff like `LC_CTYPE' is not found. Locale oddness? - -- header optimizations to keep compile times reasonable are most -certainly detracting from full conformance, as many templatized -definitions are squired away and pre-instantiated, so that the -compiler doesn't have to parse them. Areas effected: valarray, string, -all of iostreams and locales. - -- basic_string not implemented - -- ostreambuf_iterator has not been made standards-conformant (both -char and wchar_t) In particular, look at -time_put::put(OutIt, ios_base&, char, const tm*, const char*, const -char*) const - -- C-related issues WRT to libio and filepos, mbstate_t. Need to -straighten this stuff out with the glibc-2.2 libio. Also may need to -define operators for mbstate_t so that 'mbstate_t& == mbstate_t' is -something that can be done. - -- codecvt has not been adequently handled in terms of the -locale bits. (The io bits are done, with the exception of one -ostream inserter for char. - -- bool locale::operator() looks to be non-conformant - -- num_get::do_get - num_put::do_put -num_put::do_put(char *, ios_base &, char, long double) const -num_put::do_put(char *, ios_base &, char, double) const -num_put::do_put(char *, ios_base &, char, void const *) const -etc. -appear to be broken, or headers mashed, or undefined. - -- locale and std::combine not working correctly - template class locale locale::combine(const locale &) - -- ctype_byname: check to make sure derivation standards-conformant. - -- codecvt::unshift not working for char, wchar_t - -- no match for money_base::pattern &[int] - -- money_get::do_get weirded out for wchar_t - -- looks like deque::get_allocator not standards conformant or deque -allocator non-standard. - -- list::assignment operator needs const_cast - -- a cleaner division between pointers-to-value_type and true iterators -needs to be drawn throughout the entire STL implementation. - -- priority_queue conversions may be non-conformant - -- istream_iterator uses 2 arguments, should it be 4? - -- 'do the right thing' ctor fixing needs to be done for string. This -is still subject to some debate on the library issues list, so I -suggest punting till the dust clears. - -- the ctype and "tolower" "isspace" stuff really needs to be sorted -out. A portable, cross platform interface needs to be defined. A -"fixincludes"-like solution needs to be put into place to prune -headers. The "C" functions need to be able to work in std:: and "C" -namespaces. - -- complex seems to be the single largest source of internal -compiler errors when compiling the c++ library across non-x86 -platforms. Somebody needs to make sure the complex support builtin to -gcc is actually working. Just as a "for-instance" these things give ICEs: -class complex& complex::operator-=(const complex &) -class complex& complex::operator/=(const complex &) -class complex& complex::operator+=(const complex &) -class complex& complex::operator-=(const complex &) -class complex& complex::operator*=(const complex &) - -- appears as if the following extraction operators are undefined: -operator>>(istream, complex&) -operator>>(istream, complex&) -operator>>(istream, complex&) -operator>>(istream, complex&) -sqrt (const complex& x) - -- Protect valarray::result_type (not Standard) and make it work with - the various helper classes. - -- Make sure `valarray & == _Expr<_BinClos,bool>' - is defined - -- long double std_cmath stuff looks weak - -- fwide not declared. C++ wchar_t issues completely unaddressed. - -- known issues WRT to io and corner cases with the buffers. This is -still subject to interpretation, and I think the current -implementation is credible. - -- All of the Library working group closed issues need to be -addressed. Some of them proposed resolutions are already in the v-3 -sources, with macro-guards. - -- add deprecated features from Annex D - - add #ifdef wrappers for all of them, including in each - C header - - replace typedef'd non-deprecated types with more type-safe equivalents. - -- add optimization hooks (esp. whitespace eating) to streambuf - - add _M_begin() and _M_end() to streambuf - - add algorithm specializations for [io]streambuf_iterator (copy find etc.) - -- fix template members of basic_string<> to overload iterators and - non-iterators properly. (This is the infamous hack as in vector<> etc - 23.1.1 para 10.) - -- write filebuf for wide characters - -- replace stl/bits/stl_config - -- add feature-test macros for non-standard extensions - -- move major extensions into separate namespace (e.g. stl::) - -- create MT abstraction layer - -- add MT support for locale, string, istream, ostream - -- specialize functions that use_facet<> calls on failure for the required - facets, and construct them lazily so unused facets need not be constructed - when the locale is. - -- get mknumeric_limits coope with 'exotic' OSes. - -- : provide missing names. - -- provide testsuites for numerics. - -- add FAQ entries -- improve the install instructions - -- add HOWTO entries diff --git a/libstdc++-v3/docs/17_intro/contribute.html b/libstdc++-v3/docs/17_intro/contribute.html deleted file mode 100644 index 4f16b845d48..00000000000 --- a/libstdc++-v3/docs/17_intro/contribute.html +++ /dev/null @@ -1,95 +0,0 @@ - - - -How to contribute - - -

How to contribute

-

-The Standard C++ Library v3, or libstc++-2.90.x, follows an open development model. Active contributors are assigned maintainer-ship responsibility, and given write access to the CVS repository. First time submitors and all other potential contributors should follow this procedure: - -

-

-

ONE : read the documentation

-

- -

-

 - - - -

-

-

TWO : copyright 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. Here is the form. - -Please contact Benjamin -Kosnik if you are confused about the assignment or have general -licensing questions. - - -

-

-

THREE : 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 plaintext; 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 CVS repository at - Cygnus, use "cvs update; cvs diff -c3p NEW"; else, use "diff -c3p OLD - NEW" ... If your version of diff does not support these options, then - get the latest version of GNU 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++ mailinglist. - -
- - diff --git a/libstdc++-v3/docs/17_intro/headers_cc.txt b/libstdc++-v3/docs/17_intro/headers_cc.txt deleted file mode 100644 index d95f17aee68..00000000000 --- a/libstdc++-v3/docs/17_intro/headers_cc.txt +++ /dev/null @@ -1,83 +0,0 @@ -// 1999-05-12 bkoz - -// Copyright (C) 1999 Free Software Foundation, Inc. -// -// This file is part of the GNU ISO C++ Library. This library 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, or (at your option) -// any later version. - -// This library 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 library; see the file COPYING. If not, write to the Free -// Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, -// USA. - -// 17.4.1.2 Headers - - -// "C++" headers -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -// "C" headers -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -// "C" headers that might not work if wchar_t support is disabled. -#include -#if _GLIBCPP_USE_WCHAR_T - #include - #include -#endif - -int main() { } diff --git a/libstdc++-v3/docs/17_intro/howto.html b/libstdc++-v3/docs/17_intro/howto.html deleted file mode 100644 index f52e867dceb..00000000000 --- a/libstdc++-v3/docs/17_intro/howto.html +++ /dev/null @@ -1,156 +0,0 @@ - - - - - - - - - libstdc++-v3 HOWTO: Chapter 17 - - - - - -

Chapter 17: Library Introduction

- -

Chapter 17 is actually a list of definitions and descriptions used - in the following chapters of the Standard when describing the actual - library. Here, we use "Introduction" as an introduction - to the GNU implementation of the ISO Standard C++ Library. -

- - - -
-

Contents

- - -
- - - -

The Standard C++ header files

-

The Standard C++ Library specifies 50 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 you #include a certain header, the - contents of that header, as defined by the Standard, become - available to you, no matter how. -

-

The names of the headers can be easily seen in - testsuite/17_intro/headers.cc, - which is a small testbed we use to make certain that the headers - all compile and run. -

- -
-

Thread-safety

-

This is a thorny issue that gets brought up on the libstdc++-v3 - and gcc mailing lists on a regular basis (probably by a cron job). - This entry will mention a very little bit about the general MT - issues with libstdc++. The latest status and quick notes will be - in FAQ 5.6. Some discussion about threadsafe containers will be - in section 6.8 (the HOWTOs on containers). -

-

The libstdc++ code (all of it, not just the containers) has been - designed so that thread-safety will be easily possible. The first - (!) problem is finding a fast method of implementation - portable to all platforms. 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. -

-

A recent journal article has described "atomic integer - operations," which would allow us to, well, perform updates - on integers atomically, and without requiring an explicit mutex - lock. This appears promising, but the major difficulty is that - these operations "may not be available on all systems, and - if they are, may have different interfaces." [quoting from - mailing list messages] -

-

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 - relevent message in the thread; from there you can use - "Thread Next" to move down the thread. This farm is in - latest-to-oldest order. -

    -
  • -
-
- Here are discussions that took place before the current snapshot; - they are still relevant and instructive. -
-
    -
  • One way of preventing memory leaks by the old default memory - allocator in multithreaded code is - discussed here. -
  • This thread - concerns strings. -
  • So does this - one. This initial message also refers to another - thread in the GCC mailing list... -
  • which is here, - and goes on for some time. Ironically, the initial message - in this thread also mentions another threading thread... -
  • beginning here, - and talking about pthreads. (Note that a much more recent - message from the first thread in this list notes that - pthreads - should not be used as a starting point for making - libstdc++ threadsafe.) -
  • This - message, - this one, - and this one - are the tops of related threads (all within the same time - period) discussing threading and the IO library. Much of it - is dealing with the C library, but C++ is included as well. -
-

-

This section will be updated as new and interesting issues come - to light. -

-

Return to top of page or - to the FAQ. -

- -
-

<foo> vs <foo.h>

-

The new-style headers are fully supported in libstdc++-v3. The compiler - itself fully supports namespaces. However, at the moment, the compiler - treats std:: as the global namespace by default. -

-

For those of you new to ISO C++98, no, that isn't a typo, the headers - really have new names. Marshall Cline's C++ FAQ Lite has a good - explanation in -item [25.4]. -

-

Return to top of page or - to the FAQ. -

- - - - - -
-

-Comments and suggestions are welcome, and may be sent to -Phil Edwards or -Gabriel Dos Reis. -
$Id: howto.html,v 1.5 2000/10/21 00:51:49 jsm28 Exp $ -

- - - - - - diff --git a/libstdc++-v3/docs/17_intro/libstdc++-assign.txt b/libstdc++-v3/docs/17_intro/libstdc++-assign.txt deleted file mode 100644 index b70be688bca..00000000000 --- a/libstdc++-v3/docs/17_intro/libstdc++-assign.txt +++ /dev/null @@ -1,129 +0,0 @@ -The way to assign copyright to the Free Software Foundation is to sign -an assignment contract. This is what legally makes the Free Software -Foundation the copyright holder so that we can register the copyright -on the new version. I'm assuming that you wrote these changes -yourself; if other people wrote parts, we may need papers from them. - -If you are employed to do programming (even at a university), or have -made an agreement with your employer or school saying it owns programs -you write, then you and we need a signed piece of paper from your -employer disclaiming rights to the program. - -The disclaimer should be signed by a vice president or general manager -of the company. If you can't get at them, anyone else authorized to -license software produced there will do. Here is a sample wording: - - Digital Stimulation Corporation hereby disclaims all copyright interest - in the changes and enhancements made by Hugh Heffner to the program - "libstdc++", also including any future revisions of these changes and - enhancements. - - Digital Stimulation Corporation affirms that it has no other - intellectual property interest that would undermine this release, or - the use of the Program, and will do nothing to undermine it in the - future. - - , 1 April 1987 - Ty Coon, President of Vice, Digital Stimulation Corp. - -(If your employer says they do have an intellectual property claim -that could conflict with the use of the program, then please put me in -touch with a suitable representative of the company, so that we can -negotiate what to do about it.) - -IMPORTANT: When you talk to your employer, *no matter what -instructions they have given you*, don't fail to show them the sample -disclaimer above, or a disclaimer with the details filled in for your -specific case. Companies are usually willing to sign a disclaimer -without any fuss. If you make your request less specific, you may -open Pandora's box and cause a long and unnecessary delay. - -Below is the assignment contract that we usually use. You need -to print it out, sign it, and snail it to: - -Richard Stallman -545 Tech Sq rm 425 -Cambridge, MA 02139 -USA - -Please try to print the whole first page below on a single piece of -paper. If it doesn't fit on one printed page, put it on two sides of -a single piece of paper. - -Don't forget to put down the date when you sign! Spell out the month -name--don't use a number for the month. Dates using a number for the -month are ambiguous; 2/8/95 means one thing in the US and another in -Europe. - -Snail a copy of the employer's disclaimer as well. - -Please send me email about what you decide to do. If you have any -questions, or would like something to be changed, ask bkoz@gnu.org via -email. - ASSIGNMENT - - For good and valuable consideration, receipt of which I -acknowledge, I, [your name here], hereby transfer to the Free Software -Foundation, Inc. (the "Foundation") my entire right, title, and -interest (including all rights under copyright) in my changes and -enhancements to the libstdc++ library, subject to the conditions -below. These changes and enhancements are herein called the "Work". -The work hereby assigned shall also include any future revisions of -these changes and enhancements hereafter made by me. - - Upon thirty days' prior written notice, the "Foundation" agrees to -grant me non-exclusive rights to use the Work (i.e. my changes and -enhancements, not the program which I enhanced) as I see fit; (and -the "Foundation"'s rights shall otherwise continue unchanged). - - I hereby agree that if I have or acquire hereafter any patent or -interface copyright or other intellectual property interest dominating -the program enhanced by the Work (or use of that program), such -dominating interest will not be used to undermine the effect of this -assignment, i.e. the "Foundation" and the general public will be -licensed to use, in that program and its derivative works, without -royalty or limitation, the subject matter of the dominating interest. -This license provision will be binding on my heirs, assignees, or -other successors to the dominating interest, as well as on me. - - I hereby represent and warrant that I am the sole copyright holder -for the Work and that I have the right and power to enter into this -contract. I hereby indemnify and hold harmless the "Foundation", its -officers, employees, and agents against any and all claims, actions or -damages (including attorney's reasonable fees) asserted by or paid to -any party on account of a breach or alleged breach of the foregoing -warranty. I make no other express or implied warranty (including -without limitation, in this disclaimer of warranty, any warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE). - -Agreed: [signature] Date [Write the month with LETTERS]: - - -For the "Foundation", -Richard Stallman, head dude in charge - -Please do not delete the control-l character before this line. -Please print this as a separate page. - -Please email a copy of the information on this page to -fsf-records@gnu.ai.mit.edu, and cc bkoz@gnu.org, if you can, so that -our clerk doesn't have to type it in. Use your full name as the -subject line. - -[For the copyright registration, what country are you a citizen of? -What year were you born?] - - -[Please write your email address here.] - - -[Please write your snail address here, so we can snail a copy back to you.] - - - -[Which files have you changed so far, and which new files have you written -so far?] - - -[Which Belgian comic book character is better, Tintin or Asterix, and why?] - diff --git a/libstdc++-v3/docs/17_intro/organization b/libstdc++-v3/docs/17_intro/organization deleted file mode 100644 index 828a8112834..00000000000 --- a/libstdc++-v3/docs/17_intro/organization +++ /dev/null @@ -1,84 +0,0 @@ -20 [lib.utilities] - - namespace rel_ops { operators !=, >, <=, >= } - struct pair; - pair binary operators { operators ==, <, !=, >, >=, <= } - - // function objects, or objects with operator() defined - - template class allocator; - template<> class allocator; - template class raw_storage_iterator; - temporary buffers - specialized algorithms for uninitialized_{copy, fill, fill_n} - template class auto_ptr; - - - - -21 [lib.strings] - - template struct char_traits - template<> struct char_traits - template<> struct char_traits - template, A=a > class basic_string; - - typedef basic_string string; - typedef basic_string wstring; - - template void swap(string&, string&) - template istream& operator>>(istream&, string&); - template istream& getline(istream&, string&, C); - template istream& getline(istream&, string&); - template ostream& operator<<(ostream&, string&); - - - - - - -23 [lib.containers] - - - - - - - - - -24 [lib.iterators] - - -25 [lib.algorithms] - - non-modifying sequence operations - for_each, find, find_if, find_end, find_first_of, - adjacent_find, count, count_if, mismatch, equal, - search, search_n - modifying sequence operations - copy, copy_backward, swap, swap_ranges, iter_swap, - transform, replace, replace_if, replace_copy, - replace_copy_if, fill, fill_n, generate, generate_n, - remove, remove_if, remove_copy, remove_copy_if, unique, - unique_copy, reverse, reverse_copy, rotate, - rotate_copy, random_shuffle - sorting and related operations - sort, stable_sort, partial_sort, partial_sort_copy, - nth_element, lower_bound, upper_bound, equal_range, - binary_search, merge, inplace_merge, includes, - set_union, set_intersection, set_difference, - set_symmetric_difference, push_heap, pop_heap, - make_heap, sort_heap, min, max, min_element, - max_element, lexicographical_compare, next_permutation, - prev_permutation - - - - - - - - - - diff --git a/libstdc++-v3/docs/17_intro/porting-howto.html b/libstdc++-v3/docs/17_intro/porting-howto.html deleted file mode 100644 index 54290b328c2..00000000000 --- a/libstdc++-v3/docs/17_intro/porting-howto.html +++ /dev/null @@ -1,726 +0,0 @@ - - - Libstdc++-porting-howto - - - -
-
-

- Libstdc++-porting-howto -

-

Felix Natter

-

- This document can be distributed under the FDL - (www.gnu.org) -

-

what kind of a date ? I don't drink !

-
- - - - - - - - - - - - - - - - - - - - - - -
Revision History
Revision 0.5Thu Jun 1 13:06:50 2000fnatter
First docbook-version.
Revision 0.8Sun Jul 30 20:28:40 2000fnatter
First released version using docbook-xml - + second upload to libstdc++-page. -
Revision 0.9Wed Sep 6 02:59:32 2000fnatter
5 new sections.
-
-
-

- Abstract -

-

- Some notes on porting applications from libstdc++-2.90 (or earlier - versions) to libstdc++-v3. Not speaking in terms of the GNU libstdc++ - implementations, this means porting from earlier versions of the - C++-Standard to ISO 14882. -

-
-
-
-
-

- Table of Contents -

-
-
1. Namespace std:: -
-
-
-
1.1.1. Using namespace - composition if the project uses a separate - namespace -
-
1.1.2. Defining an empty namespace std -
-
1.1.3. Avoid to use fully qualified names - (i.e. std::string) -
-
1.1.4. How some open-source-projects deal - with this -
-
-
-
2. there is no ios::nocreate/ios::noreplace - in ISO 14882 -
-
3. stream::attach(int - fd) is not in the standard any more -
-
4. The new headers -
-
-
-
4.4.1. New headers replacing C-headers -
-
4.4.2. - <fstream> does - not define std::cout, - std::cin etc. -
-
-
-
5. Iterators -
-
6. - Libc-macros (i.e. isspace from - <cctype>) -
-
7. - State of streams - -
-
8. vector::at is missing (i.e. gcc 2.95.2) -
-
9. Using std::char_traits<char>::eof() -
-
10. Using string::clear()/string::erase() -
-
11. Using stringstream's -
-
12. About... -
-
-
-

- In the following, when I say portable, I will refer to "portable among ISO - 14882-implementations". On the other hand, if I say "backportable" or - "conservative", I am talking about "compiles with older - libstdc++-implementations". -

-
-

- 1. Namespace std:: -

-

- The latest C++-standard (ISO-14882) requires that the standard - C++-library is defined in namespace std::. Thus, in order to use - classes from the standard C++-library, you can do one of three - things: -

-
    -
  • - -

    wrap your code in namespace std { - ... } => This is not an option because only symbols - from the standard c++-library are defined in namespace std::. -

    -
    • -
  • - -

    put a kind of - using-declaration in your source (either - using namespace std; or i.e. using - std::string;) => works well for source-files, but - cannot be used in header-files. -

    -
    • -
  • - -

    use a fully qualified name for - each libstdc++-symbol (i.e. std::string, - std::cout) => can always be used -

    -
    • -
-
-

-

- Because there are many compilers which still use an implementation - that does not have the standard C++-library in namespace - std::, some care is required to support these as - well. -

-

- Namespace back-portability-issues are generally not a problem with - g++, because versions of g++ that do not have libstdc++ in - std:: 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. -

-

- The following sections list some possible solutions to support compilers - that cannot ignore std::. -

-
-

- 1.1.1. Using namespace - composition if the project uses a separate - namespace -

-

- Gtk-- defines - most of its classes in namespace Gtk::. Thus, it was possible to - adapt Gtk-- to namespace std:: by using a C++-feature called - namespace composition. This is what happens if - you put a using-declaration into a - namespace-definition: the imported symbol(s) gets imported into the - currently active namespace(s). For example: - 

-		  namespace Gtk {
-		  using std::string;
-		  class Window { ... }
-		  }
-
- In this example, std::string gets imported into - namespace Gtk::. The result is that you don't have to use - std::string in this header, but still - std::string does not get imported into - user-space (the global namespace ::) unless the user does - using namespace Gtk; (which is not recommended - practice for Gtk--, so it is not a problem). Additionally, the - using-declarations are 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>) -

-
-
-

- 1.1.2. Defining an empty namespace std -

-

- By defining an (empty) namespace std:: before - using it, you avoid getting errors on systems where no part of the - library is in namespace std: - 

-		  namespace std { }
-		  using namespace std;
-
-

-
-
-

- 1.1.3. Avoid to use fully qualified names - (i.e. std::string) -

-

- If some compilers complain about using - std::string;, and if the "hack" for gtk-- mentioned above - does not work, then it might be a good idea to define a macro - NS_STD, which is defined to either "" or "std" - based on an autoconf-test. Then you should be able to use - NS_STD::string, which will evaluate to - ::string ("string in the global namespace") on - systems that do not put string in std::. (This is untested) -

-
-
-

- 1.1.4. How some open-source-projects deal - with this -

-

- This information was gathered around May 2000. It may not be correct - by the time you read this. -

-
-

- Table 1. Namespace std:: in Open-Source programs -

- - - - - - - - - - - - - - - - - - - - - - -
clanlibusual
pingususual
mozillausual
mnemonicnone
- libsigc++conservative-impl
-
-
-

- Table 2. Notations for categories -

- - - - - - - - - - - - - - - - -
usualmostly fully qualified names and some - using-declarations (but not in headers)
noneno namespace std at all
conservative-implwrap all - namespace-handling in macros to support compilers without - namespace-support (no libstdc++ used in headers)
-
-

- As you can see, this currently lacks an example of a project which - uses libstdc++-symbols in headers in a back-portable way (except - for Gtk--: see the ). -

-
-
-
-

- 2. there is no ios::nocreate/ios::noreplace - in ISO 14882 -

-

- I have seen ios::nocreate being used for input-streams, - most probably because the authors thought it would be more correct - to specify nocreate "explicitly". So you can simply leave it 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 ?). -

-
-
-

- 3. stream::attach(int - fd) is not in the standard any more -

-

- When using libstdc++-v3, you can use -

-

-

- - 
-		  #include <fstream>
-
-

- int basic_filebuf(__fd, __name, __mode);
int __fd;
const char* __name;
ios_base::openmode __mode; -

-

-

-
- For a portable solution (if there is one), you need to implement a - subclass of streambuf which opens a file given a - descriptor, and then pass an instance of this to the - stream-constructor (from the Josuttis-book). -

-
-
-

- 4. The new headers -

-

- All new headers can be seen in this source-code. -

-

- I think it is a problem for libstdc++-v3 to add links or wrappers - for the old headers, because the implementation has changed, and - the header name-changes indicate this. It might be preferable to - use the new headers and tell users of old compilers that they - should create links (which is what they will have to do sometime - anyway). -

-
-

- 4.4.1. New headers replacing C-headers -

-

- You should not use the C-headers (except for system-level headers) - from C++ programs. Instead, you should use a set of headers that - are named by prepending 'c' and, as usual, ommiting the extension - (.h). For example, instead of using <math.h>, you should use <cmath>. The standard - specifies that if you include the C-style header (<math.h> in this case), the symbols - will be available both in the global namespace and in namespace - std:: (libstdc++-v3, version 2.90.8 currently - puts them in std:: only) On the other hand, if - you include only the new header (i.e. <pcmath>), the symbols will only be - defined in namespace std:: (and macros will be - converted to inline-functions). -

-

- For more information on this, and for information on how the GNU - C++ implementation reuses ("shadows") the C library-functions, have - a look at - www.cantrip.org. -

-
-
-

- 4.4.2. - <fstream> does - not define std::cout, - std::cin etc. -

-

- In previous versions of the standard, <fstream.h>, <ostream.h> and <istream.h> used to define - cout, cin and so on. Because - of the templatized iostreams in libstdc++-v3, you need to include - <iostream> - explicitly to define these. -

-
-
-
-

- 5. Iterators -

-

- The following are not proper uses of iterators, but may be working - fixes for existing uses of iterators. -

-
    -
  • - -

    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()) - ?

    -
    • -
-
-

-
-
-

- 6. - Libc-macros (i.e. isspace from - <cctype>) -

-

- Glibc 2.0.x and 2.1.x define the <ctype.h> -functionality as - macros (isspace, isalpha etc.). Libstdc++-v3 "shadows" these macros - as described in the . -

-

- Older implementations of libstdc++ (g++-2 for egcs 1.x and g++-3 - for gcc 2.95.2), 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'); }
-
- will result in something like this (unless using g++-v3): - 
-		std:: (__ctype_b[(int) ( ( 'X' ) )] & (unsigned short int)
-		_ISspace )  ;
-
-

-

- One solution I can think of is to test for -v3 using - autoconf-macros, and define macros for each of the C-functions - (maybe that is possible with one "wrapper" macro as well ?). -

-

- Another solution which would fix g++ is to tell the user to modify a - header-file so that g++-2 (egcs 1.x) and g++-3 (gcc 2.95.2) define a - macro which 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
-
-		[ now 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>). -

-

- The solution to this problem was posted to the libstdc++-v3 - mailing-list: - Benjamin Kosnik <bkoz@redhat.com> writes: - " - --enable-cshadow-headers is currently broken. As a result, shadow - headers are not being searched.... - " -

-
-
-

- 7. - State of streams - -

-

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

-
-
-

- 8. vector::at is missing (i.e. gcc 2.95.2) -

-

- For my use, I added it to - prefix/include/g++-3/stl_vector.h: - 

-  reference operator[](size_type __n) { return *(begin() + __n); }
-  reference at(size_type __n) {
-    if (begin() + __n >= end())
-      throw out_of_range("vector::at");
-    return *(begin() + __n);
-  }
-  const_reference operator[](size_type __n) const { return *(begin() + __n); }
-  const_reference at(size_type __n) const {
-    if (begin() + __n >= end())
-      throw out_of_range("vector::at");
-    return *(begin() + __n);
-  }
-
-

-
-
-

- 9. Using std::char_traits<char>::eof() -

-

- 

-		#ifdef HAVE_CHAR_TRAITS
-		#define CPP_EOF std::char_traits<char>::eof()
-		#else
-		#define CPP_EOF EOF
-		#endif
-
-

-
-
-

- 10. Using string::clear()/string::erase() -

-

- 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()); 
-      }
-
- The implementation of erase seems to be more - complicated (from libstdc++-v3), but clear is not - implemented in gcc 2.95.2's libstdc++, so you should use - erase (which is probably faster than - operator=(charT*)). -

-
-
-

- 11. Using stringstream's -

-

- Libstdc++-v3 includes the new - i/ostringstream-classes, (<sstream>), but with older - implementations you still have to use i/ostrstream - (<strstream>): - 

-		#ifdef HAVE_SSTREAM
-		#include <sstream>
-		#else
-		#include <strstream>
-		#endif
-
-
-
    -
  • - -

    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
-		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;
-		}
-
-

-

- I have read the Josuttis book on Standard C++, so some information - comes from there. Additionally, there is information in - "info iostream", which covers the old implementation that gcc 2.95.2 - uses. -

-
-
-

- 12. About... -

-

- Please send any experience, additions, corrections or questions to - fnatter@gmx.net or for - discussion to the libstdc++-v3-mailing-list. -

-
-
- - diff --git a/libstdc++-v3/docs/18_support/howto.html b/libstdc++-v3/docs/18_support/howto.html deleted file mode 100644 index 6b6be0209b4..00000000000 --- a/libstdc++-v3/docs/18_support/howto.html +++ /dev/null @@ -1,269 +0,0 @@ - - - - - - - - - libstdc++-v3 HOWTO: Chapter 18 - - - - - -

Chapter 18: Library Support

- -

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

- - - -
-

Contents

- - -
- - - -

Types

-

All the types that you're used to in C are here in one form or - another. 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. -

-

In 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: - 

-   const                             // this is a const object...
-   class {
-   public:
-     template<class T>               // convertible to any type
-       operator T*() const           // of null non-member
-       { return 0; }                 // pointer...
-
-     template<class C, class T>      // or any type of null
-       operator T C::*() const       // member pointer...
-       { return 0; }
-
-   private:
-     void operator&() const;         // whose address can't be
-                                     // taken (see Item 27)...
-
-   } NULL;                           // and whose name is NULL
-
(Cribbed from the published version of - the - Effective C++ CD, reproduced here with permission.) -

-

If you aren't using g++ (why?), but you do have a compiler which - supports member function templates, then you can use this definition - of NULL (be sure to #undef any existing versions). It only helps if - you actually use NULL in function calls, though; if you make a call of - foo(0); instead of foo(NULL);, then you're back - where you started. -

-

Added Note: When we contacted Dr. Meyers to ask permission to - print this stuff, it prompted him to run this code through current - compilers to see what the state of the art is with respect to member - template functions. He posted - an - article to Usenet after discovering that the code above is not - valid! Even though it has no data members, it still needs a - user-defined constructor (which means that the class needs a type name - after all). The ctor can have an empty body; it just needs to be - there. (Stupid requirement? We think so too, and this will probably - be changed in the language itself.) -

-

Return to top of page or - to the FAQ. -

- -
-

Implementation properties

-

-

<limits>

- This header mainly defines traits classes to give access to various - implementation defined-aspects of the fundamental types. The - traits classes -- fourteen in total -- are all specilizations of the - template class numeric_limits 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;
-   };
-

-

Return to top of page or - to the FAQ. -

- -
-

Start and Termination

-

Not many changes here to <cstdlib> (the old stdlib.h). - 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: -

    -
  1. Static objects are destroyed in reverse order of their creation. -
  2. Functions registered with atexit() are called in - reverse order of registration, once per registration call. - (This isn't actually new.) -
  3. The previous two actions are "interleaved," that is, - given this code: - 
    -              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 propogate - out of them, Bad Things happen. -
-

-

Return to top of page or - to the FAQ. -

- -
-

Dynamic memory management

-

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

-

Return to top of page or - to the FAQ. -

- - - - - - - -
-

-Comments and suggestions are welcome, and may be sent to -Phil Edwards or -Gabriel Dos Reis. -
$Id: howto.html,v 1.6 2000/10/21 00:51:49 jsm28 Exp $ -

- - - - diff --git a/libstdc++-v3/docs/19_diagnostics/howto.html b/libstdc++-v3/docs/19_diagnostics/howto.html deleted file mode 100644 index 3502ed3b8a4..00000000000 --- a/libstdc++-v3/docs/19_diagnostics/howto.html +++ /dev/null @@ -1,107 +0,0 @@ - - - - - - - - - libstdc++-v3 HOWTO: Chapter 19 - - - - - -

Chapter 19: Diagnostics

- -

Chapter 19 deals with program diagnostics, such as exceptions - and assertions. You know, all the things we wish weren't even - necessary at all. -

- - - -
-

Contents

- - -
- - - -

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 heirarchy: -

- 
-   using std::runtime_error;
-   struct My_Exception : public runtime_error
-   {
-     public:
-       My_Exception (const string& whatarg)
-           : 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
-   };
-
-

Return to top of page or - to the FAQ. -

- -
-

Exception class hierarchy diagram

-

The diagram is in PDF, or - at least it will be once it gets finished. -

-

Return to top of page or - to the FAQ. -

- -
-

Concept checkers

-

As part of their 3.3 release, SGI added some nifty macros which - perform assertions on type properties. For example, the Standard - requires that types passed as template parameters to vector - be "Assignable" (which means what you think it means). -

-

The concept checkers allow the source code for vector to - declare - 

-   __STL_CLASS_REQUIRES(_Tp, _Assignable);
-
inside the template. _Tp is the element type of the - vector, and _Assignable is the concept to be checked (it is - defined in some back-end header files). When you instantiate - vector<MyType>, compile-time checking can be done on - whether MyType meets the requirements for vectors. -

-

This is an extension to the library. This documentation needs updating.

-

Return to top of page or - to the FAQ. -

- - - - - - - -
-

-Comments and suggestions are welcome, and may be sent to -Phil Edwards or -Gabriel Dos Reis. -
$Id: howto.html,v 1.4 2000/10/21 00:51:49 jsm28 Exp $ -

- - - - diff --git a/libstdc++-v3/docs/20_util/howto.html b/libstdc++-v3/docs/20_util/howto.html deleted file mode 100644 index 1976e2ba3ef..00000000000 --- a/libstdc++-v3/docs/20_util/howto.html +++ /dev/null @@ -1,193 +0,0 @@ - - - - - - - - - libstdc++-v3 HOWTO: Chapter 20 - - - - - -

Chapter 20: General Utilities

- -

Chapter 20 deals with utility classes and functions, such as - the oft-debated auto_ptr<>. -

- - - -
-

Contents

- - -
- - - -

auto_ptr is not omnipotent

-

I'm not going to try and explain all of the fun and delicious - things that can happen with misuse of the auto_ptr class template - (called AP here), nor am I going to try and teach you how to use - AP safely in the presence of copying. 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 not be 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 newsgroups, Usenet, Boost, etc). -

-

Return to top of page or - to the FAQ. -

- -
-

Automatically-generated operators

-

Many programs (for that matter, many of the Standard algorithms - and containers) require that you write comparison operators for - your classes, like operator>=. As any mathmatician - will tell you, once you have defined equality and ordering, all - of the other comparisons are easily defined in terms of those two. -

-

The Committee agrees. So, once you have written - operator== and operator< for your class - (whether they are global or member functions is up to you), you - can have the compiler do the grunt-work of generating the rest: - 

-    #include <header_with_my_op==_and_op<_defined>
-    #include <utility>
-    using std::rel_ops;     // note the nested namespace!
-
-    ...
-    if ((obj1 != obj2) || (obj3 >= obj4))  foo();
-
-

-

Return to top of page or - to the FAQ. -

- -
-

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/Technology/STL/functors.html. -

-

Return to top of page or - to the FAQ. -

- -
-

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> pain (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);
-
-

-

Return to top of page or - to the FAQ. -

- - - - - - -
-

-Comments and suggestions are welcome, and may be sent to -Phil Edwards or -Gabriel Dos Reis. -
$Id: howto.html,v 1.3 2000/10/21 00:51:49 jsm28 Exp $ -

- - - - diff --git a/libstdc++-v3/docs/21_strings/gotw29a.txt b/libstdc++-v3/docs/21_strings/gotw29a.txt deleted file mode 100644 index d823f30504e..00000000000 --- a/libstdc++-v3/docs/21_strings/gotw29a.txt +++ /dev/null @@ -1,155 +0,0 @@ -From: herbs@cntc.com (Herb Sutter) -Subject: Guru of the Week #29: Solution -Date: 22 Jan 1998 00:00:00 GMT -Message-ID: <6a8q26$9qa@netlab.cs.rpi.edu> -Newsgroups: comp.lang.c++.moderated - - - .--------------------------------------------------------------------. - | Guru of the Week problems and solutions are posted regularly on | - | news:comp.lang.c++.moderated. For past problems and solutions | - | see the GotW archive at http://www.cntc.com. | - | Is there a topic you'd like to see covered? mailto:herbs@cntc.com | - `--------------------------------------------------------------------' -_______________________________________________________ - -GotW #29: Strings - -Difficulty: 7 / 10 -_______________________________________________________ - - ->Write a ci_string class which is identical to the ->standard 'string' class, but is case-insensitive in the ->same way as the C function stricmp(): - -The "how can I make a case-insensitive string?" -question is so common that it probably deserves its own -FAQ -- hence this issue of GotW. - -Note 1: The stricmp() case-insensitive string -comparison function is not part of the C standard, but -it is a common extension on many C compilers. - -Note 2: What "case insensitive" actually means depends -entirely on your application and language. For -example, many languages do not have "cases" at all, and -for languages that do you have to decide whether you -want accented characters to compare equal to unaccented -characters, and so on. This GotW provides guidance on -how to implement case-insensitivity for standard -strings in whatever sense applies to your particular -situation. - - -Here's what we want to achieve: - -> 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 key here is to understand what a "string" actually -is in standard C++. If you look in your trusty string -header, you'll see something like this: - - typedef basic_string string; - -So string isn't really a class... it's a typedef of a -template. In turn, the basic_string<> template is -declared as follows, in all its glory: - - template, - class Allocator = allocator > - class basic_string; - -So "string" really means "basic_string, allocator >". We don't need -to worry about the allocator part, but the key here is -the char_traits part because char_traits defines how -characters interact and compare(!). - -basic_string supplies useful comparison functions that -let you compare whether a string is equal to another, -less than another, and so on. These string comparisons -functions are built on top of character comparison -functions supplied in the char_traits template. In -particular, the char_traits template supplies character -comparison functions named eq(), ne(), and lt() for -equality, inequality, and less-than comparisons, and -compare() and find() functions to compare and search -sequences of characters. - -If we want these to behave differently, all we have to -do is provide a different char_traits template! Here's -the easiest way: - - struct ci_char_traits : public char_traits - // just inherit all the other functions - // that we don't need to override - { - static bool eq( char c1, char c2 ) { - return tolower(c1) == tolower(c2); - } - - static bool ne( char c1, char c2 ) { - return tolower(c1) != tolower(c2); - } - - static bool lt( char c1, char c2 ) { - return tolower(c1) < tolower(c2); - } - - static int compare( const char* s1, - const char* s2, - size_t n ) { - return strnicmp( s1, s2, n ); - // if available on your compiler, - // otherwise you can roll your own - } - - static const char* - find( const char* s, int n, char a ) { - while( n-- > 0 && tolower(*s) != tolower(a) ) { - ++s; - } - return s; - } - }; - -And finally, the key that brings it all together: - - typedef basic_string ci_string; - -All we've done is created a typedef named "ci_string" -which operates exactly like the standard "string", -except that it uses ci_char_traits instead of -char_traits to get its character comparison -rules. Since we've handily made the ci_char_traits -rules case-insensitive, we've made ci_string itself -case-insensitive without any further surgery -- that -is, we have a case-insensitive string without having -touched basic_string at all! - -This GotW should give you a flavour for how the -basic_string template works and how flexible it is in -practice. If you want different comparisons than the -ones stricmp() and tolower() give you, just replace the -five functions shown above with your own code that -performs character comparisons the way that's -appropriate in your particular application. - - - -Exercise for the reader: - -Is it safe to inherit ci_char_traits from -char_traits this way? Why or why not? - - diff --git a/libstdc++-v3/docs/21_strings/howto.html b/libstdc++-v3/docs/21_strings/howto.html deleted file mode 100644 index 9ffd99d4deb..00000000000 --- a/libstdc++-v3/docs/21_strings/howto.html +++ /dev/null @@ -1,332 +0,0 @@ - - - - - - - - - libstdc++-v3 HOWTO: Chapter 21 - - - - - -

Chapter 21: Strings

- -

Chapter 21 deals with the C++ strings library (a welcome relief). -

- - - -
-

Contents

- - -
- - - -

MFC's CString

-

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 functons 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 - heirarchy. 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 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++-v3, their - string class is not. The SGI string is essentially - vector<char> and does not do any reference - counting like libstdc++-v3'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?) -
-

-

Return to top of page or - to the FAQ. -

- -
-

A case-insensitive string class

-

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 pages - on the GotW website were removed into cold storage, in - preparation for - a - published book of GotW notes. Before being - put on the web, of course, it was posted on Usenet, and that - posting containing the answer is available - here. -

-

See? Told you it was easy!

-

Added June 2000: The May 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. -

-

Return to top of page or - to the FAQ. -

- -
-

Breaking a C++ string into tokens

-

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. It's given - in this file 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). 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 outweight 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. -

-

Return to top of page or - to the FAQ. -

- -
-

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 (no pun). Here's the - simplistic version usually seen on Usenet: - 

-   #include <string>
-   #include <algorithm>
-   #include <cctype>      // old <ctype.h>
-
-   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.reserve(s.size());
-   std::transform (s.begin(), s.end(), capital_s.begin(), tolower);
- 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. -

-

At minimum, you can write short wrappers like - 

-   char toLower (char c)
-   {
-      return tolower(static_cast<unsigned char>(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 - here, 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 existance. -

-

Return to top of page or - to the FAQ. -

- - - - - - -
-

-Comments and suggestions are welcome, and may be sent to -Phil Edwards or -Gabriel Dos Reis. -
$Id: howto.html,v 1.6 2000/10/21 00:51:49 jsm28 Exp $ -

- - - - diff --git a/libstdc++-v3/docs/21_strings/stringtok_h.txt b/libstdc++-v3/docs/21_strings/stringtok_h.txt deleted file mode 100644 index 81d87a6efaf..00000000000 --- a/libstdc++-v3/docs/21_strings/stringtok_h.txt +++ /dev/null @@ -1,102 +0,0 @@ -/* - * stringtok.h -- Breaks a string into tokens. This is an example for lib3. - * - * Template function looks like this: - * - * template - * void stringtok (Container &l, - * string const &s, - * char const * const ws = " \t\n"); - * - * A nondestructive version of strtok() that handles its own memory and can - * be broken up by any character(s). Does all the work at once rather than - * in an invocation loop like strtok() requires. - * - * Container is any type that supports push_back(a_string), although using - * list and deque are indicated due to their O(1) push_back. - * (I prefer deque<> because op[]/at() is available as well.) The first - * parameter references an existing Container. - * - * s is the string to be tokenized. From the parameter declaration, it can - * be seen that s is not affected. Since references-to-const may refer to - * temporaries, you could use stringtok(some_container, readline("")) when - * using the GNU readline library. - * - * The final parameter is an array of characters that serve as whitespace. - * Whitespace characters default to one or more of tab, space, and newline, - * in any combination. - * - * 'l' need not be empty on entry. On return, 'l' will have the token - * strings appended. - * - * - * [Example: - * list ls; - * stringtok (ls, " this \t is\t\n a test "); - * for (list::const_iterator i = ls.begin(); - * i != ls.end(); ++i) - * { - * cerr << ':' << (*i) << ":\n"; - * } - * - * would print - * :this: - * :is: - * :a: - * :test: - * -end example] - * - * pedwards@jaj.com May 1999 -*/ - - -#include -#include // for strchr - - -/***************************************************************** - * This is the only part of the implementation that I don't like. - * It can probably be improved upon by the reader... -*/ -namespace { - inline bool - isws (char c, char const * const wstr) - { - return (strchr(wstr,c) != NULL); - } -} - - -/***************************************************************** - * Simplistic and quite Standard, but a bit slow. This should be - * templatized on basic_string instead, or on a more generic StringT - * that just happens to support ::size_type, .substr(), and so on. - * I had hoped that "whitespace" would be a trait, but it isn't, so - * the user must supply it. Enh, this lets them break up strings on - * different things easier than traits would anyhow. -*/ -template -void -stringtok (Container &l, string const &s, char const * const ws = " \t\n") -{ - const string::size_type S = s.size(); - string::size_type i = 0; - - while (i < S) { - // eat leading whitespace - while ((i < S) && (isws(s[i],ws))) ++i; - if (i == S) return; // nothing left but WS - - // find end of word - string::size_type j = i+1; - while ((j < S) && (!isws(s[j],ws))) ++j; - - // add word - l.push_back(s.substr(i,j-i)); - - // set up for next loop - i = j+1; - } -} - - diff --git a/libstdc++-v3/docs/21_strings/stringtok_std_h.txt b/libstdc++-v3/docs/21_strings/stringtok_std_h.txt deleted file mode 100644 index 2f3d7e07368..00000000000 --- a/libstdc++-v3/docs/21_strings/stringtok_std_h.txt +++ /dev/null @@ -1,39 +0,0 @@ -/* - * Same as stringtok_h.txt, but doesn't (visiably) use C functions. -*/ - -#include - -// The std:: prefix is not used here, for readability, and a line like -// "using namespace std;" is dangerous to have in a header file. - -template -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; - } -} - diff --git a/libstdc++-v3/docs/22_locale/codecvt.html b/libstdc++-v3/docs/22_locale/codecvt.html deleted file mode 100644 index 2ce6c95a1e5..00000000000 --- a/libstdc++-v3/docs/22_locale/codecvt.html +++ /dev/null @@ -1,522 +0,0 @@ - - -

- Notes on the codecvt implementation. -

- - -prepared by Benjamin Kosnik (bkoz@redhat.com) on August 28, 2000 - - -

-

-1. Abstract -

-

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

- -

-

-2. What the standard says -

-Around page 425 of the C++ Standard, this charming heading comes into view: - -
-22.2.1.5 - Template class codecvt [lib.locale.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.

- -

-

-3. Some thoughts on what would be useful -

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

-In particular, 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. - -

-Getting back to the frequently asked question: What about Unicode strings? - -

-What magic spell will do this conversion? - -

-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-CCITT, 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, UNICODELITTLE, 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 are 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. -
- -

-

-4. Problems with "C" code conversions : thread safety, global -locales, termination. -

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

-

-5. Design -

-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++-v3 implements a partial specialization -of the codecvt class with and iconv wrapper class, __enc_traits 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 __enc_traits 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 __enc_traits: - -

- -__enc_traits() : __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). - -

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

- -__enc_traits(const __enc_traits&) - -

-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, __enc_traits> is consistent with other -codecvt usage. - -

-

-6. Examples -

- -
    -
  • - a. conversions involving string literals - -
    -  typedef codecvt_base::result			result;
-  typedef unsigned short			unicode_t;
-  typedef unicode_t				int_type;
-  typedef char					ext_type;
-  typedef __enc_traits				enc_type;
-  typedef codecvt<int_type, ext_type, enc_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 );
-
    -
  • - b. conversions involving std::string -
  • - c. conversions involving std::filebuf and std::ostream -
- -More information can be found in the following testcases: -
    -
  • testsuite/22_locale/codecvt_char_char.cc -
  • testsuite/22_locale/codecvt_unicode_wchar_t.cc -
  • testsuite/22_locale/codecvt_unicode_char.cc -
  • testsuite/22_locale/codecvt_wchar_t_char.cc -
- -

-

-7. Unresolved Issues -

-
    -
  • - 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? -
    -
- -

-

-8. Acknowledgments -

-Ulrich Drepper for the iconv suggestions and patient answering of -late-night questions, Jason Merrill for the template partial -specialization hints, language clarification, and wchar_t fixes. - -

-

-9. Bibliography / Referenced Documents -

- -Drepper, Ulrich, GNU libc (glibc) 2.2 manual. In particular, Chapters "6. Character Set Handling" and "7 Locales and Internationalization" - -

-Drepper, Ulrich, Numerous, late-night email correspondence - -

-Feather, Clive, "A brief description of Normative Addendum 1," in particular the parts on Extended Character Sets -http://www.lysator.liu.se/c/na1.html - -

-Haible, Bruno, "The Unicode HOWTO" v0.18, 4 August 2000 -ftp://ftp.ilog.fr/pub/Users/haible/utf8/Unicode-HOWTO.html - -

-ISO/IEC 14882:1998 Programming languages - C++ - -

-ISO/IEC 9899:1999 Programming languages - C - -

-Khun, Markus, "UTF-8 and Unicode FAQ for Unix/Linux" -http://www.cl.cam.ac.uk/~mgk25/unicode.html - -

-Langer, Angelika and Klaus Kreft, Standard C++ IOStreams and Locales, Advanced Programmer's Guide and Reference, Addison Wesley Longman, Inc. 2000 - -

-Stroustrup, Bjarne, Appendix D, The C++ Programming Language, Special Edition, Addison Wesley, Inc. 2000 - -

-System Interface Definitions, Issue 6 (IEEE Std. 1003.1-200x) -The Open Group/The Institute of Electrical and Electronics Engineers, Inc. -http://www.opennc.org/austin/docreg.html - - diff --git a/libstdc++-v3/docs/22_locale/ctype.html b/libstdc++-v3/docs/22_locale/ctype.html deleted file mode 100644 index 08be102fe26..00000000000 --- a/libstdc++-v3/docs/22_locale/ctype.html +++ /dev/null @@ -1,146 +0,0 @@ - - -

- Notes on the ctype implementation. -

- - -prepared by Benjamin Kosnik (bkoz@redhat.com) on August 30, 2000 - - -

-

-1. Abstract -

-

-Woe is me. -

- -

-

-2. What the standard says -

- - -

-

-3. Problems with "C" ctype : global locales, termination. -

- -

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

-

-4. Design -

-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. As such, libstdc++-v3 implements - - - -

-

-5. Examples -

- -
-  typedef ctype cctype;
-
- -More information can be found in the following testcases: -
    -
  • testsuite/22_locale/ctype_char_members.cc -
  • testsuite/22_locale/ctype_wchar_t_members.cc -
- -

-

-6. Unresolved Issues -

- -
    -
  • how to deal with the global locale issue? - -
  • how to deal with different types than char, wchar_t? - -
  • codecvt/ctype overlap: 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::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 - -
  • rename abstract base class. See if just smash-overriding - is a better approach. Clarify, add sanity to naming. - -
- - -

-

-7. Acknowledgments -

-Ulrich Drepper for patient answering of late-night questions, skeletal -examples, and C language expertise. - -

-

-8. Bibliography / Referenced Documents -

- -Drepper, Ulrich, GNU libc (glibc) 2.2 manual. In particular, Chapters "6. Character Set Handling" and "7 Locales and Internationalization" - -

-Drepper, Ulrich, Numerous, late-night email correspondence - -

-ISO/IEC 14882:1998 Programming languages - C++ - -

-ISO/IEC 9899:1999 Programming languages - C - -

-Langer, Angelika and Klaus Kreft, Standard C++ IOStreams and Locales, Advanced Programmer's Guide and Reference, Addison Wesley Longman, Inc. 2000 - -

-Stroustrup, Bjarne, Appendix D, The C++ Programming Language, Special Edition, Addison Wesley, Inc. 2000 - -

-System Interface Definitions, Issue 6 (IEEE Std. 1003.1-200x) -The Open Group/The Institute of Electrical and Electronics Engineers, Inc. -http://www.opennc.org/austin/docreg.html - - diff --git a/libstdc++-v3/docs/22_locale/howto.html b/libstdc++-v3/docs/22_locale/howto.html deleted file mode 100644 index 8f559e09322..00000000000 --- a/libstdc++-v3/docs/22_locale/howto.html +++ /dev/null @@ -1,235 +0,0 @@ - - - - - - - - - libstdc++-v3 HOWTO: Chapter 22 - - - - - -

Chapter 22: Localization

- -

Chapter 22 deals with the C++ localization facilities. -

- - - -
-

Contents

- - -
- - - -

Stroustrup on Locales

-

Dr. Bjarne Stroustrup has released a - pointer - to Appendix D of his book, - The C++ - Programming Language (3rd Edition). It is a detailed - description of locales and how to use them. -

-

He also writes: -

- Please note that I still consider this detailed description of - locales beyond the needs of most C++ programmers. It is written - with experienced programmers in mind and novices will do best to - avoid it. -
-

-

Return to top of page or - to the FAQ. -

- -
-

Nathan Myers on Locales

-

An article entitled "The Standard C++ Locale" was published in - Dr. Dobb's Journal and can be found - here -

-

Return to top of page or - to the FAQ. -

- -
-

class locale

-

Notes made during the implementation of locales can be found - here. -

-

Return to top of page or - to the FAQ. -

- -
-

class codecvt

-

Notes made during the implementation of codecvt can be found - here. -

- -

The following is the abstract from the implementation notes: -

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

Return to top of page or - to the FAQ. -

- -
-

class ctype

-

Notes made during the implementation of ctype can be found - here. -

-

Return to top of page or - to the FAQ. -

- -
-

Correct Transformations

- -

A very common question on newsgroups and mailing lists is, "How - do I do <foo> to a character string?" where <foo> is - a task such as changing all the letters to uppercase, to lowercase, - testing for digits, etc. A skilled and conscientious programmer - will follow the question with another, "And how do I make the - code portable?" -

-

(Poor innocent programmer, you have no idea the depths of trouble - you are getting yourself into. 'Twould be best for your sanity if - you dropped the whole idea and took up basket weaving instead. No? - Fine, you asked for it...) -

-

The task of changing the case of a letter or classifying a character - as numeric, graphical, etc, all depends on the cultural context of the - program at runtime. So, first you must take the portability question - into account. Once you have localized the program to a particular - natural language, only then can you perform the specific task. - Unfortunately, specializing a function for a human language is not - as simple as declaring - extern "Danish" int tolower (int); . -

-

The C++ code to do all this proceeds in the same way. First, a locale - is created. Then member functions of that locale are called to - perform minor tasks. Continuing the example from Chapter 21, we wish - to use the following convenience functions: - 

-   namespace std {
-     template <class charT>
-       charT
-       toupper (charT c, const locale& loc) const;
-     template <class charT>
-       charT
-       tolower (charT c, const locale& loc) const;
-   }
- This function extracts the appropriate "facet" from the - locale loc and calls the appropriate member function of that - facet, passing c as its argument. The resulting character - is returned. -

-

For the C/POSIX locale, the results are the same as calling the - classic C toupper/tolower function that was used in previous - examples. For other locales, the code should Do The Right Thing. -

-

Of course, these functions take a second argument, and the - transformation algorithm's operator argument can only take a single - parameter. So we write simple wrapper structs to handle that. -

-

The next-to-final version of the code started in Chapter 21 looks like: - 

-   #include <iterator>    // for back_inserter
-   #include <locale>
-   #include <string>
-   #include <algorithm>
-   #include <cctype>      // old <ctype.h>
-
-   struct Toupper
-   {
-       Toupper (std::locale const& l) : loc(l) {;}
-       char operator() (char c)  { return std::toupper(c,loc); }
-   private:
-       std::locale const& loc;
-   };
-   
-   struct Tolower
-   {
-       Tolower (std::locale const& l) : loc(l) {;}
-       char operator() (char c)  { return std::tolower(c,loc); }
-   private:
-       std::locale const& loc;
-   };
-   
-   int main ()
-   {
-      std::string  s ("Some Kind Of Initial Input Goes Here");
-      Toupper      up ( std::locale("C") );
-      Tolower      down ( std::locale("C") );
-   
-      // Change everything into upper case
-      std::transform (s.begin(), s.end(), s.begin(),
-                      up
-                     );
-   
-      // Change everything into lower case
-      std::transform (s.begin(), s.end(), s.begin(),
-                      down
-                     );
-   
-      // Change everything back into upper case, but store the
-      // result in a different string
-      std::string  capital_s;
-      std::transform (s.begin(), s.end(), std::back_inserter(capital_s),
-                      up
-                     );
-   }
-

-

The final version of the code uses bind2nd to eliminate - the wrapper structs, but the resulting code is tricky. I have not - shown it here because no compilers currently available to me will - handle it. -

-

Return to top of page or - to the FAQ. -

- - - - - - -
-

-Comments and suggestions are welcome, and may be sent to -Phil Edwards or -Gabriel Dos Reis. -
$Id: howto.html,v 1.7 2000/10/21 00:51:50 jsm28 Exp $ -

- - - - diff --git a/libstdc++-v3/docs/22_locale/locale.html b/libstdc++-v3/docs/22_locale/locale.html deleted file mode 100644 index dc3510be351..00000000000 --- a/libstdc++-v3/docs/22_locale/locale.html +++ /dev/null @@ -1,103 +0,0 @@ - - -

- Notes on the locale implementation. -

- - -prepared by Benjamin Kosnik (bkoz@redhat.com) on September 15, 2000 - - -

-

-1. Abstract -

-

-

- -

-

-2. What the standard says -

- - -

-

-3. Problems with "C" locales : global locales, termination. -

- -

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

-

-4. Design -

-The two required specializations are implemented as follows: - - -

-

-5. Examples -

- -
-  typedef ctype cctype;
-
- -More information can be found in the following testcases: -
    -
  • testsuite/22_locale/ctype_char_members.cc -
  • testsuite/22_locale/ctype_wchar_t_members.cc -
- -

-

-6. Unresolved Issues -

- -
    -
  • locale -a displays available locales on linux - -
  • locale initialization: at what point does _S_classic, - _S_global get initialized? Can named locales assume this - initialization has already taken place? -
- - -

-

-7. Acknowledgments -

- -

-

-8. Bibliography / Referenced Documents -

- -Drepper, Ulrich, GNU libc (glibc) 2.2 manual. In particular, Chapters "6. Character Set Handling" and "7 Locales and Internationalization" - -

-Drepper, Ulrich, Numerous, late-night email correspondence - -

-ISO/IEC 14882:1998 Programming languages - C++ - -

-ISO/IEC 9899:1999 Programming languages - C - -

-Langer, Angelika and Klaus Kreft, Standard C++ IOStreams and Locales, Advanced Programmer's Guide and Reference, Addison Wesley Longman, Inc. 2000 - -

-Stroustrup, Bjarne, Appendix D, The C++ Programming Language, Special Edition, Addison Wesley, Inc. 2000 - -

-System Interface Definitions, Issue 6 (IEEE Std. 1003.1-200x) -The Open Group/The Institute of Electrical and Electronics Engineers, Inc. -http://www.opennc.org/austin/docreg.html - - diff --git a/libstdc++-v3/docs/23_containers/howto.html b/libstdc++-v3/docs/23_containers/howto.html deleted file mode 100644 index f254f923f7e..00000000000 --- a/libstdc++-v3/docs/23_containers/howto.html +++ /dev/null @@ -1,245 +0,0 @@ - - - - - - - - - libstdc++-v3 HOWTO: Chapter 23 - - - - - -

Chapter 23: Containers

- -

Chapter 23 deals with container classes and what they offer. -

- - - -
-

Contents

- - -
- - - -

Making code unaware of the container/array difference

-

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

-

Return to top of page or - to the FAQ. -

- -
-

Variable-sized bitmasks

-

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

-

Return to top of page or - to the FAQ. -

- -
-

Containers and multithreading

-

This section will mention some of the problems in designing MT - programs that use Standard containers. For information on other - aspects of multithreading (e.g., the library as a whole), see - the Received Wisdom on Chapter 17. -

-

An excellent page to read when working with templatized containers - and threads is - SGI's - http://www.sgi.com/Technology/STL/thread_safety.html. The - libstdc++-v3 uses the same definition of thread safety - when discussing design. A key point that beginners may miss is the - fourth major paragraph ("For most clients,"...), pointing - out that locking must nearly always be done outside the container, - by client code (that'd be you, not us *grin*). -

-

You didn't read it, did you? *sigh* I'm serious, go read the - SGI page. It's really good and doesn't take long, and makes most - of the points that would otherwise have to be made here (and does - a better job). -

-

That's much better. Now, the issue of MT has been brought up on - the libstdc++-v3 mailing list as well as the main GCC mailing list - several times. The Chapter 17 HOWTO has some links into the mail - archives, so you can see what's been thrown around. The usual - container (or pseudo-container, depending on how you look at it) - that people have in mind is string, which is one of the - points where libstdc++ departs from the SGI STL. As of the - 2.90.8 snapshot, the libstdc++-v3 string class is safe for - certain kinds of multithreaded access. -

-

For implementing a container which does its own locking, it is - trivial to (as SGI suggests) provide a wrapper class which obtains - the lock, performs the container operation, 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. -

- -

Return to top of page or - to the FAQ. -

- - - - - - -
-

-Comments and suggestions are welcome, and may be sent to -Phil Edwards or -Gabriel Dos Reis. -
$Id: howto.html,v 1.3 2000/10/21 00:51:50 jsm28 Exp $ -

- - - - diff --git a/libstdc++-v3/docs/23_containers/wrappers_h.txt b/libstdc++-v3/docs/23_containers/wrappers_h.txt deleted file mode 100644 index 53b59204220..00000000000 --- a/libstdc++-v3/docs/23_containers/wrappers_h.txt +++ /dev/null @@ -1,48 +0,0 @@ - -/***************************************************************** - * Functions to help treat arrays in a uniform manner. These were - * inspired by a thread on comp.lang.c++.moderated, started by Dietmar - * Kuehl and contributed to by the rest of the entire planet. - * - * beginof (x), endof (x), lengthof (x) now accompany sizeof, where x - * can be either a container (currently only sequences) or a builtin - * array (/not/ a pointer). The beginof/endof are intended for use in - * the algorithms library, and lengthof is a "sizing" function. - * - * Note example: - * char an_array [17]; - * cerr << lengthof(an_array) << endl; - * produces assembly code of - * mov 17,register0 - * call ofstream_put - * i.e., the template function inlining really does work; g++ - * requires -O3 (or -finline-functions) before it does this, though. - * - * pedwards 13Nov98 -*/ -// beginof -template - inline typename vector::iterator beginof (vector &v) - { return v.begin(); } - -template - inline T* beginof (T (&array)[sz]) { return array; } - - -// endof -template - inline typename vector::iterator endof (vector &v) - { return v.end(); } - -template - inline T* endof (T (&array)[sz]) { return array + sz; } - - -// lengthof -template - inline typename vector::size_type lengthof (vector &v) - { return v.size(); } - -template - inline unsigned int lengthof (T (&)[sz]) { return sz; } - diff --git a/libstdc++-v3/docs/24_iterators/howto.html b/libstdc++-v3/docs/24_iterators/howto.html deleted file mode 100644 index de2fac5dd9d..00000000000 --- a/libstdc++-v3/docs/24_iterators/howto.html +++ /dev/null @@ -1,94 +0,0 @@ - - - - - - - - - libstdc++-v3 HOWTO: Chapter 24 - - - - - -

Chapter 24: Iterators

- -

Chapter 24 deals with the FORTRAN subroutines for automatically - transforming lemmings into gold. -

- - - -
-

Contents

- - -
- - - -

They ain't 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++-v3 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 interator 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.) -

-

Return to top of page or - to the FAQ. -

- -
-

It ends where?

-

Blah. -

-

Return to top of page or - to the FAQ. -

- - - - - - -
-

-Comments and suggestions are welcome, and may be sent to -Phil Edwards or -Gabriel Dos Reis. -
$Id: howto.html,v 1.4 2000/10/21 00:51:50 jsm28 Exp $ -

- - - - diff --git a/libstdc++-v3/docs/25_algorithms/howto.html b/libstdc++-v3/docs/25_algorithms/howto.html deleted file mode 100644 index 118ccba865d..00000000000 --- a/libstdc++-v3/docs/25_algorithms/howto.html +++ /dev/null @@ -1,96 +0,0 @@ - - - - - - - - - libstdc++-v3 HOWTO: Chapter 25 - - - - - -

Chapter 25: Algorithms

- -

Chapter 25 deals with the generalized subroutines for automatically - transforming lemmings into gold. -

- - - -
-

Contents

- - -
- - - -

Prerequisites

-

The neatest accomplishment of the algorithms chapter is that all the - work is done via iterators, not containers directly. This means two - important things: -

    -
  1. 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. So do your own iterators. -
  2. 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 legal 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. -

-

-

-

Return to top of page or - to the FAQ. -

- -
-

Topic

-

Blah. -

-

Return to top of page or - to the FAQ. -

- - - - - - -
-

-Comments and suggestions are welcome, and may be sent to -Phil Edwards or -Gabriel Dos Reis. -
$Id: howto.html,v 1.4 2000/10/21 00:51:50 jsm28 Exp $ -

- - - - diff --git a/libstdc++-v3/docs/26_numerics/howto.html b/libstdc++-v3/docs/26_numerics/howto.html deleted file mode 100644 index 43670a9cc05..00000000000 --- a/libstdc++-v3/docs/26_numerics/howto.html +++ /dev/null @@ -1,142 +0,0 @@ - - - - - - - - - libstdc++-v3 HOWTO: Chapter 26 - - - - - -

Chapter 26: Numerics

- -

Chapter 26 deals with building block abstractions to aid in - numerical computing: -

    -
  • Template data structures such as valarray<> - and complex<>. -
  • Template numerical functions such as accumulate; - inner_product; partial_sum and - adjacent_difference. -
- All of the Standard C math functions are of course included in C++, - and overloaded versions for long, float, and - long double have been added for all of them. -

- - -
-

Contents

- - -
- - - -

Complex Number 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). -

-

Return to top of page or - to the FAQ. -

- -
-

Array Processing

-

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

-

Some more stuff should go here once somebody has time to write it. -

-

Return to top of page or - to the FAQ. -

- -
-

Numerical Functions

-

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

-

Return to top of page or - to the FAQ. -

- - - - - -
-

-Comments and suggestions are welcome, and may be sent to -Phil Edwards or -Gabriel Dos Reis. -
$Id: howto.html,v 1.6 2000/10/21 00:51:50 jsm28 Exp $ -

- - - - diff --git a/libstdc++-v3/docs/27_io/howto.html b/libstdc++-v3/docs/27_io/howto.html deleted file mode 100644 index e31c787f421..00000000000 --- a/libstdc++-v3/docs/27_io/howto.html +++ /dev/null @@ -1,345 +0,0 @@ - - - - - - - - - libstdc++-v3 HOWTO: Chapter 27 - - - - - -

Chapter 27: Input/Output

- -

Chapter 27 deals with iostreams and all their subcomponents - and extensions. All kinds of fun stuff. -

- - - -
-

Contents

- - -
- - - -

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

-

Return to top of page or - to the FAQ. -

- -
-

The buffering is screwing up my program!

- -

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-dependant. (The "newline-buffer-flushing only occuring - 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 thing 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, i.e., as soon as possible after opening: - 

-   std::ofstream    os ("/foo/bar/baz");
-   std::ifstream    is ("/qux/quux/quuux");
-   int   i;
-
-   os.rdbuf()->pubsetbuf(0,0);
-   is.rdbuf()->pubsetbuf(0,0);
-   ...
-   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-dependant. 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 has undefined behavior for - its sibling stringbuf, and specifying anything other - than (0,0) has varying effects. Other user-defined class derived - from streambuf can do whatever they want. -

-

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

-

Return to top of page or - to the FAQ. -

- -
-

Binary I/O

-

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

-

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

- -
-

Iostreams class hierarchy diagram

-

The diagram is in PDF. Rumor - has it that once Benjamin Kosnik has been dead for a few decades, - this work of his will be hung next to the Mona Lisa in the - Musee du Louvre. -

- -
-

What is this <sstream>/stringstreams thing?

-

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

- - - - -
-

-Comments and suggestions are welcome, and may be sent to -Phil Edwards or -Gabriel Dos Reis. -
$Id: howto.html,v 1.4 2000/11/29 20:37:02 pme Exp $ -

- - - - - - diff --git a/libstdc++-v3/docs/27_io/iostreams_hierarchy.pdf b/libstdc++-v3/docs/27_io/iostreams_hierarchy.pdf deleted file mode 100644 index ab889130017..00000000000 --- a/libstdc++-v3/docs/27_io/iostreams_hierarchy.pdf +++ /dev/null @@ -1 +0,0 @@ -%PDF-1.2 1 0 obj << /Type /Catalog /Pages 2 0 R >> endobj 2 0 obj << /Type /Pages /Count 1 /Kids [3 0 R] >> endobj 3 0 obj << /Type /Page /Parent 2 0 R /MediaBox [0 0 841 595] /Resources 4 0 R /Contents 5 0 R /PieceInfo << /Illustrator7.0 << /LastModified (D:19990723224941+00'00') >> >> >> endobj 4 0 obj << /ProcSet [/PDF /Text] /Font 6 0 R >> endobj 6 0 obj << /F0 7 0 R >> endobj 5 0 obj << /Length 4532 /Filter [/ASCII85Decode /FlateDecode] >> stream GhUtXCMt.N(B"F5&+aY/@Qi]I;%s0lBq&tK!K+"a/W^0g,*/;JNiYL/lXkYFSkBQ+3$VRLAAp6[+Gk2p ]Y$V'q][Ii0`9nKmh=9$qUafIYES-6c9>:0iiB70cd1lN;\^Z5B(On5=3Kp1o4O9Ms/FWC4.r(nFZ"ID e#N8>Y&;s3hk&Gh=oPY>g/R7S`N35&lSnKGJT'N#f3]=I^3Ma7p@ZTLj1W%,c`?_IA&WBR:iYE0/De,) .5tSk?gUfI?gLVJ]B-%RhCB-/&1(hF(H3"13[7AhH6TkcV(T9#\l_XZ&A6prLn^=89]&sO]lO>H;AgG. E*Ffh#_X%&%CJ$hiAQ5#<*ID"b0kT-./,#D&_iK%9J/jH(%lNWYDLdVe&3s]TMfhIS&j#;9I<#\Qb$,7 OX=,>d],8TWGK,=QAXgt=(NL2B`c5r3!;DaCQfNY@HgI98u#(\L+TN8Jl%5*BSV6Z6K9q_Z)(MW:'d`5 CE&^O_Q6P>1m6SXTkQu$46r]!#A8?WKTu\^;IZ(1X`PciW(Q+Lf.k&6r_R]!C16>/_7.8)ebcN7*qjii`eZi1/lL%Sq>dU+ngdD%eur2Ir!M];qA%XP nggM_lW7J!bTqU+1.e,$hd?==gUobOrnIVuqu)sI^0ESJMlYEI^7K1Boq03mjIdgC#]cL-`Mp(D""BX_ 4*ghojioIOq^$>j-UD`2S$S)U@SX26/\%YFiKkq]SH'UgFsDKYc3pK<*th-hCrY?5N'BlZta# XuECr[WqMT*BHe=_R7LH*hKeO"[W?DCL1*,ub^MT0XZm%bleOB\KK]eSSfp?Yd)Uop%!fsF5729u=_ZrQ 5i@n/UVhOk%R==$MqJL_I=6iS#FhP;d 2Ufpk&(MK2D4[:eTU]13N@h:pI!M%FR(1,0_QrEs+Q$' Yn2o%b82KoY(S\8Pd88GM)kr+\o3H%i1p+NQ0K1E_t@s\pi$i7GVkCc"r:[KJu^'S\<74km['*s#_\Ft dMtM_6;h@h@Xq':.(O*fP^rU]N.D+#-m,3igY6dHDAg)`Pc^^`PkR6[#7dB$&m<*P$o:\9>RPgW*&XO: =AJ*0Yqp!^F@ld:d@mtqV%U&G7$WCp^tP0cWR`Fi\,aRdr7U!:Cd_.&3$"/Ee0;p&J8WO>BkO<5Vi34m 7O=jKMcj^c`DsuQ7&c/HYmi"_5%_(>kr8t6*NoP5:e2bi&TMLFZW[O#aDk322g:'@0^j[o+dY&WH1=bO .5iY75"c']o1"[T&)?Y&?^*Q!WeRT]g9Bo\ocqOAgR@"4h\b^tXf)'7dPL?>[(>+T4=g/*U.0cD''>im=>33CX'CB; 3GJX7QE_7QK=04O^T Y;TT?I\&I@q5g"@TW[#C->uYV^H=klN'`Do:g44"6nm6Tr-GXCpaIu4.!A.l99YQFY7\B@RsIqM*r$L: ctp+YI=*i@S[\K\R_G:Lc+D[,GNc9fCo]L5+7FWa0\DE`.,n0-oYYaG;[jClT-,@fT`A!.$l0]d70>8& B2h**HZlu[*6;P:D\9*7o*f:V!7OpNp^k&9^Du'>a!=G06qosuDO;9WG&PPrhd'UE_5!QLVIXN?3kefN S)$62YNh%W3oAP7T>L9OFFLoL5jrpIjTBg1q$o2*oE"*" #MjR0VX;"P?T^dW4f?oH[02C`1F3P*&bn;/$"54+HToa31o9QYBA4E2-MB,p)'7MA_4rcY8H6p,*>Ye>MJNe+i?d8NU3c;RgeDM[M7b&\Egn`&g8I+]ePi'UB=X/WH9dDIHtH)X`qkOd%N"&E`qe= ?C"#SYq<"D#I:GXRB6%_QXsi[BhMK^%V-HR10NkrJK&KaWXQnDou/BF*pHQ#n3ORHThoac+*Yb"dV.30 jM4,s=K)(LjAZbj$uIba,:_-`>WX14KH.\GNa%Z91hBVdEouFiBIfLZe'R<"m*r.u[Ss*f^o-97="l59 0;]h"VcRV69',:O:;V@O.ZV.TM.$^-En$cc=3ej,]p"PO[r*65)!\T8[RDOPr?f5mpc-H830fjj?mOD&V2fGJ0;nXLjUYB7S;iW!$qjV;3)2" +p6_sKT,_'lJH#s.$JZoaCQVu3UpW/oCrX:X4?e;6^Bu\FcMQ*oIXa_hQd'=>[o[^$SJ%Da5fBUpW2&o rRRU_+s_\t&T5Y`>dV]'S-k@"Q_kM?n_.I&4da\chQkMCLk)1%@f4\9GX#!HfnpZSEd 5B4@A0t)n-ciJ-WAjb9Ai!?.?F9;/<=hf^D5%cfket6q?T``S$NEX'@qD/F@qIuIR-.3o33<0"0Z2*C& ](Tdo:@SsHBq*3gY@lfrQ[90l\$q+^c-^g0-3t+"EZa%<[+CI;?,F"&F!tPGJGBK!YuEtS^Mj9R"Iekj ftBa(*OOrY;2DU%`o3kZF#L!cVp0L-BKO8n.PU;?r:TE:TE=Ug9K7 !N&L88e(4u=W"i,"cZ?qFSk8.n>E?ad$qUprd3T>7CH16s 4(],a>iE0c7#WqRT.IqDUJll/WsBaY+eHbLpWU#QjTQ0aoa,:UJ=/+5M2!W7E1fE,-t0eH+m<,]+hjGn M'aa8e_U[@eh1I)Cd!4MWnHO2i]&!)gJ`E;)5'Y;lfW-c`Rrmh7SCpj.DWjc(`,PSO_oPJbKPG/RJ6HG&htqbr484ODB,["l69o4n9F i)8b-L%'&bR!>dH;\*!YB"Io8>$Wu.S,QU.iO`0ZY;Mu(')F>_.g?f&Kq^t6a\op<%ifGI2?T1@\fU!E4Q_?<[Fg&Df40DH29ln?<1(*I( *NMEfeVDBiQ[)(Ind`qAo(c4L3/+\H8?^>$PP"*O-o0p2HN^\%3V9r`NO/"VWSQH=-iXDQ?kBF~> endstream endobj 7 0 obj << /Type /Font /Subtype /Type1 /Name /F0 /BaseFont /Helvetica /Encoding /MacRomanEncoding >> endobj xref 0 8 0000000000 65535 f 0000000009 00000 n 0000000058 00000 n 0000000115 00000 n 0000000298 00000 n 0000000384 00000 n 0000000353 00000 n 0000005005 00000 n trailer << /Root 1 0 R /Size 8 >> startxref 5113 %%EOF \ No newline at end of file diff --git a/libstdc++-v3/docs/Makefile b/libstdc++-v3/docs/Makefile deleted file mode 100644 index bedbd883f18..00000000000 --- a/libstdc++-v3/docs/Makefile +++ /dev/null @@ -1,5 +0,0 @@ - - -faq/index.txt: faq/index.html - lynx -dump faq/index.html | sed "s%file://localhost`pwd`%..%" > $@ - diff --git a/libstdc++-v3/docs/configopts.html b/libstdc++-v3/docs/configopts.html deleted file mode 100644 index e6ed73d884f..00000000000 --- a/libstdc++-v3/docs/configopts.html +++ /dev/null @@ -1,175 +0,0 @@ - - - - - - - - libstdc++-v3 configure options - - - - - -

Interesting configure -options

- -

The latest version of this document is always available at - - http://gcc.gnu.org/libstdc++/configopts.html. -

- -

To the libstdc++-v3 homepage. - - - -

-

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 the latest - snapshot, 2.90.8. -

-

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

The configure script will automatically detect the highest level - of optimization that the compiler in use can use (certain - versions of g++ will ICE if given the -O2 option, but - this is fixed in later versions of the compiler). This --enable - flag will disable all optimizations and instruct the compiler to - emit as much extra debugging information as it can, for use - inside GDB. -

- -
--enable-cstdio [default] -

This is an abbreviated form of '--enable-cstdio=libio' - (described next). -

- -
--enable-cstdio=LIB -

Select a target-specific I/O package. As of libstdc++-v3 - snapshot 2.90.8, the choices are 'libio' to specify the GNU - I/O package (from - glibc, the - GNU C library), or 'stdio' to use a generic "C" abstraction. -

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

- -
--enable-cshadow-headers -

This turns on the code to construct shadowed C headers, and to - use c headers in the std:: namespace. Very experimental as of - this writing. -

- -
--enable-threads -

This is an abbreviated form of '--enable-threads=yes' - (described next). -

- -
--enable-threads=LIB -

Select a threading library. As of libstdc++-v3 snapshot 2.90.8, - the choices are: - 'yes' for some kind of default (hmmmmm); - 'decosf1', 'irix', 'mach', 'os2', 'posix'/'pthreads' - (same thing), - 'solaris', 'win32', 'dce', or 'vxworks' to select the - corresponding interface; - and 'single', 'no', or 'none' for the null-case, - single-threaded library. -

-

All of this is currently undergoing a lot of changes. As of - 2.90.8, 'single' and 'posix' are the only implemented models. -

- -
--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 - "g++-v3". - 

-   --with-gxx-include-dir=/foo/H-x86-gcc-3-c-gxx-inc/include/2.97-20001008
-

- -
--enable-cxx-flags=FLAGS -

With this option, you can pass a string of -f (functionality) - flags to the compiler to use when building libstdc++. FLAGS - is a quoted string of options, like - 

-  --enable-cxx-flags='-fsquangle -fvtable-gc -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 libgcc is 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
-  -fnew-abi
-  -fnew-exceptions
-  -ffunction-sections
-  -fvtable-gc
- and -fno- forms of the same. Tell us (the mailing list) if - you discover more! -

- -
--enable-wchar [default] -

Certain template specializations are required for wide character - conversion support. This is tricky and currently changing rapidly, - and can cause problems on new platforms. Disabling wide character - specializations is useful for initial porting steps, but builds - only a subset of what is required by ISO. -

-
-

-

Return to the top of the page or - to the homepage. -

- - - - -
-

-$Id: configopts.html,v 1.17 2000/11/29 20:37:02 pme Exp $ -

- - - - diff --git a/libstdc++-v3/docs/documentation.html b/libstdc++-v3/docs/documentation.html deleted file mode 100644 index f59da91070f..00000000000 --- a/libstdc++-v3/docs/documentation.html +++ /dev/null @@ -1,76 +0,0 @@ - - - - Standard C++ Library v3 - - - - - - - -

All of these documents (in fact, this entire homepage set) are - bundled with the library source, under the docs subdirectory, - for releases and snapshots. -

- -

Introductory notes for libstdc++

-

This is a short list of text files pertaining to this - implementation of ISO 14882. A brief description follows the name - of the file. -

- - -
-

Configuring, Building, Installing

- - -
-

Chapter-Specific Information, Extensions, Notes and Advice

-
    -
  1. Chapter 17 (Intro) -
  2. Chapter 18 (Library Support) -
  3. Chapter 19 (Diagnostics) -
  4. Chapter 20 (Utilities) -
  5. Chapter 21 (Strings) -
  6. Chapter 22 (Localization) -
  7. Chapter 23 (Containers) -
  8. Chapter 24 (Iterators) -
  9. Chapter 25 (Algorithms) -
  10. Chapter 26 (Numerics) -
  11. Chapter 27 (I/O) -
  12. Extensions to the Standard Library -
- - - - - diff --git a/libstdc++-v3/docs/doxygen/run_doxygen b/libstdc++-v3/docs/doxygen/run_doxygen new file mode 100644 index 00000000000..9585e04afd7 --- /dev/null +++ b/libstdc++-v3/docs/doxygen/run_doxygen @@ -0,0 +1,6 @@ +#!/bin/sh + + +# This file is a placeholder to keep the doxygen subdir in place. It +# will be used to test for the presence of doxygen(1) and run it. + diff --git a/libstdc++-v3/docs/ext/howto.html b/libstdc++-v3/docs/ext/howto.html deleted file mode 100644 index b668c446663..00000000000 --- a/libstdc++-v3/docs/ext/howto.html +++ /dev/null @@ -1,156 +0,0 @@ - - - - - - - - - libstdc++-v3 HOWTO: Extensions - - - - - -

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 these, be aware of two things: -

    -
  1. 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++-v3 may not recognize these names, or - treat them differently, or... -
  2. You should know how to access - these headers properly. -
-

- - - -
-

Contents

- - -
- - - -

Ropes and trees and hashes, oh my!

-

The SGI headers - 

-     <bvector>
-     <hash_map>
-     <hash_set>
-     <rope>
-     <slist>
-     <tree>
-
are all here; <bvector> exposes the old bit_vector - class that was used before specialization of vector<bool> was - available. <hash_map> and <hash_set> - are discussed further below. <rope> is the SGI - specialization for large strings ("rope," "large - strings," get it? love those SGI folks). - <slist> is a singly-linked list, for when the - doubly-linked list<> is too much space overhead, and - <tree> exposes the red-black tree classes used in the - implementation of the standard maps and sets. -

-

Okay, about those hashing classes... I'm going to foist most of the - work off onto SGI's own site. -

-

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 - "normal" implementations? 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.
-

-

(Side note: for those of you wondering, "Why wasn't a hash - table included in the Standard in the first #!$@ place?" I'll - give a quick answer: it was proposed, but too late and in too - unorganized a fashion. Some sort of hashing will undoubtably be - included in a future Standard. -

-

Return to top of page or - to the FAQ. -

- -
-

Added members

-

Some of the classes in the Standard Library have additional - publicly-available members. Of those, some are intended purely for - the implementors, for example, additional typedefs. Those won't be - described here (or anywhere else). This list will grow slowly, since - we expect it to be rare -- most extensions will be self-contained. -

-

-

    -
  • filebufs have another ctor with this signature:
    -basic_filebuf(int __fd, const char* __name, ios_base::openmode __mode); -
    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:
    - int __fd, // open file descriptor
    - const char* __name,
    - ios_base::openmode __mode // same as the other openmode uses -
-

-

Return to top of page or - to the FAQ. -

- -
-

Allocators

-

This will be blank for a while. It will describe all of the different - memory allocators, most inherited from SGI's code. Input is solicited. -

-

Return to top of page or - to the FAQ. -

- - - - - - - -
-

-Comments and suggestions are welcome, and may be sent to -Phil Edwards or -Gabriel Dos Reis. -
$Id: howto.html,v 1.3 2000/10/21 00:51:50 jsm28 Exp $ -

- - - - diff --git a/libstdc++-v3/docs/faq/index.html b/libstdc++-v3/docs/faq/index.html deleted file mode 100644 index 6aa1a0e8f09..00000000000 --- a/libstdc++-v3/docs/faq/index.html +++ /dev/null @@ -1,660 +0,0 @@ - - - - - - libstdc++-v3 FAQ - - - - - - -

libstdc++ Frequently Asked Questions

- -

The latest version of this document is always available at - -http://gcc.gnu.org/libstdc++/faq/.

- -

To the libstdc++-v3 homepage. - - -

-

Questions

-
    -
  1. General Information - -
      -
    1. What is libstdc++-v3? -
    2. Why should I use libstdc++? -
    3. Who's in charge of it? -
    4. How do I get libstdc++? -
    5. When is libstdc++ going to be finished? -
    6. How do I contribute to the effort? -
    7. What happened to libg++? I need that! -
    8. What if I have more questions? -
    - -
  2. Installation -
      -
    1. How do I install libstdc++-v3? -
    2. Is this a drop-in replacement for the - libstdc++ that's shipped with g++? -
    3. What is this CVS thing that you keep - mentioning? -
    4. How do I know if it works? -
    - -
  3. Platform-Specific Issues -
      -
    1. Can libstdc++-v3 be used with <my - favorite compiler>? -
    2. Building under Cygwin hangs/explodes!? -
    - -
  4. Known Bugs and Non-Bugs -
      -
    1. What works already? -
    2. Bugs in gcc/g++ (not libstdc++-v3) -
    3. Bugs in the C++ language/lib specification -
    4. Things in libstdc++ that look like bugs -
      The g++-3 headers are - not ours -
    5. Aw, that's easy to fix! -
    - -
  5. Miscellaneous -
      -
    1. string::iterator is not char*; - vector<T>::iterator is not T* -
    2. What's next after libstdc++-v3? -
    3. What about the STL from SGI? -
    4. Extensions and Backward Compatibility -
    5. Compiling with "-fnew-abi" -
    6. Is libstdc++-v3 thread-safe? -
    7. How do I get a copy of the ISO C++ Standard? -
    - -
- -
- - - -

1.0 General Information

- -

1.1 What is libstdc++-v3?

-

The GNU Standard C++ Library v3, or libstdc++-2.90.x/2.9x, is an - ongoing project to implement the ISO 14882 Standard C++ library - as described in chapters 17 through 27 and annex D. As the - library reaches stable plateaus, it is captured in a snapshot - and released. The current release is the - tenth snapshot. 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 CVS, and can even be browsed over the Web (see below). -

-

A more formal description of the V3 goals can be found in the - official design document. -

- -
-

1.2 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 C/C++/FORTRAN/<pick-a-language> compiler - (gcc, g++, etc) is widely considered to be - one of the leading compilers in the world. Its development - has recently been taken over 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 - (such as string, vector<>, iostreams, - and algorithms) will be freely available and fully compliant. - Programmers will no longer need to "roll their own" - nor be worried about platform-specific incompatabilities. -

- -
-

1.3 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, and Ulrich - Drepper are the lead maintainers of the CVS 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! -

- -
-

1.4 How do I get libstdc++?

-

The tenth (and latest) snapshot of libstdc++-v3 is - available via ftp. -

-

The homepage - has instructions for retrieving the latest CVS sources, and for - browsing the CVS sources over the web. -

-

The subset commonly known as the Standard Template Library - (chapters 23 through 25, mostly) is adapted from the SGI STL, - which is also an ongoing work. -

- -
-

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

- - -
-

1.6 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, is more than welcome! -

- -
-

1.7 What happened to 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. -

-

The libg++ was designed and created when there was no 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 - (e.g., statistics :-), the Standards Committee couldn't include - everything, and so a lot of those "obvious" classes - didn't get included. -

-

Since libstdc++ is an implementation of the Standard Library, we - have no plans at this time to include non-Standard utilities - in the implementation, however handy they are. (The extensions - provided in the SGI STL aren't maintained by us and don't get - a lot of our attention, because they don't require a lot of our - time.) It is entirely plausable that the "useful stuff" - from libg++ might be extracted into an updated utilities library, - but nobody has stated such a project yet. -

- -

(The Boost site houses free - C++ libraries that do varying things, and happened to be started - by members of the Standards Committee. Certain "useful - stuff" classes will probably migrate there.) -

-

For the bold and/or desperate, the - GCC FAQ - describes where to find the last libg++ source. -

- -
-

1.8 What if I have more questions?

-

If you have read the README and RELEASE-NOTES files, 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 - 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, - contact Phil Edwards - or Gabriel Dos Reis. -

- -
- -

2.0 Installation

-

2.1 How do I install libstdc++-v3?

-

Complete instructions are not given here (this is a FAQ, not - an installation document), but the tools required are few: -

-
    -
  • A release of libstdc++. -
  • A recent release of GCC (version 2.95 works). Note - that building GCC is much easier and more automated - than building the GCC 2.[78] series was. -
  • If you plan on hacking around with the makefiles, you - will need the tools autoconfand automake. -
  • GNU Make is the only make that supports these makefiles. -
-

The file documentation.html - provides a good overview of the steps necessary to build, install, - and use the library. Instructions for configuring the library - with new flags such as --enable-threads are there also. -

-

The top-level install.html and - RELEASE-NOTES files contain - the exact build and installation instructions. You may wish to - browse those files over CVSweb ahead of time to get a feel for - what's required. RELEASE-NOTES is located in the - ".../docs/17_intro/" directory of the distribution. -

- -
-

2.2 Is this a drop-in replacement for the - libstdc++ that's shipped with g++?

-

Yes, as of 2.90.8, it is intended as such. And as of 2.91, - libstdc++-v3 is the library that's shipped with - g++, so much of this answer has become moot. -

- -
-

2.3 What is this CVS thing that you - keep mentioning?

-

The Concurrent Versions System 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 CVS entry in - the GNU software catalogue has a better description as - well as a - link to the makers of CVS. -

-

The "anonymous client checkout" feature of CVS is - similar to anonymous FTP in that it allows anyone to retrieve - the latest libstdc++ sources. -

-

After the first of April, American users will have a - "/pharmacy" command-line option... - -

- -
-

2.4 How do I know if it works?

-

libstdc++-v3 comes with its own testsuite. You do not need - to actually install the library ("gmake - install") to run the testsuite. Note that 2.91 does - not use DejaGNU yet. -

-

To run the testsuite on the library after building it, use - "gmake check" while in your build directory. To run - the testsuite on the library after building and installing it, - use "gmake check-install" instead. -

-

The testsuite subdirectory in your build directory will then - contain three files of the form YYYYMMDD-mkcheck*.txt. One of - them (-mkcheck.txt itself) contains the results of the tests; - this can be mailed to the list. The other files (-mkchecklog.txt - and -mkcheckfiles.txt) contain messages from the compiler while - building the test programs, and a list of the tests to be run, - respectively. -

-

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

- -
-

3.0 Platform-Specific Issues

-

3.1 Can libstdc++-v3 be used with <my - favorite compiler>?

-

Probably not. Yet.

-

Because GCC advances so rapidly, development and testing of - libstdc++ is being done almost entirely under that compiler. - If you are curious about whether other, lesser compilers - (*grin*) support libstdc++, you are more than welcome to try. - Configuring and building the library (see above) will still - require certain tools, however. Also keep in mind that - building libstdc++ does not imply that your compiler - will be able to use all of the features found in the - C++ Standard Library. -

-

Since the goal of ISO Standardization is for all C++ - implementations to be able to share code, the final libstdc++ - should, in theory, be useable under any ISO-compliant - compiler. It will still be targeted and optimized for - GCC/g++, however. -

- -
-

3.2 Building under Cygwin hangs/explodes!?

-

Sometimes, yes. You're probably in the middle of generating - the numeric_limits specializations when it hangs, - right? Thought so... -

-

The <limits> header and its associated library - code are platform-specific. These files get generated from - scratch during installation, and it is this generator that is - hanging. More specifically, the only sure way to determine - what the numeric_limits<T>::traps boolean - should be is to actually divide by zero and see if it is - trapped or not. -

-

Under NT, this will occasionally just hang. On those - occasions when the test does not hang, the zero-division is - in fact trapped. That doesn't prevent hanging elsewhere. -

-

You have two options. You can get a newer cygwin1.dll (see the - Cygwin paragraph in the - installation instructions). - Or you can get a prebuilt set of bits/std_limits.h and - src/limitsMEMBERS.cc files from Mumit Khan's - Cygwin-related website. -

- -
-

4.0 Known Bugs and Non-Bugs

- Note that this section can get rapdily outdated -- such is the - nature of an open-source project. For the latest information, join - the mailing list or look through recent archives. The RELEASE- - NOTES and BUGS files are generally kept up-to-date. - -

4.1 What works already?

-

This is a verbatim clip from the "Status" section - of the RELEASE-NOTES for the latest snapshot. -

- - - -
-New: 
-- namespace std:: is now on by default.
-- choice of "C" include strategies, including the shadow header work,
-  or generic global to std mapping of required "C" types.
-- cpu/atomicity.h tweaks, additions of ia64 and arm support.
-- abstraction of atomicity.h header to support notion of os/atomicity.h files.
-- addition of backward header bits
-- use of system_header pragma
-- Conditional use of -Werror
-- preliminary support for new g++ diagnostics capabilities, including
-  -fdiagnostics-show-location=once
-- pedantic and shadow argument warning fixes 
-- Ugly, yet correct mechanism for dealing with "C" math adopted,
-  including the use of builtins.
-- updates and configure/build work to support new libtool
-- addition of strstream 
-- valarray work
-- complex work
-- update to SGI STL 3.3
-- libio sync between glibc/libstdc++-v3. Some divergence since initial
-  merge, but sources remain quite close.
-- IO fixes for alpha
-- wide character work for IO when using libio
-- addition of c_io_stdio and "C" IO abstraction layer.
-- auto_ptr fixes, testsuite additions
-- Attempts to use -ffunction-sections -fdata-sections and
-  --gc-sections, depending on use of GNU ld and specific features. As of
-  late, --gc-sections has been disabled due to problems with it throwing
-  away initialization sections. This work is ongoing.
-- long double support
-- sub directory removal, coherent organization of cpu and os-specific
-  files, consolidation of include directories, integration of the C++
-  support bits for operator new/delete,exceptions, etc. All includes
-  are now either in the include/* hierarchy or in libsupc++'s sub directory.
-- Support for more platforms, including irix and bsd variants.
-- filebuf tweaks to deal with variable-size buffers.
-- filebuf implementation for putbackc, etc. al.
-- ctype rewritten. Includes ctype, ctype, and others.
-- codecvt rewritten. Includes codecvt,
-  codecvt. In addition,
-  implementation-defined conversions using iconv are now supported with
-  the __enc_traits partial-specialization of the State template
-  parameter of the codecvt class. In this manner, conversions between
-  encodings such as UCS4, USC2, UNICODE, UNICODEBIG, UNICODELITTLE, etc
-  can be performed.
-- preliminary work on named locales
-- preliminary documentation for locale implementation has been established.
-- Many, many bug fixes.
-- Many, many testsuite additions and consistent VERIFY usage.
-- work on mkcheck to make it more flexible, use libtool, etc.
-
- - -
-

4.2 Bugs in gcc/g++ (not libstdc++-v3)

-

This is by no means meant to be complete nor exhaustive, but - mentions some problems that users may encounter when building - or using libstdc++. If you are experiencing one of these - problems, you can find more information on the libstdc++ and - the GCC mailing lists. -

-
    -
  • As of 2.91, these bugs have all been fixed. We look forward - to new ones, well, not exactly... -
- -
-

4.3 Bugs in the C++ language/lib specification

-

Yes, unfortunately, there are some. In a message -to the list, Nathan Myers announced that he has started a list of - problems in the ISO C++ Standard itself, especially with - regard to the chapters that concern the library. The list - itself is posted on his - website. Developers who are having problems interpreting - the Standard may wish to consult his notes. -

-

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

- -
-

4.4 Things in libstdc++ that look like bugs

-

There are things which are not bugs in the compiler (4.2) nor - the language specification (4.3), but aren't really bugs in - libstdc++, either. Really! -

-

The biggest of these is the quadzillions of warnings about the - library headers 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. There are multiple solutions - under discussion. -

-

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

-

Currently our header files are installed in - ${prefix}/include/g++-v3 (see the 'v'?). This may - change with the next release of GCC, as it may be too confusing, - but the - question has not yet been decided. -

- -
-

4.5 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 of course send the patch to our mailing list, not the - GCC 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. -

- -
-

5.0 Miscellaneous

-

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

-

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

- -
-

5.2 What's next after libstdc++-v3?

-

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

-

The ISO Committee will meet periodically to review Defect Reports - in the C++ Standard. Undoubtably some of these will result in - changes to the Standard, which will be reflected in patches to - libstdc++. Some of that is already happening, see 4.2. Some of - those changes are being predicted by the library maintainers, and - we add code to the library based on what the current proposed - resolution specifies. -

-

The current libstdc++ contains extensions to the Library which - must be explicitly requested by client code (for example, the - hash tables from SGI). Other extensions may be added to - libstdc++-v3 if they seem to be "standard" enough. - (For example, the "long long" type from C99.) - Bugfixes and rewrites (to improve or fix thread safety, for - instance) will of course be a continuing task. -

-

This - question about the next libstdc++ prompted some brief but - interesting speculation. -

- -
-

5.3 What about the STL from SGI?

-

The STL from SGI - is merged into libstdc++-v3 with changes as necessary. - Currently release 3.3 is being used. Changes in the STL - usually produce some weird bugs and lots of changes in the - rest of the libstd++ source as we scramble to keep up. :-) -

-

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

-

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

- -
-

5.4 Extensions and Backward Compatibility

-

Although you can specify -I options to make the - preprocessor search the g++-v3/ext and /backward directories, - it is better to refer to files there by their path, as in: - -

- 
-       #include <ext/hash_map>
-
-

Extensions to the library have - their own page. -

- -
-

5.5 Compiling with "-fnew-abi"

-

Towards the end of July 1999, this subject was brought up again - on the mailing list under a different name. The related - thread - (by the name HOWTO-honor-std) is very instructive. More info - is at the end of RELEASE-NOTES. -

-

This functionality is now automated and turned on by default. -

- -
-

5.6 Is libstdc++-v3 thread-safe?

-

Quick answer: no, as of 2.91 (tenth snapshot), the - library is not appropriate for multithreaded access. The - string class is MT-safe. -

-

This is assuming that your idea of "multithreaded" - is the same as ours... The general question of multithreading - and libstdc++-v3 is addressed in the chapter-specific advice for -Library - Introduction. Threadsafe containers are covered in - more detail in -the - Received Wisdom section on containers. - -

- -
-

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

- - - -
-

-Comments and suggestions are welcome, and may be sent to -Phil Edwards or -Gabriel Dos Reis. -
$Id: index.html,v 1.9 2000/11/29 20:37:02 pme Exp $ -

- - - - diff --git a/libstdc++-v3/docs/faq/index.txt b/libstdc++-v3/docs/faq/index.txt deleted file mode 100644 index 61e92a65bdf..00000000000 --- a/libstdc++-v3/docs/faq/index.txt +++ /dev/null @@ -1,603 +0,0 @@ - - libstdc++ Frequently Asked Questions - - The latest version of this document is always available at - [1]http://gcc.gnu.org/libstdc++/faq/. - - To the [2]libstdc++-v3 homepage. - _________________________________________________________________ - - Questions - - 1. [3]General Information - 1. [4]What is libstdc++-v3? - 2. [5]Why should I use libstdc++? - 3. [6]Who's in charge of it? - 4. [7]How do I get libstdc++? - 5. [8]When is libstdc++ going to be finished? - 6. [9]How do I contribute to the effort? - 7. [10]What happened to libg++? I need that! - 8. [11]What if I have more questions? - 2. [12]Installation - 1. [13]How do I install libstdc++-v3? - 2. [14]Is this a drop-in replacement for the libstdc++ that's - shipped with g++? - 3. [15]What is this CVS thing that you keep mentioning? - 4. [16]How do I know if it works? - 3. [17]Platform-Specific Issues - 1. [18]Can libstdc++-v3 be used with ? - 2. [19]Building under Cygwin hangs/explodes!? - 4. [20]Known Bugs and Non-Bugs - 1. [21]What works already? - 2. [22]Bugs in gcc/g++ (not libstdc++-v3) - 3. [23]Bugs in the C++ language/lib specification - 4. [24]Things in libstdc++ that look like bugs - [25]The g++-3 headers are not ours - 5. [26]Aw, that's easy to fix! - 5. [27]Miscellaneous - 1. [28]string::iterator is not char*; vector::iterator is not - T* - 2. [29]What's next after libstdc++-v3? - 3. [30]What about the STL from SGI? - 4. [31]Extensions and Backward Compatibility - 5. [32]Compiling with "-fnew-abi" - 6. [33]Is libstdc++-v3 thread-safe? - 7. [34]How do I get a copy of the ISO C++ Standard? - _________________________________________________________________ - - 1.0 General Information - -1.1 What is libstdc++-v3? - - The GNU Standard C++ Library v3, or libstdc++-2.90.x/2.9x, is an - ongoing project to implement the ISO 14882 Standard C++ library as - described in chapters 17 through 27 and annex D. As the library - reaches stable plateaus, it is captured in a snapshot and released. - The current release is [35]the tenth snapshot. 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 - CVS, and can even be browsed over the Web (see below). - - A more formal description of the V3 goals can be found in the official - [36]design document. - _________________________________________________________________ - -1.2 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 C/C++/FORTRAN/ compiler (gcc, g++, etc) is - widely considered to be one of the leading compilers in the world. Its - development has recently been taken over by the [37]GCC team. All of - the rapid development and near-legendary [38]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 (such as - string, vector<>, iostreams, and algorithms) will be freely available - and fully compliant. Programmers will no longer need to "roll their - own" nor be worried about platform-specific incompatabilities. - _________________________________________________________________ - -1.3 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, and Ulrich Drepper are the lead maintainers of - the CVS 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 [39]homepage. - If you have questions, ideas, code, or are just curious, sign up! - _________________________________________________________________ - -1.4 How do I get libstdc++? - - The tenth (and latest) snapshot of libstdc++-v3 is [40]available via - ftp. - - The [41]homepage has instructions for retrieving the latest CVS - sources, and for browsing the CVS sources over the web. - - The subset commonly known as the Standard Template Library (chapters - 23 through 25, mostly) is adapted from the SGI STL, which is also an - ongoing work. - _________________________________________________________________ - -1.5 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. - _________________________________________________________________ - -1.6 How do I contribute to the effort? - - Here is [42]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, is more than welcome! - _________________________________________________________________ - -1.7 What happened to 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. - - The libg++ was designed and created when there was no Standard to - provide guidance. Classes like linked lists are now provided for by - list 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 (e.g., statistics :-), - the Standards Committee couldn't include everything, and so a lot of - those "obvious" classes didn't get included. - - Since libstdc++ is an implementation of the Standard Library, we have - no plans at this time to include non-Standard utilities in the - implementation, however handy they are. (The extensions provided in - the SGI STL aren't maintained by us and don't get a lot of our - attention, because they don't require a lot of our time.) It is - entirely plausable that the "useful stuff" from libg++ might be - extracted into an updated utilities library, but nobody has stated - such a project yet. - - (The [43]Boost site houses free C++ libraries that do varying things, - and happened to be started by members of the Standards Committee. - Certain "useful stuff" classes will probably migrate there.) - - For the bold and/or desperate, the [44]GCC FAQ describes where to find - the last libg++ source. - _________________________________________________________________ - -1.8 What if I have more questions? - - If you have read the README and RELEASE-NOTES files, 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 to the list, use [45]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, contact [46]Phil - Edwards or [47]Gabriel Dos Reis. - _________________________________________________________________ - - 2.0 Installation - -2.1 How do I install libstdc++-v3? - - Complete instructions are not given here (this is a FAQ, not an - installation document), but the tools required are few: - * A release of libstdc++. - * A recent release of GCC (version 2.95 works). Note that building - GCC is much easier and more automated than building the GCC 2.[78] - series was. - * If you plan on hacking around with the makefiles, you will need - the tools [48]autoconfand [49]automake. - * GNU Make is the only make that supports these makefiles. - - The file [50]documentation.html provides a good overview of the steps - necessary to build, install, and use the library. Instructions for - configuring the library with new flags such as --enable-threads are - there also. - - The top-level install.html and [51]RELEASE-NOTES files contain the - exact build and installation instructions. You may wish to browse - those files over CVSweb ahead of time to get a feel for what's - required. RELEASE-NOTES is located in the ".../docs/17_intro/" - directory of the distribution. - _________________________________________________________________ - -2.2 Is this a drop-in replacement for the libstdc++ that's shipped with g++? - - Yes, as of 2.90.8, it is intended as such. And as of 2.91, - libstdc++-v3 is the library that's shipped with g++, so much of this - answer has become moot. - _________________________________________________________________ - -2.3 What is this CVS thing that you keep mentioning? - - The Concurrent Versions System 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 [52]CVS entry in the GNU - software catalogue has a better description as well as a [53]link to - the makers of CVS. - - The "anonymous client checkout" feature of CVS is similar to anonymous - FTP in that it allows anyone to retrieve the latest libstdc++ sources. - - After the first of April, American users will have a "/pharmacy" - command-line option... - _________________________________________________________________ - -2.4 How do I know if it works? - - libstdc++-v3 comes with its own testsuite. You do not need to actually - install the library ("gmake install") to run the testsuite. Note that - 2.91 does not use DejaGNU yet. - - To run the testsuite on the library after building it, use "gmake - check" while in your build directory. To run the testsuite on the - library after building and installing it, use "gmake check-install" - instead. - - The testsuite subdirectory in your build directory will then contain - three files of the form YYYYMMDD-mkcheck*.txt. One of them - (-mkcheck.txt itself) contains the results of the tests; this can be - mailed to the list. The other files (-mkchecklog.txt and - -mkcheckfiles.txt) contain messages from the compiler while building - the test programs, and a list of the tests to be run, respectively. - - 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! - _________________________________________________________________ - - 3.0 Platform-Specific Issues - -3.1 Can libstdc++-v3 be used with ? - - Probably not. Yet. - - Because GCC advances so rapidly, development and testing of libstdc++ - is being done almost entirely under that compiler. If you are curious - about whether other, lesser compilers (*grin*) support libstdc++, you - are more than welcome to try. Configuring and building the library - (see above) will still require certain tools, however. Also keep in - mind that building libstdc++ does not imply that your compiler will be - able to use all of the features found in the C++ Standard Library. - - Since the goal of ISO Standardization is for all C++ implementations - to be able to share code, the final libstdc++ should, in theory, be - useable under any ISO-compliant compiler. It will still be targeted - and optimized for GCC/g++, however. - _________________________________________________________________ - -3.2 Building under Cygwin hangs/explodes!? - - Sometimes, yes. You're probably in the middle of generating the - numeric_limits specializations when it hangs, right? Thought so... - - The header and its associated library code are - platform-specific. These files get generated from scratch during - installation, and it is this generator that is hanging. More - specifically, the only sure way to determine what the - numeric_limits::traps boolean should be is to actually divide by - zero and see if it is trapped or not. - - Under NT, this will occasionally just hang. On those occasions when - the test does not hang, the zero-division is in fact trapped. That - doesn't prevent hanging elsewhere. - - You have two options. You can get a newer cygwin1.dll (see the Cygwin - paragraph in the [54]installation instructions). Or you can get a - prebuilt set of bits/std_limits.h and src/limitsMEMBERS.cc files from - Mumit Khan's [55]Cygwin-related website. - _________________________________________________________________ - - 4.0 Known Bugs and Non-Bugs - - Note that this section can get rapdily outdated -- such is the nature - of an open-source project. For the latest information, join the - mailing list or look through recent archives. The RELEASE- NOTES and - BUGS files are generally kept up-to-date. - -4.1 What works already? - - This is a verbatim clip from the "Status" section of the RELEASE-NOTES - for the latest snapshot. -New: -- namespace std:: is now on by default. -- choice of "C" include strategies, including the shadow header work, - or generic global to std mapping of required "C" types. -- cpu/atomicity.h tweaks, additions of ia64 and arm support. -- abstraction of atomicity.h header to support notion of os/atomicity.h files. -- addition of backward header bits -- use of system_header pragma -- Conditional use of -Werror -- preliminary support for new g++ diagnostics capabilities, including - -fdiagnostics-show-location=once -- pedantic and shadow argument warning fixes -- Ugly, yet correct mechanism for dealing with "C" math adopted, - including the use of builtins. -- updates and configure/build work to support new libtool -- addition of strstream -- valarray work -- complex work -- update to SGI STL 3.3 -- libio sync between glibc/libstdc++-v3. Some divergence since initial - merge, but sources remain quite close. -- IO fixes for alpha -- wide character work for IO when using libio -- addition of c_io_stdio and "C" IO abstraction layer. -- auto_ptr fixes, testsuite additions -- Attempts to use -ffunction-sections -fdata-sections and - --gc-sections, depending on use of GNU ld and specific features. As of - late, --gc-sections has been disabled due to problems with it throwing - away initialization sections. This work is ongoing. -- long double support -- sub directory removal, coherent organization of cpu and os-specific - files, consolidation of include directories, integration of the C++ - support bits for operator new/delete,exceptions, etc. All includes - are now either in the include/* hierarchy or in libsupc++'s sub directory. -- Support for more platforms, including irix and bsd variants. -- filebuf tweaks to deal with variable-size buffers. -- filebuf implementation for putbackc, etc. al. -- ctype rewritten. Includes ctype, ctype, and others. -- codecvt rewritten. Includes codecvt, - codecvt. In addition, - implementation-defined conversions using iconv are now supported with - the __enc_traits partial-specialization of the State template - parameter of the codecvt class. In this manner, conversions between - encodings such as UCS4, USC2, UNICODE, UNICODEBIG, UNICODELITTLE, etc - can be performed. -- preliminary work on named locales -- preliminary documentation for locale implementation has been established. -- Many, many bug fixes. -- Many, many testsuite additions and consistent VERIFY usage. -- work on mkcheck to make it more flexible, use libtool, etc. - _________________________________________________________________ - -4.2 Bugs in gcc/g++ (not libstdc++-v3) - - This is by no means meant to be complete nor exhaustive, but mentions - some problems that users may encounter when building or using - libstdc++. If you are experiencing one of these problems, you can find - more information on the libstdc++ and the GCC mailing lists. - * As of 2.91, these bugs have all been fixed. We look forward to new - ones, well, not exactly... - _________________________________________________________________ - -4.3 Bugs in the C++ language/lib specification - - Yes, unfortunately, there are some. In a [56]message to the list, - Nathan Myers announced that he has started a list of problems in the - ISO C++ Standard itself, especially with regard to the chapters that - concern the library. The list itself is [57]posted on his website. - Developers who are having problems interpreting the Standard may wish - to consult his notes. - - 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 [58]here. - _________________________________________________________________ - -4.4 Things in libstdc++ that look like bugs - - There are things which are not bugs in the compiler (4.2) nor the - language specification (4.3), but aren't really bugs in libstdc++, - either. Really! - - The biggest of these is the quadzillions of warnings about the library - headers 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. There - are multiple solutions under discussion. - - 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 [59]the GCC bug database). - - If the headers are in ${prefix}/include/g++-3, 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. - - Currently our header files are installed in ${prefix}/include/g++-v3 - (see the 'v'?). This may change with the next release of GCC, as it - may be too confusing, but [60]the question has not yet been decided. - _________________________________________________________________ - -4.5 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 - [61]submitting patches that covers the procedure, but for libstdc++ - you should of course send the patch to our mailing list, not the GCC - mailing list. The libstdc++ [62]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 [63]testsuite -- but only if such a test - exists. - _________________________________________________________________ - - 5.0 Miscellaneous - -5.1 string::iterator is not char*; vector::iterator is not T* - - If you have code that depends on container iterators being - implemented as pointer-to-T, your code is broken. - - 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. - _________________________________________________________________ - -5.2 What's next after libstdc++-v3? - - Hopefully, not much. The goal of libstdc++-v3 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. - - The ISO Committee will meet periodically to review Defect Reports in - the C++ Standard. Undoubtably some of these will result in changes to - the Standard, which will be reflected in patches to libstdc++. Some of - that is already happening, see 4.2. Some of those changes are being - predicted by the library maintainers, and we add code to the library - based on what the current proposed resolution specifies. - - The current libstdc++ contains extensions to the Library which must be - explicitly requested by client code (for example, the hash tables from - SGI). Other extensions may be added to libstdc++-v3 if they seem to be - "standard" enough. (For example, the "long long" type from C99.) - Bugfixes and rewrites (to improve or fix thread safety, for instance) - will of course be a continuing task. - - [64]This question about the next libstdc++ prompted some brief but - interesting [65]speculation. - _________________________________________________________________ - -5.3 What about the STL from SGI? - - The [66]STL from SGI is merged into libstdc++-v3 with changes as - necessary. Currently release 3.3 is being used. Changes in the STL - usually produce some weird bugs and lots of changes in the rest of the - libstd++ source as we scramble to keep up. :-) - - 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, however. - - The FAQ for SGI's STL (one jump off of their main page) is recommended - reading. - _________________________________________________________________ - -5.4 Extensions and Backward Compatibility - - Although you can specify -I options to make the preprocessor search - the g++-v3/ext and /backward directories, it is better to refer to - files there by their path, as in: - #include - - - Extensions to the library have [67]their own page. - _________________________________________________________________ - -5.5 Compiling with "-fnew-abi" - - Towards the end of July 1999, this subject was brought up again on the - mailing list under a different name. The related [68]thread (by the - name HOWTO-honor-std) is very instructive. More info is at the end of - RELEASE-NOTES. - - This functionality is now automated and turned on by default. - _________________________________________________________________ - -5.6 Is libstdc++-v3 thread-safe? - - Quick answer: no, as of 2.91 (tenth snapshot), the library is not - appropriate for multithreaded access. The string class is MT-safe. - - This is assuming that your idea of "multithreaded" is the same as - ours... The general question of multithreading and libstdc++-v3 is - addressed in the chapter-specific advice for [69]Library Introduction. - Threadsafe containers are covered in more detail in [70]the Received - Wisdom section on containers. - _________________________________________________________________ - -5.7 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 [71]here. (And if you've already registered with them, clicking - this link will take you to directly to the place where you can [72]buy - the standard on-line. - - Who is your country's member body? Visit the [73]ISO homepage and find - out! - _________________________________________________________________ - - Comments and suggestions are welcome, and may be sent to [74]Phil - Edwards or [75]Gabriel Dos Reis. - $Id: index.html,v 1.9 2000/11/29 20:37:02 pme Exp $ - -References - - 1. http://gcc.gnu.org/libstdc++/faq/ - 2. ../index.html - 3. ../faq/index.html#1_0 - 4. ../faq/index.html#1_1 - 5. ../faq/index.html#1_2 - 6. ../faq/index.html#1_3 - 7. ../faq/index.html#1_4 - 8. ../faq/index.html#1_5 - 9. ../faq/index.html#1_6 - 10. ../faq/index.html#1_7 - 11. ../faq/index.html#1_8 - 12. ../faq/index.html#2_0 - 13. ../faq/index.html#2_1 - 14. ../faq/index.html#2_2 - 15. ../faq/index.html#2_3 - 16. ../faq/index.html#2_4 - 17. ../faq/index.html#3_0 - 18. ../faq/index.html#3_1 - 19. ../faq/index.html#3_2 - 20. ../faq/index.html#4_0 - 21. ../faq/index.html#4_1 - 22. ../faq/index.html#4_2 - 23. ../faq/index.html#4_3 - 24. ../faq/index.html#4_4 - 25. ../faq/index.html#4_4_interface - 26. ../faq/index.html#4_5 - 27. ../faq/index.html#5_0 - 28. ../faq/index.html#5_1 - 29. ../faq/index.html#5_2 - 30. ../faq/index.html#5_3 - 31. ../faq/index.html#5_4 - 32. ../faq/index.html#5_5 - 33. ../faq/index.html#5_6 - 34. ../faq/index.html#5_7 - 35. ftp://gcc.gnu.org/pub/libstdc++/libstdc++-2.91.tar.gz - 36. ../17_intro/DESIGN - 37. http://gcc.gnu.org/ - 38. http://gcc.gnu.org/gcc-2.95/buildstat.html - 39. ../index.html - 40. ftp://gcc.gnu.org/pub/libstdc++/libstdc++-2.91.tar.gz - 41. ../index.html - 42. ../17_intro/contribute.html - 43. http://www.boost.org/ - 44. http://gcc.gnu.org/fom_serv/cache/33.html - 45. mailto:libstdc++@gcc.gnu.org - 46. mailto:pme@sources.redhat.com - 47. mailto:gdr@gcc.gnu.org - 48. http://sources.redhat.com/autoconf/ - 49. http://sources.redhat.com/automake/ - 50. ../documentation.html - 51. ../17_intro/RELEASE-NOTES - 52. http://www.gnu.org/software/cvs/cvs.html - 53. http://www.cyclic.com/ - 54. ../install.html - 55. http://www.xraylith.wisc.edu/~khan/software/gnu-win32/libstdc++-v3.html - 56. http://gcc.gnu.org/ml/libstdc++/1998/msg00006.html - 57. http://www.cantrip.org/draft-bugs.txt - 58. http://anubis.dkuug.dk/jtc1/sc22/wg21/ - 59. http://gcc.gnu.org/gnatswrite.html - 60. http://gcc.gnu.org/ml/gcc/2000-10/msg00732.html - 61. http://gcc.gnu.org/contribute.html - 62. ../17_intro/contribute.html - 63. ../faq/index.html#2_4 - 64. http://gcc.gnu.org/ml/libstdc++/1999/msg00080.html - 65. http://gcc.gnu.org/ml/libstdc++/1999/msg00084.html - 66. http://www.sgi.com/Technology/STL/ - 67. ../ext/howto.html - 68. http://gcc.gnu.org/ml/libstdc++/1999-q3/msg00066.html - 69. http://gcc.gnu.org/libstdc++/17_intro/howto.html#3 - 70. http://gcc.gnu.org/libstdc++/23_containers/howto.html - 71. http://www.ansi.org/ - 72. http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%2D1998 - 73. http://www.iso.ch/ - 74. mailto:pme@sources.redhat.com - 75. mailto:gdr@gcc.gnu.org diff --git a/libstdc++-v3/docs/html/17_intro/BADNAMES b/libstdc++-v3/docs/html/17_intro/BADNAMES new file mode 100644 index 00000000000..3e9557bc8d9 --- /dev/null +++ b/libstdc++-v3/docs/html/17_intro/BADNAMES @@ -0,0 +1,162 @@ + +This is the list of names "reserved to the implementation" +that have been claimed by certain compilers 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 + +For egcs: + + 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 diff --git a/libstdc++-v3/docs/html/17_intro/BUGS b/libstdc++-v3/docs/html/17_intro/BUGS new file mode 100644 index 00000000000..150503593fe --- /dev/null +++ b/libstdc++-v3/docs/html/17_intro/BUGS @@ -0,0 +1,31 @@ +2000-03-24 libstdc++2.90.8 + +- testsuite/27_io/istream_extractors_char.cc: + Failing on all platforms with -O2, working with -O. Need to look at this. + +- _GLIBCPP_HAS_BUILTIN_SINF: We should still hold out for a cleaner solution the is currenly the case in bits/std_cmath.h. + +- there may be one set of remaining string bugs, dependant on final +clarification of the string::find technicalities when finding in an +empty string or using an empty string for an argument. At the very +least, v-3 has interpreted the standard in a way that is in opposition +to other libraries on other platforms. + +- trigraphs and keywords a la the iso646 header are not correctly +implemented. It looks like the compiler recognizes them as keywords +but then doesn't translate into the correct bit ops. It is a mystery. + +- wide strings have not been tested, and may therefore be unusable. + +- Chapter 27 io functionality is not finished. As such, there are +known bugs in: filebuf::putbackfail + +- Many facet implementations are stubs. (22) + +- Almost no optimizations for small-footprint/low-overhead. (22,27) + +- There has been some work to wrap the C headers in namespace std::, but + it may not be complete yet, and C macros are not shadowed. Please consult + the mailing list archives for more information. + + diff --git a/libstdc++-v3/docs/html/17_intro/C++STYLE b/libstdc++-v3/docs/html/17_intro/C++STYLE new file mode 100644 index 00000000000..f4f84372403 --- /dev/null +++ b/libstdc++-v3/docs/html/17_intro/C++STYLE @@ -0,0 +1,318 @@ + +C++ Standard Library Style Guidelines DRAFT 1999-02-26 +------------------------------------- + +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 here: + +http://www.gnu.ai.mit.edu/prep/standards_toc.html + +ChangeLog entries for member functions should use the +classname::member function name syntax as follows: + +1999-04-15 Dennis Ritchie + + * 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 + void + template_function(args) + { } + -NOT- + template + 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 + class basic_ios : public ios_base + { + public: + // Types: + }; + -NOT- + template + class basic_ios : public ios_base + { + public: + // Types: + }; + -NOT- + template + 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 defintions + 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: ??? + +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: + // ctor, op=, dtor + gribble() throw(); + + gribble(const gribble&); + + explicit + gribble(int __howmany); + + gribble& + operator=(const gribble&); + + virtual + ~gribble() throw (); + + // argument + 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 + void + public_template() const throw(); + + template + 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 // notice: "typename", not "class", no space + long_return_value_type + 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. + } + +} + + + + diff --git a/libstdc++-v3/docs/html/17_intro/CHECKLIST b/libstdc++-v3/docs/html/17_intro/CHECKLIST new file mode 100644 index 00000000000..bef9635e850 --- /dev/null +++ b/libstdc++-v3/docs/html/17_intro/CHECKLIST @@ -0,0 +1,6014 @@ + + Completion Checklist for the Standard C++ Library + Updated: 1999-05-18 + + 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: (restricted site) + http://www.cygnus.com/iso/wp/html/fdis/lwg-issues.html + The LWG has announced its intention to release a public version + of the issues list, URL to be added here. XXX + + 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. + + ---------------------------------------------------------------------- + + + +X + + + + + [C header names must be in std:: to qualify. Related to shadow/ dir.] + + +X + + + Macro: +X errno, declared or defined in . + + Macro fn: +X setjmp(jmp_buf), declared or defined in +X va_end(va_list), declared or defined in + + 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 +X NULL +X offsetof +X ptrdiff_t +X size_t + + 18.2 Implementation properties [lib.support.limits] + + , , and + + 18.2.1 Numeric limits [lib.limits] + + [Note: the numeric_limits templates are now automatically + generated. ] + +X template class numeric_limits; + +T enum float_round_style; +T enum float_denorm_style; + +T template<> class numeric_limits; + +T template<> class numeric_limits; +T template<> class numeric_limits; +T template<> class numeric_limits; +T template<> class numeric_limits; + +T template<> class numeric_limits; +T template<> class numeric_limits; +T template<> class numeric_limits; +T template<> class numeric_limits; +T template<> class numeric_limits; +T template<> class numeric_limits; + +X template<> class numeric_limits; +X template<> class numeric_limits; +X template<> class numeric_limits; + + 18.2.1.1 Template class numeric_limits [lib.numeric.limits] +T template 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 (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 (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 (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 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 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 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 (variable arguments), (nonlocal jumps), + (system clock clock(), time()), (signal handling), + and (runtime environment getenv(), system()). + + Table 6--Header synopsis + Macros: va_arg va_end va_start +X Type: va_list + + Table 7--Header synopsis + + Macro: setjmp | +X Type: jmp_buf + Function: longjmp + + Table 8--Header synopsis + + Macros: CLOCKS_PER_SEC +X Types: clock_t + Functions: clock + + Table 9--Header 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 synopsis + +X Functions: getenv system + + 19.1 Exception classes [lib.std.exceptions] + + Header 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 synopsis + +X Macro: assert + + 19.3 Error numbers [lib.errno] + + Table 3--Header synopsis + +X |Macros: EDOM ERANGE errno | + + + 20.2 Utility components [lib.utility] + + Header synopsis + + // _lib.operators_, operators: +X namespace rel_ops { +T template bool operator!=(const T&, const T&); +T template bool operator> (const T&, const T&); +T template bool operator<=(const T&, const T&); +T template bool operator>=(const T&, const T&); + } + // _lib.pairs_, pairs: +T template struct pair; +T template + bool operator==(const pair&, const pair&); +T template + bool operator< (const pair&, const pair&); +T template + bool operator!=(const pair&, const pair&); +T template + bool operator> (const pair&, const pair&); +T template + bool operator>=(const pair&, const pair&); +T template + bool operator<=(const pair&, const pair&); +T template pair make_pair(const T1&, const T2&); + + + 20.2.2 Pairs [lib.pairs] + +T template + 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 pair(const pair &p); + }; + + 20.3 Function objects [lib.function.objects] + + Header synopsis + + // _lib.base_, base: +V template struct unary_function; +V template struct binary_function; + + // _lib.arithmetic.operations_, arithmetic operations: +V template struct plus; +V template struct minus; +V template struct multiplies; +V template struct divides; +V template struct modulus; +V template struct negate; + // _lib.comparisons_, comparisons: +V template struct equal_to; +V template struct not_equal_to; +V template struct greater; +V template struct less; +V template struct greater_equal; +V template struct less_equal; + // _lib.logical.operations_, logical operations: +V template struct logical_and; +V template struct logical_or; +V template struct logical_not; + // _lib.negators_, negators: + template struct unary_negate; +V template + unary_negate not1(const Predicate&); +V template struct binary_negate; +V template + binary_negate not2(const Predicate&); + // _lib.binders_, binders: +V template class binder1st; +V template + binder1st bind1st(const Operation&, const T&); +V template class binder2nd; +V template + binder2nd bind2nd(const Operation&, const T&); + // _lib.function.pointer.adaptors_, adaptors: +V template class pointer_to_unary_function; +V template + pointer_to_unary_function ptr_fun(Result (*)(Arg)); +V template + class pointer_to_binary_function; +V template + pointer_to_binary_function + ptr_fun(Result (*)(Arg1,Arg2)); + + // _lib.member.pointer.adaptors_, adaptors: +V template class mem_fun_t; +V template class mem_fun1_t; +V template + mem_fun_t mem_fun(S (T::*f)()); +V template + mem_fun1_t mem_fun(S (T::*f)(A)); +V template class mem_fun_ref_t; +V template class mem_fun1_ref_t; +V template + mem_fun_ref_t mem_fun_ref(S (T::*f)()); +V template + mem_fun1_ref_t mem_fun_ref(S (T::*f)(A)); + +V template class const_mem_fun_t; +V template class const_mem_fun1_t; +V template + const_mem_fun_t mem_fun(S (T::*f)() const); +V template + const_mem_fun1_t mem_fun(S (T::*f)(A) const); +V template class const_mem_fun_ref_t; +V template class const_mem_fun1_ref_t; +V template + const_mem_fun_ref_t mem_fun_ref(S (T::*f)() const); +V template + const_mem_fun1_ref_t mem_fun_ref(S (T::*f)(A) const); + } + + 20.3.1 Base [lib.base] + +V template + struct unary_function { +V typedef Arg argument_type; +V typedef Result result_type; + }; +V template + 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 struct plus : binary_function { +V T operator()(const T& x, const T& y) const; + }; + +T template struct minus : binary_function { +V T operator()(const T& x, const T& y) const; + }; + +T template struct multiplies : binary_function { +V T operator()(const T& x, const T& y) const; + }; + +T template struct divides : binary_function { +V T operator()(const T& x, const T& y) const; + }; + +T template struct modulus : binary_function { +V T operator()(const T& x, const T& y) const; + }; + +T template struct negate : unary_function { +V T operator()(const T& x) const; + }; + + 20.3.3 Comparisons [lib.comparisons] + +T template struct equal_to : binary_function { +V bool operator()(const T& x, const T& y) const; + }; + +T template struct not_equal_to : binary_function { +V bool operator()(const T& x, const T& y) const; + }; + +T template struct greater : binary_function { +V bool operator()(const T& x, const T& y) const; + }; + +T template struct less : binary_function { +V bool operator()(const T& x, const T& y) const; + }; + +T template struct greater_equal : binary_function { +V bool operator()(const T& x, const T& y) const; + }; + +T template struct less_equal : binary_function { +V bool operator()(const T& x, const T& y) const; + }; + + 20.3.4 Logical operations [lib.logical.operations] + +T template struct logical_and : binary_function { +V bool operator()(const T& x, const T& y) const; + }; + +T template struct logical_or : binary_function { +V bool operator()(const T& x, const T& y) const; + }; + +T template struct logical_not : unary_function { +V bool operator()(const T& x) const; + }; + + 20.3.5 Negators [lib.negators] + +T template + class unary_negate + : public unary_function { + public: +T explicit unary_negate(const Predicate& pred); +V bool operator()(const typename Predicate::argument_type& x) const; + }; + +T template + class binary_negate + : public binary_function { + 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 binder1st + : public unary_function { + 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 + binder1st bind1st(const Operation& op, const T& x); + + 20.3.6.3 Template class binder2nd [lib.binder.2nd] +T template + class binder2nd + : public unary_function { + 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 + binder2nd 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 pointer_to_unary_function : public unary_function { + public: +T explicit pointer_to_unary_function(Result (*f)(Arg)); +V Result operator()(Arg x) const; + }; + +T template + pointer_to_unary_function ptr_fun(Result (*f)(Arg)); + +T template + class pointer_to_binary_function : + public binary_function { + 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 mem_fun_t + : public unary_function { + public: +T explicit mem_fun_t(S (T::*p)()); +V S operator()(T* p) const; + }; + +T template class mem_fun1_t + : public binary_function { + public: +T explicit mem_fun1_t(S (T::*p)(A)); +V S operator()(T* p, A x) const; + }; + +V template mem_fun_t + mem_fun(S (T::*f)()); +V template mem_fun1_t + mem_fun(S (T::*f)(A)); + +T template class mem_fun_ref_t + : public unary_function { + public: +T explicit mem_fun_ref_t(S (T::*p)()); +V S operator()(T& p) const; + }; + +T template class mem_fun1_ref_t + : public binary_function { + public: +T explicit mem_fun1_ref_t(S (T::*p)(A)); +V S operator()(T& p, A x) const; + }; + +T template mem_fun_ref_t + mem_fun_ref(S (T::*f)()); + +T template mem_fun1_ref_t + mem_fun_ref(S (T::*f)(A)); + +T template class const_mem_fun_t + : public unary_function { + public: +T explicit const_mem_fun_t(S (T::*p)() const); +V S operator()(const T* p) const; + }; + +T template class const_mem_fun1_t + : public binary_function { + public: +T explicit const mem_fun1_t(S (T::*p)(A) const); +V S operator()(const T* p, A x) const; + }; + +V template const_mem_fun_t + mem_fun(S (T::*f)() const); +V template const_mem_fun1_t + mem_fun(S (T::*f)(A) const); + +T template class const_mem_fun_ref_t + : public unary_function { + public: +T explicit const_mem_fun_ref_t(S (T::*p)() const); +V S operator()(const T& p) const; + }; + +T template class const_mem_fun1_ref_t + : public binary_function { + public: +T explicit const_mem_fun1_ref_t(S (T::*p)(A) const); +V S operator()(const T& p, A x) const; + }; + +T template const_mem_fun_ref_t + mem_fun_ref(S (T::*f)() const); + +T template const_mem_fun1_ref_t + mem_fun_ref(S (T::*f)(A) const); + + 20.4 Memory [lib.memory] + + Header synopsis + + // _lib.default.allocator_, the default allocator: +T template class allocator; +T template <> class allocator; +T template + bool operator==(const allocator&, const allocator&) throw(); +T template + bool operator!=(const allocator&, const allocator&) throw(); + // _lib.storage.iterator_, raw storage iterator: +T template class raw_storage_iterator; + // _lib.temporary.buffer_, temporary buffers: +T template + pair get_temporary_buffer(ptrdiff_t n); +T template + void return_temporary_buffer(T* p); + // _lib.specialized.algorithms_, specialized algorithms: +T template + ForwardIterator + uninitialized_copy(InputIterator first, InputIterator last, + ForwardIterator result); +T template + void uninitialized_fill(ForwardIterator first, ForwardIterator last, + const T& x); +T template + void uninitialized_fill_n(ForwardIterator first, Size n, const T& x); + // _lib.auto.ptr_, pointers: +X template class auto_ptr; + } + + 20.4.1 The default allocator [lib.default.allocator] + +T template class allocator; + // specialize for void: +T template <> class allocator { + public: +T typedef void* pointer; +T typedef const void* const_pointer; + // reference-to-void members are impossible. +T typedef void value_type; +T template struct rebind { typedef allocator other; }; + }; + +T template 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 struct rebind { typedef allocator other; }; +T allocator() throw(); +T allocator(const allocator&) throw(); +T template allocator(const allocator&) throw(); +T ~allocator() throw(); +T pointer address(reference x) const; +T const_pointer address(const_reference x) const; +T pointer allocate( + size_type, allocator::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 + bool operator==(const allocator&, const allocator&) throw(); +T template + bool operator!=(const allocator&, const allocator&) throw(); + + 20.4.2 Raw storage iterator [lib.storage.iterator] + +T template + class raw_storage_iterator + : public iterator { + public: +T explicit raw_storage_iterator(OutputIterator x); +T raw_storage_iterator& operator*(); +T raw_storage_iterator& operator=(const T& element); +T raw_storage_iterator& operator++(); +T raw_storage_iterator operator++(int); + }; + + 20.4.3 Temporary buffers [lib.temporary.buffer] + +T template + pair get_temporary_buffer(ptrdiff_t n); + +T template 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 + ForwardIterator + uninitialized_copy(InputIterator first, InputIterator last, + ForwardIterator result); + + 20.4.4.2 uninitialized_fill [lib.uninitialized.fill] + +V template + void uninitialized_fill(ForwardIterator first, ForwardIterator last, + const T& x); + + 20.4.4.3 uninitialized_fill_n [lib.uninitialized.fill.n] + +V template + void uninitialized_fill_n(ForwardIterator first, Size n, const T& x); + + 20.4.5 Template class auto_ptr [lib.auto.ptr] + +X template class auto_ptr { + template 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 auto_ptr(auto_ptr&) throw(); +T auto_ptr& operator=(auto_ptr&) throw(); +T template auto_ptr& operator=(auto_ptr&) 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_ converions: +X auto_ptr(auto_ptr_ref) throw(); +X template operator auto_ptr_ref() throw(); +X template operator auto_ptr() throw(); + }; + + 20.4.6 C Library [lib.c.malloc] + + Table 7--Header synopsis + +X Functions: calloc malloc + free realloc + + + Table 8--Header synopsis + +X Macro: NULL +X Type: size_t +X Functions: memchr memcmp +X memcpy memmove memset + + Table 9--Header 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 struct char_traits; + shall be provided in the header as a basis for explicit spe- + cializations. + + + 21.1.3.1 struct [lib.char.traits.specializations.char] + char_traits + +T template<> + struct char_traits { +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 + +V template<> + struct char_traits { +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 + struct char_traits; +V template <> struct char_traits; +V template <> struct char_traits; + + // _lib.basic.string_, basic_string: +V template, + class Allocator = allocator > + class basic_string; +V template + basic_string + operator+(const basic_string& lhs, + const basic_string& rhs); +V template + basic_string + operator+(const charT* lhs, + const basic_string& rhs); +V template + basic_string + operator+(charT lhs, const basic_string& rhs); +V template + basic_string + operator+(const basic_string& lhs, + const charT* rhs); +V template + basic_string + operator+(const basic_string& lhs, charT rhs); + +V template + bool operator==(const basic_string& lhs, + const basic_string& rhs); +V template + bool operator==(const charT* lhs, + const basic_string& rhs); +V template + bool operator==(const basic_string& lhs, + const charT* rhs); +V template + bool operator!=(const basic_string& lhs, + const basic_string& rhs); +V template + bool operator!=(const charT* lhs, + const basic_string& rhs); +V template + bool operator!=(const basic_string& lhs, + const charT* rhs); +V template + bool operator< (const basic_string& lhs, + const basic_string& rhs); +V template + bool operator< (const basic_string& lhs, + const charT* rhs); +V template + bool operator< (const charT* lhs, + const basic_string& rhs); +V template + bool operator> (const basic_string& lhs, + const basic_string& rhs); +V template + bool operator> (const basic_string& lhs, + const charT* rhs); +V template + bool operator> (const charT* lhs, + const basic_string& rhs); +V template + bool operator<=(const basic_string& lhs, + const basic_string& rhs); +V template + bool operator<=(const basic_string& lhs, + const charT* rhs); +V template + bool operator<=(const charT* lhs, + const basic_string& rhs); +V template + bool operator>=(const basic_string& lhs, + const basic_string& rhs); +V template + bool operator>=(const basic_string& lhs, + const charT* rhs); +V template + bool operator>=(const charT* lhs, + const basic_string& rhs); + + // _lib.string.special_: +V template + void swap(basic_string& lhs, + basic_string& rhs); +V template + basic_istream& + operator>>(basic_istream& is, + basic_string& str); +T template + basic_ostream& + operator<<(basic_ostream& os, + const basic_string& str); +V template + basic_istream& + getline(basic_istream& is, + basic_string& str, + charT delim); +V template + basic_istream& + getline(basic_istream& is, + basic_string& str); +V typedef basic_string string; +T typedef basic_string wstring; + } + + 21.3 Template class basic_string [lib.basic.string] + +V namespace std { + template, + class Allocator = allocator > + 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 reverse_iterator; + typedef std::reverse_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 + 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 + 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 + 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 + 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 + 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&); + // _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 synopsis + + isalnum isdigit isprint isupper tolower +X isalpha isgraph ispunct isxdigit toupper + iscntrl islower isspace + + Table 11--Header synopsis + +X Macro: WEOF +X Types: wctrans_t wctype_t wint_t + Functions: +X iswalnum iswctype iswlower iswspace towctrans wctrans +X iswalpha iswdigit iswprint iswupper towlower wctype +X iswcntrl iswgraph iswpunct iswxdigit towupper + + Table 12--Header synopsis + +X Macro: NULL +X Type: size_t + 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 synopsis + Macros: NULL WCHAR_MAX WCHAR_MIN WEOF + Types: mbstate_t wint_t 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 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 synopsis + + // _lib.locale_, locale: +T class locale; +T template const Facet& use_facet(const locale&); +T template bool has_facet(const locale&) throw(); + + // _lib.locale.convenience_, convenience interfaces: +T template bool isspace (charT c, const locale& loc); +T template bool isprint (charT c, const locale& loc); +T template bool iscntrl (charT c, const locale& loc); +T template bool isupper (charT c, const locale& loc); +T template bool islower (charT c, const locale& loc); +T template bool isalpha (charT c, const locale& loc); +T template bool isdigit (charT c, const locale& loc); +T template bool ispunct (charT c, const locale& loc); +T template bool isxdigit(charT c, const locale& loc); +T template bool isalnum (charT c, const locale& loc); +T template bool isgraph (charT c, const locale& loc); +T template charT toupper(charT c, const locale& loc); +T template charT tolower(charT c, const locale& loc); + // _lib.category.ctype_ and _lib.facet.ctype.special_, ctype: + class ctype_base; +T template class ctype; +T template <> class ctype; // specialization +S template class ctype_byname; +S template <> class ctype_byname; // specialization +T class codecvt_base; +X template class codecvt; +S template class codecvt_byname; + // _lib.category.numeric_ and _lib.facet.numpunct_, numeric: +X template class num_get; +X template class num_put; +T template class numpunct; +S template class numpunct_byname; + // _lib.category.collate_, collation: +T template class collate; +S template class collate_byname; + // _lib.category.time_, date and time: +T class time_base; +S template class time_get; +S template class time_get_byname; +S template class time_put; +S template class time_put_byname; + // _lib.category.monetary_, money: +T class money_base; +S template class money_get; +S template class money_put; +S template class moneypunct; +S template class moneypunct_byname; + // _lib.category.messages_, message retrieval: +T class messages_base; +S template class messages; +S template 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 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 locale combine(const locale& other) const; + // locale operations: +X basic_string name() const; +T bool operator==(const locale& other) const; +T bool operator!=(const locale& other) const; +T template + bool operator()(const basic_string& s1, + const basic_string& 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, collate +T ctype, ctype +T codecvt, +S codecvt +T moneypunct, moneypunct +T moneypunct, moneypunct, +S money_get, money_get, money_put +T numpunct, numpunct, +X num_get, num_get +X num_put, num_put +S time_get, time_get, +S time_put, time_put +S messages, messages + + [required instantiations] +S collate_byname, collate_byname +S ctype_byname, ctype_byname +S codecvt_byname, +S codecvt_byname +S moneypunct_byname, +S moneypunct_byname, +S money_get, +S money_put +S numpunct_byname, numpunct_byname +X num_get, num_put +S time_get, +S time_get_byname, +S time_get, +S time_get_byname, +S time_put, +S time_put_byname, +S time_put +S time_put_byname +S messages_byname, messages_byname + + + 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 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 ctype_byname : public ctype { + public: +T typedef ctype::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 + : 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 + +X template <> class ctype_byname : public ctype { + 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 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 codecvt_byname : public codecvt { + 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 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 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 numpunct : public locale::facet { + public: +T typedef charT char_type; +T typedef basic_string 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 numpunct_byname : public numpunct { + // this class is specialized for char and wchar_t. + public: +T typedef charT char_type; +T typedef basic_string 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 collate : public locale::facet { + public: +T typedef charT char_type; +T typedef basic_string 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 collate_byname : public collate { + public: +T typedef basic_string 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 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 time_get_byname : public time_get { + 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 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 time_put_byname : public time_put + { + 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 money_get : public locale::facet { + public: +T typedef charT char_type; +T typedef InputIterator iter_type; +T typedef basic_string 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 money_put : public locale::facet { + public: +T typedef charT char_type; +T typedef OutputIterator iter_type; +T typedef basic_string 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 moneypunct : public locale::facet, public money_base { + public: +T typedef charT char_type; +T typedef basic_string 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 moneypunct_byname : public moneypunct { + public: +T typedef money_base::pattern pattern; +T typedef basic_string 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 messages : public locale::facet, public messages_base { + public: +T typedef charT char_type; +T typedef basic_string string_type; +T explicit messages(size_t refs = 0); +T catalog open(const basic_string& 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&, 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 messages_byname : public messages { + public: +T typedef messages_base::catalog catalog; +T typedef basic_string 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&, 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 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] + + , , , , and . + + Header synopsis + +X template > class deque; +T template + bool operator==(const deque& x, const deque& y); +T template + bool operator< (const deque& x, const deque& y); +T template + bool operator!=(const deque& x, const deque& y); +T template + bool operator> (const deque& x, const deque& y); +T template + bool operator>=(const deque& x, const deque& y); +T template + bool operator<=(const deque& x, const deque& y); +T template + void swap(deque& x, deque& y); + } + + Header synopsis + +X template > class list; +T template + bool operator==(const list& x, const list& y); +T template + bool operator< (const list& x, const list& y); +T template + bool operator!=(const list& x, const list& y); +T template + bool operator> (const list& x, const list& y); +T template + bool operator>=(const list& x, const list& y); +T template + bool operator<=(const list& x, const list& y); +T template + void swap(list& x, list& y); + } + + Header synopsis + + namespace std { +X template > class queue; +T template + bool operator==(const queue& x, + const queue& y); +T template + bool operator< (const queue& x, + const queue& y); +T template + bool operator!=(const queue& x, + const queue& y); +T template + bool operator> (const queue& x, + const queue& y); +T template + bool operator>=(const queue& x, + const queue& y); +T template + bool operator<=(const queue& x, + const queue& y); +T template , + class Compare = less > +T class priority_queue; + } + + Header synopsis + + namespace std { +T template > class stack; +T template + bool operator==(const stack& x, + const stack& y); +T template + bool operator< (const stack& x, + const stack& y); +T template + bool operator!=(const stack& x, + const stack& y); +T template + bool operator> (const stack& x, + const stack& y); +T template + bool operator>=(const stack& x, + const stack& y); +T template + bool operator<=(const stack& x, + const stack& y); + } + + Header synopsis + +T template > class vector; + +T template + bool operator==(const vector& x, + const vector& y); +T template + bool operator< (const vector& x, + const vector& y); +T template + bool operator!=(const vector& x, + const vector& y); +T template + bool operator> (const vector& x, + const vector& y); +T template + bool operator>=(const vector& x, + const vector& y); +T template + bool operator<=(const vector& x, + const vector& y); +T template + void swap(vector& x, vector& y); + +T template class vector; +T template + bool operator==(const vector& x, + const vector& y); +T template + bool operator< (const vector& x, + const vector& y); +T template + bool operator!=(const vector& x, + const vector& y); +T template + bool operator> (const vector& x, + const vector& y); +T template + bool operator>=(const vector& x, + const vector& y); +T template + bool operator<=(const vector& x, + const vector& y); +T template + void swap(vector& x, vector& y); + } + + 23.2.1 Template class deque [lib.deque] + + template > +X class deque { + public: + // types: +T typedef typename Allocator::reference reference; +T typedef typename Allocator::const_reference const_reference; +X typedef implementation defined iterator; +X 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 reverse_iterator; +T typedef std::reverse_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 + deque(InputIterator first, InputIterator last, + const Allocator& = Allocator()); +T deque(const deque& x); +T ~deque(); +T deque& operator=(const deque& x); +T template + 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 + 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 void clear(); + }; +T template + bool operator==(const deque& x, + const deque& y); +T template + bool operator< (const deque& x, + const deque& y); +T template + bool operator!=(const deque& x, + const deque& y); +T template + bool operator> (const deque& x, + const deque& y); +T template + bool operator>=(const deque& x, + const deque& y); +T template + bool operator<=(const deque& x, + const deque& y); + // specialized algorithms: +T template + void swap(deque& x, deque& y); + + + 23.2.2 Template class list [lib.list] + +X template > + class list { + public: + // types: +T typedef typename Allocator::reference reference; +T typedef typename Allocator::const_reference const_reference; +X typedef implementation defined iterator; +X 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 reverse_iterator; +T typedef std::reverse_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 + list(InputIterator first, InputIterator last, + const Allocator& = Allocator()); +T list(const list& x); +T ~list(); +T list& operator=(const list& x); +T template + 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 + 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 void clear(); + // _lib.list.ops_ list operations: +T void splice(iterator position, list& x); +T void splice(iterator position, list& x, iterator i); +T void splice(iterator position, list& x, iterator first, + iterator last); +T void remove(const T& value); +T template void remove_if(Predicate pred); + +T void unique(); +T template + void unique(BinaryPredicate binary_pred); +T void merge(list& x); +T template void merge(list& x, Compare comp); + void sort(); +T template void sort(Compare comp); + void reverse(); + }; +T template + bool operator==(const list& x, const list& y); +T template + bool operator< (const list& x, const list& y); +T template + bool operator!=(const list& x, const list& y); +T template + bool operator> (const list& x, const list& y); +T template + bool operator>=(const list& x, const list& y); +T template + bool operator<=(const list& x, const list& y); + // specialized algorithms: +T template + void swap(list& x, list& y); + + + 23.2.3.1 Template class queue [lib.queue] + +T template > + 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 + bool operator==(const queue& x, + const queue& y); +T template + bool operator< (const queue& x, + const queue& y); +T template + bool operator!=(const queue& x, + const queue& y); +T template + bool operator> (const queue& x, + const queue& y); +T template + bool operator>=(const queue& x, + const queue& y); +T template + bool operator<=(const queue& x, + const queue& y); + + 23.2.3.2 Template class priority_queue [lib.priority.queue] + +T template , + class Compare = less > + 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 + 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 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 + bool operator==(const stack& x, + const stack& y); +T template + bool operator< (const stack& x, + const stack& y); +T template + bool operator!=(const stack& x, + const stack& y); +T template + bool operator> (const stack& x, + const stack& y); +T template + bool operator>=(const stack& x, + const stack& y); +T template + bool operator<=(const stack& x, + const stack& y); + + 23.2.4 Template class vector [lib.vector] + + template > +X class vector { + public: + // types: +T typedef typename Allocator::reference reference; +T typedef typename Allocator::const_reference const_reference; +X typedef implementation defined iterator; +X 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 reverse_iterator; +T typedef std::reverse_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 + vector(InputIterator first, InputIterator last, + const Allocator& = Allocator()); +T vector(const vector& x); +T ~vector(); +T vector& operator=(const vector& x); +T template + 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 + 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 void clear(); + }; + +T template + bool operator==(const vector& x, + const vector& y); +T template + bool operator< (const vector& x, + const vector& y); +T template + bool operator!=(const vector& x, + const vector& y); +T template + bool operator> (const vector& x, + const vector& y); +T template + bool operator>=(const vector& x, + const vector& y); +T template + bool operator<=(const vector& x, + const vector& y); + // specialized algorithms: +T template + void swap(vector& x, vector& y); + + + 23.2.5 Class vector [lib.vector.bool] + +X template class vector { + public: + // types: +T typedef bool const_reference; +X typedef implementation defined iterator; +X 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 reverse_iterator; +T typedef std::reverse_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 + vector(InputIterator first, InputIterator last, + const Allocator& = Allocator()); +T vector(const vector& x); +T ~vector(); +T vector& operator=(const vector& x); +T template + 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 + 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 static void swap(reference x, reference y); +T void flip(); // flips all bits +T void clear(); + }; + +T template + bool operator==(const vector& x, + const vector& y); +T template + bool operator< (const vector& x, + const vector& y); +T template + bool operator!=(const vector& x, + const vector& y); +T template + bool operator> (const vector& x, + const vector& y); +T template + bool operator>=(const vector& x, + const vector& y); +T template + bool operator<=(const vector& x, + const vector& y); + // specialized algorithms: +T template + void swap(vector& x, vector& y); + + 23.3 Associative containers [lib.associative] + + and : + + Header synopsis + + template , + class Allocator = allocator > > +X class map; + +T template + bool operator==(const map& x, + const map& y); +T template + bool operator< (const map& x, + const map& y); +T template + bool operator!=(const map& x, + const map& y); +T template + bool operator> (const map& x, + const map& y); +T template + bool operator>=(const map& x, + const map& y); +T template + bool operator<=(const map& x, + const map& y); +T template + void swap(map& x, + map& y); +T template , + class Allocator = allocator > > + class multimap; +T template + bool operator==(const multimap& x, + const multimap& y); +T template + bool operator< (const multimap& x, + const multimap& y); +T template + bool operator!=(const multimap& x, + const multimap& y); +T template + bool operator> (const multimap& x, + const multimap& y); +T template + bool operator>=(const multimap& x, + const multimap& y); +T template + bool operator<=(const multimap& x, + const multimap& y); +T template + void swap(multimap& x, + multimap& y); + } + + Header synopsis + + template , + class Allocator = allocator > +X class set; + +T template + bool operator==(const set& x, + const set& y); +T template + bool operator< (const set& x, + const set& y); +T template + bool operator!=(const set& x, + const set& y); +T template + bool operator> (const set& x, + const set& y); +T template + bool operator>=(const set& x, + const set& y); +T template + bool operator<=(const set& x, + const set& y); +T template + void swap(set& x, + set& y); +T template , + class Allocator = allocator > + class multiset; +T template + bool operator==(const multiset& x, + const multiset& y); +T template + bool operator< (const multiset& x, + const multiset& y); +T template + bool operator!=(const multiset& x, + const multiset& y); +T template + bool operator> (const multiset& x, + const multiset& y); +T template + bool operator>=(const multiset& x, + const multiset& y); +T template + bool operator<=(const multiset& x, + const multiset& y); +T template + void swap(multiset& x, + multiset& y); + } + + 23.3.1 Template class map [lib.map] + + template , + class Allocator = allocator > > +X class map { + public: + // types: +T typedef Key key_type; +T typedef T mapped_type; +T typedef pair 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; +X typedef implementation defined iterator; +X 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 reverse_iterator; +T typedef std::reverse_iterator const_reverse_iterator; +T class value_compare + : public binary_function { + 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 + map(InputIterator first, InputIterator last, + const Compare& comp = Compare(), const Allocator& = Allocator()); +T map(const map& x); +T ~map(); +T map& + operator=(const map& 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 insert(const value_type& x); +T iterator insert(iterator position, const value_type& x); +T template + 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&); +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 + equal_range(const key_type& x); +T pair + equal_range(const key_type& x) const; + }; + +T template + bool operator==(const map& x, + const map& y); +T template + bool operator< (const map& x, + const map& y); +T template + bool operator!=(const map& x, + const map& y); +T template + bool operator> (const map& x, + const map& y); +T template + bool operator>=(const map& x, + const map& y); +T template + bool operator<=(const map& x, + const map& y); + // specialized algorithms: +T template + void swap(map& x, + map& y); + + 23.3.2 Template class multimap [lib.multimap] + + template , + class Allocator = allocator > > +X class multimap { + public: + // types: +T typedef Key key_type; +T typedef T mapped_type; +T typedef pair 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; +X typedef implementation defined iterator; +X 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 reverse_iterator; +T typedef std::reverse_iterator const_reverse_iterator; +T class value_compare + : public binary_function { + 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 + multimap(InputIterator first, InputIterator last, + const Compare& comp = Compare(), + const Allocator& = Allocator()); +T multimap(const multimap& x); +T ~multimap(); +T multimap& + operator=(const multimap& 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 + 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&); +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 equal_range(const key_type& x); +T pair equal_range(const key_type& x) const; + }; + +T template + bool operator==(const multimap& x, + const multimap& y); +T template + bool operator< (const multimap& x, + const multimap& y); +T template + bool operator!=(const multimap& x, + const multimap& y); +T template + bool operator> (const multimap& x, + const multimap& y); +T template + bool operator>=(const multimap& x, + const multimap& y); +T template + bool operator<=(const multimap& x, + const multimap& y); + // specialized algorithms: +T template + void swap(multimap& x, + multimap& y); + + + 23.3.3 Template class set [lib.set] + + template , + class Allocator = allocator > +X 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; +X typedef implementation defined iterator; +X 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 reverse_iterator; +T typedef std::reverse_iterator const_reverse_iterator; + // _lib.set.cons_ construct/copy/destroy: +T explicit set(const Compare& comp = Compare(), + const Allocator& = Allocator()); +T template + set(InputIterator first, InputIterator last, + const Compare& comp = Compare(), const Allocator& = Allocator()); +T set(const set& x); +T ~set(); +T set& + operator=(const set& 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 insert(const value_type& x); +T iterator insert(iterator position, const value_type& x); +T template +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&); +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 equal_range(const key_type& x) const; + }; +T template + bool operator==(const set& x, + const set& y); +T template + bool operator< (const set& x, + const set& y); +T template + bool operator!=(const set& x, + const set& y); +T template + bool operator> (const set& x, + const set& y); +T template + bool operator>=(const set& x, + const set& y); +T template + bool operator<=(const set& x, + const set& y); + // specialized algorithms: +T template + void swap(set& x, + set& y); + + 23.3.4 Template class multiset [lib.multiset] + + template , + class Allocator = allocator > +X 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; +X typedef implementation defined iterator; +X 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 reverse_iterator; +T typedef std::reverse_iterator const_reverse_iterator; + + // construct/copy/destroy: +T explicit multiset(const Compare& comp = Compare(), + const Allocator& = Allocator()); +T template + multiset(InputIterator first, InputIterator last, + const Compare& comp = Compare(), + const Allocator& = Allocator()); +T multiset(const multiset& x); +T ~multiset(); +T multiset& + operator=(const multiset& 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 + 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&); +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 equal_range(const key_type& x) const; + }; + +T template + bool operator==(const multiset& x, + const multiset& y); +T template + bool operator< (const multiset& x, + const multiset& y); +T template + bool operator!=(const multiset& x, + const multiset& y); +T template + bool operator> (const multiset& x, + const multiset& y); +T template + bool operator>=(const multiset& x, + const multiset& y); +T template + bool operator<=(const multiset& x, + const multiset& y); + // specialized algorithms: +T template + void swap(multiset& x, + multiset& y); + + 23.3.5 Template class bitset [lib.template.bitset] + + Header synopsis + + [What's this stuff? + #include // for size_t + #include + #include // for invalid_argument, + // out_of_range, overflow_error + #include // for istream, ostream + ] +X template class bitset; + // _lib.bitset.operators_ bitset operations: +T template + bitset operator&(const bitset&, const bitset&); +T template + bitset operator|(const bitset&, const bitset&); +T template + bitset operator^(const bitset&, const bitset&); +T template + basic_istream& + operator>>(basic_istream& is, bitset& x); +T template + basic_ostream& + operator<<(basic_ostream& os, const bitset& x); + +X template 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 + explicit bitset( + const basic_string& str, + typename basic_string::size_type pos = 0, + typename basic_string::size_type n = + basic_string::npos); + // _lib.bitset.members_ bitset operations: +T bitset& operator&=(const bitset& rhs); +T bitset& operator|=(const bitset& rhs); +T bitset& operator^=(const bitset& rhs); +T bitset& operator<<=(size_t pos); +T bitset& operator>>=(size_t pos); +T bitset& set(); +T bitset& set(size_t pos, int val = true); +T bitset& reset(); +T bitset& reset(size_t pos); +T bitset operator~() const; +T bitset& flip(); +T bitset& flip(size_t pos); + // element access: +T reference operator[](size_t pos); // for b[i]; +T unsigned long to_ulong() const; +T template + basic_string to_string() const; +T size_t count() const; +T size_t size() const; +T bool operator==(const bitset& rhs) const; +T bool operator!=(const bitset& rhs) const; +T bool test(size_t pos) const; +T bool any() const; +T bool none() const; +T bitset operator<<(size_t pos) const; +T bitset operator>>(size_t pos) const; + }; + + + + + 24.2 Header synopsis [lib.iterator.synopsis] + + // _lib.iterator.primitives_, primitives: +T template struct iterator_traits; +T template struct iterator_traits; + +X template 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 + void advance(InputIterator& i, Distance n); +T template + typename iterator_traits::difference_type + distance(InputIterator first, InputIterator last); + // _lib.predef.iterators_, predefined iterators: +X template class reverse_iterator; +T template + bool operator==( + const reverse_iterator& x, + const reverse_iterator& y); +T template + bool operator<( + const reverse_iterator& x, + const reverse_iterator& y); +T template + bool operator!=( + const reverse_iterator& x, + const reverse_iterator& y); +T template + bool operator>( + const reverse_iterator& x, + const reverse_iterator& y); +T template + bool operator>=( + const reverse_iterator& x, + const reverse_iterator& y); +T template + bool operator<=( + const reverse_iterator& x, + const reverse_iterator& y); +T template + typename reverse_iterator::difference_type operator-( + const reverse_iterator& x, + const reverse_iterator& y); +T template + reverse_iterator + operator+( + typename reverse_iterator::difference_type n, + const reverse_iterator& x); + +X template class back_insert_iterator; +T template + back_insert_iterator back_inserter(Container& x); +X template class front_insert_iterator; +T template + front_insert_iterator front_inserter(Container& x); +X template class insert_iterator; +T template + insert_iterator inserter(Container& x, Iterator i); + // _lib.stream.iterators_, stream iterators: +X template , + class Distance = ptrdiff_t> + class istream_iterator; + template +X bool operator==(const istream_iterator& x, + const istream_iterator& y); + template +X bool operator!=(const istream_iterator& x, + const istream_iterator& y); +X template > + class ostream_iterator; +X template > + class istreambuf_iterator; +X template + bool operator==(const istreambuf_iterator& a, + const istreambuf_iterator& b); +X template + bool operator!=(const istreambuf_iterator& a, + const istreambuf_iterator& b); +T template > + class ostreambuf_iterator; + + 24.3 Iterator primitives [lib.iterator.primitives] + +T template 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 struct iterator_traits { +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 struct iterator_traits { +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 +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 +X class reverse_iterator : public + iterator::iterator_category, + typename iterator_traits::value_type, + typename iterator_traits::difference_type, + typename iterator_traits::pointer, + typename iterator_traits::reference> { + protected: +T Iterator current; + public: +T typedef Iterator + iterator_type; +T typedef typename iterator_traits::difference_type + difference_type; +T typedef typename iterator_traits::reference + reference; +T typedef typename iterator_traits::pointer + pointer; + +T reverse_iterator(); +T explicit reverse_iterator(Iterator x); +T template reverse_iterator(const reverse_iterator& 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 + bool operator==( + const reverse_iterator& x, + const reverse_iterator& y); +T template + bool operator<( + const reverse_iterator& x, + const reverse_iterator& y); +T template + bool operator!=( + const reverse_iterator& x, + const reverse_iterator& y); +T template + bool operator>( + const reverse_iterator& x, + const reverse_iterator& y); +T template + bool operator>=( + const reverse_iterator& x, + const reverse_iterator& y); +T template + bool operator<=( + const reverse_iterator& x, + const reverse_iterator& y); +T template + typename reverse_iterator::difference_type operator-( + const reverse_iterator& x, + const reverse_iterator& y); +T template + reverse_iterator operator+( + typename reverse_iterator::difference_type n, + const reverse_iterator& x); + + + 24.4.2.1 Template class [lib.back.insert.iterator] + back_insert_iterator + + template +X class back_insert_iterator : + public iterator { + protected: +T Container* container; + public: +T typedef Container container_type; +T explicit back_insert_iterator(Container& x); +T back_insert_iterator& + operator=(typename Container::const_reference value); + +T back_insert_iterator& operator*(); +T back_insert_iterator& operator++(); +T back_insert_iterator operator++(int); + }; +T template + back_insert_iterator back_inserter(Container& x); + + + + 24.4.2.3 Template class [lib.front.insert.iterator] + front_insert_iterator + + template +X class front_insert_iterator : + public iterator { + protected: +T Container* container; + public: +T typedef Container container_type; +T explicit front_insert_iterator(Container& x); +T front_insert_iterator& + operator=(typename Container::const_reference value); +T front_insert_iterator& operator*(); +T front_insert_iterator& operator++(); +T front_insert_iterator operator++(int); + }; +T template + front_insert_iterator front_inserter(Container& x); + + + 24.4.2.5 Template class insert_iterator [lib.insert.iterator] + + template +X class insert_iterator : + public iterator { + 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& + operator=(typename Container::const_reference value); +T insert_iterator& operator*(); +T insert_iterator& operator++(); +T insert_iterator& operator++(int); + }; +T template + insert_iterator inserter(Container& x, Iterator i); + + 24.5.1 Template class istream_iterator [lib.istream.iterator] + + template , + class Distance = ptrdiff_t> +X class istream_iterator: + public iterator { + public: +T typedef charT char_type +T typedef traits traits_type; +T typedef basic_istream istream_type; +T istream_iterator(); +T istream_iterator(istream_type& s); +T istream_iterator(const istream_iterator& x); +T ~istream_iterator(); + +T const T& operator*() const; +T const T* operator->() const; +T istream_iterator& operator++(); +T istream_iterator operator++(int); + }; + +T template + bool operator==(const istream_iterator& x, + const istream_iterator& y); +T template + bool operator!=(const istream_iterator& x, + const istream_iterator& y); + + + 24.5.2 Template class ostream_iterator [lib.ostream.iterator] + + template > +X class ostream_iterator: + public iterator { + public: +T typedef charT char_type; +T typedef traits traits_type; +T typedef basic_ostream ostream_type; +T ostream_iterator(ostream_type& s); +T ostream_iterator(ostream_type& s, const charT* delimiter); +T ostream_iterator(const ostream_iterator& x); +T ~ostream_iterator(); +T ostream_iterator& operator=(const T& value); + +T ostream_iterator& operator*(); +T ostream_iterator& operator++(); +T ostream_iterator& operator++(int); + }; + + + 24.5.3 Template class [lib.istreambuf.iterator] + istreambuf_iterator + + template > +X class istreambuf_iterator + : public iterator { + public: +T typedef charT char_type; +T typedef traits traits_type; +T typedef typename traits::int_type int_type; +T typedef basic_streambuf streambuf_type; +T typedef basic_istream 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& operator++(); +T proxy operator++(int); +X bool equal(istreambuf_iterator& b); + }; + +T template + bool operator==(const istreambuf_iterator& a, + const istreambuf_iterator& b); + +T template + bool operator!=(const istreambuf_iterator& a, + const istreambuf_iterator& b); + + 24.5.3.1 Template class [lib.istreambuf.iterator::proxy] + istreambuf_iterator::proxy + + template > +T class istreambuf_iterator::proxy + { +T charT keep_; +T basic_streambuf* sbuf_; +T proxy(charT c, + basic_streambuf* sbuf); + : keep_(c), sbuf_(sbuf) {} + public: +T charT operator*() { return keep_; } + }; + + + + 24.5.4 Template class [lib.ostreambuf.iterator] + ostreambuf_iterator + + template > +T class ostreambuf_iterator: + public iterator { + public: +T typedef charT char_type; +T typedef traits traits_type; +T typedef basic_streambuf streambuf_type; +T typedef basic_ostream 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 synopsis + + + // _lib.alg.nonmodifying_, non-modifying sequence operations: +T template + Function for_each(InputIterator first, InputIterator last, Function f); +T template + InputIterator find(InputIterator first, InputIterator last, + const T& value); +T template + InputIterator find_if(InputIterator first, InputIterator last, + Predicate pred); +T template + ForwardIterator1 + find_end(ForwardIterator1 first1, ForwardIterator1 last1, + ForwardIterator2 first2, ForwardIterator2 last2); +T template + ForwardIterator1 + find_end(ForwardIterator1 first1, ForwardIterator1 last1, + ForwardIterator2 first2, ForwardIterator2 last2, + BinaryPredicate pred); +T template + ForwardIterator1 + find_first_of(ForwardIterator1 first1, ForwardIterator1 last1, + ForwardIterator2 first2, ForwardIterator2 last2); +T template + ForwardIterator1 + find_first_of(ForwardIterator1 first1, ForwardIterator1 last1, + ForwardIterator2 first2, ForwardIterator2 last2, + BinaryPredicate pred); +T template + ForwardIterator adjacent_find(ForwardIterator first, + ForwardIterator last); +T template + ForwardIterator adjacent_find(ForwardIterator first, + ForwardIterator last, BinaryPredicate pred); +T template + typename iterator_traits::difference_type + count(InputIterator first, InputIterator last, const T& value); +T template + typename iterator_traits::difference_type + count_if(InputIterator first, InputIterator last, Predicate pred); +T template + pair + mismatch(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2); +T template + pair + mismatch(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, BinaryPredicate pred); + +T template + bool equal(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2); +T template + bool equal(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, BinaryPredicate pred); +T template + ForwardIterator1 search(ForwardIterator1 first1, ForwardIterator1 last1, + ForwardIterator2 first2, ForwardIterator2 last2); +T template + ForwardIterator1 search(ForwardIterator1 first1, ForwardIterator1 last1, + ForwardIterator2 first2, ForwardIterator2 last2, + BinaryPredicate pred); +T template + ForwardIterator search_n(ForwardIterator first, ForwardIterator last, + Size count, const T& value); +T template + 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 + OutputIterator copy(InputIterator first, InputIterator last, + OutputIterator result); +T template + BidirectionalIterator2 + copy_backward(BidirectionalIterator1 first, BidirectionalIterator1 last, + BidirectionalIterator2 result); + // _lib.alg.swap_, swap: +T template void swap(T& a, T& b); +T template + ForwardIterator2 swap_ranges(ForwardIterator1 first1, + ForwardIterator1 last1, ForwardIterator2 first2); +T template + void iter_swap(ForwardIterator1 a, ForwardIterator2 b); +T template + OutputIterator transform(InputIterator first, InputIterator last, + OutputIterator result, UnaryOperation op); +T template + OutputIterator transform(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, OutputIterator result, + BinaryOperation binary_op); + +T template + void replace(ForwardIterator first, ForwardIterator last, + const T& old_value, const T& new_value); +T template + void replace_if(ForwardIterator first, ForwardIterator last, + Predicate pred, const T& new_value); +T template + OutputIterator replace_copy(InputIterator first, InputIterator last, + OutputIterator result, + const T& old_value, const T& new_value); +T template + OutputIterator replace_copy_if(Iterator first, Iterator last, + OutputIterator result, + Predicate pred, const T& new_value); +T template + void fill(ForwardIterator first, ForwardIterator last, const T& value); +T template + void fill_n(OutputIterator first, Size n, const T& value); +T template + void generate(ForwardIterator first, ForwardIterator last, Generator gen); +T template + void generate_n(OutputIterator first, Size n, Generator gen); +T template + ForwardIterator remove(ForwardIterator first, ForwardIterator last, + const T& value); +T template + ForwardIterator remove_if(ForwardIterator first, ForwardIterator last, + Predicate pred); +T template + OutputIterator remove_copy(InputIterator first, InputIterator last, + OutputIterator result, const T& value); +T template + OutputIterator remove_copy_if(InputIterator first, InputIterator last, + OutputIterator result, Predicate pred); +T template + ForwardIterator unique(ForwardIterator first, ForwardIterator last); +T template + ForwardIterator unique(ForwardIterator first, ForwardIterator last, + BinaryPredicate pred); +T template + OutputIterator unique_copy(InputIterator first, InputIterator last, + OutputIterator result); +T template + OutputIterator unique_copy(InputIterator first, InputIterator last, + OutputIterator result, BinaryPredicate pred); +T template + void reverse(BidirectionalIterator first, BidirectionalIterator last); +T template + OutputIterator reverse_copy(BidirectionalIterator first, + BidirectionalIterator last, + OutputIterator result); + +T template + void rotate(ForwardIterator first, ForwardIterator middle, + ForwardIterator last); +T template + OutputIterator rotate_copy(ForwardIterator first, ForwardIterator middle, + ForwardIterator last, OutputIterator result); +T template + void random_shuffle(RandomAccessIterator first, + RandomAccessIterator last); +T template + void random_shuffle(RandomAccessIterator first, + RandomAccessIterator last, + RandomNumberGenerator& rand); + // _lib.alg.partitions_, partitions: +T template + BidirectionalIterator partition(BidirectionalIterator first, + BidirectionalIterator last, + Predicate pred); +T template + BidirectionalIterator stable_partition(BidirectionalIterator first, + BidirectionalIterator last, + Predicate pred); + // _lib.alg.sorting_, sorting and related operations: + // _lib.alg.sort_, sorting: +T template + void sort(RandomAccessIterator first, RandomAccessIterator last); +T template + void sort(RandomAccessIterator first, RandomAccessIterator last, + Compare comp); +T template + void stable_sort(RandomAccessIterator first, RandomAccessIterator last); +T template + void stable_sort(RandomAccessIterator first, RandomAccessIterator last, + Compare comp); +T template + void partial_sort(RandomAccessIterator first, + RandomAccessIterator middle, + RandomAccessIterator last); +T template + void partial_sort(RandomAccessIterator first, + RandomAccessIterator middle, + RandomAccessIterator last, Compare comp); +T template + RandomAccessIterator + partial_sort_copy(InputIterator first, InputIterator last, + RandomAccessIterator result_first, + RandomAccessIterator result_last); +T template + RandomAccessIterator + partial_sort_copy(InputIterator first, InputIterator last, + RandomAccessIterator result_first, + RandomAccessIterator result_last, + Compare comp); + +T template + void nth_element(RandomAccessIterator first, RandomAccessIterator nth, + RandomAccessIterator last); +T template + void nth_element(RandomAccessIterator first, RandomAccessIterator nth, + RandomAccessIterator last, Compare comp); + // _lib.alg.binary.search_, binary search: +T template + ForwardIterator lower_bound(ForwardIterator first, ForwardIterator last, + const T& value); +T template + ForwardIterator lower_bound(ForwardIterator first, ForwardIterator last, + const T& value, Compare comp); +T template + ForwardIterator upper_bound(ForwardIterator first, ForwardIterator last, + const T& value); +T template + ForwardIterator upper_bound(ForwardIterator first, ForwardIterator last, + const T& value, Compare comp); +T template + pair + equal_range(ForwardIterator first, ForwardIterator last, + const T& value); +T template + pair + equal_range(ForwardIterator first, ForwardIterator last, + const T& value, Compare comp); +T template + bool binary_search(ForwardIterator first, ForwardIterator last, + const T& value); +T template + bool binary_search(ForwardIterator first, ForwardIterator last, + const T& value, Compare comp); + // _lib.alg.merge_, merge: +T template + OutputIterator merge(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2, + OutputIterator result); +T template + OutputIterator merge(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2, + OutputIterator result, Compare comp); +T template + void inplace_merge(BidirectionalIterator first, + BidirectionalIterator middle, + BidirectionalIterator last); +T template + void inplace_merge(BidirectionalIterator first, + BidirectionalIterator middle, + BidirectionalIterator last, Compare comp); + + // _lib.alg.set.operations_, set operations: +T template + bool includes(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2); +T template + bool includes(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2, Compare comp); +T template + OutputIterator set_union(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2, + OutputIterator result); +T template + OutputIterator set_union(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2, + OutputIterator result, Compare comp); +T template + OutputIterator set_intersection + (InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2, + OutputIterator result); +T template + OutputIterator set_intersection + (InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2, + OutputIterator result, Compare comp); +T template + OutputIterator set_difference + (InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2, + OutputIterator result); +T template + OutputIterator set_difference(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2, + OutputIterator result, Compare comp); +T template + OutputIterator + set_symmetric_difference(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2, + OutputIterator result); +T template + OutputIterator + set_symmetric_difference(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2, + OutputIterator result, Compare comp); + // _lib.alg.heap.operations_, heap operations: +T template + void push_heap(RandomAccessIterator first, RandomAccessIterator last); +T template + void push_heap(RandomAccessIterator first, RandomAccessIterator last, + Compare comp); + +T template + void pop_heap(RandomAccessIterator first, RandomAccessIterator last); +T template + void pop_heap(RandomAccessIterator first, RandomAccessIterator last, + Compare comp); +T template + void make_heap(RandomAccessIterator first, RandomAccessIterator last); +T template + void make_heap(RandomAccessIterator first, RandomAccessIterator last, + Compare comp); +T template + void sort_heap(RandomAccessIterator first, RandomAccessIterator last); +T template + void sort_heap(RandomAccessIterator first, RandomAccessIterator last, + Compare comp); + // _lib.alg.min.max_, minimum and maximum: +T template const T& min(const T& a, const T& b); +T template + const T& min(const T& a, const T& b, Compare comp); +T template const T& max(const T& a, const T& b); +T template + const T& max(const T& a, const T& b, Compare comp); +T template + ForwardIterator min_element(ForwardIterator first, ForwardIterator last); +T template + ForwardIterator min_element(ForwardIterator first, ForwardIterator last, + Compare comp); +T template + ForwardIterator max_element(ForwardIterator first, ForwardIterator last); +T template + ForwardIterator max_element(ForwardIterator first, ForwardIterator last, + Compare comp); +T template + bool lexicographical_compare + (InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2); +T template + bool lexicographical_compare + (InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, InputIterator2 last2, + Compare comp); + + // _lib.alg.permutation.generators_, permutations +T template + bool next_permutation(BidirectionalIterator first, + BidirectionalIterator last); +T template + bool next_permutation(BidirectionalIterator first, + BidirectionalIterator last, Compare comp); +T template + bool prev_permutation(BidirectionalIterator first, + BidirectionalIterator last); +T template + bool prev_permutation(BidirectionalIterator first, + BidirectionalIterator last, Compare comp); + + + 25.4 C library algorithms [lib.alg.c.library] + + 1 Header (partial, Table 2): + + Table 2--Header 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 synopsis [lib.complex.synopsis] + +T template class complex; +T template<> class complex; +T template<> class complex; +T template<> class complex; + // _lib.complex.ops_ operators: +T template + complex operator+(const complex&, const complex&); +T template complex operator+(const complex&, const T&); +T template complex operator+(const T&, const complex&); +T template complex operator- + (const complex&, const complex&); +T template complex operator-(const complex&, const T&); +T template complex operator-(const T&, const complex&); +T template complex operator* + (const complex&, const complex&); +T template complex operator*(const complex&, const T&); +T template complex operator*(const T&, const complex&); +T template complex operator/ + (const complex&, const complex&); +T template complex operator/(const complex&, const T&); +T template complex operator/(const T&, const complex&); +T template complex operator+(const complex&); +T template complex operator-(const complex&); +T template bool operator== + (const complex&, const complex&); +T template bool operator==(const complex&, const T&); +T template bool operator==(const T&, const complex&); +T template bool operator!=(const complex&, const complex&); +T template bool operator!=(const complex&, const T&); +T template bool operator!=(const T&, const complex&); +T template + basic_istream& + operator>>(basic_istream&, complex&); + +T template + basic_ostream& + operator<<(basic_ostream&, const complex&); + // _lib.complex.value.ops_ values: +T template T real(const complex&); +T template T imag(const complex&); + +T template T abs(const complex&); +T template T arg(const complex&); +T template T norm(const complex&); +T template complex conj(const complex&); +T template complex polar(const T&, const T&); + // _lib.complex.transcendentals_ transcendentals: +T template complex cos (const complex&); +T template complex cosh (const complex&); +T template complex exp (const complex&); +T template complex log (const complex&); +T template complex log10(const complex&); +T template complex pow(const complex&, int); +T template complex pow(const complex&, const T&); +T template complex pow(const complex&, const complex&); +T template complex pow(const T&, const complex&); +T template complex sin (const complex&); +T template complex sinh (const complex&); +T template complex sqrt (const complex&); +T template complex tan (const complex&); +T template complex tanh (const complex&); + } + + 26.2.2 Template class complex [lib.complex] + + template +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 complex(const complex&); + +T T real() const; +T T imag() const; + +T complex& operator= (const T&); +T complex& operator+=(const T&); +T complex& operator-=(const T&); +T complex& operator*=(const T&); +T complex& operator/=(const T&); + +T complex& operator=(const complex&); +T template complex& operator= (const complex&); +T template complex& operator+=(const complex&); +T template complex& operator-=(const complex&); +T template complex& operator*=(const complex&); +T template complex& operator/=(const complex&); + }; + +T template complex operator+ + (const complex&, const complex&); +T template complex operator+(const complex&, const T&); +T template complex operator+(const T&, const complex&); + +T template complex operator- + (const complex&, const complex&); +T template complex operator-(const complex&, const T&); +T template complex operator-(const T&, const complex&); + +T template complex operator* + (const complex&, const complex&); +T template complex operator*(const complex&, const T&); +T template complex operator*(const T&, const complex&); + +T template complex operator/ + (const complex&, const complex&); +T template complex operator/(const complex&, const T&); +T template complex operator/(const T&, const complex&); + +T template complex operator+(const complex&); +T template complex operator-(const complex&); + +T template bool operator==(const complex&, const complex&); +T template bool operator==(const complex&, const T&); +T template bool operator==(const T&, const complex&); + +T template bool operator!=(const complex&, const complex&); +T template bool operator!=(const complex&, const T&); +T template bool operator!=(const T&, const complex&); + +T template + basic_istream& + operator>>(basic_istream&, complex&); + +T template + basic_ostream& + operator<<(basic_ostream&, const complex&); + + + 26.2.3 complex specializations [lib.complex.special] + +T template<> class complex { + public: +T typedef float value_type; + +T complex(float re = 0.0f, float im = 0.0f); +T explicit complex(const complex&); +T explicit complex(const complex&); +T float real() const; +T float imag() const; + +T complex& operator= (float); +T complex& operator+=(float); +T complex& operator-=(float); +T complex& operator*=(float); +T complex& operator/=(float); + +T complex& operator=(const complex&); +T template complex& operator= (const complex&); +T template complex& operator+=(const complex&); +T template complex& operator-=(const complex&); +T template complex& operator*=(const complex&); +T template complex& operator/=(const complex&); + }; +T template<> class complex { + public: +T typedef double value_type; + +T complex(double re = 0.0, double im = 0.0); +T complex(const complex&); +T explicit complex(const complex&); +T double real() const; +T double imag() const; + +T complex& operator= (double); +T complex& operator+=(double); +T complex& operator-=(double); +T complex& operator*=(double); +T complex& operator/=(double); + +T complex& operator=(const complex&); +T template complex& operator= (const complex&); +T template complex& operator+=(const complex&); +T template complex& operator-=(const complex&); +T template complex& operator*=(const complex&); +T template complex& operator/=(const complex&); + }; + +T template<> class complex { + public: +T typedef long double value_type; + +T complex(long double re = 0.0L, long double im = 0.0L); +T complex(const complex&); +T complex(const complex&); +T long double real() const; +T long double imag() const; + +T complex& operator=(const complex&); +T complex& operator= (long double); +T complex& operator+=(long double); +T complex& operator-=(long double); +T complex& operator*=(long double); +T complex& operator/=(long double); + +T template complex& operator= (const complex&); +T template complex& operator+=(const complex&); +T template complex& operator-=(const complex&); +T template complex& operator*=(const complex&); +T template complex& operator/=(const complex&); + }; + + 26.3 Numeric arrays [lib.numarray] + + 26.3.1 Header synopsis [lib.valarray.synopsis] + +T template class valarray; // An array of type T +T class slice; +T template class slice_array; +T class gslice; +T template class gslice_array; +T template class mask_array; // a masked array +T template class indirect_array; // an indirected array + +T template valarray operator* + (const valarray&, const valarray&); +T template valarray operator* (const valarray&, const T&); +T template valarray operator* (const T&, const valarray&); +T template valarray operator/ + (const valarray&, const valarray&); +T template valarray operator/ (const valarray&, const T&); +T template valarray operator/ (const T&, const valarray&); +T template valarray operator% + (const valarray&, const valarray&); +T template valarray operator% (const valarray&, const T&); +T template valarray operator% (const T&, const valarray&); +T template valarray operator+ + (const valarray&, const valarray&); +T template valarray operator+ (const valarray&, const T&); +T template valarray operator+ (const T&, const valarray&); +T template valarray operator- + (const valarray&, const valarray&); +T template valarray operator- (const valarray&, const T&); +T template valarray operator- (const T&, const valarray&); +T template valarray operator^ + (const valarray&, const valarray&); +T template valarray operator^ (const valarray&, const T&); +T template valarray operator^ (const T&, const valarray&); +T template valarray operator& + (const valarray&, const valarray&); +T template valarray operator& (const valarray&, const T&); +T template valarray operator& (const T&, const valarray&); +T template valarray operator| + (const valarray&, const valarray&); +T template valarray operator| (const valarray&, const T&); +T template valarray operator| (const T&, const valarray&); +T template valarray operator<< + (const valarray&, const valarray&); +T template valarray operator<<(const valarray&, const T&); +T template valarray operator<<(const T&, const valarray&); +T template valarray operator>> + (const valarray&, const valarray&); +T template valarray operator>>(const valarray&, const T&); +T template valarray operator>>(const T&, const valarray&); +T template valarray operator&& + (const valarray&, const valarray&); +T template valarray operator&&(const valarray&, const T&); +T template valarray operator&&(const T&, const valarray&); +T template valarray operator|| + (const valarray&, const valarray&); +T template valarray operator||(const valarray&, const T&); +T template valarray operator||(const T&, const valarray&); + +T template + valarray operator==(const valarray&, const valarray&); +T template valarray operator==(const valarray&, const T&); +T template valarray operator==(const T&, const valarray&); +T template + valarray operator!=(const valarray&, const valarray&); +T template valarray operator!=(const valarray&, const T&); +T template valarray operator!=(const T&, const valarray&); +T template + valarray operator< (const valarray&, const valarray&); +T template valarray operator< (const valarray&, const T&); +T template valarray operator< (const T&, const valarray&); +T template + valarray operator> (const valarray&, const valarray&); +T template valarray operator> (const valarray&, const T&); +T template valarray operator> (const T&, const valarray&); +T template + valarray operator<=(const valarray&, const valarray&); +T template valarray operator<=(const valarray&, const T&); +T template valarray operator<=(const T&, const valarray&); +T template + valarray operator>=(const valarray&, const valarray&); +T template valarray operator>=(const valarray&, const T&); +T template valarray operator>=(const T&, const valarray&); +T template valarray abs (const valarray&); +T template valarray acos (const valarray&); +T template valarray asin (const valarray&); +T template valarray atan (const valarray&); +T template valarray atan2 + (const valarray&, const valarray&); +T template valarray atan2(const valarray&, const T&); +T template valarray atan2(const T&, const valarray&); +T template valarray cos (const valarray&); +T template valarray cosh (const valarray&); +T template valarray exp (const valarray&); +T template valarray log (const valarray&); +T template valarray log10(const valarray&); +T template valarray pow(const valarray&, const valarray&); +T template valarray pow(const valarray&, const T&); +T template valarray pow(const T&, const valarray&); +T template valarray sin (const valarray&); +T template valarray sinh (const valarray&); +T template valarray sqrt (const valarray&); +T template valarray tan (const valarray&); +T template valarray tanh (const valarray&); + } + + + 26.3.2 Template class valarray [lib.template.valarray] + +T template 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 valarray(const gslice_array&); +T valarray(const mask_array&); +T valarray(const indirect_array&); +T ~valarray(); + + // _lib.valarray.assign_ assignment: +T valarray& operator=(const valarray&); +T valarray& operator=(const T&); +T valarray& operator=(const slice_array&); +T valarray& operator=(const gslice_array&); +T valarray& operator=(const mask_array&); +T valarray& operator=(const indirect_array&); + // _lib.valarray.access_ element access: +T T operator[](size_t) const; +T T& operator[](size_t); + // _lib.valarray.sub_ subset operations: +T valarray operator[](slice) const; +T slice_array operator[](slice); +T valarray operator[](const gslice&) const; +T gslice_array operator[](const gslice&); +T valarray operator[](const valarray&) const; +T mask_array operator[](const valarray&); +T valarray operator[](const valarray&) const; +T indirect_array operator[](const valarray&); + // _lib.valarray.unary_ unary operators: +T valarray operator+() const; +T valarray operator-() const; +T valarray operator~() const; +T valarray operator!() const; + // _lib.valarray.cassign_ computed assignment: +T valarray& operator*= (const T&); +T valarray& operator/= (const T&); +T valarray& operator%= (const T&); +T valarray& operator+= (const T&); +T valarray& operator-= (const T&); +T valarray& operator^= (const T&); +T valarray& operator&= (const T&); +T valarray& operator|= (const T&); +T valarray& operator<<=(const T&); +T valarray& operator>>=(const T&); +T valarray& operator*= (const valarray&); +T valarray& operator/= (const valarray&); +T valarray& operator%= (const valarray&); +T valarray& operator+= (const valarray&); +T valarray& operator-= (const valarray&); +T valarray& operator^= (const valarray&); +T valarray& operator|= (const valarray&); +T valarray& operator&= (const valarray&); +T valarray& operator<<=(const valarray&); +T valarray& operator>>=(const valarray&); + // _lib.valarray.members_ member functions: +T size_t size() const; +T T sum() const; +T T min() const; +T T max() const; + +T valarray shift (int) const; +T valarray cshift(int) const; +T valarray apply(T func(T)) const; +T valarray 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 slice_array { + public: +T typedef T value_type; + +T void operator= (const valarray&) const; +T void operator*= (const valarray&) const; +T void operator/= (const valarray&) const; +T void operator%= (const valarray&) const; +T void operator+= (const valarray&) const; +T void operator-= (const valarray&) const; +T void operator^= (const valarray&) const; +T void operator&= (const valarray&) const; +T void operator|= (const valarray&) const; +T void operator<<=(const valarray&) const; +T void operator>>=(const valarray&) 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& l, const valarray& d); + +T size_t start() const; +T valarray size() const; +T valarray stride() const; + }; + + + 26.3.7 Template class gslice_array [lib.template.gslice.array] + +T template class gslice_array { + public: +T typedef T value_type; + +T void operator= (const valarray&) const; +T void operator*= (const valarray&) const; +T void operator/= (const valarray&) const; +T void operator%= (const valarray&) const; +T void operator+= (const valarray&) const; +T void operator-= (const valarray&) const; +T void operator^= (const valarray&) const; +T void operator&= (const valarray&) const; +T void operator|= (const valarray&) const; +T void operator<<=(const valarray&) const; +T void operator>>=(const valarray&) 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 mask_array { + public: +T typedef T value_type; + +T void operator= (const valarray&) const; +T void operator*= (const valarray&) const; +T void operator/= (const valarray&) const; +T void operator%= (const valarray&) const; +T void operator+= (const valarray&) const; +T void operator-= (const valarray&) const; +T void operator^= (const valarray&) const; +T void operator&= (const valarray&) const; +T void operator|= (const valarray&) const; +T void operator<<=(const valarray&) const; +T void operator>>=(const valarray&) 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 indirect_array { + public: +T typedef T value_type; + +T void operator= (const valarray&) const; +T void operator*= (const valarray&) const; +T void operator/= (const valarray&) const; +T void operator%= (const valarray&) const; +T void operator+= (const valarray&) const; +T void operator-= (const valarray&) const; +T void operator^= (const valarray&) const; +T void operator&= (const valarray&) const; +T void operator|= (const valarray&) const; +T void operator<<=(const valarray&) const; +T void operator>>=(const valarray&) 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 synopsis + +T template + T accumulate(InputIterator first, InputIterator last, T init); + +T template + T accumulate(InputIterator first, InputIterator last, T init, + BinaryOperation binary_op); + +T template + T inner_product(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, T init); + +T template + T inner_product(InputIterator1 first1, InputIterator1 last1, + InputIterator2 first2, T init, + BinaryOperation1 binary_op1, + BinaryOperation2 binary_op2); + +T template + OutputIterator partial_sum(InputIterator first, + InputIterator last, + OutputIterator result); + +T template + OutputIterator partial_sum(InputIterator first, + InputIterator last, + OutputIterator result, + BinaryOperation binary_op); + +T template + OutputIterator adjacent_difference(InputIterator first, + InputIterator last, + OutputIterator result); + +T template + OutputIterator adjacent_difference(InputIterator first, + InputIterator last, + OutputIterator result, + BinaryOperation binary_op); + + + 26.5 C Library [lib.c.math] + + Table 2--Header 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 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 synopsis + +X template class char_traits; +X template<> class char_traits; +X template<> class char_traits; +X template class allocator; +X template > + class basic_ios; + +X template > + class basic_streambuf; + +X template > + class basic_istream; + +X template > + class basic_ostream; + +X template > + class basic_iostream; + +X template , + class Allocator = allocator > + class basic_stringbuf; + +X template , + class Allocator = allocator > + class basic_istringstream; + +X template , + class Allocator = allocator > + class basic_ostringstream; + +X template , + class Allocator = allocator > + class basic_stringstream; + +X template > + class basic_filebuf; + +X template > + class basic_ifstream; + +X template > + class basic_ofstream; + +X template > + class basic_fstream; +X template > + class istreambuf_iterator; + +X template > + class ostreambuf_iterator; +X typedef basic_ios ios; +X typedef basic_ios wios; +X typedef basic_streambuf streambuf; +X typedef basic_istream istream; +X typedef basic_ostream ostream; +X typedef basic_iostream iostream; +X typedef basic_stringbuf stringbuf; +X typedef basic_istringstream istringstream; +X typedef basic_ostringstream ostringstream; +X typedef basic_stringstream stringstream; +X typedef basic_filebuf filebuf; +X typedef basic_ifstream ifstream; +X typedef basic_ofstream ofstream; +X typedef basic_fstream fstream; +X typedef basic_streambuf wstreambuf; +X typedef basic_istream wistream; +X typedef basic_ostream wostream; +X typedef basic_iostream wiostream; +X typedef basic_stringbuf wstringbuf; +X typedef basic_istringstream wistringstream; +X typedef basic_ostringstream wostringstream; +X typedef basic_stringstream wstringstream; + +X typedef basic_filebuf wfilebuf; +X typedef basic_ifstream wifstream; +X typedef basic_ofstream wofstream; +X typedef basic_fstream wfstream; +X template class fpos; +X typedef fpos::state_type> streampos; +X typedef fpos::state_type> wstreampos; + + 27.3 Standard iostream objects [lib.iostream.objects] + + Header synopsis + +T [must also include and ] +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 synopsis + + #include + +T typedef OFF_T streamoff; +T typedef SZ_T streamsize; +T template class fpos; + + class ios_base; + template > + 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 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 > +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* sb); +T virtual ~basic_ios(); + // _lib.basic.ios.members_ Members: +T basic_ostream* tie() const; +T basic_ostream* tie(basic_ostream* tiestr); +T basic_streambuf* rdbuf() const; +T basic_streambuf* rdbuf(basic_streambuf* 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* 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 synopsis + +X template > + class basic_streambuf; +T typedef basic_streambuf streambuf; +T typedef basic_streambuf wstreambuf; + + 27.5.2 Template class [lib.streambuf] + basic_streambuf + + template > +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* + 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* + 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 synopsis + +T template > + class basic_istream; +T typedef basic_istream istream; +T typedef basic_istream wistream; + +T template > + class basic_iostream; +T typedef basic_iostream iostream; +T typedef basic_iostream wiostream; + +X template + basic_istream& ws(basic_istream& is); + + Header synopsis + +X template > + class basic_ostream; +T typedef basic_ostream ostream; +T typedef basic_ostream wostream; + +T template + basic_ostream& endl(basic_ostream& os); +T template + basic_ostream& ends(basic_ostream& os); +T template + basic_ostream& flush(basic_ostream& os); + + Header 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 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 > +T class basic_istream : virtual public basic_ios { + 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* sb); +T virtual ~basic_istream(); + // _lib.istream::sentry_ Prefix/suffix: +T class sentry; + + // _lib.istream.formatted_ Formatted input: +T basic_istream& operator>> + (basic_istream& (*pf)(basic_istream&)) +T basic_istream& operator>> + (basic_ios& (*pf)(basic_ios&)) +T basic_istream& operator>> + (ios_base& (*pf)(ios_base&)) +S basic_istream& operator>>(bool& n); +S basic_istream& operator>>(short& n); +S basic_istream& operator>>(unsigned short& n); +S basic_istream& operator>>(int& n); +S basic_istream& operator>>(unsigned int& n); +S basic_istream& operator>>(long& n); +S basic_istream& operator>>(unsigned long& n); +S basic_istream& operator>>(float& f); +S basic_istream& operator>>(double& f); +S basic_istream& operator>>(long double& f); +S basic_istream& operator>>(void*& p); +S basic_istream& operator>> + (basic_streambuf* sb); + // _lib.istream.unformatted_ Unformatted input: +T streamsize gcount() const; +S int_type get(); +S basic_istream& get(char_type& c); +S basic_istream& get(char_type* s, streamsize n); +S basic_istream& get(char_type* s, streamsize n, + char_type delim); +S basic_istream& get(basic_streambuf& sb); +S basic_istream& get(basic_streambuf& sb, + char_type delim); +S basic_istream& getline(char_type* s, streamsize n); +S basic_istream& getline(char_type* s, streamsize n, + char_type delim); +S basic_istream& ignore + (streamsize n = 1, int_type delim = traits::eof()); +S int_type peek(); +S basic_istream& read (char_type* s, streamsize n); +S streamsize readsome(char_type* s, streamsize n); +S basic_istream& putback(char_type c); +S basic_istream& unget(); +S int sync(); + +S pos_type tellg(); +S basic_istream& seekg(pos_type); +S basic_istream& seekg(off_type, ios_base::seekdir); + }; + + // _lib.istream::extractors_ character extraction templates: +S template + basic_istream& operator>>(basic_istream&, + charT&); +S template + basic_istream& operator>>(basic_istream&, + unsigned char&); +S template + basic_istream& operator>>(basic_istream&, + signed char&); + +S template + basic_istream& operator>>(basic_istream&, + charT*); +S template + basic_istream& operator>>(basic_istream&, + unsigned char*); +S template + basic_istream& operator>>(basic_istream&, + signed char*); + + 27.6.1.1.2 Class basic_istream::sentry [lib.istream::sentry] + + + template > +S class basic_istream::sentry { + typedef traits traits_type; +S bool ok_; // exposition only + public: +S explicit sentry(basic_istream& 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 > +T class basic_iostream : + public basic_istream, + public basic_ostream { + public: + // constructor/destructor +T explicit basic_iostream(basic_streambuf* sb); +T virtual ~basic_iostream(); + }; + + + 27.6.2.1 Template class basic_ostream [lib.ostream] + + template > +X class basic_ostream : virtual public basic_ios { + 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* sb); +T virtual ~basic_ostream(); + // _lib.ostream::sentry_ Prefix/suffix: +T class sentry; + // _lib.ostream.formatted_ Formatted output: +T basic_ostream& operator<< + (basic_ostream& (*pf)(basic_ostream&)); +T basic_ostream& operator<< + (basic_ios& (*pf)(basic_ios&)); +T basic_ostream& operator<< + (ios_base& (*pf)(ios_base&)); +T basic_ostream& operator<<(bool n); +T basic_ostream& operator<<(short n); +T basic_ostream& operator<<(unsigned short n); +T basic_ostream& operator<<(int n); +T basic_ostream& operator<<(unsigned int n); +T basic_ostream& operator<<(long n); +T basic_ostream& operator<<(unsigned long n); +S basic_ostream& operator<<(float f); +S basic_ostream& operator<<(double f); +S basic_ostream& operator<<(long double f); +T basic_ostream& operator<<(const void* p); +X basic_ostream& operator<< + (basic_streambuf* sb); + // _lib.ostream.unformatted_ Unformatted output: +T basic_ostream& put(char_type c); +T basic_ostream& write(const char_type* s, streamsize n); +X basic_ostream& flush(); + + // _lib.ostream.seeks_ seeks: +S pos_type tellp(); +S basic_ostream& seekp(pos_type); +S basic_ostream& seekp(off_type, ios_base::seekdir); + }; + // _lib.ostream.inserters.character_ character inserters +X template + basic_ostream& operator<<(basic_ostream&, + charT); +X template + basic_ostream& operator<<(basic_ostream&, + char); + // specialization +X template + basic_ostream& operator<<(basic_ostream&, + char); + // signed and unsigned +X template + basic_ostream& operator<<(basic_ostream&, + signed char); +X template + basic_ostream& operator<<(basic_ostream&, + unsigned char) +X template + basic_ostream& operator<<(basic_ostream&, + const charT*); +X template + basic_ostream& operator<<(basic_ostream&, + const char*); + // partial specializationss +X template + basic_ostream& operator<<(basic_ostream&, + const char*); + // signed and unsigned +X template + basic_ostream& operator<<(basic_ostream&, + const signed char*); +X template + basic_ostream& operator<<(basic_ostream&, + const unsigned char*); + + + 27.6.2.3 Class basic_ostream::sentry [lib.ostream::sentry] + + template > +X class basic_ostream::sentry { + bool ok_; // exposition only + public: +X explicit sentry(basic_ostream& 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 synopsis + +X template , + class Allocator = allocator > + class basic_stringbuf; + +T typedef basic_stringbuf stringbuf; +T typedef basic_stringbuf wstringbuf; + + template , + class Allocator = allocator > +X class basic_istringstream; + +T typedef basic_istringstream istringstream; +T typedef basic_istringstream wistringstream; + + template , + class Allocator = allocator > +X class basic_ostringstream; +T typedef basic_ostringstream ostringstream; +T typedef basic_ostringstream wostringstream; + + template , + class Allocator = allocator > +X class basic_stringstream; +T typedef basic_stringstream stringstream; +T typedef basic_stringstream wstringstream; + + 27.7.1 Template class basic_stringbuf [lib.stringbuf] + + template , + class Allocator = allocator > +X class basic_stringbuf : public basic_streambuf { + 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& str, + ios_base::openmode which = ios_base::in | ios_base::out); + // _lib.stringbuf.members_ Get and set: +S basic_string str() const; +S void str(const basic_string& 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* 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 Allocator = allocator > +X class basic_istringstream : public basic_istream { + 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& str, + ios_base::openmode which = ios_base::in); + + // _lib.istringstream.members_ Members: +S basic_stringbuf* rdbuf() const; +S basic_string str() const; +S void str(const basic_string& s); + private: + // basic_stringbuf sb; exposition only + }; + + 27.7.3 Class basic_ostringstream [lib.ostringstream] + + template , + class Allocator = allocator > +X class basic_ostringstream : public basic_ostream { + 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& str, + ios_base::openmode which = ios_base::out); + // _lib.ostringstream.members_ Members: +S basic_stringbuf* rdbuf() const; +S basic_string str() const; +S void str(const basic_string& s); + }; + + + 27.7.4 Template class basic_stringstream [lib.stringstream] + + template , + class Allocator = allocator > +X class basic_stringstream + : public basic_iostream { + 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& str, + ios_base::openmode which = ios_base::out|ios_base::in); + // Members: +S basic_stringbuf* rdbuf() const; +S basic_string str() const; +S void str(const basic_string& str); + }; + + + + 27.8.1 File streams [lib.fstreams] + + + Header synopsis + +X template > + class basic_filebuf; +T typedef basic_filebuf filebuf; +T typedef basic_filebuf wfilebuf; + +X template > + class basic_ifstream; +T typedef basic_ifstream ifstream; +T typedef basic_ifstream wifstream; + +X template > + class basic_ofstream; +T typedef basic_ofstream ofstream; +T typedef basic_ofstream wofstream; + +X template > + class basic_fstream; +T typedef basic_fstream fstream; +T typedef basic_fstream wfstream; + + 27.8.1.1 Template class basic_filebuf [lib.filebuf] + + template > +X class basic_filebuf : public basic_streambuf { + 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* open + (const char* s, ios_base::openmode mode); +X basic_filebuf* 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* + 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 > +X class basic_ifstream : public basic_istream { + 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* 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 > +X class basic_ofstream : public basic_ostream { + 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* 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 > +X class basic_fstream + : public basic_iostream { + 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* 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 synopsis + Macros: +X BUFSIZ L_tmpnam SEEK_SET TMP_MAX +X EOF NULL stderr _IOFBF +X FILENAME_MAX SEEK_CUR stdin _IOLBF +X FOPEN_MAX SEEK_END stdout _IONBF + +X Types: FILE fpos_t size_t + 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 + + + + + 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 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 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 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 basic_filebuf : public basic_streambuf { + public: +M basic_filebuf* open + (const char* s, ios_base::open_mode mode); + // remainder unchanged + }; + template > + class basic_ifstream : public basic_istream { + public: +M void open(const char* s, ios_base::open_mode mode = in); + // remainder unchanged + }; + template > + class basic_ofstream : public basic_ostream { + 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 { + 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* setbuf(char* s, streamsize n); + } + + 1.7.4 Class strstream [depr.strstream] + +M class strstream + : public basic_iostream { + public: + // Types +M typedef char char_type; +M typedef typename char_traits::int_type int_type +M typedef typename char_traits::pos_type pos_type; +M typedef typename char_traits::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(); + }; + diff --git a/libstdc++-v3/docs/html/17_intro/COPYING b/libstdc++-v3/docs/html/17_intro/COPYING new file mode 100644 index 00000000000..60549be514a --- /dev/null +++ b/libstdc++-v3/docs/html/17_intro/COPYING @@ -0,0 +1,340 @@ + GNU GENERAL PUBLIC LICENSE + Version 2, June 1991 + + Copyright (C) 1989, 1991 Free Software Foundation, Inc. + 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + 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: (1) copyright the software, and +(2) 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. + + GNU GENERAL PUBLIC LICENSE + TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION + + 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. + + 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. + + 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: + + a) You must cause the modified files to carry prominent notices + stating that you changed the files and the date of any change. + + b) 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. + + c) 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. + + 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: + + a) 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, + + b) 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, + + c) 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. + + 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. + + 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. + + 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. + + 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. + + 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. + + 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. + + 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 + + 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. + + 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. + + + Copyright (C) 19yy + + 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 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) 19yy 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. + + , 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/docs/html/17_intro/DESIGN b/libstdc++-v3/docs/html/17_intro/DESIGN new file mode 100644 index 00000000000..6979bc40f80 --- /dev/null +++ b/libstdc++-v3/docs/html/17_intro/DESIGN @@ -0,0 +1,859 @@ + +Standard C++ Library Design Document +------------------------------------ + +This is an overview of libstdc++-v3, with particular attention +to projects to be done and how they fit into the whole. + +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 +, we might have: + + template class basic_string { + ... // member declarations + }; + ... // operator declarations + + #ifdef _STRICT_ISO_ + # if _G_NO_TEMPLATE_EXPORT + # include // headers needed by definitions + # ... + # include // 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 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, 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 contructs), 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 +). 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: +C headers: + (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 +, 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. + +, 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: +C headers: + +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: +C header: (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: +C headers: (also in 27) + (also in 18, 25, 26) + +We have "mostly-complete" char_traits<> implementations. Many of the +char_traits 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 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 are different from the C version. +generally overloaded on const and non-const argument pointers. For +example, in strchr is overloaded. The functions isupper +etc. in typically implemented as macros in C are functions +in C++, because they are overloaded with others of the same name +defined in . + +Many of the functions required in and cannot be +implemented using underlying C facilities on intended targets because +such facilities only partly exist. + +Chapter 22 Locale +------------------ +Headers: +C headers: + +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 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 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 , , +and , and the codecvt<> facet is used by basic_filebuf<> +in , 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: + +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: + +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: +C headers: (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: +C headers: , (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: + +C headers: (also in 21) + +Iostream is currently in a very incomplete state. , , +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, and 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<::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 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, 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 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: + +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 +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: + (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 +, , and various SGI extensions such +as . Many of these are already placed in the +subdirectories ext/ and backward/. (Note that it is better to +include them via "" or "" than +to search the subdirectory itself via a "-I" directive. + diff --git a/libstdc++-v3/docs/html/17_intro/HEADER_POLICY b/libstdc++-v3/docs/html/17_intro/HEADER_POLICY new file mode 100644 index 00000000000..c6fa6d38b54 --- /dev/null +++ b/libstdc++-v3/docs/html/17_intro/HEADER_POLICY @@ -0,0 +1,164 @@ + +Header Policy +------------- + +The C++ Standard specifies many mutual dependencies among the +headers it defines. It offers no advice on how to arrange headers +to avoid problems. The worst such problem is circular references. +Most simply this is "A includes B, B includes A": + + // file // file + #ifndef A #ifndef B + #define A 1 #define B 1 + #include #include + typedef int A_type; typedef int B_type; + extern B_type g(A_type); extern A_type f(B_type); + #endif /* A */ #endif /* B */ + + // file C.cc + #include + +The typical effect of such an "include loop" may be seen by tracing +the preprocessor activity: + + C // file C.cc + C #include + A // file + A #ifndef A + A #define A 1 + A #include + B // file + B #ifndef B + B #define B 1 + B #include + A // file + A #ifndef A <-- oops, cpp symbol A defined already + A ... <-- skip contents + A #endif + B typedef int B_type; + B extern A_type f(B_type); <-- error, A_type not defined yet. + B #endif /* B */ + A typedef int A_type; + A extern B_type g(A_type); + A #endif /* A */ + +The main symptom of #include loops is that definitions from file +are not available after the #include for certain include orders. +The number of standard headers makes testing all permutations of +include order impractical, so a policy is needed to prevent chaos. +In any case, for some standard headers (as for the above) no ordering +can eliminate the loop. + +Other factors influence the policy. Typical implementations of +Make (unfortunately including GNU make) have bugs relating to file +names with no suffix, that lead to such problems as failure to track +dependencies on such files and an inclination to _delete_ them. +Therefore, headers used in building the library are always of the +form generally, or specifically for +an equivalent to the standard header . + +Standard headers are all placed under directory std/, and +are ignored except during installation. These headers simply +#include the corresponding header . + +Standard substitute headers that have any complexity +may sub-include other headers. When they sub-include non-standard +headers, they first include all the headers required for that +non-standard header. + +Mutual dependencies are handled by splitting up the declarations +intended for standard headers among two or more files, and then +interleaving them as needed. For example, we replace and +above, as follows: + + // file + #ifndef _CPP_A + #define _CPP_A + # include + # include + # include + #endif + + // file + #ifndef _CPP_B + #define _CPP_B + # include + # include + # include + #endif + + // file + #ifndef _CPP_BITS_A_TYPES_H + #define _CPP_BITS_A_TYPES_H + typedef int A_type; + #endif + + // file + #ifndef _CPP_BITS_B_TYPES_H + #define _CPP_BITS_B_TYPES_H + typedef int B_type; + #endif + + // file + #ifndef _CPP_BITS_A_FUNS_H + #define _CPP_BITS_A_FUNS_H + extern B_type g(A_type); + #endif + + // file + #ifndef _CPP_BITS_B_FUNS_H + #define _CPP_BITS_B_FUNS_H + extern A_type f(B_type); + #endif + +Of course we have the standard headers under their mandated names: + + // file + #ifndef _CPP_A + #define _CPP_A + # include + #endif + + // file + #ifndef _CPP_B + #define _CPP_B + # include + #endif + +Notice that the include guards are named uniformly except that +the guard for standard header is just _CPP_A, +identically as the header in std/. + +At installation the files std/* can be replaced by symbolic links, +or simply copied into place as is. The result is: + + include/ + include/A -> bits/std_A.h + include/B -> bits/std_A.h + include/bits/ + include/bits/std_A.h + include/bits/std_B.h + include/bits/A_types.h + include/bits/B_types.h + include/bits/A_funs.h + include/bits/B_funs.h + + +Of course splitting up standard headers this way creates +complexity, so it is not done routinely, but only in response +to discovered needs. + +Another reason to split up headers is for support of separate +compilation of templates. This interacts with the foregoing +because template definitions typically have many more dependencies +on other headers than do pure declarations. Non-inline template +definitions are placed in a separate ".tcc" file that is included +by the standard header, and any other standard header that +requires definitions from it for its implementation. + +The key to preventing chaos, given the above structure, is: + + Only standard headers should sub-include + other headers. + + diff --git a/libstdc++-v3/docs/html/17_intro/PROBLEMS b/libstdc++-v3/docs/html/17_intro/PROBLEMS new file mode 100644 index 00000000000..52223911295 --- /dev/null +++ b/libstdc++-v3/docs/html/17_intro/PROBLEMS @@ -0,0 +1,8 @@ +Irix 6.2: +- math.h: defines extern long double hypotl( long double ); i.e., only + one argument. They've fixed this in 6.3. + +DES OSF 3.2 & 4.0: +- libm define sincos, sincosf, and sincosl but there are no prototypes and + especially the return type is nowhere defined. The functions are + documented in the man pages, though. diff --git a/libstdc++-v3/docs/html/17_intro/RELEASE-NOTES b/libstdc++-v3/docs/html/17_intro/RELEASE-NOTES new file mode 100644 index 00000000000..1ebaf66d829 --- /dev/null +++ b/libstdc++-v3/docs/html/17_intro/RELEASE-NOTES @@ -0,0 +1,118 @@ +2000-11-29 + +Release Notes +------------- +The Standard C++ Library v3, or libstdc++-2.90.x, is an ongoing +project to implement the ISO 14882 Standard C++ library as described +in chapters 17 through 27 and annex D, as a drop-in replacement +for the current (ARM-conformant) library. + +This is the tenth snapshot of the libstdc++ rewrite. It is still +incomplet and incorrekt. It's a lot less incomplete and incorrect than +some of the earlier snapshots though, and quite usable. + +The Standard C++ Library v3, or libstdc++-2.9x, follows an open +development model, attempting to be fully buzzword, bazaar, and GNU +compliant. Full details on participating, including contributor +guidelines, mailing list subscription, mailing list archives, +up-to-date documentation, and various and sundry other details can be +found at the following URL: + + http://gcc.gnu.org/libstdc++/ + + +New: +--- +- namespace std:: is now on by default. +- choice of "C" include strategies, including the shadow header work, + or generic global to std mapping of required "C" types. +- cpu/atomicity.h tweaks, additions of ia64 and arm support. +- abstraction of atomicity.h header to support notion of os/atomicity.h files. +- addition of backward header bits +- use of system_header pragma +- Conditional use of -Werror +- preliminary support for new g++ diagnostics capabilities, including + -fdiagnostics-show-location=once +- pedantic and shadow argument warning fixes +- Ugly, yet correct mechanism for dealing with "C" math adopted, + including the use of builtins. +- updates and configure/build work to support new libtool +- addition of strstream +- valarray work +- complex work +- update to SGI STL 3.3 +- libio sync between glibc/libstdc++-v3. Some divergence since initial + merge, but sources remain quite close. +- IO fixes for alpha +- wide character work for IO when using libio +- addition of c_io_stdio and "C" IO abstraction layer. +- auto_ptr fixes, testsuite additions +- Attempts to use -ffunction-sections -fdata-sections and + --gc-sections, depending on use of GNU ld and specific features. As of + late, --gc-sections has been disabled due to problems with it throwing + away initialization sections. This work is ongoing. +- long double support +- sub directory removal, coherent organization of cpu and os-specific + files, consolidation of include directories, integration of the C++ + support bits for operator new/delete,exceptions, etc. All includes + are now either in the include/* hierarchy or in libsupc++'s sub directory. +- Support for more platforms, including irix and bsd variants. +- filebuf tweaks to deal with variable-size buffers. +- filebuf implementation for putbackc, etc. al. +- ctype rewritten. Includes ctype, ctype, and others. +- codecvt rewritten. Includes codecvt, + codecvt. In addition, + implementation-defined conversions using iconv are now supported with + the __enc_traits partial-specialization of the State template + parameter of the codecvt class. In this manner, conversions between + encodings such as UCS4, USC2, UNICODE, UNICODEBIG, UNICODELITTLE, etc + can be performed. +- preliminary work on named locales +- preliminary documentation for locale implementation has been established. +- Many, many bug fixes. +- Many, many testsuite additions and consistent VERIFY usage. +- work on mkcheck to make it more flexible, use libtool, etc. + +What doesn't: +------------- +- see BUGS. + + +Build and Install +----------------- +Up to date build and install directions can be found at: +http://gcc.gnu.org/libstdc++/install.html + + +Contact: +-------- +Places have changed from previous snapshots. The web page, which has +information about joining the mailing list and searching its archives, +CVS access, and contribution information is now at: + + http://gcc.gnu.org/libstdc++/ + +Please note that the mailing list has recently moved, and is now +hosted on gcc.gnu.org. (The web site above has the most +up-to-date info.) + +Obtain the library snapshot via ftp (including these release notes) from + + ftp://gcc.gnu.org/pub/libstdc++/ + +The library is maintained by Benjamin Kosnik, Gabriel +Dos Reis, Phil Edwards, and Ulrich Drepper. + + +Development tools: +------------------ + +You will need a recent version of gcc to compile the snapshot of +libstdc++. The use of CVS g++ is strongly recommended. In addition, +you may need up-to-date tools for modifying Makefiles and regenerating +configure scripts: automake (version 1.4), autoconf (version 2.13 and +higher), and libtool. + + + + diff --git a/libstdc++-v3/docs/html/17_intro/TODO b/libstdc++-v3/docs/html/17_intro/TODO new file mode 100644 index 00000000000..4da846277d6 --- /dev/null +++ b/libstdc++-v3/docs/html/17_intro/TODO @@ -0,0 +1,177 @@ +- exception specifications need to be reviewed for all parts of the +library support and utility areas, particularly . + +- exception/stdexcept headers will do, but are not cleanly +implemented. Also, some kind of consensus needs to be established on +if the presence of stdexcept should be assumed in iostreams +headers. V3 currently takes the position that references to stdexcept +classes necessitates the inclusion of stdexcept, other library vendors +seem less inclined. + +- scoping/linking issues WRT to C structs need to be worked out. See +Nathan's commentary on cantrip, http://www.cantrip.org/cheaders.html + +- triglyphs/ciso646: and, and_eq, bitand, bitor, compl, not, not_eq, +or, or_eq, xor, xor_eq, true && 45, true and false, true or 45, etc. +(bool and int), etc. + +- operator!= and utility/rel_ops operators need to be made safe with +string and vector iterator classes. basic_string::reverse_iterator may +be implemented incorrectly, or need things like +operator==(__normal_iterator, const char*&), and swap(vector) + +- SGI iterator/allocator classes are not strictly conforming. In +particular, raw_storage_iterator, mem_fun1_ref_t are all problem +areas. + +- auto_ptr: seems to be some disagreement on what is +standards-conformant behavior, specially on conversion operators. + +- vswprintf, vwprintf, wprintf, wscanf, wcsftime, swscanf, fgetws, +fputwc, fputws, fwide, fwprintf, fwscanf, getwc, getwchar, putwc, etc: +C library wchar_t functionality. + +- facets heirarchies seem on occasion give odd errors to conformace +tests. Need to test that they are constructed in a strictly-conforming +manner. + +- stuff like `LC_CTYPE' is not found. Locale oddness? + +- header optimizations to keep compile times reasonable are most +certainly detracting from full conformance, as many templatized +definitions are squired away and pre-instantiated, so that the +compiler doesn't have to parse them. Areas effected: valarray, string, +all of iostreams and locales. + +- basic_string not implemented + +- ostreambuf_iterator has not been made standards-conformant (both +char and wchar_t) In particular, look at +time_put::put(OutIt, ios_base&, char, const tm*, const char*, const +char*) const + +- C-related issues WRT to libio and filepos, mbstate_t. Need to +straighten this stuff out with the glibc-2.2 libio. Also may need to +define operators for mbstate_t so that 'mbstate_t& == mbstate_t' is +something that can be done. + +- codecvt has not been adequently handled in terms of the +locale bits. (The io bits are done, with the exception of one +ostream inserter for char. + +- bool locale::operator() looks to be non-conformant + +- num_get::do_get + num_put::do_put +num_put::do_put(char *, ios_base &, char, long double) const +num_put::do_put(char *, ios_base &, char, double) const +num_put::do_put(char *, ios_base &, char, void const *) const +etc. +appear to be broken, or headers mashed, or undefined. + +- locale and std::combine not working correctly + template class locale locale::combine(const locale &) + +- ctype_byname: check to make sure derivation standards-conformant. + +- codecvt::unshift not working for char, wchar_t + +- no match for money_base::pattern &[int] + +- money_get::do_get weirded out for wchar_t + +- looks like deque::get_allocator not standards conformant or deque +allocator non-standard. + +- list::assignment operator needs const_cast + +- a cleaner division between pointers-to-value_type and true iterators +needs to be drawn throughout the entire STL implementation. + +- priority_queue conversions may be non-conformant + +- istream_iterator uses 2 arguments, should it be 4? + +- 'do the right thing' ctor fixing needs to be done for string. This +is still subject to some debate on the library issues list, so I +suggest punting till the dust clears. + +- the ctype and "tolower" "isspace" stuff really needs to be sorted +out. A portable, cross platform interface needs to be defined. A +"fixincludes"-like solution needs to be put into place to prune +headers. The "C" functions need to be able to work in std:: and "C" +namespaces. + +- complex seems to be the single largest source of internal +compiler errors when compiling the c++ library across non-x86 +platforms. Somebody needs to make sure the complex support builtin to +gcc is actually working. Just as a "for-instance" these things give ICEs: +class complex& complex::operator-=(const complex &) +class complex& complex::operator/=(const complex &) +class complex& complex::operator+=(const complex &) +class complex& complex::operator-=(const complex &) +class complex& complex::operator*=(const complex &) + +- appears as if the following extraction operators are undefined: +operator>>(istream, complex&) +operator>>(istream, complex&) +operator>>(istream, complex&) +operator>>(istream, complex&) +sqrt (const complex& x) + +- Protect valarray::result_type (not Standard) and make it work with + the various helper classes. + +- Make sure `valarray & == _Expr<_BinClos,bool>' + is defined + +- long double std_cmath stuff looks weak + +- fwide not declared. C++ wchar_t issues completely unaddressed. + +- known issues WRT to io and corner cases with the buffers. This is +still subject to interpretation, and I think the current +implementation is credible. + +- All of the Library working group closed issues need to be +addressed. Some of them proposed resolutions are already in the v-3 +sources, with macro-guards. + +- add deprecated features from Annex D + - add #ifdef wrappers for all of them, including in each + C header + - replace typedef'd non-deprecated types with more type-safe equivalents. + +- add optimization hooks (esp. whitespace eating) to streambuf + - add _M_begin() and _M_end() to streambuf + - add algorithm specializations for [io]streambuf_iterator (copy find etc.) + +- fix template members of basic_string<> to overload iterators and + non-iterators properly. (This is the infamous hack as in vector<> etc + 23.1.1 para 10.) + +- write filebuf for wide characters + +- replace stl/bits/stl_config + +- add feature-test macros for non-standard extensions + +- move major extensions into separate namespace (e.g. stl::) + +- create MT abstraction layer + +- add MT support for locale, string, istream, ostream + +- specialize functions that use_facet<> calls on failure for the required + facets, and construct them lazily so unused facets need not be constructed + when the locale is. + +- get mknumeric_limits coope with 'exotic' OSes. + +- : provide missing names. + +- provide testsuites for numerics. + +- add FAQ entries -- improve the install instructions + +- add HOWTO entries diff --git a/libstdc++-v3/docs/html/17_intro/contribute.html b/libstdc++-v3/docs/html/17_intro/contribute.html new file mode 100644 index 00000000000..4f16b845d48 --- /dev/null +++ b/libstdc++-v3/docs/html/17_intro/contribute.html @@ -0,0 +1,95 @@ + + + +How to contribute + + +

How to contribute

+

+The Standard C++ Library v3, or libstc++-2.90.x, follows an open development model. Active contributors are assigned maintainer-ship responsibility, and given write access to the CVS repository. First time submitors and all other potential contributors should follow this procedure: + +

+

+

ONE : read the documentation

+

+ +

+

 + + + +

+

+

TWO : copyright 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. Here is the form. + +Please contact Benjamin +Kosnik if you are confused about the assignment or have general +licensing questions. + + +

+

+

THREE : 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 plaintext; 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 CVS repository at + Cygnus, use "cvs update; cvs diff -c3p NEW"; else, use "diff -c3p OLD + NEW" ... If your version of diff does not support these options, then + get the latest version of GNU 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++ mailinglist. + +
+ + diff --git a/libstdc++-v3/docs/html/17_intro/headers_cc.txt b/libstdc++-v3/docs/html/17_intro/headers_cc.txt new file mode 100644 index 00000000000..d95f17aee68 --- /dev/null +++ b/libstdc++-v3/docs/html/17_intro/headers_cc.txt @@ -0,0 +1,83 @@ +// 1999-05-12 bkoz + +// Copyright (C) 1999 Free Software Foundation, Inc. +// +// This file is part of the GNU ISO C++ Library. This library 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, or (at your option) +// any later version. + +// This library 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 library; see the file COPYING. If not, write to the Free +// Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, +// USA. + +// 17.4.1.2 Headers + + +// "C++" headers +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +// "C" headers +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +// "C" headers that might not work if wchar_t support is disabled. +#include +#if _GLIBCPP_USE_WCHAR_T + #include + #include +#endif + +int main() { } diff --git a/libstdc++-v3/docs/html/17_intro/howto.html b/libstdc++-v3/docs/html/17_intro/howto.html new file mode 100644 index 00000000000..707d04ded47 --- /dev/null +++ b/libstdc++-v3/docs/html/17_intro/howto.html @@ -0,0 +1,156 @@ + + + + + + + + + libstdc++-v3 HOWTO: Chapter 17 + + + + + +

Chapter 17: Library Introduction

+ +

Chapter 17 is actually a list of definitions and descriptions used + in the following chapters of the Standard when describing the actual + library. Here, we use "Introduction" as an introduction + to the GNU implementation of the ISO Standard C++ Library. +

+ + + +
+

Contents

+ + +
+ + + +

The Standard C++ header files

+

The Standard C++ Library specifies 50 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 you #include a certain header, the + contents of that header, as defined by the Standard, become + available to you, no matter how. +

+

The names of the headers can be easily seen in + testsuite/17_intro/headers.cc, + which is a small testbed we use to make certain that the headers + all compile and run. +

+ +
+

Thread-safety

+

This is a thorny issue that gets brought up on the libstdc++-v3 + and gcc mailing lists on a regular basis (probably by a cron job). + This entry will mention a very little bit about the general MT + issues with libstdc++. The latest status and quick notes will be + in FAQ 5.6. Some discussion about threadsafe containers will be + in section 6.8 (the HOWTOs on containers). +

+

The libstdc++ code (all of it, not just the containers) has been + designed so that thread-safety will be easily possible. The first + (!) problem is finding a fast method of implementation + portable to all platforms. 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. +

+

A recent journal article has described "atomic integer + operations," which would allow us to, well, perform updates + on integers atomically, and without requiring an explicit mutex + lock. This appears promising, but the major difficulty is that + these operations "may not be available on all systems, and + if they are, may have different interfaces." [quoting from + mailing list messages] +

+

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 + relevent message in the thread; from there you can use + "Thread Next" to move down the thread. This farm is in + latest-to-oldest order. +

    +
  • +
+
+ Here are discussions that took place before the current snapshot; + they are still relevant and instructive. +
+
    +
  • One way of preventing memory leaks by the old default memory + allocator in multithreaded code is + discussed here. +
  • This thread + concerns strings. +
  • So does this + one. This initial message also refers to another + thread in the GCC mailing list... +
  • which is here, + and goes on for some time. Ironically, the initial message + in this thread also mentions another threading thread... +
  • beginning here, + and talking about pthreads. (Note that a much more recent + message from the first thread in this list notes that + pthreads + should not be used as a starting point for making + libstdc++ threadsafe.) +
  • This + message, + this one, + and this one + are the tops of related threads (all within the same time + period) discussing threading and the IO library. Much of it + is dealing with the C library, but C++ is included as well. +
+

+

This section will be updated as new and interesting issues come + to light. +

+

Return to top of page or + to the FAQ. +

+ +
+

<foo> vs <foo.h>

+

The new-style headers are fully supported in libstdc++-v3. The compiler + itself fully supports namespaces. However, at the moment, the compiler + treats std:: as the global namespace by default. +

+

For those of you new to ISO C++98, no, that isn't a typo, the headers + really have new names. Marshall Cline's C++ FAQ Lite has a good + explanation in +item [25.4]. +

+

Return to top of page or + to the FAQ. +

+ + + + + +
+

+Comments and suggestions are welcome, and may be sent to +Phil Edwards or +Gabriel Dos Reis. +
$Id: howto.html,v 1.6 2000/12/03 23:47:47 jsm28 Exp $ +

+ + + + + + diff --git a/libstdc++-v3/docs/html/17_intro/libstdc++-assign.txt b/libstdc++-v3/docs/html/17_intro/libstdc++-assign.txt new file mode 100644 index 00000000000..b70be688bca --- /dev/null +++ b/libstdc++-v3/docs/html/17_intro/libstdc++-assign.txt @@ -0,0 +1,129 @@ +The way to assign copyright to the Free Software Foundation is to sign +an assignment contract. This is what legally makes the Free Software +Foundation the copyright holder so that we can register the copyright +on the new version. I'm assuming that you wrote these changes +yourself; if other people wrote parts, we may need papers from them. + +If you are employed to do programming (even at a university), or have +made an agreement with your employer or school saying it owns programs +you write, then you and we need a signed piece of paper from your +employer disclaiming rights to the program. + +The disclaimer should be signed by a vice president or general manager +of the company. If you can't get at them, anyone else authorized to +license software produced there will do. Here is a sample wording: + + Digital Stimulation Corporation hereby disclaims all copyright interest + in the changes and enhancements made by Hugh Heffner to the program + "libstdc++", also including any future revisions of these changes and + enhancements. + + Digital Stimulation Corporation affirms that it has no other + intellectual property interest that would undermine this release, or + the use of the Program, and will do nothing to undermine it in the + future. + + , 1 April 1987 + Ty Coon, President of Vice, Digital Stimulation Corp. + +(If your employer says they do have an intellectual property claim +that could conflict with the use of the program, then please put me in +touch with a suitable representative of the company, so that we can +negotiate what to do about it.) + +IMPORTANT: When you talk to your employer, *no matter what +instructions they have given you*, don't fail to show them the sample +disclaimer above, or a disclaimer with the details filled in for your +specific case. Companies are usually willing to sign a disclaimer +without any fuss. If you make your request less specific, you may +open Pandora's box and cause a long and unnecessary delay. + +Below is the assignment contract that we usually use. You need +to print it out, sign it, and snail it to: + +Richard Stallman +545 Tech Sq rm 425 +Cambridge, MA 02139 +USA + +Please try to print the whole first page below on a single piece of +paper. If it doesn't fit on one printed page, put it on two sides of +a single piece of paper. + +Don't forget to put down the date when you sign! Spell out the month +name--don't use a number for the month. Dates using a number for the +month are ambiguous; 2/8/95 means one thing in the US and another in +Europe. + +Snail a copy of the employer's disclaimer as well. + +Please send me email about what you decide to do. If you have any +questions, or would like something to be changed, ask bkoz@gnu.org via +email. + ASSIGNMENT + + For good and valuable consideration, receipt of which I +acknowledge, I, [your name here], hereby transfer to the Free Software +Foundation, Inc. (the "Foundation") my entire right, title, and +interest (including all rights under copyright) in my changes and +enhancements to the libstdc++ library, subject to the conditions +below. These changes and enhancements are herein called the "Work". +The work hereby assigned shall also include any future revisions of +these changes and enhancements hereafter made by me. + + Upon thirty days' prior written notice, the "Foundation" agrees to +grant me non-exclusive rights to use the Work (i.e. my changes and +enhancements, not the program which I enhanced) as I see fit; (and +the "Foundation"'s rights shall otherwise continue unchanged). + + I hereby agree that if I have or acquire hereafter any patent or +interface copyright or other intellectual property interest dominating +the program enhanced by the Work (or use of that program), such +dominating interest will not be used to undermine the effect of this +assignment, i.e. the "Foundation" and the general public will be +licensed to use, in that program and its derivative works, without +royalty or limitation, the subject matter of the dominating interest. +This license provision will be binding on my heirs, assignees, or +other successors to the dominating interest, as well as on me. + + I hereby represent and warrant that I am the sole copyright holder +for the Work and that I have the right and power to enter into this +contract. I hereby indemnify and hold harmless the "Foundation", its +officers, employees, and agents against any and all claims, actions or +damages (including attorney's reasonable fees) asserted by or paid to +any party on account of a breach or alleged breach of the foregoing +warranty. I make no other express or implied warranty (including +without limitation, in this disclaimer of warranty, any warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE). + +Agreed: [signature] Date [Write the month with LETTERS]: + + +For the "Foundation", +Richard Stallman, head dude in charge + +Please do not delete the control-l character before this line. +Please print this as a separate page. + +Please email a copy of the information on this page to +fsf-records@gnu.ai.mit.edu, and cc bkoz@gnu.org, if you can, so that +our clerk doesn't have to type it in. Use your full name as the +subject line. + +[For the copyright registration, what country are you a citizen of? +What year were you born?] + + +[Please write your email address here.] + + +[Please write your snail address here, so we can snail a copy back to you.] + + + +[Which files have you changed so far, and which new files have you written +so far?] + + +[Which Belgian comic book character is better, Tintin or Asterix, and why?] + diff --git a/libstdc++-v3/docs/html/17_intro/organization b/libstdc++-v3/docs/html/17_intro/organization new file mode 100644 index 00000000000..828a8112834 --- /dev/null +++ b/libstdc++-v3/docs/html/17_intro/organization @@ -0,0 +1,84 @@ +20 [lib.utilities] + + namespace rel_ops { operators !=, >, <=, >= } + struct pair; + pair binary operators { operators ==, <, !=, >, >=, <= } + + // function objects, or objects with operator() defined + + template class allocator; + template<> class allocator; + template class raw_storage_iterator; + temporary buffers + specialized algorithms for uninitialized_{copy, fill, fill_n} + template class auto_ptr; + + + + +21 [lib.strings] + + template struct char_traits + template<> struct char_traits + template<> struct char_traits + template, A=a > class basic_string; + + typedef basic_string string; + typedef basic_string wstring; + + template void swap(string&, string&) + template istream& operator>>(istream&, string&); + template istream& getline(istream&, string&, C); + template istream& getline(istream&, string&); + template ostream& operator<<(ostream&, string&); + + + + + + +23 [lib.containers] + + + + + + + + + +24 [lib.iterators] + + +25 [lib.algorithms] + + non-modifying sequence operations + for_each, find, find_if, find_end, find_first_of, + adjacent_find, count, count_if, mismatch, equal, + search, search_n + modifying sequence operations + copy, copy_backward, swap, swap_ranges, iter_swap, + transform, replace, replace_if, replace_copy, + replace_copy_if, fill, fill_n, generate, generate_n, + remove, remove_if, remove_copy, remove_copy_if, unique, + unique_copy, reverse, reverse_copy, rotate, + rotate_copy, random_shuffle + sorting and related operations + sort, stable_sort, partial_sort, partial_sort_copy, + nth_element, lower_bound, upper_bound, equal_range, + binary_search, merge, inplace_merge, includes, + set_union, set_intersection, set_difference, + set_symmetric_difference, push_heap, pop_heap, + make_heap, sort_heap, min, max, min_element, + max_element, lexicographical_compare, next_permutation, + prev_permutation + + + + + + + + + + diff --git a/libstdc++-v3/docs/html/17_intro/porting-howto.html b/libstdc++-v3/docs/html/17_intro/porting-howto.html new file mode 100644 index 00000000000..54290b328c2 --- /dev/null +++ b/libstdc++-v3/docs/html/17_intro/porting-howto.html @@ -0,0 +1,726 @@ + + + Libstdc++-porting-howto + + + +
+
+

+ Libstdc++-porting-howto +

+

Felix Natter

+

+ This document can be distributed under the FDL + (www.gnu.org) +

+

what kind of a date ? I don't drink !

+
+ + + + + + + + + + + + + + + + + + + + + + +
Revision History
Revision 0.5Thu Jun 1 13:06:50 2000fnatter
First docbook-version.
Revision 0.8Sun Jul 30 20:28:40 2000fnatter
First released version using docbook-xml + + second upload to libstdc++-page. +
Revision 0.9Wed Sep 6 02:59:32 2000fnatter
5 new sections.
+
+
+

+ Abstract +

+

+ Some notes on porting applications from libstdc++-2.90 (or earlier + versions) to libstdc++-v3. Not speaking in terms of the GNU libstdc++ + implementations, this means porting from earlier versions of the + C++-Standard to ISO 14882. +

+
+
+
+
+

+ Table of Contents +

+
+
1. Namespace std:: +
+
+
+
1.1.1. Using namespace + composition if the project uses a separate + namespace +
+
1.1.2. Defining an empty namespace std +
+
1.1.3. Avoid to use fully qualified names + (i.e. std::string) +
+
1.1.4. How some open-source-projects deal + with this +
+
+
+
2. there is no ios::nocreate/ios::noreplace + in ISO 14882 +
+
3. stream::attach(int + fd) is not in the standard any more +
+
4. The new headers +
+
+
+
4.4.1. New headers replacing C-headers +
+
4.4.2. + <fstream> does + not define std::cout, + std::cin etc. +
+
+
+
5. Iterators +
+
6. + Libc-macros (i.e. isspace from + <cctype>) +
+
7. + State of streams + +
+
8. vector::at is missing (i.e. gcc 2.95.2) +
+
9. Using std::char_traits<char>::eof() +
+
10. Using string::clear()/string::erase() +
+
11. Using stringstream's +
+
12. About... +
+
+
+

+ In the following, when I say portable, I will refer to "portable among ISO + 14882-implementations". On the other hand, if I say "backportable" or + "conservative", I am talking about "compiles with older + libstdc++-implementations". +

+
+

+ 1. Namespace std:: +

+

+ The latest C++-standard (ISO-14882) requires that the standard + C++-library is defined in namespace std::. Thus, in order to use + classes from the standard C++-library, you can do one of three + things: +

+
    +
  • + +

    wrap your code in namespace std { + ... } => This is not an option because only symbols + from the standard c++-library are defined in namespace std::. +

    +
    • +
  • + +

    put a kind of + using-declaration in your source (either + using namespace std; or i.e. using + std::string;) => works well for source-files, but + cannot be used in header-files. +

    +
    • +
  • + +

    use a fully qualified name for + each libstdc++-symbol (i.e. std::string, + std::cout) => can always be used +

    +
    • +
+
+

+

+ Because there are many compilers which still use an implementation + that does not have the standard C++-library in namespace + std::, some care is required to support these as + well. +

+

+ Namespace back-portability-issues are generally not a problem with + g++, because versions of g++ that do not have libstdc++ in + std:: 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. +

+

+ The following sections list some possible solutions to support compilers + that cannot ignore std::. +

+
+

+ 1.1.1. Using namespace + composition if the project uses a separate + namespace +

+

+ Gtk-- defines + most of its classes in namespace Gtk::. Thus, it was possible to + adapt Gtk-- to namespace std:: by using a C++-feature called + namespace composition. This is what happens if + you put a using-declaration into a + namespace-definition: the imported symbol(s) gets imported into the + currently active namespace(s). For example: + 

+		  namespace Gtk {
+		  using std::string;
+		  class Window { ... }
+		  }
+
+ In this example, std::string gets imported into + namespace Gtk::. The result is that you don't have to use + std::string in this header, but still + std::string does not get imported into + user-space (the global namespace ::) unless the user does + using namespace Gtk; (which is not recommended + practice for Gtk--, so it is not a problem). Additionally, the + using-declarations are 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>) +

+
+
+

+ 1.1.2. Defining an empty namespace std +

+

+ By defining an (empty) namespace std:: before + using it, you avoid getting errors on systems where no part of the + library is in namespace std: + 

+		  namespace std { }
+		  using namespace std;
+
+

+
+
+

+ 1.1.3. Avoid to use fully qualified names + (i.e. std::string) +

+

+ If some compilers complain about using + std::string;, and if the "hack" for gtk-- mentioned above + does not work, then it might be a good idea to define a macro + NS_STD, which is defined to either "" or "std" + based on an autoconf-test. Then you should be able to use + NS_STD::string, which will evaluate to + ::string ("string in the global namespace") on + systems that do not put string in std::. (This is untested) +

+
+
+

+ 1.1.4. How some open-source-projects deal + with this +

+

+ This information was gathered around May 2000. It may not be correct + by the time you read this. +

+
+

+ Table 1. Namespace std:: in Open-Source programs +

+ + + + + + + + + + + + + + + + + + + + + + +
clanlibusual
pingususual
mozillausual
mnemonicnone
+ libsigc++conservative-impl
+
+
+

+ Table 2. Notations for categories +

+ + + + + + + + + + + + + + + + +
usualmostly fully qualified names and some + using-declarations (but not in headers)
noneno namespace std at all
conservative-implwrap all + namespace-handling in macros to support compilers without + namespace-support (no libstdc++ used in headers)
+
+

+ As you can see, this currently lacks an example of a project which + uses libstdc++-symbols in headers in a back-portable way (except + for Gtk--: see the ). +

+
+
+
+

+ 2. there is no ios::nocreate/ios::noreplace + in ISO 14882 +

+

+ I have seen ios::nocreate being used for input-streams, + most probably because the authors thought it would be more correct + to specify nocreate "explicitly". So you can simply leave it 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 ?). +

+
+
+

+ 3. stream::attach(int + fd) is not in the standard any more +

+

+ When using libstdc++-v3, you can use +

+

+

+ + 
+		  #include <fstream>
+
+

+ int basic_filebuf(__fd, __name, __mode);
int __fd;
const char* __name;
ios_base::openmode __mode; +

+

+

+
+ For a portable solution (if there is one), you need to implement a + subclass of streambuf which opens a file given a + descriptor, and then pass an instance of this to the + stream-constructor (from the Josuttis-book). +

+
+
+

+ 4. The new headers +

+

+ All new headers can be seen in this source-code. +

+

+ I think it is a problem for libstdc++-v3 to add links or wrappers + for the old headers, because the implementation has changed, and + the header name-changes indicate this. It might be preferable to + use the new headers and tell users of old compilers that they + should create links (which is what they will have to do sometime + anyway). +

+
+

+ 4.4.1. New headers replacing C-headers +

+

+ You should not use the C-headers (except for system-level headers) + from C++ programs. Instead, you should use a set of headers that + are named by prepending 'c' and, as usual, ommiting the extension + (.h). For example, instead of using <math.h>, you should use <cmath>. The standard + specifies that if you include the C-style header (<math.h> in this case), the symbols + will be available both in the global namespace and in namespace + std:: (libstdc++-v3, version 2.90.8 currently + puts them in std:: only) On the other hand, if + you include only the new header (i.e. <pcmath>), the symbols will only be + defined in namespace std:: (and macros will be + converted to inline-functions). +

+

+ For more information on this, and for information on how the GNU + C++ implementation reuses ("shadows") the C library-functions, have + a look at + www.cantrip.org. +

+
+
+

+ 4.4.2. + <fstream> does + not define std::cout, + std::cin etc. +

+

+ In previous versions of the standard, <fstream.h>, <ostream.h> and <istream.h> used to define + cout, cin and so on. Because + of the templatized iostreams in libstdc++-v3, you need to include + <iostream> + explicitly to define these. +

+
+
+
+

+ 5. Iterators +

+

+ The following are not proper uses of iterators, but may be working + fixes for existing uses of iterators. +

+
    +
  • + +

    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()) + ?

    +
    • +
+
+

+
+
+

+ 6. + Libc-macros (i.e. isspace from + <cctype>) +

+

+ Glibc 2.0.x and 2.1.x define the <ctype.h> -functionality as + macros (isspace, isalpha etc.). Libstdc++-v3 "shadows" these macros + as described in the . +

+

+ Older implementations of libstdc++ (g++-2 for egcs 1.x and g++-3 + for gcc 2.95.2), 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'); }
+
+ will result in something like this (unless using g++-v3): + 
+		std:: (__ctype_b[(int) ( ( 'X' ) )] & (unsigned short int)
+		_ISspace )  ;
+
+

+

+ One solution I can think of is to test for -v3 using + autoconf-macros, and define macros for each of the C-functions + (maybe that is possible with one "wrapper" macro as well ?). +

+

+ Another solution which would fix g++ is to tell the user to modify a + header-file so that g++-2 (egcs 1.x) and g++-3 (gcc 2.95.2) define a + macro which 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
+
+		[ now 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>). +

+

+ The solution to this problem was posted to the libstdc++-v3 + mailing-list: + Benjamin Kosnik <bkoz@redhat.com> writes: + " + --enable-cshadow-headers is currently broken. As a result, shadow + headers are not being searched.... + " +

+
+
+

+ 7. + State of streams + +

+

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

+
+
+

+ 8. vector::at is missing (i.e. gcc 2.95.2) +

+

+ For my use, I added it to + prefix/include/g++-3/stl_vector.h: + 

+  reference operator[](size_type __n) { return *(begin() + __n); }
+  reference at(size_type __n) {
+    if (begin() + __n >= end())
+      throw out_of_range("vector::at");
+    return *(begin() + __n);
+  }
+  const_reference operator[](size_type __n) const { return *(begin() + __n); }
+  const_reference at(size_type __n) const {
+    if (begin() + __n >= end())
+      throw out_of_range("vector::at");
+    return *(begin() + __n);
+  }
+
+

+
+
+

+ 9. Using std::char_traits<char>::eof() +

+

+ 

+		#ifdef HAVE_CHAR_TRAITS
+		#define CPP_EOF std::char_traits<char>::eof()
+		#else
+		#define CPP_EOF EOF
+		#endif
+
+

+
+
+

+ 10. Using string::clear()/string::erase() +

+

+ 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()); 
+      }
+
+ The implementation of erase seems to be more + complicated (from libstdc++-v3), but clear is not + implemented in gcc 2.95.2's libstdc++, so you should use + erase (which is probably faster than + operator=(charT*)). +

+
+
+

+ 11. Using stringstream's +

+

+ Libstdc++-v3 includes the new + i/ostringstream-classes, (<sstream>), but with older + implementations you still have to use i/ostrstream + (<strstream>): + 

+		#ifdef HAVE_SSTREAM
+		#include <sstream>
+		#else
+		#include <strstream>
+		#endif
+
+
+
    +
  • + +

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

+

+ I have read the Josuttis book on Standard C++, so some information + comes from there. Additionally, there is information in + "info iostream", which covers the old implementation that gcc 2.95.2 + uses. +

+
+
+

+ 12. About... +

+

+ Please send any experience, additions, corrections or questions to + fnatter@gmx.net or for + discussion to the libstdc++-v3-mailing-list. +

+
+
+ + diff --git a/libstdc++-v3/docs/html/18_support/howto.html b/libstdc++-v3/docs/html/18_support/howto.html new file mode 100644 index 00000000000..8dbc96c38d7 --- /dev/null +++ b/libstdc++-v3/docs/html/18_support/howto.html @@ -0,0 +1,269 @@ + + + + + + + + + libstdc++-v3 HOWTO: Chapter 18 + + + + + +

Chapter 18: Library Support

+ +

Chapter 18 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. +

+ + + +
+

Contents

+ + +
+ + + +

Types

+

All the types that you're used to in C are here in one form or + another. 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. +

+

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

+   const                             // this is a const object...
+   class {
+   public:
+     template<class T>               // convertible to any type
+       operator T*() const           // of null non-member
+       { return 0; }                 // pointer...
+
+     template<class C, class T>      // or any type of null
+       operator T C::*() const       // member pointer...
+       { return 0; }
+
+   private:
+     void operator&() const;         // whose address can't be
+                                     // taken (see Item 27)...
+
+   } NULL;                           // and whose name is NULL
+
(Cribbed from the published version of + the + Effective C++ CD, reproduced here with permission.) +

+

If you aren't using g++ (why?), but you do have a compiler which + supports member function templates, then you can use this definition + of NULL (be sure to #undef any existing versions). It only helps if + you actually use NULL in function calls, though; if you make a call of + foo(0); instead of foo(NULL);, then you're back + where you started. +

+

Added Note: When we contacted Dr. Meyers to ask permission to + print this stuff, it prompted him to run this code through current + compilers to see what the state of the art is with respect to member + template functions. He posted + an + article to Usenet after discovering that the code above is not + valid! Even though it has no data members, it still needs a + user-defined constructor (which means that the class needs a type name + after all). The ctor can have an empty body; it just needs to be + there. (Stupid requirement? We think so too, and this will probably + be changed in the language itself.) +

+

Return to top of page or + to the FAQ. +

+ +
+

Implementation properties

+

+

<limits>

+ This header mainly defines traits classes to give access to various + implementation defined-aspects of the fundamental types. The + traits classes -- fourteen in total -- are all specilizations of the + template class numeric_limits 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;
+   };
+

+

Return to top of page or + to the FAQ. +

+ +
+

Start and Termination

+

Not many changes here to <cstdlib> (the old stdlib.h). + 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: +

    +
  1. Static objects are destroyed in reverse order of their creation. +
  2. Functions registered with atexit() are called in + reverse order of registration, once per registration call. + (This isn't actually new.) +
  3. The previous two actions are "interleaved," that is, + given this code: + 
    +              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 propogate + out of them, Bad Things happen. +
+

+

Return to top of page or + to the FAQ. +

+ +
+

Dynamic memory management

+

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

+

Return to top of page or + to the FAQ. +

+ + + + + + + +
+

+Comments and suggestions are welcome, and may be sent to +Phil Edwards or +Gabriel Dos Reis. +
$Id: howto.html,v 1.7 2000/12/03 23:47:47 jsm28 Exp $ +

+ + + + diff --git a/libstdc++-v3/docs/html/19_diagnostics/howto.html b/libstdc++-v3/docs/html/19_diagnostics/howto.html new file mode 100644 index 00000000000..7bfbcdf9bb4 --- /dev/null +++ b/libstdc++-v3/docs/html/19_diagnostics/howto.html @@ -0,0 +1,107 @@ + + + + + + + + + libstdc++-v3 HOWTO: Chapter 19 + + + + + +

Chapter 19: Diagnostics

+ +

Chapter 19 deals with program diagnostics, such as exceptions + and assertions. You know, all the things we wish weren't even + necessary at all. +

+ + + +
+

Contents

+ + +
+ + + +

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

+ 
+   using std::runtime_error;
+   struct My_Exception : public runtime_error
+   {
+     public:
+       My_Exception (const string& whatarg)
+           : 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
+   };
+
+

Return to top of page or + to the FAQ. +

+ +
+

Exception class hierarchy diagram

+

The diagram is in PDF, or + at least it will be once it gets finished. +

+

Return to top of page or + to the FAQ. +

+ +
+

Concept checkers

+

As part of their 3.3 release, SGI added some nifty macros which + perform assertions on type properties. For example, the Standard + requires that types passed as template parameters to vector + be "Assignable" (which means what you think it means). +

+

The concept checkers allow the source code for vector to + declare + 

+   __STL_CLASS_REQUIRES(_Tp, _Assignable);
+
inside the template. _Tp is the element type of the + vector, and _Assignable is the concept to be checked (it is + defined in some back-end header files). When you instantiate + vector<MyType>, compile-time checking can be done on + whether MyType meets the requirements for vectors. +

+

This is an extension to the library. This documentation needs updating.

+

Return to top of page or + to the FAQ. +

+ + + + + + + +
+

+Comments and suggestions are welcome, and may be sent to +Phil Edwards or +Gabriel Dos Reis. +
$Id: howto.html,v 1.5 2000/12/03 23:47:47 jsm28 Exp $ +

+ + + + diff --git a/libstdc++-v3/docs/html/20_util/howto.html b/libstdc++-v3/docs/html/20_util/howto.html new file mode 100644 index 00000000000..98f2a277bae --- /dev/null +++ b/libstdc++-v3/docs/html/20_util/howto.html @@ -0,0 +1,193 @@ + + + + + + + + + libstdc++-v3 HOWTO: Chapter 20 + + + + + +

Chapter 20: General Utilities

+ +

Chapter 20 deals with utility classes and functions, such as + the oft-debated auto_ptr<>. +

+ + + +
+

Contents

+ + +
+ + + +

auto_ptr is not omnipotent

+

I'm not going to try and explain all of the fun and delicious + things that can happen with misuse of the auto_ptr class template + (called AP here), nor am I going to try and teach you how to use + AP safely in the presence of copying. 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 not be 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 newsgroups, Usenet, Boost, etc). +

+

Return to top of page or + to the FAQ. +

+ +
+

Automatically-generated operators

+

Many programs (for that matter, many of the Standard algorithms + and containers) require that you write comparison operators for + your classes, like operator>=. As any mathmatician + will tell you, once you have defined equality and ordering, all + of the other comparisons are easily defined in terms of those two. +

+

The Committee agrees. So, once you have written + operator== and operator< for your class + (whether they are global or member functions is up to you), you + can have the compiler do the grunt-work of generating the rest: + 

+    #include <header_with_my_op==_and_op<_defined>
+    #include <utility>
+    using std::rel_ops;     // note the nested namespace!
+
+    ...
+    if ((obj1 != obj2) || (obj3 >= obj4))  foo();
+
+

+

Return to top of page or + to the FAQ. +

+ +
+

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/Technology/STL/functors.html. +

+

Return to top of page or + to the FAQ. +

+ +
+

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> pain (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);
+
+

+

Return to top of page or + to the FAQ. +

+ + + + + + +
+

+Comments and suggestions are welcome, and may be sent to +Phil Edwards or +Gabriel Dos Reis. +
$Id: howto.html,v 1.4 2000/12/03 23:47:47 jsm28 Exp $ +

+ + + + diff --git a/libstdc++-v3/docs/html/21_strings/gotw29a.txt b/libstdc++-v3/docs/html/21_strings/gotw29a.txt new file mode 100644 index 00000000000..d823f30504e --- /dev/null +++ b/libstdc++-v3/docs/html/21_strings/gotw29a.txt @@ -0,0 +1,155 @@ +From: herbs@cntc.com (Herb Sutter) +Subject: Guru of the Week #29: Solution +Date: 22 Jan 1998 00:00:00 GMT +Message-ID: <6a8q26$9qa@netlab.cs.rpi.edu> +Newsgroups: comp.lang.c++.moderated + + + .--------------------------------------------------------------------. + | Guru of the Week problems and solutions are posted regularly on | + | news:comp.lang.c++.moderated. For past problems and solutions | + | see the GotW archive at http://www.cntc.com. | + | Is there a topic you'd like to see covered? mailto:herbs@cntc.com | + `--------------------------------------------------------------------' +_______________________________________________________ + +GotW #29: Strings + +Difficulty: 7 / 10 +_______________________________________________________ + + +>Write a ci_string class which is identical to the +>standard 'string' class, but is case-insensitive in the +>same way as the C function stricmp(): + +The "how can I make a case-insensitive string?" +question is so common that it probably deserves its own +FAQ -- hence this issue of GotW. + +Note 1: The stricmp() case-insensitive string +comparison function is not part of the C standard, but +it is a common extension on many C compilers. + +Note 2: What "case insensitive" actually means depends +entirely on your application and language. For +example, many languages do not have "cases" at all, and +for languages that do you have to decide whether you +want accented characters to compare equal to unaccented +characters, and so on. This GotW provides guidance on +how to implement case-insensitivity for standard +strings in whatever sense applies to your particular +situation. + + +Here's what we want to achieve: + +> 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 key here is to understand what a "string" actually +is in standard C++. If you look in your trusty string +header, you'll see something like this: + + typedef basic_string string; + +So string isn't really a class... it's a typedef of a +template. In turn, the basic_string<> template is +declared as follows, in all its glory: + + template, + class Allocator = allocator > + class basic_string; + +So "string" really means "basic_string, allocator >". We don't need +to worry about the allocator part, but the key here is +the char_traits part because char_traits defines how +characters interact and compare(!). + +basic_string supplies useful comparison functions that +let you compare whether a string is equal to another, +less than another, and so on. These string comparisons +functions are built on top of character comparison +functions supplied in the char_traits template. In +particular, the char_traits template supplies character +comparison functions named eq(), ne(), and lt() for +equality, inequality, and less-than comparisons, and +compare() and find() functions to compare and search +sequences of characters. + +If we want these to behave differently, all we have to +do is provide a different char_traits template! Here's +the easiest way: + + struct ci_char_traits : public char_traits + // just inherit all the other functions + // that we don't need to override + { + static bool eq( char c1, char c2 ) { + return tolower(c1) == tolower(c2); + } + + static bool ne( char c1, char c2 ) { + return tolower(c1) != tolower(c2); + } + + static bool lt( char c1, char c2 ) { + return tolower(c1) < tolower(c2); + } + + static int compare( const char* s1, + const char* s2, + size_t n ) { + return strnicmp( s1, s2, n ); + // if available on your compiler, + // otherwise you can roll your own + } + + static const char* + find( const char* s, int n, char a ) { + while( n-- > 0 && tolower(*s) != tolower(a) ) { + ++s; + } + return s; + } + }; + +And finally, the key that brings it all together: + + typedef basic_string ci_string; + +All we've done is created a typedef named "ci_string" +which operates exactly like the standard "string", +except that it uses ci_char_traits instead of +char_traits to get its character comparison +rules. Since we've handily made the ci_char_traits +rules case-insensitive, we've made ci_string itself +case-insensitive without any further surgery -- that +is, we have a case-insensitive string without having +touched basic_string at all! + +This GotW should give you a flavour for how the +basic_string template works and how flexible it is in +practice. If you want different comparisons than the +ones stricmp() and tolower() give you, just replace the +five functions shown above with your own code that +performs character comparisons the way that's +appropriate in your particular application. + + + +Exercise for the reader: + +Is it safe to inherit ci_char_traits from +char_traits this way? Why or why not? + + diff --git a/libstdc++-v3/docs/html/21_strings/howto.html b/libstdc++-v3/docs/html/21_strings/howto.html new file mode 100644 index 00000000000..7318084f3ad --- /dev/null +++ b/libstdc++-v3/docs/html/21_strings/howto.html @@ -0,0 +1,332 @@ + + + + + + + + + libstdc++-v3 HOWTO: Chapter 21 + + + + + +

Chapter 21: Strings

+ +

Chapter 21 deals with the C++ strings library (a welcome relief). +

+ + + +
+

Contents

+ + +
+ + + +

MFC's CString

+

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 functons 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 + heirarchy. 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 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++-v3, their + string class is not. The SGI string is essentially + vector<char> and does not do any reference + counting like libstdc++-v3'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?) +
+

+

Return to top of page or + to the FAQ. +

+ +
+

A case-insensitive string class

+

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 pages + on the GotW website were removed into cold storage, in + preparation for + a + published book of GotW notes. Before being + put on the web, of course, it was posted on Usenet, and that + posting containing the answer is available + here. +

+

See? Told you it was easy!

+

Added June 2000: The May 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. +

+

Return to top of page or + to the FAQ. +

+ +
+

Breaking a C++ string into tokens

+

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. It's given + in this file 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). 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 outweight 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. +

+

Return to top of page or + to the FAQ. +

+ +
+

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 (no pun). Here's the + simplistic version usually seen on Usenet: + 

+   #include <string>
+   #include <algorithm>
+   #include <cctype>      // old <ctype.h>
+
+   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.reserve(s.size());
+   std::transform (s.begin(), s.end(), capital_s.begin(), tolower);
+ 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. +

+

At minimum, you can write short wrappers like + 

+   char toLower (char c)
+   {
+      return tolower(static_cast<unsigned char>(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 + here, 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 existance. +

+

Return to top of page or + to the FAQ. +

+ + + + + + +
+

+Comments and suggestions are welcome, and may be sent to +Phil Edwards or +Gabriel Dos Reis. +
$Id: howto.html,v 1.7 2000/12/03 23:47:47 jsm28 Exp $ +

+ + + + diff --git a/libstdc++-v3/docs/html/21_strings/stringtok_h.txt b/libstdc++-v3/docs/html/21_strings/stringtok_h.txt new file mode 100644 index 00000000000..81d87a6efaf --- /dev/null +++ b/libstdc++-v3/docs/html/21_strings/stringtok_h.txt @@ -0,0 +1,102 @@ +/* + * stringtok.h -- Breaks a string into tokens. This is an example for lib3. + * + * Template function looks like this: + * + * template + * void stringtok (Container &l, + * string const &s, + * char const * const ws = " \t\n"); + * + * A nondestructive version of strtok() that handles its own memory and can + * be broken up by any character(s). Does all the work at once rather than + * in an invocation loop like strtok() requires. + * + * Container is any type that supports push_back(a_string), although using + * list and deque are indicated due to their O(1) push_back. + * (I prefer deque<> because op[]/at() is available as well.) The first + * parameter references an existing Container. + * + * s is the string to be tokenized. From the parameter declaration, it can + * be seen that s is not affected. Since references-to-const may refer to + * temporaries, you could use stringtok(some_container, readline("")) when + * using the GNU readline library. + * + * The final parameter is an array of characters that serve as whitespace. + * Whitespace characters default to one or more of tab, space, and newline, + * in any combination. + * + * 'l' need not be empty on entry. On return, 'l' will have the token + * strings appended. + * + * + * [Example: + * list ls; + * stringtok (ls, " this \t is\t\n a test "); + * for (list::const_iterator i = ls.begin(); + * i != ls.end(); ++i) + * { + * cerr << ':' << (*i) << ":\n"; + * } + * + * would print + * :this: + * :is: + * :a: + * :test: + * -end example] + * + * pedwards@jaj.com May 1999 +*/ + + +#include +#include // for strchr + + +/***************************************************************** + * This is the only part of the implementation that I don't like. + * It can probably be improved upon by the reader... +*/ +namespace { + inline bool + isws (char c, char const * const wstr) + { + return (strchr(wstr,c) != NULL); + } +} + + +/***************************************************************** + * Simplistic and quite Standard, but a bit slow. This should be + * templatized on basic_string instead, or on a more generic StringT + * that just happens to support ::size_type, .substr(), and so on. + * I had hoped that "whitespace" would be a trait, but it isn't, so + * the user must supply it. Enh, this lets them break up strings on + * different things easier than traits would anyhow. +*/ +template +void +stringtok (Container &l, string const &s, char const * const ws = " \t\n") +{ + const string::size_type S = s.size(); + string::size_type i = 0; + + while (i < S) { + // eat leading whitespace + while ((i < S) && (isws(s[i],ws))) ++i; + if (i == S) return; // nothing left but WS + + // find end of word + string::size_type j = i+1; + while ((j < S) && (!isws(s[j],ws))) ++j; + + // add word + l.push_back(s.substr(i,j-i)); + + // set up for next loop + i = j+1; + } +} + + diff --git a/libstdc++-v3/docs/html/21_strings/stringtok_std_h.txt b/libstdc++-v3/docs/html/21_strings/stringtok_std_h.txt new file mode 100644 index 00000000000..2f3d7e07368 --- /dev/null +++ b/libstdc++-v3/docs/html/21_strings/stringtok_std_h.txt @@ -0,0 +1,39 @@ +/* + * Same as stringtok_h.txt, but doesn't (visiably) use C functions. +*/ + +#include + +// The std:: prefix is not used here, for readability, and a line like +// "using namespace std;" is dangerous to have in a header file. + +template +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; + } +} + diff --git a/libstdc++-v3/docs/html/22_locale/codecvt.html b/libstdc++-v3/docs/html/22_locale/codecvt.html new file mode 100644 index 00000000000..2ce6c95a1e5 --- /dev/null +++ b/libstdc++-v3/docs/html/22_locale/codecvt.html @@ -0,0 +1,522 @@ + + +

+ Notes on the codecvt implementation. +

+ + +prepared by Benjamin Kosnik (bkoz@redhat.com) on August 28, 2000 + + +

+

+1. Abstract +

+

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

+ +

+

+2. What the standard says +

+Around page 425 of the C++ Standard, this charming heading comes into view: + +
+22.2.1.5 - Template class codecvt [lib.locale.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.

+ +

+

+3. Some thoughts on what would be useful +

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

+In particular, 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. + +

+Getting back to the frequently asked question: What about Unicode strings? + +

+What magic spell will do this conversion? + +

+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-CCITT, 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, UNICODELITTLE, 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 are 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. +
+ +

+

+4. Problems with "C" code conversions : thread safety, global +locales, termination. +

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

+

+5. Design +

+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++-v3 implements a partial specialization +of the codecvt class with and iconv wrapper class, __enc_traits 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 __enc_traits 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 __enc_traits: + +

+ +__enc_traits() : __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). + +

+ +__enc_traits(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 __enc_traits 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 __enc_traits 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. + +

+ +__enc_traits(const __enc_traits&) + +

+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, __enc_traits> is consistent with other +codecvt usage. + +

+

+6. Examples +

+ +
    +
  • + a. conversions involving string literals + +
    +  typedef codecvt_base::result			result;
+  typedef unsigned short			unicode_t;
+  typedef unicode_t				int_type;
+  typedef char					ext_type;
+  typedef __enc_traits				enc_type;
+  typedef codecvt<int_type, ext_type, enc_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 );
+
    +
  • + b. conversions involving std::string +
  • + c. conversions involving std::filebuf and std::ostream +
+ +More information can be found in the following testcases: +
    +
  • testsuite/22_locale/codecvt_char_char.cc +
  • testsuite/22_locale/codecvt_unicode_wchar_t.cc +
  • testsuite/22_locale/codecvt_unicode_char.cc +
  • testsuite/22_locale/codecvt_wchar_t_char.cc +
+ +

+

+7. Unresolved Issues +

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

+

+8. Acknowledgments +

+Ulrich Drepper for the iconv suggestions and patient answering of +late-night questions, Jason Merrill for the template partial +specialization hints, language clarification, and wchar_t fixes. + +

+

+9. Bibliography / Referenced Documents +

+ +Drepper, Ulrich, GNU libc (glibc) 2.2 manual. In particular, Chapters "6. Character Set Handling" and "7 Locales and Internationalization" + +

+Drepper, Ulrich, Numerous, late-night email correspondence + +

+Feather, Clive, "A brief description of Normative Addendum 1," in particular the parts on Extended Character Sets +http://www.lysator.liu.se/c/na1.html + +

+Haible, Bruno, "The Unicode HOWTO" v0.18, 4 August 2000 +ftp://ftp.ilog.fr/pub/Users/haible/utf8/Unicode-HOWTO.html + +

+ISO/IEC 14882:1998 Programming languages - C++ + +

+ISO/IEC 9899:1999 Programming languages - C + +

+Khun, Markus, "UTF-8 and Unicode FAQ for Unix/Linux" +http://www.cl.cam.ac.uk/~mgk25/unicode.html + +

+Langer, Angelika and Klaus Kreft, Standard C++ IOStreams and Locales, Advanced Programmer's Guide and Reference, Addison Wesley Longman, Inc. 2000 + +

+Stroustrup, Bjarne, Appendix D, The C++ Programming Language, Special Edition, Addison Wesley, Inc. 2000 + +

+System Interface Definitions, Issue 6 (IEEE Std. 1003.1-200x) +The Open Group/The Institute of Electrical and Electronics Engineers, Inc. +http://www.opennc.org/austin/docreg.html + + diff --git a/libstdc++-v3/docs/html/22_locale/ctype.html b/libstdc++-v3/docs/html/22_locale/ctype.html new file mode 100644 index 00000000000..08be102fe26 --- /dev/null +++ b/libstdc++-v3/docs/html/22_locale/ctype.html @@ -0,0 +1,146 @@ + + +

+ Notes on the ctype implementation. +

+ + +prepared by Benjamin Kosnik (bkoz@redhat.com) on August 30, 2000 + + +

+

+1. Abstract +

+

+Woe is me. +

+ +

+

+2. What the standard says +

+ + +

+

+3. Problems with "C" ctype : global locales, termination. +

+ +

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

+

+4. Design +

+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. As such, libstdc++-v3 implements + + + +

+

+5. Examples +

+ +
+  typedef ctype cctype;
+
+ +More information can be found in the following testcases: +
    +
  • testsuite/22_locale/ctype_char_members.cc +
  • testsuite/22_locale/ctype_wchar_t_members.cc +
+ +

+

+6. Unresolved Issues +

+ +
    +
  • how to deal with the global locale issue? + +
  • how to deal with different types than char, wchar_t? + +
  • codecvt/ctype overlap: 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::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 + +
  • rename abstract base class. See if just smash-overriding + is a better approach. Clarify, add sanity to naming. + +
+ + +

+

+7. Acknowledgments +

+Ulrich Drepper for patient answering of late-night questions, skeletal +examples, and C language expertise. + +

+

+8. Bibliography / Referenced Documents +

+ +Drepper, Ulrich, GNU libc (glibc) 2.2 manual. In particular, Chapters "6. Character Set Handling" and "7 Locales and Internationalization" + +

+Drepper, Ulrich, Numerous, late-night email correspondence + +

+ISO/IEC 14882:1998 Programming languages - C++ + +

+ISO/IEC 9899:1999 Programming languages - C + +

+Langer, Angelika and Klaus Kreft, Standard C++ IOStreams and Locales, Advanced Programmer's Guide and Reference, Addison Wesley Longman, Inc. 2000 + +

+Stroustrup, Bjarne, Appendix D, The C++ Programming Language, Special Edition, Addison Wesley, Inc. 2000 + +

+System Interface Definitions, Issue 6 (IEEE Std. 1003.1-200x) +The Open Group/The Institute of Electrical and Electronics Engineers, Inc. +http://www.opennc.org/austin/docreg.html + + diff --git a/libstdc++-v3/docs/html/22_locale/howto.html b/libstdc++-v3/docs/html/22_locale/howto.html new file mode 100644 index 00000000000..6c76a5cef22 --- /dev/null +++ b/libstdc++-v3/docs/html/22_locale/howto.html @@ -0,0 +1,235 @@ + + + + + + + + + libstdc++-v3 HOWTO: Chapter 22 + + + + + +

Chapter 22: Localization

+ +

Chapter 22 deals with the C++ localization facilities. +

+ + + +
+

Contents

+ + +
+ + + +

Stroustrup on Locales

+

Dr. Bjarne Stroustrup has released a + pointer + to Appendix D of his book, + The C++ + Programming Language (3rd Edition). It is a detailed + description of locales and how to use them. +

+

He also writes: +

+ Please note that I still consider this detailed description of + locales beyond the needs of most C++ programmers. It is written + with experienced programmers in mind and novices will do best to + avoid it. +
+

+

Return to top of page or + to the FAQ. +

+ +
+

Nathan Myers on Locales

+

An article entitled "The Standard C++ Locale" was published in + Dr. Dobb's Journal and can be found + here +

+

Return to top of page or + to the FAQ. +

+ +
+

class locale

+

Notes made during the implementation of locales can be found + here. +

+

Return to top of page or + to the FAQ. +

+ +
+

class codecvt

+

Notes made during the implementation of codecvt can be found + here. +

+ +

The following is the abstract from the implementation notes: +

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

Return to top of page or + to the FAQ. +

+ +
+

class ctype

+

Notes made during the implementation of ctype can be found + here. +

+

Return to top of page or + to the FAQ. +

+ +
+

Correct Transformations

+ +

A very common question on newsgroups and mailing lists is, "How + do I do <foo> to a character string?" where <foo> is + a task such as changing all the letters to uppercase, to lowercase, + testing for digits, etc. A skilled and conscientious programmer + will follow the question with another, "And how do I make the + code portable?" +

+

(Poor innocent programmer, you have no idea the depths of trouble + you are getting yourself into. 'Twould be best for your sanity if + you dropped the whole idea and took up basket weaving instead. No? + Fine, you asked for it...) +

+

The task of changing the case of a letter or classifying a character + as numeric, graphical, etc, all depends on the cultural context of the + program at runtime. So, first you must take the portability question + into account. Once you have localized the program to a particular + natural language, only then can you perform the specific task. + Unfortunately, specializing a function for a human language is not + as simple as declaring + extern "Danish" int tolower (int); . +

+

The C++ code to do all this proceeds in the same way. First, a locale + is created. Then member functions of that locale are called to + perform minor tasks. Continuing the example from Chapter 21, we wish + to use the following convenience functions: + 

+   namespace std {
+     template <class charT>
+       charT
+       toupper (charT c, const locale& loc) const;
+     template <class charT>
+       charT
+       tolower (charT c, const locale& loc) const;
+   }
+ This function extracts the appropriate "facet" from the + locale loc and calls the appropriate member function of that + facet, passing c as its argument. The resulting character + is returned. +

+

For the C/POSIX locale, the results are the same as calling the + classic C toupper/tolower function that was used in previous + examples. For other locales, the code should Do The Right Thing. +

+

Of course, these functions take a second argument, and the + transformation algorithm's operator argument can only take a single + parameter. So we write simple wrapper structs to handle that. +

+

The next-to-final version of the code started in Chapter 21 looks like: + 

+   #include <iterator>    // for back_inserter
+   #include <locale>
+   #include <string>
+   #include <algorithm>
+   #include <cctype>      // old <ctype.h>
+
+   struct Toupper
+   {
+       Toupper (std::locale const& l) : loc(l) {;}
+       char operator() (char c)  { return std::toupper(c,loc); }
+   private:
+       std::locale const& loc;
+   };
+   
+   struct Tolower
+   {
+       Tolower (std::locale const& l) : loc(l) {;}
+       char operator() (char c)  { return std::tolower(c,loc); }
+   private:
+       std::locale const& loc;
+   };
+   
+   int main ()
+   {
+      std::string  s ("Some Kind Of Initial Input Goes Here");
+      Toupper      up ( std::locale("C") );
+      Tolower      down ( std::locale("C") );
+   
+      // Change everything into upper case
+      std::transform (s.begin(), s.end(), s.begin(),
+                      up
+                     );
+   
+      // Change everything into lower case
+      std::transform (s.begin(), s.end(), s.begin(),
+                      down
+                     );
+   
+      // Change everything back into upper case, but store the
+      // result in a different string
+      std::string  capital_s;
+      std::transform (s.begin(), s.end(), std::back_inserter(capital_s),
+                      up
+                     );
+   }
+

+

The final version of the code uses bind2nd to eliminate + the wrapper structs, but the resulting code is tricky. I have not + shown it here because no compilers currently available to me will + handle it. +

+

Return to top of page or + to the FAQ. +

+ + + + + + +
+

+Comments and suggestions are welcome, and may be sent to +Phil Edwards or +Gabriel Dos Reis. +
$Id: howto.html,v 1.8 2000/12/03 23:47:47 jsm28 Exp $ +

+ + + + diff --git a/libstdc++-v3/docs/html/22_locale/locale.html b/libstdc++-v3/docs/html/22_locale/locale.html new file mode 100644 index 00000000000..dc3510be351 --- /dev/null +++ b/libstdc++-v3/docs/html/22_locale/locale.html @@ -0,0 +1,103 @@ + + +

+ Notes on the locale implementation. +

+ + +prepared by Benjamin Kosnik (bkoz@redhat.com) on September 15, 2000 + + +

+

+1. Abstract +

+

+

+ +

+

+2. What the standard says +

+ + +

+

+3. Problems with "C" locales : global locales, termination. +

+ +

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

+

+4. Design +

+The two required specializations are implemented as follows: + + +

+

+5. Examples +

+ +
+  typedef ctype cctype;
+
+ +More information can be found in the following testcases: +
    +
  • testsuite/22_locale/ctype_char_members.cc +
  • testsuite/22_locale/ctype_wchar_t_members.cc +
+ +

+

+6. Unresolved Issues +

+ +
    +
  • locale -a displays available locales on linux + +
  • locale initialization: at what point does _S_classic, + _S_global get initialized? Can named locales assume this + initialization has already taken place? +
+ + +

+

+7. Acknowledgments +

+ +

+

+8. Bibliography / Referenced Documents +

+ +Drepper, Ulrich, GNU libc (glibc) 2.2 manual. In particular, Chapters "6. Character Set Handling" and "7 Locales and Internationalization" + +

+Drepper, Ulrich, Numerous, late-night email correspondence + +

+ISO/IEC 14882:1998 Programming languages - C++ + +

+ISO/IEC 9899:1999 Programming languages - C + +

+Langer, Angelika and Klaus Kreft, Standard C++ IOStreams and Locales, Advanced Programmer's Guide and Reference, Addison Wesley Longman, Inc. 2000 + +

+Stroustrup, Bjarne, Appendix D, The C++ Programming Language, Special Edition, Addison Wesley, Inc. 2000 + +

+System Interface Definitions, Issue 6 (IEEE Std. 1003.1-200x) +The Open Group/The Institute of Electrical and Electronics Engineers, Inc. +http://www.opennc.org/austin/docreg.html + + diff --git a/libstdc++-v3/docs/html/23_containers/howto.html b/libstdc++-v3/docs/html/23_containers/howto.html new file mode 100644 index 00000000000..a6c0afc0d4b --- /dev/null +++ b/libstdc++-v3/docs/html/23_containers/howto.html @@ -0,0 +1,245 @@ + + + + + + + + + libstdc++-v3 HOWTO: Chapter 23 + + + + + +

Chapter 23: Containers

+ +

Chapter 23 deals with container classes and what they offer. +

+ + + +
+

Contents

+ + +
+ + + +

Making code unaware of the container/array difference

+

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

+

Return to top of page or + to the FAQ. +

+ +
+

Variable-sized bitmasks

+

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 spae 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 Independant 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... +

+

Return to top of page or + to the FAQ. +

+ +
+

Containers and multithreading

+

This section will mention some of the problems in designing MT + programs that use Standard containers. For information on other + aspects of multithreading (e.g., the library as a whole), see + the Received Wisdom on Chapter 17. +

+

An excellent page to read when working with templatized containers + and threads is + SGI's + http://www.sgi.com/Technology/STL/thread_safety.html. The + libstdc++-v3 uses the same definition of thread safety + when discussing design. A key point that beginners may miss is the + fourth major paragraph ("For most clients,"...), pointing + out that locking must nearly always be done outside the container, + by client code (that'd be you, not us *grin*). +

+

You didn't read it, did you? *sigh* I'm serious, go read the + SGI page. It's really good and doesn't take long, and makes most + of the points that would otherwise have to be made here (and does + a better job). +

+

That's much better. Now, the issue of MT has been brought up on + the libstdc++-v3 mailing list as well as the main GCC mailing list + several times. The Chapter 17 HOWTO has some links into the mail + archives, so you can see what's been thrown around. The usual + container (or pseudo-container, depending on how you look at it) + that people have in mind is string, which is one of the + points where libstdc++ departs from the SGI STL. As of the + 2.90.8 snapshot, the libstdc++-v3 string class is safe for + certain kinds of multithreaded access. +

+

For implementing a container which does its own locking, it is + trivial to (as SGI suggests) provide a wrapper class which obtains + the lock, performs the container operation, 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. +

+ +

Return to top of page or + to the FAQ. +

+ + + + + + +
+

+Comments and suggestions are welcome, and may be sent to +Phil Edwards or +Gabriel Dos Reis. +
$Id: howto.html,v 1.4 2000/12/03 23:47:48 jsm28 Exp $ +

+ + + + diff --git a/libstdc++-v3/docs/html/23_containers/wrappers_h.txt b/libstdc++-v3/docs/html/23_containers/wrappers_h.txt new file mode 100644 index 00000000000..53b59204220 --- /dev/null +++ b/libstdc++-v3/docs/html/23_containers/wrappers_h.txt @@ -0,0 +1,48 @@ + +/***************************************************************** + * Functions to help treat arrays in a uniform manner. These were + * inspired by a thread on comp.lang.c++.moderated, started by Dietmar + * Kuehl and contributed to by the rest of the entire planet. + * + * beginof (x), endof (x), lengthof (x) now accompany sizeof, where x + * can be either a container (currently only sequences) or a builtin + * array (/not/ a pointer). The beginof/endof are intended for use in + * the algorithms library, and lengthof is a "sizing" function. + * + * Note example: + * char an_array [17]; + * cerr << lengthof(an_array) << endl; + * produces assembly code of + * mov 17,register0 + * call ofstream_put + * i.e., the template function inlining really does work; g++ + * requires -O3 (or -finline-functions) before it does this, though. + * + * pedwards 13Nov98 +*/ +// beginof +template + inline typename vector::iterator beginof (vector &v) + { return v.begin(); } + +template + inline T* beginof (T (&array)[sz]) { return array; } + + +// endof +template + inline typename vector::iterator endof (vector &v) + { return v.end(); } + +template + inline T* endof (T (&array)[sz]) { return array + sz; } + + +// lengthof +template + inline typename vector::size_type lengthof (vector &v) + { return v.size(); } + +template + inline unsigned int lengthof (T (&)[sz]) { return sz; } + diff --git a/libstdc++-v3/docs/html/24_iterators/howto.html b/libstdc++-v3/docs/html/24_iterators/howto.html new file mode 100644 index 00000000000..a807cf3d8b9 --- /dev/null +++ b/libstdc++-v3/docs/html/24_iterators/howto.html @@ -0,0 +1,94 @@ + + + + + + + + + libstdc++-v3 HOWTO: Chapter 24 + + + + + +

Chapter 24: Iterators

+ +

Chapter 24 deals with the FORTRAN subroutines for automatically + transforming lemmings into gold. +

+ + + +
+

Contents

+ + +
+ + + +

They ain't 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++-v3 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 interator 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.) +

+

Return to top of page or + to the FAQ. +

+ +
+

It ends where?

+

Blah. +

+

Return to top of page or + to the FAQ. +

+ + + + + + +
+

+Comments and suggestions are welcome, and may be sent to +Phil Edwards or +Gabriel Dos Reis. +
$Id: howto.html,v 1.5 2000/12/03 23:47:48 jsm28 Exp $ +

+ + + + diff --git a/libstdc++-v3/docs/html/25_algorithms/howto.html b/libstdc++-v3/docs/html/25_algorithms/howto.html new file mode 100644 index 00000000000..c161b1871a3 --- /dev/null +++ b/libstdc++-v3/docs/html/25_algorithms/howto.html @@ -0,0 +1,96 @@ + + + + + + + + + libstdc++-v3 HOWTO: Chapter 25 + + + + + +

Chapter 25: Algorithms

+ +

Chapter 25 deals with the generalized subroutines for automatically + transforming lemmings into gold. +

+ + + +
+

Contents

+ + +
+ + + +

Prerequisites

+

The neatest accomplishment of the algorithms chapter is that all the + work is done via iterators, not containers directly. This means two + important things: +

    +
  1. 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. So do your own iterators. +
  2. 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 legal 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. +

+

+

+

Return to top of page or + to the FAQ. +

+ +
+

Topic

+

Blah. +

+

Return to top of page or + to the FAQ. +

+ + + + + + +
+

+Comments and suggestions are welcome, and may be sent to +Phil Edwards or +Gabriel Dos Reis. +
$Id: howto.html,v 1.5 2000/12/03 23:47:48 jsm28 Exp $ +

+ + + + diff --git a/libstdc++-v3/docs/html/26_numerics/howto.html b/libstdc++-v3/docs/html/26_numerics/howto.html new file mode 100644 index 00000000000..c69532dbfcd --- /dev/null +++ b/libstdc++-v3/docs/html/26_numerics/howto.html @@ -0,0 +1,142 @@ + + + + + + + + + libstdc++-v3 HOWTO: Chapter 26 + + + + + +

Chapter 26: Numerics

+ +

Chapter 26 deals with building block abstractions to aid in + numerical computing: +

    +
  • Template data structures such as valarray<> + and complex<>. +
  • Template numerical functions such as accumulate; + inner_product; partial_sum and + adjacent_difference. +
+ All of the Standard C math functions are of course included in C++, + and overloaded versions for long, float, and + long double have been added for all of them. +

+ + +
+

Contents

+ + +
+ + + +

Complex Number 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). +

+

Return to top of page or + to the FAQ. +

+ +
+

Array Processing

+

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

+

Some more stuff should go here once somebody has time to write it. +

+

Return to top of page or + to the FAQ. +

+ +
+

Numerical Functions

+

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

+

Return to top of page or + to the FAQ. +

+ + + + + +
+

+Comments and suggestions are welcome, and may be sent to +Phil Edwards or +Gabriel Dos Reis. +
$Id: howto.html,v 1.7 2000/12/03 23:47:48 jsm28 Exp $ +

+ + + + diff --git a/libstdc++-v3/docs/html/27_io/howto.html b/libstdc++-v3/docs/html/27_io/howto.html new file mode 100644 index 00000000000..c7eb7c05b15 --- /dev/null +++ b/libstdc++-v3/docs/html/27_io/howto.html @@ -0,0 +1,345 @@ + + + + + + + + + libstdc++-v3 HOWTO: Chapter 27 + + + + + +

Chapter 27: Input/Output

+ +

Chapter 27 deals with iostreams and all their subcomponents + and extensions. All kinds of fun stuff. +

+ + + +
+

Contents

+ + +
+ + + +

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 hexidecimal + 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 + descendents. +

+

Return to top of page or + to the FAQ. +

+ +
+

The buffering is screwing up my program!

+ +

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-dependant. (The "newline-buffer-flushing only occuring + 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 thing 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, i.e., as soon as possible after opening: + 

+   std::ofstream    os ("/foo/bar/baz");
+   std::ifstream    is ("/qux/quux/quuux");
+   int   i;
+
+   os.rdbuf()->pubsetbuf(0,0);
+   is.rdbuf()->pubsetbuf(0,0);
+   ...
+   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-dependant. 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 has undefined behavior for + its sibling stringbuf, and specifying anything other + than (0,0) has varying effects. Other user-defined class derived + from streambuf can do whatever they want. +

+

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

+

Return to top of page or + to the FAQ. +

+ +
+

Binary I/O

+

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

+

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

+ +
+

Iostreams class hierarchy diagram

+

The diagram is in PDF. Rumor + has it that once Benjamin Kosnik has been dead for a few decades, + this work of his will be hung next to the Mona Lisa in the + Musee du Louvre. +

+ +
+

What is this <sstream>/stringstreams thing?

+

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

+ + + + +
+

+Comments and suggestions are welcome, and may be sent to +Phil Edwards or +Gabriel Dos Reis. +
$Id: howto.html,v 1.5 2000/12/03 23:47:49 jsm28 Exp $ +

+ + + + + + diff --git a/libstdc++-v3/docs/html/27_io/iostreams_hierarchy.pdf b/libstdc++-v3/docs/html/27_io/iostreams_hierarchy.pdf new file mode 100644 index 00000000000..ab889130017 --- /dev/null +++ b/libstdc++-v3/docs/html/27_io/iostreams_hierarchy.pdf @@ -0,0 +1 @@ +%PDF-1.2 1 0 obj << /Type /Catalog /Pages 2 0 R >> endobj 2 0 obj << /Type /Pages /Count 1 /Kids [3 0 R] >> endobj 3 0 obj << /Type /Page /Parent 2 0 R /MediaBox [0 0 841 595] /Resources 4 0 R /Contents 5 0 R /PieceInfo << /Illustrator7.0 << /LastModified (D:19990723224941+00'00') >> >> >> endobj 4 0 obj << /ProcSet [/PDF /Text] /Font 6 0 R >> endobj 6 0 obj << /F0 7 0 R >> endobj 5 0 obj << /Length 4532 /Filter [/ASCII85Decode /FlateDecode] >> stream GhUtXCMt.N(B"F5&+aY/@Qi]I;%s0lBq&tK!K+"a/W^0g,*/;JNiYL/lXkYFSkBQ+3$VRLAAp6[+Gk2p ]Y$V'q][Ii0`9nKmh=9$qUafIYES-6c9>:0iiB70cd1lN;\^Z5B(On5=3Kp1o4O9Ms/FWC4.r(nFZ"ID e#N8>Y&;s3hk&Gh=oPY>g/R7S`N35&lSnKGJT'N#f3]=I^3Ma7p@ZTLj1W%,c`?_IA&WBR:iYE0/De,) .5tSk?gUfI?gLVJ]B-%RhCB-/&1(hF(H3"13[7AhH6TkcV(T9#\l_XZ&A6prLn^=89]&sO]lO>H;AgG. E*Ffh#_X%&%CJ$hiAQ5#<*ID"b0kT-./,#D&_iK%9J/jH(%lNWYDLdVe&3s]TMfhIS&j#;9I<#\Qb$,7 OX=,>d],8TWGK,=QAXgt=(NL2B`c5r3!;DaCQfNY@HgI98u#(\L+TN8Jl%5*BSV6Z6K9q_Z)(MW:'d`5 CE&^O_Q6P>1m6SXTkQu$46r]!#A8?WKTu\^;IZ(1X`PciW(Q+Lf.k&6r_R]!C16>/_7.8)ebcN7*qjii`eZi1/lL%Sq>dU+ngdD%eur2Ir!M];qA%XP nggM_lW7J!bTqU+1.e,$hd?==gUobOrnIVuqu)sI^0ESJMlYEI^7K1Boq03mjIdgC#]cL-`Mp(D""BX_ 4*ghojioIOq^$>j-UD`2S$S)U@SX26/\%YFiKkq]SH'UgFsDKYc3pK<*th-hCrY?5N'BlZta# XuECr[WqMT*BHe=_R7LH*hKeO"[W?DCL1*,ub^MT0XZm%bleOB\KK]eSSfp?Yd)Uop%!fsF5729u=_ZrQ 5i@n/UVhOk%R==$MqJL_I=6iS#FhP;d 2Ufpk&(MK2D4[:eTU]13N@h:pI!M%FR(1,0_QrEs+Q$' Yn2o%b82KoY(S\8Pd88GM)kr+\o3H%i1p+NQ0K1E_t@s\pi$i7GVkCc"r:[KJu^'S\<74km['*s#_\Ft dMtM_6;h@h@Xq':.(O*fP^rU]N.D+#-m,3igY6dHDAg)`Pc^^`PkR6[#7dB$&m<*P$o:\9>RPgW*&XO: =AJ*0Yqp!^F@ld:d@mtqV%U&G7$WCp^tP0cWR`Fi\,aRdr7U!:Cd_.&3$"/Ee0;p&J8WO>BkO<5Vi34m 7O=jKMcj^c`DsuQ7&c/HYmi"_5%_(>kr8t6*NoP5:e2bi&TMLFZW[O#aDk322g:'@0^j[o+dY&WH1=bO .5iY75"c']o1"[T&)?Y&?^*Q!WeRT]g9Bo\ocqOAgR@"4h\b^tXf)'7dPL?>[(>+T4=g/*U.0cD''>im=>33CX'CB; 3GJX7QE_7QK=04O^T Y;TT?I\&I@q5g"@TW[#C->uYV^H=klN'`Do:g44"6nm6Tr-GXCpaIu4.!A.l99YQFY7\B@RsIqM*r$L: ctp+YI=*i@S[\K\R_G:Lc+D[,GNc9fCo]L5+7FWa0\DE`.,n0-oYYaG;[jClT-,@fT`A!.$l0]d70>8& B2h**HZlu[*6;P:D\9*7o*f:V!7OpNp^k&9^Du'>a!=G06qosuDO;9WG&PPrhd'UE_5!QLVIXN?3kefN S)$62YNh%W3oAP7T>L9OFFLoL5jrpIjTBg1q$o2*oE"*" #MjR0VX;"P?T^dW4f?oH[02C`1F3P*&bn;/$"54+HToa31o9QYBA4E2-MB,p)'7MA_4rcY8H6p,*>Ye>MJNe+i?d8NU3c;RgeDM[M7b&\Egn`&g8I+]ePi'UB=X/WH9dDIHtH)X`qkOd%N"&E`qe= ?C"#SYq<"D#I:GXRB6%_QXsi[BhMK^%V-HR10NkrJK&KaWXQnDou/BF*pHQ#n3ORHThoac+*Yb"dV.30 jM4,s=K)(LjAZbj$uIba,:_-`>WX14KH.\GNa%Z91hBVdEouFiBIfLZe'R<"m*r.u[Ss*f^o-97="l59 0;]h"VcRV69',:O:;V@O.ZV.TM.$^-En$cc=3ej,]p"PO[r*65)!\T8[RDOPr?f5mpc-H830fjj?mOD&V2fGJ0;nXLjUYB7S;iW!$qjV;3)2" +p6_sKT,_'lJH#s.$JZoaCQVu3UpW/oCrX:X4?e;6^Bu\FcMQ*oIXa_hQd'=>[o[^$SJ%Da5fBUpW2&o rRRU_+s_\t&T5Y`>dV]'S-k@"Q_kM?n_.I&4da\chQkMCLk)1%@f4\9GX#!HfnpZSEd 5B4@A0t)n-ciJ-WAjb9Ai!?.?F9;/<=hf^D5%cfket6q?T``S$NEX'@qD/F@qIuIR-.3o33<0"0Z2*C& ](Tdo:@SsHBq*3gY@lfrQ[90l\$q+^c-^g0-3t+"EZa%<[+CI;?,F"&F!tPGJGBK!YuEtS^Mj9R"Iekj ftBa(*OOrY;2DU%`o3kZF#L!cVp0L-BKO8n.PU;?r:TE:TE=Ug9K7 !N&L88e(4u=W"i,"cZ?qFSk8.n>E?ad$qUprd3T>7CH16s 4(],a>iE0c7#WqRT.IqDUJll/WsBaY+eHbLpWU#QjTQ0aoa,:UJ=/+5M2!W7E1fE,-t0eH+m<,]+hjGn M'aa8e_U[@eh1I)Cd!4MWnHO2i]&!)gJ`E;)5'Y;lfW-c`Rrmh7SCpj.DWjc(`,PSO_oPJbKPG/RJ6HG&htqbr484ODB,["l69o4n9F i)8b-L%'&bR!>dH;\*!YB"Io8>$Wu.S,QU.iO`0ZY;Mu(')F>_.g?f&Kq^t6a\op<%ifGI2?T1@\fU!E4Q_?<[Fg&Df40DH29ln?<1(*I( *NMEfeVDBiQ[)(Ind`qAo(c4L3/+\H8?^>$PP"*O-o0p2HN^\%3V9r`NO/"VWSQH=-iXDQ?kBF~> endstream endobj 7 0 obj << /Type /Font /Subtype /Type1 /Name /F0 /BaseFont /Helvetica /Encoding /MacRomanEncoding >> endobj xref 0 8 0000000000 65535 f 0000000009 00000 n 0000000058 00000 n 0000000115 00000 n 0000000298 00000 n 0000000384 00000 n 0000000353 00000 n 0000005005 00000 n trailer << /Root 1 0 R /Size 8 >> startxref 5113 %%EOF \ No newline at end of file diff --git a/libstdc++-v3/docs/html/Makefile b/libstdc++-v3/docs/html/Makefile new file mode 100644 index 00000000000..bedbd883f18 --- /dev/null +++ b/libstdc++-v3/docs/html/Makefile @@ -0,0 +1,5 @@ + + +faq/index.txt: faq/index.html + lynx -dump faq/index.html | sed "s%file://localhost`pwd`%..%" > $@ + diff --git a/libstdc++-v3/docs/html/configopts.html b/libstdc++-v3/docs/html/configopts.html new file mode 100644 index 00000000000..a4bdd5ef21c --- /dev/null +++ b/libstdc++-v3/docs/html/configopts.html @@ -0,0 +1,175 @@ + + + + + + + + libstdc++-v3 configure options + + + + + +

Interesting configure +options

+ +

The latest version of this document is always available at + + http://gcc.gnu.org/onlinedocs/libstdc++/configopts.html. +

+ +

To the libstdc++-v3 homepage. + + + +

+

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

+

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

The configure script will automatically detect the highest level + of optimization that the compiler in use can use (certain + versions of g++ will ICE if given the -O2 option, but + this is fixed in later versions of the compiler). This --enable + flag will disable all optimizations and instruct the compiler to + emit as much extra debugging information as it can, for use + inside GDB. +

+ +
--enable-cstdio [default] +

This is an abbreviated form of '--enable-cstdio=libio' + (described next). +

+ +
--enable-cstdio=LIB +

Select a target-specific I/O package. As of libstdc++-v3 + snapshot 2.90.8, the choices are 'libio' to specify the GNU + I/O package (from + glibc, the + GNU C library), or 'stdio' to use a generic "C" abstraction. +

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

+ +
--enable-cshadow-headers +

This turns on the code to construct shadowed C headers, and to + use c headers in the std:: namespace. Very experimental as of + this writing. +

+ +
--enable-threads +

This is an abbreviated form of '--enable-threads=yes' + (described next). +

+ +
--enable-threads=LIB +

Select a threading library. As of libstdc++-v3 snapshot 2.90.8, + the choices are: + 'yes' for some kind of default (hmmmmm); + 'decosf1', 'irix', 'mach', 'os2', 'posix'/'pthreads' + (same thing), + 'solaris', 'win32', 'dce', or 'vxworks' to select the + corresponding interface; + and 'single', 'no', or 'none' for the null-case, + single-threaded library. +

+

All of this is currently undergoing a lot of changes. As of + 2.90.8, 'single' and 'posix' are the only implemented models. +

+ +
--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 + "g++-v3". + 

+   --with-gxx-include-dir=/foo/H-x86-gcc-3-c-gxx-inc/include/2.97-20001008
+

+ +
--enable-cxx-flags=FLAGS +

With this option, you can pass a string of -f (functionality) + flags to the compiler to use when building libstdc++. FLAGS + is a quoted string of options, like + 

+  --enable-cxx-flags='-fsquangle -fvtable-gc -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 libgcc is 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
+  -fnew-abi
+  -fnew-exceptions
+  -ffunction-sections
+  -fvtable-gc
+ and -fno- forms of the same. Tell us (the mailing list) if + you discover more! +

+ +
--enable-wchar [default] +

Certain template specializations are required for wide character + conversion support. This is tricky and currently changing rapidly, + and can cause problems on new platforms. Disabling wide character + specializations is useful for initial porting steps, but builds + only a subset of what is required by ISO. +

+
+

+

Return to the top of the page or + to the homepage. +

+ + + + +
+

+$Id: configopts.html,v 1.18 2000/12/03 23:47:46 jsm28 Exp $ +

+ + + + diff --git a/libstdc++-v3/docs/html/documentation.html b/libstdc++-v3/docs/html/documentation.html new file mode 100644 index 00000000000..59cd201ffe8 --- /dev/null +++ b/libstdc++-v3/docs/html/documentation.html @@ -0,0 +1,74 @@ + + + + Standard C++ Library v3 + + + + + + +

All of these documents (in fact, this entire homepage set) are + bundled with the library source, under the docs subdirectory, + for releases and snapshots. +

+ +

Introductory notes for libstdc++

+

This is a short list of text files pertaining to this + implementation of ISO 14882. A brief description follows the name + of the file. +

+ + +
+

Configuring, Building, Installing

+ + +
+

Chapter-Specific Information, Extensions, Notes and Advice

+
    +
  1. Chapter 17 (Intro) +
  2. Chapter 18 (Library Support) +
  3. Chapter 19 (Diagnostics) +
  4. Chapter 20 (Utilities) +
  5. Chapter 21 (Strings) +
  6. Chapter 22 (Localization) +
  7. Chapter 23 (Containers) +
  8. Chapter 24 (Iterators) +
  9. Chapter 25 (Algorithms) +
  10. Chapter 26 (Numerics) +
  11. Chapter 27 (I/O) +
  12. Extensions to the Standard Library +
+ + + + diff --git a/libstdc++-v3/docs/html/ext/howto.html b/libstdc++-v3/docs/html/ext/howto.html new file mode 100644 index 00000000000..8806e8a1198 --- /dev/null +++ b/libstdc++-v3/docs/html/ext/howto.html @@ -0,0 +1,156 @@ + + + + + + + + + libstdc++-v3 HOWTO: Extensions + + + + + +

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 these, be aware of two things: +

    +
  1. 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++-v3 may not recognize these names, or + treat them differently, or... +
  2. You should know how to access + these headers properly. +
+

+ + + +
+

Contents

+ + +
+ + + +

Ropes and trees and hashes, oh my!

+

The SGI headers + 

+     <bvector>
+     <hash_map>
+     <hash_set>
+     <rope>
+     <slist>
+     <tree>
+
are all here; <bvector> exposes the old bit_vector + class that was used before specialization of vector<bool> was + available. <hash_map> and <hash_set> + are discussed further below. <rope> is the SGI + specialization for large strings ("rope," "large + strings," get it? love those SGI folks). + <slist> is a singly-linked list, for when the + doubly-linked list<> is too much space overhead, and + <tree> exposes the red-black tree classes used in the + implementation of the standard maps and sets. +

+

Okay, about those hashing classes... I'm going to foist most of the + work off onto SGI's own site. +

+

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 + "normal" implementations? 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.
+

+

(Side note: for those of you wondering, "Why wasn't a hash + table included in the Standard in the first #!$@ place?" I'll + give a quick answer: it was proposed, but too late and in too + unorganized a fashion. Some sort of hashing will undoubtably be + included in a future Standard. +

+

Return to top of page or + to the FAQ. +

+ +
+

Added members

+

Some of the classes in the Standard Library have additional + publicly-available members. Of those, some are intended purely for + the implementors, for example, additional typedefs. Those won't be + described here (or anywhere else). This list will grow slowly, since + we expect it to be rare -- most extensions will be self-contained. +

+

+

    +
  • filebufs have another ctor with this signature:
    +basic_filebuf(int __fd, const char* __name, ios_base::openmode __mode); +
    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:
    + int __fd, // open file descriptor
    + const char* __name,
    + ios_base::openmode __mode // same as the other openmode uses +
+

+

Return to top of page or + to the FAQ. +

+ +
+

Allocators

+

This will be blank for a while. It will describe all of the different + memory allocators, most inherited from SGI's code. Input is solicited. +

+

Return to top of page or + to the FAQ. +

+ + + + + + + +
+

+Comments and suggestions are welcome, and may be sent to +Phil Edwards or +Gabriel Dos Reis. +
$Id: howto.html,v 1.4 2000/12/03 23:47:49 jsm28 Exp $ +

+ + + + diff --git a/libstdc++-v3/docs/html/faq/index.html b/libstdc++-v3/docs/html/faq/index.html new file mode 100644 index 00000000000..d2c8329b611 --- /dev/null +++ b/libstdc++-v3/docs/html/faq/index.html @@ -0,0 +1,660 @@ + + + + + + libstdc++-v3 FAQ + + + + + + +

libstdc++ Frequently Asked Questions

+ +

The latest version of this document is always available at + +http://gcc.gnu.org/onlinedocs/libstdc++/faq/.

+ +

To the libstdc++-v3 homepage. + + +

+

Questions

+
    +
  1. General Information + +
      +
    1. What is libstdc++-v3? +
    2. Why should I use libstdc++? +
    3. Who's in charge of it? +
    4. How do I get libstdc++? +
    5. When is libstdc++ going to be finished? +
    6. How do I contribute to the effort? +
    7. What happened to libg++? I need that! +
    8. What if I have more questions? +
    + +
  2. Installation +
      +
    1. How do I install libstdc++-v3? +
    2. Is this a drop-in replacement for the + libstdc++ that's shipped with g++? +
    3. What is this CVS thing that you keep + mentioning? +
    4. How do I know if it works? +
    + +
  3. Platform-Specific Issues +
      +
    1. Can libstdc++-v3 be used with <my + favorite compiler>? +
    2. Building under Cygwin hangs/explodes!? +
    + +
  4. Known Bugs and Non-Bugs +
      +
    1. What works already? +
    2. Bugs in gcc/g++ (not libstdc++-v3) +
    3. Bugs in the C++ language/lib specification +
    4. Things in libstdc++ that look like bugs +
      The g++-3 headers are + not ours +
    5. Aw, that's easy to fix! +
    + +
  5. Miscellaneous +
      +
    1. string::iterator is not char*; + vector<T>::iterator is not T* +
    2. What's next after libstdc++-v3? +
    3. What about the STL from SGI? +
    4. Extensions and Backward Compatibility +
    5. Compiling with "-fnew-abi" +
    6. Is libstdc++-v3 thread-safe? +
    7. How do I get a copy of the ISO C++ Standard? +
    + +
+ +
+ + + +

1.0 General Information

+ +

1.1 What is libstdc++-v3?

+

The GNU Standard C++ Library v3, or libstdc++-2.90.x/2.9x, is an + ongoing project to implement the ISO 14882 Standard C++ library + as described in chapters 17 through 27 and annex D. As the + library reaches stable plateaus, it is captured in a snapshot + and released. The current release is the + tenth snapshot. 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 CVS, and can even be browsed over the Web (see below). +

+

A more formal description of the V3 goals can be found in the + official design document. +

+ +
+

1.2 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 C/C++/FORTRAN/<pick-a-language> compiler + (gcc, g++, etc) is widely considered to be + one of the leading compilers in the world. Its development + has recently been taken over 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 + (such as string, vector<>, iostreams, + and algorithms) will be freely available and fully compliant. + Programmers will no longer need to "roll their own" + nor be worried about platform-specific incompatabilities. +

+ +
+

1.3 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, and Ulrich + Drepper are the lead maintainers of the CVS 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! +

+ +
+

1.4 How do I get libstdc++?

+

The tenth (and latest) snapshot of libstdc++-v3 is + available via ftp. +

+

The homepage + has instructions for retrieving the latest CVS sources, and for + browsing the CVS sources over the web. +

+

The subset commonly known as the Standard Template Library + (chapters 23 through 25, mostly) is adapted from the SGI STL, + which is also an ongoing work. +

+ +
+

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

+ + +
+

1.6 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, is more than welcome! +

+ +
+

1.7 What happened to 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. +

+

The libg++ was designed and created when there was no 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 + (e.g., statistics :-), the Standards Committee couldn't include + everything, and so a lot of those "obvious" classes + didn't get included. +

+

Since libstdc++ is an implementation of the Standard Library, we + have no plans at this time to include non-Standard utilities + in the implementation, however handy they are. (The extensions + provided in the SGI STL aren't maintained by us and don't get + a lot of our attention, because they don't require a lot of our + time.) It is entirely plausable that the "useful stuff" + from libg++ might be extracted into an updated utilities library, + but nobody has stated such a project yet. +

+ +

(The Boost site houses free + C++ libraries that do varying things, and happened to be started + by members of the Standards Committee. Certain "useful + stuff" classes will probably migrate there.) +

+

For the bold and/or desperate, the + GCC FAQ + describes where to find the last libg++ source. +

+ +
+

1.8 What if I have more questions?

+

If you have read the README and RELEASE-NOTES files, 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 + 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, + contact Phil Edwards + or Gabriel Dos Reis. +

+ +
+ +

2.0 Installation

+

2.1 How do I install libstdc++-v3?

+

Complete instructions are not given here (this is a FAQ, not + an installation document), but the tools required are few: +

+
    +
  • A release of libstdc++. +
  • A recent release of GCC (version 2.95 works). Note + that building GCC is much easier and more automated + than building the GCC 2.[78] series was. +
  • If you plan on hacking around with the makefiles, you + will need the tools autoconfand automake. +
  • GNU Make is the only make that supports these makefiles. +
+

The file documentation.html + provides a good overview of the steps necessary to build, install, + and use the library. Instructions for configuring the library + with new flags such as --enable-threads are there also. +

+

The top-level install.html and + RELEASE-NOTES files contain + the exact build and installation instructions. You may wish to + browse those files over CVSweb ahead of time to get a feel for + what's required. RELEASE-NOTES is located in the + ".../docs/17_intro/" directory of the distribution. +

+ +
+

2.2 Is this a drop-in replacement for the + libstdc++ that's shipped with g++?

+

Yes, as of 2.90.8, it is intended as such. And as of 2.91, + libstdc++-v3 is the library that's shipped with + g++, so much of this answer has become moot. +

+ +
+

2.3 What is this CVS thing that you + keep mentioning?

+

The Concurrent Versions System 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 CVS entry in + the GNU software catalogue has a better description as + well as a + link to the makers of CVS. +

+

The "anonymous client checkout" feature of CVS is + similar to anonymous FTP in that it allows anyone to retrieve + the latest libstdc++ sources. +

+

After the first of April, American users will have a + "/pharmacy" command-line option... + +

+ +
+

2.4 How do I know if it works?

+

libstdc++-v3 comes with its own testsuite. You do not need + to actually install the library ("gmake + install") to run the testsuite. Note that 2.91 does + not use DejaGNU yet. +

+

To run the testsuite on the library after building it, use + "gmake check" while in your build directory. To run + the testsuite on the library after building and installing it, + use "gmake check-install" instead. +

+

The testsuite subdirectory in your build directory will then + contain three files of the form YYYYMMDD-mkcheck*.txt. One of + them (-mkcheck.txt itself) contains the results of the tests; + this can be mailed to the list. The other files (-mkchecklog.txt + and -mkcheckfiles.txt) contain messages from the compiler while + building the test programs, and a list of the tests to be run, + respectively. +

+

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

+ +
+

3.0 Platform-Specific Issues

+

3.1 Can libstdc++-v3 be used with <my + favorite compiler>?

+

Probably not. Yet.

+

Because GCC advances so rapidly, development and testing of + libstdc++ is being done almost entirely under that compiler. + If you are curious about whether other, lesser compilers + (*grin*) support libstdc++, you are more than welcome to try. + Configuring and building the library (see above) will still + require certain tools, however. Also keep in mind that + building libstdc++ does not imply that your compiler + will be able to use all of the features found in the + C++ Standard Library. +

+

Since the goal of ISO Standardization is for all C++ + implementations to be able to share code, the final libstdc++ + should, in theory, be useable under any ISO-compliant + compiler. It will still be targeted and optimized for + GCC/g++, however. +

+ +
+

3.2 Building under Cygwin hangs/explodes!?

+

Sometimes, yes. You're probably in the middle of generating + the numeric_limits specializations when it hangs, + right? Thought so... +

+

The <limits> header and its associated library + code are platform-specific. These files get generated from + scratch during installation, and it is this generator that is + hanging. More specifically, the only sure way to determine + what the numeric_limits<T>::traps boolean + should be is to actually divide by zero and see if it is + trapped or not. +

+

Under NT, this will occasionally just hang. On those + occasions when the test does not hang, the zero-division is + in fact trapped. That doesn't prevent hanging elsewhere. +

+

You have two options. You can get a newer cygwin1.dll (see the + Cygwin paragraph in the + installation instructions). + Or you can get a prebuilt set of bits/std_limits.h and + src/limitsMEMBERS.cc files from Mumit Khan's + Cygwin-related website. +

+ +
+

4.0 Known Bugs and Non-Bugs

+ Note that this section can get rapdily outdated -- such is the + nature of an open-source project. For the latest information, join + the mailing list or look through recent archives. The RELEASE- + NOTES and BUGS files are generally kept up-to-date. + +

4.1 What works already?

+

This is a verbatim clip from the "Status" section + of the RELEASE-NOTES for the latest snapshot. +

+ + + +
+New: 
+- namespace std:: is now on by default.
+- choice of "C" include strategies, including the shadow header work,
+  or generic global to std mapping of required "C" types.
+- cpu/atomicity.h tweaks, additions of ia64 and arm support.
+- abstraction of atomicity.h header to support notion of os/atomicity.h files.
+- addition of backward header bits
+- use of system_header pragma
+- Conditional use of -Werror
+- preliminary support for new g++ diagnostics capabilities, including
+  -fdiagnostics-show-location=once
+- pedantic and shadow argument warning fixes 
+- Ugly, yet correct mechanism for dealing with "C" math adopted,
+  including the use of builtins.
+- updates and configure/build work to support new libtool
+- addition of strstream 
+- valarray work
+- complex work
+- update to SGI STL 3.3
+- libio sync between glibc/libstdc++-v3. Some divergence since initial
+  merge, but sources remain quite close.
+- IO fixes for alpha
+- wide character work for IO when using libio
+- addition of c_io_stdio and "C" IO abstraction layer.
+- auto_ptr fixes, testsuite additions
+- Attempts to use -ffunction-sections -fdata-sections and
+  --gc-sections, depending on use of GNU ld and specific features. As of
+  late, --gc-sections has been disabled due to problems with it throwing
+  away initialization sections. This work is ongoing.
+- long double support
+- sub directory removal, coherent organization of cpu and os-specific
+  files, consolidation of include directories, integration of the C++
+  support bits for operator new/delete,exceptions, etc. All includes
+  are now either in the include/* hierarchy or in libsupc++'s sub directory.
+- Support for more platforms, including irix and bsd variants.
+- filebuf tweaks to deal with variable-size buffers.
+- filebuf implementation for putbackc, etc. al.
+- ctype rewritten. Includes ctype, ctype, and others.
+- codecvt rewritten. Includes codecvt,
+  codecvt. In addition,
+  implementation-defined conversions using iconv are now supported with
+  the __enc_traits partial-specialization of the State template
+  parameter of the codecvt class. In this manner, conversions between
+  encodings such as UCS4, USC2, UNICODE, UNICODEBIG, UNICODELITTLE, etc
+  can be performed.
+- preliminary work on named locales
+- preliminary documentation for locale implementation has been established.
+- Many, many bug fixes.
+- Many, many testsuite additions and consistent VERIFY usage.
+- work on mkcheck to make it more flexible, use libtool, etc.
+
+ + +
+

4.2 Bugs in gcc/g++ (not libstdc++-v3)

+

This is by no means meant to be complete nor exhaustive, but + mentions some problems that users may encounter when building + or using libstdc++. If you are experiencing one of these + problems, you can find more information on the libstdc++ and + the GCC mailing lists. +

+
    +
  • As of 2.91, these bugs have all been fixed. We look forward + to new ones, well, not exactly... +
+ +
+

4.3 Bugs in the C++ language/lib specification

+

Yes, unfortunately, there are some. In a message +to the list, Nathan Myers announced that he has started a list of + problems in the ISO C++ Standard itself, especially with + regard to the chapters that concern the library. The list + itself is posted on his + website. Developers who are having problems interpreting + the Standard may wish to consult his notes. +

+

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

+ +
+

4.4 Things in libstdc++ that look like bugs

+

There are things which are not bugs in the compiler (4.2) nor + the language specification (4.3), but aren't really bugs in + libstdc++, either. Really! +

+

The biggest of these is the quadzillions of warnings about the + library headers 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. There are multiple solutions + under discussion. +

+

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

+

Currently our header files are installed in + ${prefix}/include/g++-v3 (see the 'v'?). This may + change with the next release of GCC, as it may be too confusing, + but the + question has not yet been decided. +

+ +
+

4.5 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 of course send the patch to our mailing list, not the + GCC 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. +

+ +
+

5.0 Miscellaneous

+

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

+

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

+ +
+

5.2 What's next after libstdc++-v3?

+

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

+

The ISO Committee will meet periodically to review Defect Reports + in the C++ Standard. Undoubtably some of these will result in + changes to the Standard, which will be reflected in patches to + libstdc++. Some of that is already happening, see 4.2. Some of + those changes are being predicted by the library maintainers, and + we add code to the library based on what the current proposed + resolution specifies. +

+

The current libstdc++ contains extensions to the Library which + must be explicitly requested by client code (for example, the + hash tables from SGI). Other extensions may be added to + libstdc++-v3 if they seem to be "standard" enough. + (For example, the "long long" type from C99.) + Bugfixes and rewrites (to improve or fix thread safety, for + instance) will of course be a continuing task. +

+

This + question about the next libstdc++ prompted some brief but + interesting speculation. +

+ +
+

5.3 What about the STL from SGI?

+

The STL from SGI + is merged into libstdc++-v3 with changes as necessary. + Currently release 3.3 is being used. Changes in the STL + usually produce some weird bugs and lots of changes in the + rest of the libstd++ source as we scramble to keep up. :-) +

+

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, however. +

+

The FAQ for SGI's STL (one jump off of their main page) is + recommended reading. +

+ +
+

5.4 Extensions and Backward Compatibility

+

Although you can specify -I options to make the + preprocessor search the g++-v3/ext and /backward directories, + it is better to refer to files there by their path, as in: + +

+ 
+       #include <ext/hash_map>
+
+

Extensions to the library have + their own page. +

+ +
+

5.5 Compiling with "-fnew-abi"

+

Towards the end of July 1999, this subject was brought up again + on the mailing list under a different name. The related + thread + (by the name HOWTO-honor-std) is very instructive. More info + is at the end of RELEASE-NOTES. +

+

This functionality is now automated and turned on by default. +

+ +
+

5.6 Is libstdc++-v3 thread-safe?

+

Quick answer: no, as of 2.91 (tenth snapshot), the + library is not appropriate for multithreaded access. The + string class is MT-safe. +

+

This is assuming that your idea of "multithreaded" + is the same as ours... The general question of multithreading + and libstdc++-v3 is addressed in the chapter-specific advice for +Library + Introduction. Threadsafe containers are covered in + more detail in +the + Received Wisdom section on containers. + +

+ +
+

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

+ + + +
+

+Comments and suggestions are welcome, and may be sent to +Phil Edwards or +Gabriel Dos Reis. +
$Id: index.html,v 1.10 2000/12/03 23:47:49 jsm28 Exp $ +

+ + + + diff --git a/libstdc++-v3/docs/html/faq/index.txt b/libstdc++-v3/docs/html/faq/index.txt new file mode 100644 index 00000000000..b10d61c91ee --- /dev/null +++ b/libstdc++-v3/docs/html/faq/index.txt @@ -0,0 +1,603 @@ + + libstdc++ Frequently Asked Questions + + The latest version of this document is always available at + [1]http://gcc.gnu.org/onlinedocs/libstdc++/faq/. + + To the [2]libstdc++-v3 homepage. + _________________________________________________________________ + + Questions + + 1. [3]General Information + 1. [4]What is libstdc++-v3? + 2. [5]Why should I use libstdc++? + 3. [6]Who's in charge of it? + 4. [7]How do I get libstdc++? + 5. [8]When is libstdc++ going to be finished? + 6. [9]How do I contribute to the effort? + 7. [10]What happened to libg++? I need that! + 8. [11]What if I have more questions? + 2. [12]Installation + 1. [13]How do I install libstdc++-v3? + 2. [14]Is this a drop-in replacement for the libstdc++ that's + shipped with g++? + 3. [15]What is this CVS thing that you keep mentioning? + 4. [16]How do I know if it works? + 3. [17]Platform-Specific Issues + 1. [18]Can libstdc++-v3 be used with ? + 2. [19]Building under Cygwin hangs/explodes!? + 4. [20]Known Bugs and Non-Bugs + 1. [21]What works already? + 2. [22]Bugs in gcc/g++ (not libstdc++-v3) + 3. [23]Bugs in the C++ language/lib specification + 4. [24]Things in libstdc++ that look like bugs + [25]The g++-3 headers are not ours + 5. [26]Aw, that's easy to fix! + 5. [27]Miscellaneous + 1. [28]string::iterator is not char*; vector::iterator is not + T* + 2. [29]What's next after libstdc++-v3? + 3. [30]What about the STL from SGI? + 4. [31]Extensions and Backward Compatibility + 5. [32]Compiling with "-fnew-abi" + 6. [33]Is libstdc++-v3 thread-safe? + 7. [34]How do I get a copy of the ISO C++ Standard? + _________________________________________________________________ + + 1.0 General Information + +1.1 What is libstdc++-v3? + + The GNU Standard C++ Library v3, or libstdc++-2.90.x/2.9x, is an + ongoing project to implement the ISO 14882 Standard C++ library as + described in chapters 17 through 27 and annex D. As the library + reaches stable plateaus, it is captured in a snapshot and released. + The current release is [35]the tenth snapshot. 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 + CVS, and can even be browsed over the Web (see below). + + A more formal description of the V3 goals can be found in the official + [36]design document. + _________________________________________________________________ + +1.2 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 C/C++/FORTRAN/ compiler (gcc, g++, etc) is + widely considered to be one of the leading compilers in the world. Its + development has recently been taken over by the [37]GCC team. All of + the rapid development and near-legendary [38]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 (such as + string, vector<>, iostreams, and algorithms) will be freely available + and fully compliant. Programmers will no longer need to "roll their + own" nor be worried about platform-specific incompatabilities. + _________________________________________________________________ + +1.3 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, and Ulrich Drepper are the lead maintainers of + the CVS 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 [39]homepage. + If you have questions, ideas, code, or are just curious, sign up! + _________________________________________________________________ + +1.4 How do I get libstdc++? + + The tenth (and latest) snapshot of libstdc++-v3 is [40]available via + ftp. + + The [41]homepage has instructions for retrieving the latest CVS + sources, and for browsing the CVS sources over the web. + + The subset commonly known as the Standard Template Library (chapters + 23 through 25, mostly) is adapted from the SGI STL, which is also an + ongoing work. + _________________________________________________________________ + +1.5 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. + _________________________________________________________________ + +1.6 How do I contribute to the effort? + + Here is [42]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, is more than welcome! + _________________________________________________________________ + +1.7 What happened to 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. + + The libg++ was designed and created when there was no Standard to + provide guidance. Classes like linked lists are now provided for by + list 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 (e.g., statistics :-), + the Standards Committee couldn't include everything, and so a lot of + those "obvious" classes didn't get included. + + Since libstdc++ is an implementation of the Standard Library, we have + no plans at this time to include non-Standard utilities in the + implementation, however handy they are. (The extensions provided in + the SGI STL aren't maintained by us and don't get a lot of our + attention, because they don't require a lot of our time.) It is + entirely plausable that the "useful stuff" from libg++ might be + extracted into an updated utilities library, but nobody has stated + such a project yet. + + (The [43]Boost site houses free C++ libraries that do varying things, + and happened to be started by members of the Standards Committee. + Certain "useful stuff" classes will probably migrate there.) + + For the bold and/or desperate, the [44]GCC FAQ describes where to find + the last libg++ source. + _________________________________________________________________ + +1.8 What if I have more questions? + + If you have read the README and RELEASE-NOTES files, 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 to the list, use [45]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, contact [46]Phil + Edwards or [47]Gabriel Dos Reis. + _________________________________________________________________ + + 2.0 Installation + +2.1 How do I install libstdc++-v3? + + Complete instructions are not given here (this is a FAQ, not an + installation document), but the tools required are few: + * A release of libstdc++. + * A recent release of GCC (version 2.95 works). Note that building + GCC is much easier and more automated than building the GCC 2.[78] + series was. + * If you plan on hacking around with the makefiles, you will need + the tools [48]autoconfand [49]automake. + * GNU Make is the only make that supports these makefiles. + + The file [50]documentation.html provides a good overview of the steps + necessary to build, install, and use the library. Instructions for + configuring the library with new flags such as --enable-threads are + there also. + + The top-level install.html and [51]RELEASE-NOTES files contain the + exact build and installation instructions. You may wish to browse + those files over CVSweb ahead of time to get a feel for what's + required. RELEASE-NOTES is located in the ".../docs/17_intro/" + directory of the distribution. + _________________________________________________________________ + +2.2 Is this a drop-in replacement for the libstdc++ that's shipped with g++? + + Yes, as of 2.90.8, it is intended as such. And as of 2.91, + libstdc++-v3 is the library that's shipped with g++, so much of this + answer has become moot. + _________________________________________________________________ + +2.3 What is this CVS thing that you keep mentioning? + + The Concurrent Versions System 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 [52]CVS entry in the GNU + software catalogue has a better description as well as a [53]link to + the makers of CVS. + + The "anonymous client checkout" feature of CVS is similar to anonymous + FTP in that it allows anyone to retrieve the latest libstdc++ sources. + + After the first of April, American users will have a "/pharmacy" + command-line option... + _________________________________________________________________ + +2.4 How do I know if it works? + + libstdc++-v3 comes with its own testsuite. You do not need to actually + install the library ("gmake install") to run the testsuite. Note that + 2.91 does not use DejaGNU yet. + + To run the testsuite on the library after building it, use "gmake + check" while in your build directory. To run the testsuite on the + library after building and installing it, use "gmake check-install" + instead. + + The testsuite subdirectory in your build directory will then contain + three files of the form YYYYMMDD-mkcheck*.txt. One of them + (-mkcheck.txt itself) contains the results of the tests; this can be + mailed to the list. The other files (-mkchecklog.txt and + -mkcheckfiles.txt) contain messages from the compiler while building + the test programs, and a list of the tests to be run, respectively. + + 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! + _________________________________________________________________ + + 3.0 Platform-Specific Issues + +3.1 Can libstdc++-v3 be used with ? + + Probably not. Yet. + + Because GCC advances so rapidly, development and testing of libstdc++ + is being done almost entirely under that compiler. If you are curious + about whether other, lesser compilers (*grin*) support libstdc++, you + are more than welcome to try. Configuring and building the library + (see above) will still require certain tools, however. Also keep in + mind that building libstdc++ does not imply that your compiler will be + able to use all of the features found in the C++ Standard Library. + + Since the goal of ISO Standardization is for all C++ implementations + to be able to share code, the final libstdc++ should, in theory, be + useable under any ISO-compliant compiler. It will still be targeted + and optimized for GCC/g++, however. + _________________________________________________________________ + +3.2 Building under Cygwin hangs/explodes!? + + Sometimes, yes. You're probably in the middle of generating the + numeric_limits specializations when it hangs, right? Thought so... + + The header and its associated library code are + platform-specific. These files get generated from scratch during + installation, and it is this generator that is hanging. More + specifically, the only sure way to determine what the + numeric_limits::traps boolean should be is to actually divide by + zero and see if it is trapped or not. + + Under NT, this will occasionally just hang. On those occasions when + the test does not hang, the zero-division is in fact trapped. That + doesn't prevent hanging elsewhere. + + You have two options. You can get a newer cygwin1.dll (see the Cygwin + paragraph in the [54]installation instructions). Or you can get a + prebuilt set of bits/std_limits.h and src/limitsMEMBERS.cc files from + Mumit Khan's [55]Cygwin-related website. + _________________________________________________________________ + + 4.0 Known Bugs and Non-Bugs + + Note that this section can get rapdily outdated -- such is the nature + of an open-source project. For the latest information, join the + mailing list or look through recent archives. The RELEASE- NOTES and + BUGS files are generally kept up-to-date. + +4.1 What works already? + + This is a verbatim clip from the "Status" section of the RELEASE-NOTES + for the latest snapshot. +New: +- namespace std:: is now on by default. +- choice of "C" include strategies, including the shadow header work, + or generic global to std mapping of required "C" types. +- cpu/atomicity.h tweaks, additions of ia64 and arm support. +- abstraction of atomicity.h header to support notion of os/atomicity.h files. +- addition of backward header bits +- use of system_header pragma +- Conditional use of -Werror +- preliminary support for new g++ diagnostics capabilities, including + -fdiagnostics-show-location=once +- pedantic and shadow argument warning fixes +- Ugly, yet correct mechanism for dealing with "C" math adopted, + including the use of builtins. +- updates and configure/build work to support new libtool +- addition of strstream +- valarray work +- complex work +- update to SGI STL 3.3 +- libio sync between glibc/libstdc++-v3. Some divergence since initial + merge, but sources remain quite close. +- IO fixes for alpha +- wide character work for IO when using libio +- addition of c_io_stdio and "C" IO abstraction layer. +- auto_ptr fixes, testsuite additions +- Attempts to use -ffunction-sections -fdata-sections and + --gc-sections, depending on use of GNU ld and specific features. As of + late, --gc-sections has been disabled due to problems with it throwing + away initialization sections. This work is ongoing. +- long double support +- sub directory removal, coherent organization of cpu and os-specific + files, consolidation of include directories, integration of the C++ + support bits for operator new/delete,exceptions, etc. All includes + are now either in the include/* hierarchy or in libsupc++'s sub directory. +- Support for more platforms, including irix and bsd variants. +- filebuf tweaks to deal with variable-size buffers. +- filebuf implementation for putbackc, etc. al. +- ctype rewritten. Includes ctype, ctype, and others. +- codecvt rewritten. Includes codecvt, + codecvt. In addition, + implementation-defined conversions using iconv are now supported with + the __enc_traits partial-specialization of the State template + parameter of the codecvt class. In this manner, conversions between + encodings such as UCS4, USC2, UNICODE, UNICODEBIG, UNICODELITTLE, etc + can be performed. +- preliminary work on named locales +- preliminary documentation for locale implementation has been established. +- Many, many bug fixes. +- Many, many testsuite additions and consistent VERIFY usage. +- work on mkcheck to make it more flexible, use libtool, etc. + _________________________________________________________________ + +4.2 Bugs in gcc/g++ (not libstdc++-v3) + + This is by no means meant to be complete nor exhaustive, but mentions + some problems that users may encounter when building or using + libstdc++. If you are experiencing one of these problems, you can find + more information on the libstdc++ and the GCC mailing lists. + * As of 2.91, these bugs have all been fixed. We look forward to new + ones, well, not exactly... + _________________________________________________________________ + +4.3 Bugs in the C++ language/lib specification + + Yes, unfortunately, there are some. In a [56]message to the list, + Nathan Myers announced that he has started a list of problems in the + ISO C++ Standard itself, especially with regard to the chapters that + concern the library. The list itself is [57]posted on his website. + Developers who are having problems interpreting the Standard may wish + to consult his notes. + + 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 [58]here. + _________________________________________________________________ + +4.4 Things in libstdc++ that look like bugs + + There are things which are not bugs in the compiler (4.2) nor the + language specification (4.3), but aren't really bugs in libstdc++, + either. Really! + + The biggest of these is the quadzillions of warnings about the library + headers 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. There + are multiple solutions under discussion. + + 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 [59]the GCC bug database). + + If the headers are in ${prefix}/include/g++-3, 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. + + Currently our header files are installed in ${prefix}/include/g++-v3 + (see the 'v'?). This may change with the next release of GCC, as it + may be too confusing, but [60]the question has not yet been decided. + _________________________________________________________________ + +4.5 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 + [61]submitting patches that covers the procedure, but for libstdc++ + you should of course send the patch to our mailing list, not the GCC + mailing list. The libstdc++ [62]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 [63]testsuite -- but only if such a test + exists. + _________________________________________________________________ + + 5.0 Miscellaneous + +5.1 string::iterator is not char*; vector::iterator is not T* + + If you have code that depends on container iterators being + implemented as pointer-to-T, your code is broken. + + 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. + _________________________________________________________________ + +5.2 What's next after libstdc++-v3? + + Hopefully, not much. The goal of libstdc++-v3 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. + + The ISO Committee will meet periodically to review Defect Reports in + the C++ Standard. Undoubtably some of these will result in changes to + the Standard, which will be reflected in patches to libstdc++. Some of + that is already happening, see 4.2. Some of those changes are being + predicted by the library maintainers, and we add code to the library + based on what the current proposed resolution specifies. + + The current libstdc++ contains extensions to the Library which must be + explicitly requested by client code (for example, the hash tables from + SGI). Other extensions may be added to libstdc++-v3 if they seem to be + "standard" enough. (For example, the "long long" type from C99.) + Bugfixes and rewrites (to improve or fix thread safety, for instance) + will of course be a continuing task. + + [64]This question about the next libstdc++ prompted some brief but + interesting [65]speculation. + _________________________________________________________________ + +5.3 What about the STL from SGI? + + The [66]STL from SGI is merged into libstdc++-v3 with changes as + necessary. Currently release 3.3 is being used. Changes in the STL + usually produce some weird bugs and lots of changes in the rest of the + libstd++ source as we scramble to keep up. :-) + + 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, however. + + The FAQ for SGI's STL (one jump off of their main page) is recommended + reading. + _________________________________________________________________ + +5.4 Extensions and Backward Compatibility + + Although you can specify -I options to make the preprocessor search + the g++-v3/ext and /backward directories, it is better to refer to + files there by their path, as in: + #include + + + Extensions to the library have [67]their own page. + _________________________________________________________________ + +5.5 Compiling with "-fnew-abi" + + Towards the end of July 1999, this subject was brought up again on the + mailing list under a different name. The related [68]thread (by the + name HOWTO-honor-std) is very instructive. More info is at the end of + RELEASE-NOTES. + + This functionality is now automated and turned on by default. + _________________________________________________________________ + +5.6 Is libstdc++-v3 thread-safe? + + Quick answer: no, as of 2.91 (tenth snapshot), the library is not + appropriate for multithreaded access. The string class is MT-safe. + + This is assuming that your idea of "multithreaded" is the same as + ours... The general question of multithreading and libstdc++-v3 is + addressed in the chapter-specific advice for [69]Library Introduction. + Threadsafe containers are covered in more detail in [70]the Received + Wisdom section on containers. + _________________________________________________________________ + +5.7 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 [71]here. (And if you've already registered with them, clicking + this link will take you to directly to the place where you can [72]buy + the standard on-line. + + Who is your country's member body? Visit the [73]ISO homepage and find + out! + _________________________________________________________________ + + Comments and suggestions are welcome, and may be sent to [74]Phil + Edwards or [75]Gabriel Dos Reis. + $Id: index.html,v 1.10 2000/12/03 23:47:49 jsm28 Exp $ + +References + + 1. http://gcc.gnu.org/onlinedocs/libstdc++/faq/ + 2. http://gcc.gnu.org/libstdc++/ + 3. ../faq/index.html#1_0 + 4. ../faq/index.html#1_1 + 5. ../faq/index.html#1_2 + 6. ../faq/index.html#1_3 + 7. ../faq/index.html#1_4 + 8. ../faq/index.html#1_5 + 9. ../faq/index.html#1_6 + 10. ../faq/index.html#1_7 + 11. ../faq/index.html#1_8 + 12. ../faq/index.html#2_0 + 13. ../faq/index.html#2_1 + 14. ../faq/index.html#2_2 + 15. ../faq/index.html#2_3 + 16. ../faq/index.html#2_4 + 17. ../faq/index.html#3_0 + 18. ../faq/index.html#3_1 + 19. ../faq/index.html#3_2 + 20. ../faq/index.html#4_0 + 21. ../faq/index.html#4_1 + 22. ../faq/index.html#4_2 + 23. ../faq/index.html#4_3 + 24. ../faq/index.html#4_4 + 25. ../faq/index.html#4_4_interface + 26. ../faq/index.html#4_5 + 27. ../faq/index.html#5_0 + 28. ../faq/index.html#5_1 + 29. ../faq/index.html#5_2 + 30. ../faq/index.html#5_3 + 31. ../faq/index.html#5_4 + 32. ../faq/index.html#5_5 + 33. ../faq/index.html#5_6 + 34. ../faq/index.html#5_7 + 35. ftp://gcc.gnu.org/pub/libstdc++/libstdc++-2.91.tar.gz + 36. ../17_intro/DESIGN + 37. http://gcc.gnu.org/ + 38. http://gcc.gnu.org/gcc-2.95/buildstat.html + 39. http://gcc.gnu.org/libstdc++/ + 40. ftp://gcc.gnu.org/pub/libstdc++/libstdc++-2.91.tar.gz + 41. http://gcc.gnu.org/libstdc++/ + 42. ../17_intro/contribute.html + 43. http://www.boost.org/ + 44. http://gcc.gnu.org/fom_serv/cache/33.html + 45. mailto:libstdc++@gcc.gnu.org + 46. mailto:pme@sources.redhat.com + 47. mailto:gdr@gcc.gnu.org + 48. http://sources.redhat.com/autoconf/ + 49. http://sources.redhat.com/automake/ + 50. ../documentation.html + 51. ../17_intro/RELEASE-NOTES + 52. http://www.gnu.org/software/cvs/cvs.html + 53. http://www.cyclic.com/ + 54. ../install.html + 55. http://www.xraylith.wisc.edu/~khan/software/gnu-win32/libstdc++-v3.html + 56. http://gcc.gnu.org/ml/libstdc++/1998/msg00006.html + 57. http://www.cantrip.org/draft-bugs.txt + 58. http://anubis.dkuug.dk/jtc1/sc22/wg21/ + 59. http://gcc.gnu.org/gnatswrite.html + 60. http://gcc.gnu.org/ml/gcc/2000-10/msg00732.html + 61. http://gcc.gnu.org/contribute.html + 62. ../17_intro/contribute.html + 63. ../faq/index.html#2_4 + 64. http://gcc.gnu.org/ml/libstdc++/1999/msg00080.html + 65. http://gcc.gnu.org/ml/libstdc++/1999/msg00084.html + 66. http://www.sgi.com/Technology/STL/ + 67. ../ext/howto.html + 68. http://gcc.gnu.org/ml/libstdc++/1999-q3/msg00066.html + 69. http://gcc.gnu.org/libstdc++/17_intro/howto.html#3 + 70. http://gcc.gnu.org/libstdc++/23_containers/howto.html + 71. http://www.ansi.org/ + 72. http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%2D1998 + 73. http://www.iso.ch/ + 74. mailto:pme@sources.redhat.com + 75. mailto:gdr@gcc.gnu.org diff --git a/libstdc++-v3/docs/html/install.html b/libstdc++-v3/docs/html/install.html new file mode 100644 index 00000000000..1a6b8114d27 --- /dev/null +++ b/libstdc++-v3/docs/html/install.html @@ -0,0 +1,411 @@ + + + + + + + + libstdc++-v3 Installation Instructions + + + + + +

libstdc++-v3 INSTALL

+ +

The latest version of this document is always available at + + http://gcc.gnu.org/onlinedocs/libstdc++/install.html. +

+ +

To the libstdc++-v3 homepage. + + + +

+

Contents

+ + +
+ + + +

Tools you will need beforehand

+

You will need a recent version of g++ to compile the snapshot of + libstdc++: gcc-2.95.2 works well, or one of the post-2.95.2 GCC + snapshots (insert standard caveat about using snapshots rather + than formal releases). You will need the full source + distribution to whatever compiler release you are using. The + GCC snapshots can be had from one of the sites on their + mirror list. +

+ +

In addition, if you plan to modify the makefiles or regenerate + the configure scripts you'll need the nuevo automake, libtool + and autoconf to regenerate the Makefiles and configure + scripts. These tools are all required to be installed in the + same location (most linux distributions install these tools by + default, so no worries.) +

+ +

If you don't have bash, and want to run 'make check' to + test your build, you'll need to get bash 2.x. Also recommended + is GNU Make, since it is the only 'make' that will parse these + makefiles correctly. +

+ +

As of June 19, 2000, libstdc++ attempts to use tricky and + space-saving features of the GNU toolchain, enabled with + -ffunction-sections -fdata-sections -Wl,--gc-sections. + To obtain maximum benefit from this, binutils after this date + should also be used (bugs were fixed with C++ exception handling + related to this change in libstdc++-v3). The version of these + tools should be 2.10.90, and you can get snapshots (as + well as releases) of binutils + here. +

+ +

Finally, a few system-specific requirements: +

+
Cygwin +
If you are using Cygwin to compile libstdc++-v3 on Win32, you'll + have to get a version of the cygwin1.dll that is dated on or + after February 1, 2000. This is necessary to successfully run + the script "mknumeric_limits" which probes the + floating-point + environment of the host in question -- before this date, Cygwin + would freeze when running this script. In addition, you may + want to get a current version of libtool (say libtool-1.3.4 + and above) as earlier versions supposedly had problems creating + shared libraries. + +
Solaris +
We recommend installing the SUNWxcu4 package from the + Solaris CD before configuring the library. You can check for + this package as a non-privileged user with the command + "pkginfo SUNWxcu4". +
+

+ +
+ +

Setting up the source directories

+

As the libstdc++-v3 sources and the core GCC sources have + converged, more and more effort goes to building the + library as the default version to be shipped with g++. With the + 2.90.8 snapshot, and especially for CVS versions after this + release, this is treated as the usual scenario. If you want to + build the library all by itself, you will need to explicitly + disable certain features (like namespaces) since the core GCC + library, libgcc.a, will not be rebuilt with those same features. + +

+ +

By default, all configurations of libstdc++-v3 now have namespaces + enabled. Being able to select/de-select this option was a complex task + that had hopelessly confused many otherwise intelligent people, and + provided an endless stream of silent cursing and cries for help. + Because of this, gcc sources are required, and are no longer optional. +

+ +

The following definitions will be used throughout the rest of this + document: +

    +
  • gccsrcdir: The directory holding the source of the + compiler. It should have several subdirectories like + gccsrcdir/libio and gccsrcdir/gcc. +
  • libsrcdir: The directory holding the source of the + C++ library. +
  • gccbuilddir: The build directory for the compiler + in gccsrcdir. GCC requires that it be built in + a different directory than its sources. +
  • libbuilddir: The build directory for libstdc++. +
  • destdir: The eventual installation directory for + the compiler/libraries, set with the --prefix option to + the configure script. +
+ Note: +
    +
  1. The .8 snapshot and following are intended to replace the + library that comes with the compiler, so libsrcdir + and libbuilddir must be contained under + gccsrcdir and gccbuilddir, respectively. +
  2. The source, build, and installation directories should + not be parents of one another; i.e., these should all be + separate directories. Please don't build out of the + source directory. +
+

+ +

Since the release of libstdc++-2.90.8, configuration patches have gone + into CVS gcc that make the management of the various libstdc++ source + trees a bit easier. Because of this, both libstdc++-v2 and + libstdc++-v3 and live together more or less in peace, without the need + for soft linking. If a CVS gcc source directory after April 5, 2000 is + being used, then the directions are slightly different: please pick + which of the following two scenarios best represents your particular + situation. +

+ +

...with gcc-2.95.2 +

Unpack the gccsrcdir and go into that directory. For + instance, gcc-2.95.2 is a valid gccsrcdir. + Once in gccsrcdir, you'll need to rename the directories + called libstdc++ and libio like so: + 

+   mv libstdc++ libstdc++-v2
+   mv libio libio-v2
+

+

Next, unpack the libstdc++-v3 library tarball into the + gccsrcdir directory; it will create a + libsrcdir called libstdc++-version: + 

+   gzip -dc libstdc++-version.tar.gz | tar xf -
+

+

Finally, make a soft link between libsrcdir and + libstdc++ so that libstdc++-v3 will be the default C++ + library used. + 

+   ln -s libsrcdir libstdc++
+ This complexity of having two completely separate libstdc++ + libraries is necessary so that you can unlink libsrcdir + and update the compiler sources. If you're not this adventurous, or + would not like to switch between different C++ standard libraries, + this extra effort is probably wasted; just remove the v2 sources. +

+

+ +

...with CVS gcc +

Check out or download the gcc sources: the resulting source + directory is gccsrcdir. +

+

Next, unpack the libstdc++-v3 library tarball into this + gccsrcdir directory; it will create a + libsrcdir called libstdc++-version: + 

+   gzip -dc libstdc++-version.tar.gz | tar xf -
+

+ +

If CVS libstdc++-v3 is being used instead of a snapshot's tarball, + then move the source directory from the CVS checkout into the + gccsrcdir directory. + +

Finally, rename libsrcdir to libstdc++-v3 so that + gcc's configure flags will be able to deal with the new library. + 

+   mv libsrcdir libstdc++-v3
+

+

+ + +
+

Configuring

+

Due to namespaces, when building libstdc++-v3 you'll have to configure + the entire gccsrcdir directory. The full list of libstdc++-v3 + 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. +

+ +

...with gcc-2.95.2 + 

+   gccsrcdir/configure --prefix=destdir
+

+ +

...with CVS gcc + 

+   gccsrcdir/configure --prefix=destdir --enable-libstdcxx-v3
+

+ +

Adding --enable-libstdcxx-v3 automatically selects libstdc++-v3 + as the C++ library to be used alongside the C++ compiler being built, + and also enables -fhonor-std by default. This option is not available + with gcc-2.95.2. +

+ + +
+

Building and installing the library

+

Now you have a few options:

+

[re]building everything

+

If you're building GCC from scratch, you can do the usual + 'make bootstrap' here, and libstdc++-v3 will be built + as its default C++ library. The generated g++ will magically + use the correct headers, link against the correct library + binary, and in general using libstdc++-v3 will be a piece of + cake. You're done; run 'make install' (the GCC + Installation instructions) to put the new compiler and libraries + into place. +

+ +

[re]building only libstdc++

+

Due to differences in the configure process, the resulting Makefiles + in thegccbuilddir will have different rules depending on + the source base being used. +

+ +

...with gcc-2.95.2 +

+ libstdc++-rule is libstdc++ +
+

+ +

...with CVS gcc +

+ libstdc++-rule is libstdc++-v3 +
+

+ +

To rebuild just libstdc++, use: + 

+   make all-target-libstdc++-rule
+ This will configure and build the C++ library in the + gccbuilddir/cpu-vendor-OS/libstdc++ directory. + As en example, for CVS gcc this would be + make all-target-libstdc++-v3, and for gcc-2.95.2 it would be + make all-target-libstdc++ +

+

If the build fails with a "warning: can't inline call" + message when compiling stringMAIN.cc, see the + resolution at the end of this document. +

+

If you are rebuilding from a previous build [attempt], some + information is kept in a cache file. This is stored in + gccbuilddir/cpu-vendor-OS/ if you are building with + multilibs (the default), or in + gccbuilddir/cpu-vendor-OS/libstdc++-v3 if you have + multilibs disabled. The filename is config.cache; if previous + information is causing problems, you can delete it entirely, or + simply edit it and remove lines. +

+

You're done. Now install the rebuilt pieces with + 

+   make install
+ or + 
+   make install-gcc
+   make install-target-libstdc++-rule
+

+ + +
+

Post-installation

+

Installation will create the destdir directory and + populate it with subdirectories: + 

+   lib/
+   include/g++-v3/
+      bits/
+      backward/
+      ext/
+

+

You can check the status of the build without installing it using + 

+   make check
+ or you can check the status of the installed library using + 
+   make check-target-libstdc++-rule
+ These commands will create a 'testsuite' directory underneath + libbuilddir containing the results of the tests. We are + interested in any strange failures of the testsuite; please see + FAQ 2.4 for which files to examine. +

+ + +
+

Using the library

+
  • Find the new library at runtime (shared linking only) +

    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 -Wl,destdir/lib +
      • IRIX ld: -Wl,-rpath -Wl,destdir/lib +
      • Solaris ld: -Wl,-Rdestdir/lib +
      • More...? +
      +
    +

    +

    Use the ldd(1) utility to show which library the system + thinks it will get at runtime. +

    + +

    + + +
    +

    warning: can't inline call to...

    +

    When building the .8 snapshot with g++ 2.95.2, compilation may halt + with this warning message. The "problem" is the -Werror + flag being passed to the compiler, which says to treat warnings as + errors. (This plus a high warning level makes us track down bugs + quickly.) The compiler can't inline a certain call, prints + a warning, and dies. +

    +

    The workaround is to edit either libsrcdir/src/Makefile.in + (before configuring) or bld-libstdc++/src/Makefile + (after configuring). There's one line that reads + 

    +   WERROR = -Werror
    + Delete the flag itself, so that the line reads + 
    +   WERROR =
    + Then the compiler will still print a warning, but it won't die. +

    +

    For the curious, this "problem" is actually a symptom + of something else. The compiler in CVS could inline more than what + 2.95.2 does, and the libstdc++ changes were made with that + compiler. One of the libstdc++ maintainers explains this +here. +

    +

    This has been patched in current CVS sources. +

    + + + + + + +
    +

    +Comments and suggestions are welcome, and may be sent to +Phil Edwards or +Gabriel Dos Reis. +
    $Id: install.html,v 1.12 2000/12/03 23:47:47 jsm28 Exp $ +

    + + + + + diff --git a/libstdc++-v3/docs/html/lib3styles.css b/libstdc++-v3/docs/html/lib3styles.css new file mode 100644 index 00000000000..ee88c366cd4 --- /dev/null +++ b/libstdc++-v3/docs/html/lib3styles.css @@ -0,0 +1,6 @@ +.centered { text-align: center } +.tocheader { font-size: large } +.fineprint { font-size: x-small } +.larger { font-size: large } +BODY { background: #FFFFFF } +PRE { text-align: left ; margin-left: 1em } diff --git a/libstdc++-v3/docs/install.html b/libstdc++-v3/docs/install.html deleted file mode 100644 index 21171cb7784..00000000000 --- a/libstdc++-v3/docs/install.html +++ /dev/null @@ -1,411 +0,0 @@ - - - - - - - - libstdc++-v3 Installation Instructions - - - - - -

    libstdc++-v3 INSTALL

    - -

    The latest version of this document is always available at - - http://gcc.gnu.org/libstdc++/install.html. -

    - -

    To the libstdc++-v3 homepage. - - - -

    -

    Contents

    - - -
    - - - -

    Tools you will need beforehand

    -

    You will need a recent version of g++ to compile the snapshot of - libstdc++: gcc-2.95.2 works well, or one of the post-2.95.2 GCC - snapshots (insert standard caveat about using snapshots rather - than formal releases). You will need the full source - distribution to whatever compiler release you are using. The - GCC snapshots can be had from one of the sites on their - mirror list. -

    - -

    In addition, if you plan to modify the makefiles or regenerate - the configure scripts you'll need the nuevo automake, libtool - and autoconf to regenerate the Makefiles and configure - scripts. These tools are all required to be installed in the - same location (most linux distributions install these tools by - default, so no worries.) -

    - -

    If you don't have bash, and want to run 'make check' to - test your build, you'll need to get bash 2.x. Also recommended - is GNU Make, since it is the only 'make' that will parse these - makefiles correctly. -

    - -

    As of June 19, 2000, libstdc++ attempts to use tricky and - space-saving features of the GNU toolchain, enabled with - -ffunction-sections -fdata-sections -Wl,--gc-sections. - To obtain maximum benefit from this, binutils after this date - should also be used (bugs were fixed with C++ exception handling - related to this change in libstdc++-v3). The version of these - tools should be 2.10.90, and you can get snapshots (as - well as releases) of binutils - here. -

    - -

    Finally, a few system-specific requirements: -

    -
    Cygwin -
    If you are using Cygwin to compile libstdc++-v3 on Win32, you'll - have to get a version of the cygwin1.dll that is dated on or - after February 1, 2000. This is necessary to successfully run - the script "mknumeric_limits" which probes the - floating-point - environment of the host in question -- before this date, Cygwin - would freeze when running this script. In addition, you may - want to get a current version of libtool (say libtool-1.3.4 - and above) as earlier versions supposedly had problems creating - shared libraries. - -
    Solaris -
    We recommend installing the SUNWxcu4 package from the - Solaris CD before configuring the library. You can check for - this package as a non-privileged user with the command - "pkginfo SUNWxcu4". -
    -

    - -
    - -

    Setting up the source directories

    -

    As the libstdc++-v3 sources and the core GCC sources have - converged, more and more effort goes to building the - library as the default version to be shipped with g++. With the - 2.90.8 snapshot, and especially for CVS versions after this - release, this is treated as the usual scenario. If you want to - build the library all by itself, you will need to explicitly - disable certain features (like namespaces) since the core GCC - library, libgcc.a, will not be rebuilt with those same features. - -

    - -

    By default, all configurations of libstdc++-v3 now have namespaces - enabled. Being able to select/de-select this option was a complex task - that had hopelessly confused many otherwise intelligent people, and - provided an endless stream of silent cursing and cries for help. - Because of this, gcc sources are required, and are no longer optional. -

    - -

    The following definitions will be used throughout the rest of this - document: -

      -
    • gccsrcdir: The directory holding the source of the - compiler. It should have several subdirectories like - gccsrcdir/libio and gccsrcdir/gcc. -
    • libsrcdir: The directory holding the source of the - C++ library. -
    • gccbuilddir: The build directory for the compiler - in gccsrcdir. GCC requires that it be built in - a different directory than its sources. -
    • libbuilddir: The build directory for libstdc++. -
    • destdir: The eventual installation directory for - the compiler/libraries, set with the --prefix option to - the configure script. -
    - Note: -
      -
    1. The .8 snapshot and following are intended to replace the - library that comes with the compiler, so libsrcdir - and libbuilddir must be contained under - gccsrcdir and gccbuilddir, respectively. -
    2. The source, build, and installation directories should - not be parents of one another; i.e., these should all be - separate directories. Please don't build out of the - source directory. -
    -

    - -

    Since the release of libstdc++-2.90.8, configuration patches have gone - into CVS gcc that make the management of the various libstdc++ source - trees a bit easier. Because of this, both libstdc++-v2 and - libstdc++-v3 and live together more or less in peace, without the need - for soft linking. If a CVS gcc source directory after April 5, 2000 is - being used, then the directions are slightly different: please pick - which of the following two scenarios best represents your particular - situation. -

    - -

    ...with gcc-2.95.2 -

    Unpack the gccsrcdir and go into that directory. For - instance, gcc-2.95.2 is a valid gccsrcdir. - Once in gccsrcdir, you'll need to rename the directories - called libstdc++ and libio like so: - 

    -   mv libstdc++ libstdc++-v2
-   mv libio libio-v2
    -

    -

    Next, unpack the libstdc++-v3 library tarball into the - gccsrcdir directory; it will create a - libsrcdir called libstdc++-version: - 

    -   gzip -dc libstdc++-version.tar.gz | tar xf -
    -

    -

    Finally, make a soft link between libsrcdir and - libstdc++ so that libstdc++-v3 will be the default C++ - library used. - 

    -   ln -s libsrcdir libstdc++
    - This complexity of having two completely separate libstdc++ - libraries is necessary so that you can unlink libsrcdir - and update the compiler sources. If you're not this adventurous, or - would not like to switch between different C++ standard libraries, - this extra effort is probably wasted; just remove the v2 sources. -

    -

    - -

    ...with CVS gcc -

    Check out or download the gcc sources: the resulting source - directory is gccsrcdir. -

    -

    Next, unpack the libstdc++-v3 library tarball into this - gccsrcdir directory; it will create a - libsrcdir called libstdc++-version: - 

    -   gzip -dc libstdc++-version.tar.gz | tar xf -
    -

    - -

    If CVS libstdc++-v3 is being used instead of a snapshot's tarball, - then move the source directory from the CVS checkout into the - gccsrcdir directory. - -

    Finally, rename libsrcdir to libstdc++-v3 so that - gcc's configure flags will be able to deal with the new library. - 

    -   mv libsrcdir libstdc++-v3
    -

    -

    - - -
    -

    Configuring

    -

    Due to namespaces, when building libstdc++-v3 you'll have to configure - the entire gccsrcdir directory. The full list of libstdc++-v3 - 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. -

    - -

    ...with gcc-2.95.2 - 

    -   gccsrcdir/configure --prefix=destdir
    -

    - -

    ...with CVS gcc - 

    -   gccsrcdir/configure --prefix=destdir --enable-libstdcxx-v3
    -

    - -

    Adding --enable-libstdcxx-v3 automatically selects libstdc++-v3 - as the C++ library to be used alongside the C++ compiler being built, - and also enables -fhonor-std by default. This option is not available - with gcc-2.95.2. -

    - - -
    -

    Building and installing the library

    -

    Now you have a few options:

    -

    [re]building everything

    -

    If you're building GCC from scratch, you can do the usual - 'make bootstrap' here, and libstdc++-v3 will be built - as its default C++ library. The generated g++ will magically - use the correct headers, link against the correct library - binary, and in general using libstdc++-v3 will be a piece of - cake. You're done; run 'make install' (the GCC - Installation instructions) to put the new compiler and libraries - into place. -

    - -

    [re]building only libstdc++

    -

    Due to differences in the configure process, the resulting Makefiles - in thegccbuilddir will have different rules depending on - the source base being used. -

    - -

    ...with gcc-2.95.2 -

    - libstdc++-rule is libstdc++ -
    -

    - -

    ...with CVS gcc -

    - libstdc++-rule is libstdc++-v3 -
    -

    - -

    To rebuild just libstdc++, use: - 

    -   make all-target-libstdc++-rule
    - This will configure and build the C++ library in the - gccbuilddir/cpu-vendor-OS/libstdc++ directory. - As en example, for CVS gcc this would be - make all-target-libstdc++-v3, and for gcc-2.95.2 it would be - make all-target-libstdc++ -

    -

    If the build fails with a "warning: can't inline call" - message when compiling stringMAIN.cc, see the - resolution at the end of this document. -

    -

    If you are rebuilding from a previous build [attempt], some - information is kept in a cache file. This is stored in - gccbuilddir/cpu-vendor-OS/ if you are building with - multilibs (the default), or in - gccbuilddir/cpu-vendor-OS/libstdc++-v3 if you have - multilibs disabled. The filename is config.cache; if previous - information is causing problems, you can delete it entirely, or - simply edit it and remove lines. -

    -

    You're done. Now install the rebuilt pieces with - 

    -   make install
    - or - 
    -   make install-gcc
-   make install-target-libstdc++-rule
    -

    - - -
    -

    Post-installation

    -

    Installation will create the destdir directory and - populate it with subdirectories: - 

    -   lib/
-   include/g++-v3/
-      bits/
-      backward/
-      ext/
    -

    -

    You can check the status of the build without installing it using - 

    -   make check
    - or you can check the status of the installed library using - 
    -   make check-target-libstdc++-rule
    - These commands will create a 'testsuite' directory underneath - libbuilddir containing the results of the tests. We are - interested in any strange failures of the testsuite; please see - FAQ 2.4 for which files to examine. -

    - - -
    -

    Using the library

    -
  • Find the new library at runtime (shared linking only) -

    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 -Wl,destdir/lib -
      • IRIX ld: -Wl,-rpath -Wl,destdir/lib -
      • Solaris ld: -Wl,-Rdestdir/lib -
      • More...? -
      -
    -

    -

    Use the ldd(1) utility to show which library the system - thinks it will get at runtime. -

    - -

    - - -
    -

    warning: can't inline call to...

    -

    When building the .8 snapshot with g++ 2.95.2, compilation may halt - with this warning message. The "problem" is the -Werror - flag being passed to the compiler, which says to treat warnings as - errors. (This plus a high warning level makes us track down bugs - quickly.) The compiler can't inline a certain call, prints - a warning, and dies. -

    -

    The workaround is to edit either libsrcdir/src/Makefile.in - (before configuring) or bld-libstdc++/src/Makefile - (after configuring). There's one line that reads - 

    -   WERROR = -Werror
    - Delete the flag itself, so that the line reads - 
    -   WERROR =
    - Then the compiler will still print a warning, but it won't die. -

    -

    For the curious, this "problem" is actually a symptom - of something else. The compiler in CVS could inline more than what - 2.95.2 does, and the libstdc++ changes were made with that - compiler. One of the libstdc++ maintainers explains this -here. -

    -

    This has been patched in current CVS sources. -

    - - - - - - -
    -

    -Comments and suggestions are welcome, and may be sent to -Phil Edwards or -Gabriel Dos Reis. -
    $Id: install.html,v 1.11 2000/11/29 20:37:02 pme Exp $ -

    - - - - - diff --git a/libstdc++-v3/docs/lib3styles.css b/libstdc++-v3/docs/lib3styles.css deleted file mode 100644 index ee88c366cd4..00000000000 --- a/libstdc++-v3/docs/lib3styles.css +++ /dev/null @@ -1,6 +0,0 @@ -.centered { text-align: center } -.tocheader { font-size: large } -.fineprint { font-size: x-small } -.larger { font-size: large } -BODY { background: #FFFFFF } -PRE { text-align: left ; margin-left: 1em } -- cgit v1.2.3