From 842618f2711e7407e4c69c79301f6c9a767f9514 Mon Sep 17 00:00:00 2001 From: pme Date: Thu, 21 Nov 2002 07:16:01 +0000 Subject: [PATCH] 2002-11-21 Phil Edwards * docs/doxygen/style.css: Update. * docs/doxygen/user.cfg.in: Update. * docs/html/documentation.html: Regenerate. * docs/html/17_intro/howto.html: Tweak I/O sentry entry. * docs/html/27_io/howto.html: New section on headers. * docs/html/faq/index.html: Add i386 threading entry. * docs/html/faq/index.txt: Regenerate. * docs/html/ext/lwg-active.html, docs/html/ext/lwg-defects.html: Import R23. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@59326 138bc75d-0d04-0410-961f-82ee72b054a4 --- libstdc++-v3/ChangeLog | 13 + libstdc++-v3/docs/doxygen/style.css | 45 +- libstdc++-v3/docs/doxygen/user.cfg.in | 157 +++++- libstdc++-v3/docs/html/17_intro/howto.html | 5 +- libstdc++-v3/docs/html/27_io/howto.html | 133 +++++ libstdc++-v3/docs/html/documentation.html | 3 +- libstdc++-v3/docs/html/ext/lwg-active.html | 784 ++++++++++++++++++++++++-- libstdc++-v3/docs/html/ext/lwg-defects.html | 264 ++++----- libstdc++-v3/docs/html/faq/index.html | 15 +- libstdc++-v3/docs/html/faq/index.txt | 832 ++++++++++++++-------------- 10 files changed, 1641 insertions(+), 610 deletions(-) diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog index 4811878..7135c13 100644 --- a/libstdc++-v3/ChangeLog +++ b/libstdc++-v3/ChangeLog @@ -1,5 +1,18 @@ 2002-11-21 Phil Edwards + * docs/doxygen/style.css: Update. + * docs/doxygen/user.cfg.in: Update. + * docs/html/documentation.html: Regenerate. + * docs/html/17_intro/howto.html: Tweak I/O sentry entry. + * docs/html/27_io/howto.html: New section on headers. + * docs/html/faq/index.html: Add i386 threading entry. + * docs/html/faq/index.txt: Regenerate. + + * docs/html/ext/lwg-active.html, docs/html/ext/lwg-defects.html: + Import R23. + +2002-11-21 Phil Edwards + * docs/doxygen/TODO: Note change in clause 27 docs. * include/bits/basic_ios.h, include/bits/fpos.h, include/bits/ios_base.h, include/bits/stl_deque.h, diff --git a/libstdc++-v3/docs/doxygen/style.css b/libstdc++-v3/docs/doxygen/style.css index 5e43005..e527a57 100644 --- a/libstdc++-v3/docs/doxygen/style.css +++ b/libstdc++-v3/docs/doxygen/style.css @@ -1,4 +1,5 @@ H1 { text-align: center; } +CAPTION { font-weight: bold } A.qindex {} A.qindexRef {} A.el { text-decoration: none; font-weight: bold } @@ -10,15 +11,39 @@ DL.el { margin-left: -1cm } DIV.fragment { width: 100%; border: none; background-color: #eeeeee } DIV.ah { background-color: black; font-weight: bold; color: #ffffff; margin-bottom: 3px; margin-top: 3px } TD.md { background-color: #f2f2ff; font-weight: bold; } -TD.mdname1 { background-color: #f2f2ff; font-weight: bold; font-style: italic; } -TD.mdname { background-color: #f2f2ff; font-weight: bold; font-style: italic; width: 600px; } +TD.mdname1 { background-color: #f2f2ff; font-weight: bold; color: #602020; } +TD.mdname { background-color: #f2f2ff; font-weight: bold; color: #602020; width: 600px; } DIV.groupHeader { margin-left: 16px; margin-top: 12px; margin-bottom: 6px; font-weight: bold } DIV.groupText { margin-left: 16px; font-style: italic; font-size: smaller } -FONT.keyword { color: #008000 } -FONT.keywordtype { color: #604020 } -FONT.keywordflow { color: #e08000 } -FONT.comment { color: #800000 } -FONT.preprocessor { color: #806020 } -FONT.stringliteral { color: #002080 } -FONT.charliteral { color: #008080 } -.smallertext { font-size: smaller } +BODY { background: white } +TD.indexkey { + background-color: #eeeeff; + font-weight: bold; + padding-right : 10px; + padding-top : 2px; + padding-left : 10px; + padding-bottom : 2px; + margin-left : 0px; + margin-right : 0px; + margin-top : 2px; + margin-bottom : 2px +} +TD.indexvalue { + background-color: #eeeeff; + font-style: italic; + padding-right : 10px; + padding-top : 2px; + padding-left : 10px; + padding-bottom : 2px; + margin-left : 0px; + margin-right : 0px; + margin-top : 2px; + margin-bottom : 2px +} +span.keyword { color: #008000 } +span.keywordtype { color: #604020 } +span.keywordflow { color: #e08000 } +span.comment { color: #800000 } +span.preprocessor { color: #806020 } +span.stringliteral { color: #002080 } +span.charliteral { color: #008080 } diff --git a/libstdc++-v3/docs/doxygen/user.cfg.in b/libstdc++-v3/docs/doxygen/user.cfg.in index dff2f3f..966d6e8 100644 --- a/libstdc++-v3/docs/doxygen/user.cfg.in +++ b/libstdc++-v3/docs/doxygen/user.cfg.in @@ -1,4 +1,4 @@ -# Doxyfile 1.2.12 +# Doxyfile 1.2.18 # This file describes the settings to be used by the documentation system # doxygen (www.doxygen.org) for a project @@ -43,9 +43,11 @@ OUTPUT_DIRECTORY = @outdir@ # documentation generated by doxygen is written. Doxygen will use this # information to generate all constant output in the proper language. # The default language is English, other supported languages are: -# Brazilian, Chinese, Croatian, Czech, Danish, Dutch, Finnish, French, -# German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, -# Portuguese, Romanian, Russian, Slovak, Slovene, Spanish and Swedish. +# Brazilian, Catalan, Chinese, Chinese-Traditional, Croatian, Czech, Danish, Dutch, +# Finnish, French, German, Greek, Hungarian, Italian, Japanese, Japanese-en +# (Japanese with english messages), Korean, Norwegian, Polish, Portuguese, +# Romanian, Russian, Serbian, Slovak, Slovene, Spanish, Swedish and Ukrainian. + OUTPUT_LANGUAGE = English @@ -66,6 +68,12 @@ EXTRACT_PRIVATE = YES EXTRACT_STATIC = YES +# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs) +# defined locally in source files will be included in the documentation. +# If set to NO only classes defined in header files are included. + +EXTRACT_LOCAL_CLASSES = NO + # If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all # undocumented members of documented classes, files or namespaces. # If set to NO (the default) these members will be included in the @@ -81,6 +89,13 @@ HIDE_UNDOC_MEMBERS = YES HIDE_UNDOC_CLASSES = YES +# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all +# friend (class|struct|union) declarations. +# If set to NO (the default) these declarations will be included in the +# documentation. + +HIDE_FRIEND_COMPOUNDS = NO + # If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will # include brief member descriptions after the members that are listed in # the file and class documentation (similar to JavaDoc). @@ -101,6 +116,14 @@ REPEAT_BRIEF = YES ALWAYS_DETAILED_SEC = YES +# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all inherited +# members of a class in the documentation of that class as if those members were +# ordinary class members. Constructors, destructors and assignment operators of +# the base classes will not be shown. + +INLINE_INHERITED_MEMB = NO +# pedwards -- this is useful, but ch27 gets huge + # If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full # path before files name in the file list and in the header files. If set # to NO the shortest path that makes the file name unique will be used. @@ -167,6 +190,21 @@ SHOW_INCLUDE_FILES = YES JAVADOC_AUTOBRIEF = NO +# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen +# treat a multi-line C++ special comment block (i.e. a block of //! or /// +# comments) as a brief description. This used to be the default behaviour. +# The new default is to treat a multi-line C++ comment block as a detailed +# description. Set this tag to YES if you prefer the old behaviour instead. + +MULTILINE_CPP_IS_BRIEF = YES + +# If the DETAILS_AT_TOP tag is set to YES then Doxygen +# will output the detailed description near the top, like JavaDoc. +# If set to NO, the detailed description appears after the member +# documentation. + +DETAILS_AT_TOP = NO + # If the INHERIT_DOCS tag is set to YES (the default) then an undocumented # member inherits the documentation from any documented member that it # reimplements. @@ -183,7 +221,7 @@ INLINE_INFO = YES # alphabetically by member name. If set to NO the members will appear in # declaration order. -SORT_MEMBER_DOCS = NO +SORT_MEMBER_DOCS = YES # If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC # tag is set to YES, then doxygen will reuse the documentation of the first @@ -215,6 +253,12 @@ GENERATE_TESTLIST = NO GENERATE_BUGLIST = YES +# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or +# disable (NO) the deprecated list. This list is created by putting +# \deprecated commands in the documentation. + +GENERATE_DEPRECATEDLIST= YES + # This tag can be used to specify a number of aliases that acts # as commands in the documentation. An alias has the form "name=value". # For example adding "sideeffect=\par Side Effects:\n" will allow you to @@ -222,7 +266,8 @@ GENERATE_BUGLIST = YES # will result in a user defined paragraph with heading "Side Effects:". # You can put \n's in the value part of an alias to insert newlines. -ALIASES = "doctodo=@todo\nDoc me! See docs/doxygen/TODO and http://gcc.gnu.org/ml/libstdc++/2002-02/msg00003.html for more." +ALIASES = "doctodo=@todo\nDoc me! See docs/doxygen/TODO and http://gcc.gnu.org/ml/libstdc++/2002-02/msg00003.html for more." \ +"isiosfwd=One of the @link s27_2_iosfwd I/O forward declarations @endlink" # The ENABLED_SECTIONS tag can be used to enable conditional # documentation sections, marked by \if sectionname ... \endif. @@ -237,7 +282,7 @@ ENABLED_SECTIONS = @enabled_sections@ # documentation can be controlled using \showinitializer or \hideinitializer # command in the documentation regardless of this setting. -MAX_INITIALIZER_LINES = 30 +MAX_INITIALIZER_LINES = 0 # Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources # only. Doxygen will then generate output that is more tailored for C. @@ -246,6 +291,13 @@ MAX_INITIALIZER_LINES = 30 OPTIMIZE_OUTPUT_FOR_C = NO +# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java sources +# only. Doxygen will then generate output that is more tailored for Java. +# For instance namespaces will be presented as packages, qualified scopes +# will look different, etc. + +OPTIMIZE_OUTPUT_JAVA = NO + # Set the SHOW_USED_FILES tag to NO to disable the list of files generated # at the bottom of the documentation of classes and structs. If set to YES the # list will mention the files that were used to generate the documentation. @@ -325,12 +377,18 @@ RECURSIVE = YES EXCLUDE = Makefile CVS +# The EXCLUDE_SYMLINKS tag can be used select whether or not files or directories +# that are symbolic links (a Unix filesystem feature) are excluded from the input. + +EXCLUDE_SYMLINKS = NO + # If the value of the INPUT tag contains directories, you can use the # EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude # certain files from those directories. EXCLUDE_PATTERNS = CVS \ - stamp-* + stamp-* \ + Makefile # The EXAMPLE_PATH tag can be used to specify one or more files or # directories that contain example code fragments that are included (see @@ -369,7 +427,7 @@ INPUT_FILTER = # If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using # INPUT_FILTER) will be used to filter the input files when producing source -# files to browse. +# files to browse (i.e. when SOURCE_BROWSER is set to YES). FILTER_SOURCE_FILES = NO @@ -437,6 +495,12 @@ GENERATE_HTML = @do_html@ HTML_OUTPUT = @html_output_dir@ +# The HTML_FILE_EXTENSION tag can be used to specify the file extension for +# each generated HTML page (for example: .htm,.php,.asp). If it is left blank +# doxygen will generate files with .html extension. + +HTML_FILE_EXTENSION = .html + # The HTML_HEADER tag can be used to specify a personal HTML header for # each generated HTML page. If it is left blank doxygen will generate a # standard header. @@ -469,6 +533,20 @@ HTML_ALIGN_MEMBERS = YES GENERATE_HTMLHELP = NO +# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can +# be used to specify the file name of the resulting .chm file. You +# can add a path in front of the file if the result should not be +# written to the html output dir. + +CHM_FILE = + +# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can +# be used to specify the location (absolute path including file name) of +# the HTML help compiler (hhc.exe). If non empty doxygen will try to run +# the html help compiler on the generated index.hhp. + +HHC_LOCATION = + # If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag # controls if a separate .chi index file is generated (YES) or that # it should be included in the master .chm file (NO). @@ -528,6 +606,17 @@ GENERATE_LATEX = NO LATEX_OUTPUT = latex +# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to +# be invoked. If left blank `latex' will be used as the default command name. + +LATEX_CMD_NAME = latex + +# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to +# generate index for LaTeX. If left blank `makeindex' will be used as the +# default command name. + +MAKEINDEX_CMD_NAME = makeindex + # If the COMPACT_LATEX tag is set to YES Doxygen generates more compact # LaTeX documents. This may be useful for small projects and may help to # save some trees in general. @@ -654,6 +743,30 @@ MAN_LINKS = NO GENERATE_XML = NO +# The XML_SCHEMA tag can be used to specify an XML schema, +# which can be used by a validating XML parser to check the +# syntax of the XML files. + +XML_SCHEMA = + +# The XML_DTD tag can be used to specify an XML DTD, +# which can be used by a validating XML parser to check the +# syntax of the XML files. + +XML_DTD = + +#--------------------------------------------------------------------------- +# configuration options for the AutoGen Definitions output +#--------------------------------------------------------------------------- + +# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will +# generate an AutoGen Definitions (see autogen.sf.net) file +# that captures the structure of the code including all +# documentation. Note that this feature is still experimental +# and incomplete at the moment. + +GENERATE_AUTOGEN_DEF = NO + #--------------------------------------------------------------------------- # Configuration options related to the preprocessor #--------------------------------------------------------------------------- @@ -707,6 +820,8 @@ INCLUDE_FILE_PATTERNS = ### completely broken, and the presence of the macros confuses the parser. PREDEFINED = _GLIBCPP_DEPRECATED \ + _GLIBCPP_USE_WCHAR_T \ + _GLIBCPP_USE_LONG_LONG \ __glibcpp_class_requires="//" \ __glibcpp_class_requires2="//" \ __glibcpp_class_requires3="//" \ @@ -745,6 +860,12 @@ GENERATE_TAGFILE = ALLEXTERNALS = YES +# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed +# in the modules index. If set to NO, only the current project's groups will +# be listed. + +EXTERNAL_GROUPS = YES + # The PERL_PATH should be the absolute path and name of the perl script # interpreter (i.e. the result of `which perl'). @@ -762,6 +883,12 @@ PERL_PATH = /usr/bin/perl CLASS_DIAGRAMS = YES +# If set to YES, the inheritance and collaboration graphs will hide +# inheritance and usage relations if the target is undocumented +# or is not a class. + +HIDE_UNDOC_RELATIONS = YES + # If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is # available from the path. This tool is part of Graphviz, a graph visualization # toolkit from AT&T and Lucent Bell Labs. The other options in this section @@ -788,12 +915,6 @@ COLLABORATION_GRAPH = YES TEMPLATE_RELATIONS = YES -# If set to YES, the inheritance and collaboration graphs will hide -# inheritance and usage relations if the target is undocumented -# or is not a class. - -HIDE_UNDOC_RELATIONS = YES - # If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT # tags are set to YES then doxygen will generate a graph for each documented # file showing the direct and indirect include dependencies of the file with @@ -813,6 +934,12 @@ INCLUDED_BY_GRAPH = YES GRAPHICAL_HIERARCHY = YES +# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images +# generated by dot. Possible values are png, jpg, or gif +# If left blank png will be used. + +DOT_IMAGE_FORMAT = png + # The tag DOT_PATH can be used to specify the path where the dot tool can be # found. If left blank, it is assumed the dot tool can be found on the path. diff --git a/libstdc++-v3/docs/html/17_intro/howto.html b/libstdc++-v3/docs/html/17_intro/howto.html index 5888a54..9d10bec 100644 --- a/libstdc++-v3/docs/html/17_intro/howto.html +++ b/libstdc++-v3/docs/html/17_intro/howto.html @@ -261,8 +261,9 @@ on the --enable-libio choice: for stdio, if the written data is already in the stdio buffer, the data may be completely safe!

-

I/O sentry ctor/dtor They can perform additional work - than the minimum required. I don't think we're currently taking +

[27.6.1.1.2],
+ [27.6.2.3] The I/O sentry ctor and dtor can perform + additional work than the minimum required. We are not currently taking advantage of this yet.

[27.7.1.3]/16,
diff --git a/libstdc++-v3/docs/html/27_io/howto.html b/libstdc++-v3/docs/html/27_io/howto.html index b4a5925..d7a984e 100644 --- a/libstdc++-v3/docs/html/27_io/howto.html +++ b/libstdc++-v3/docs/html/27_io/howto.html @@ -34,6 +34,7 @@

  • More on binary I/O
  • Pathetic performance? Ditch C.
  • Threads and I/O
    • +
  • Which header?
    • @@ -558,6 +559,138 @@ "interesting" problems.

    +
    +

    Which header?

    +

    To minimize the time you have to wait on the compiler, it's good to + only include the headers you really need. Many people simply include + <iostream> when they don't need to -- and that can penalize + your runtime as well. Here are some tips on which header to use + for which situations, starting with the simplest. +

    +

    <iosfwd> should be included whenever you simply + need the name of an I/O-related class, such as + "ofstream" or "basic_streambuf". Like the name + implies, these are forward declarations. (A word to all you fellow + old school programmers: trying to forward declare classes like + "class istream;" won't work. Look in the iosfwd header if + you'd like to know why.) For example, +

    + 
    +    #include <iosfwd>
+
+    class MyClass
+    {
+        ....
+        std::ifstream   input_file;
+    };
+
+    extern std::ostream& operator<< (std::ostream&, MyClass&);
+
    +

    <ios> declares the base classes for the entire + I/O stream hierarchy, std::ios_base and std::basic_ios<charT>, the + counting types std::streamoff and std::streamsize, the file + positioning type std::fpos, and the various manipulators like + std::hex, std::fixed, std::noshowbase, and so forth. +

    +

    The ios_base class is what holds the format flags, the state flags, + and the functions which change them (setf(), width(), precision(), + etc). You can also store extra data and register callback functions + through ios_base, but that has been historically underused. Anything + which doesn't depend on the type of characters stored is consolidated + here. +

    +

    The template class basic_ios is the highest template class in the + hierarchy; it is the first one depending on the character type, and + holds all general state associated with that type: the pointer to the + polymorphic stream buffer, the facet information, etc. +

    +

    <streambuf> declares the template class + basic_streambuf, and two standard instantiations, streambuf and + wstreambuf. If you need to work with the vastly useful and capable + stream buffer classes, e.g., to create a new form of storage + transport, this header is the one to include. +

    +

    <istream>/<ostream> are + the headers to include when you are using the >>/<< + interface, or any of the other abstract stream formatting functions. + For example, +

    + 
    +    #include <istream>
+
+    std::ostream& operator<< (std::ostream& os, MyClass& c)
+    {
+       return os << c.data1() << c.data2();
+    }
+
    +

    The std::istream and std::ostream classes are the abstract parents of + the various concrete implementations. If you are only using the + interfaces, then you only need to use the appropriate interface header. +

    +

    <iomanip> provides "extractors and inserters + that alter information maintained by class ios_base and its dervied + classes," such as std::setprecision and std::setw. If you need + to write expressions like os << setw(3); or + is >> setbase(8);, you must include <iomanip>. +

    +

    <sstream>/<fstream> + declare the six stringstream and fstream classes. As they are the + standard concrete descendants of istream and ostream, you will already + know about them. +

    +

    Finally, <iostream> provides the eight standard + global objects (cin, cout, etc). To do this correctly, this header + also provides the contents of the <istream> and <ostream> + headers, but nothing else. The contents of this header look like +

    + 
    +    #include <ostream>
+    #include <istream>
+
+    namespace std
+    {
+        extern istream cin;
+        extern ostream cout;
+        ....
+
+        // this is explained below
+        static ios_base::Init __foo;    // not its real name
+    }
+
    +

    Now, the runtime penalty mentioned previously: the global objects + must be initialized before any of your own code uses them; this is + guaranteed by the standard. Like any other global object, they must + be initialized once and only once. This is typically done with a + construct like the one above, and the nested class ios_base::Init is + specified in the standard for just this reason. +

    +

    How does it work? Because the header is included before any of your + code, the __foo object is constructed before any of + your objects. (Global objects are built in the order in which they + are declared, and destroyed in reverse order.) The first time the + constructor runs, the eight stream objects are set up. +

    +

    The static keyword means that each object file compiled + from a source file containing <iostream> will have its own + private copy of __foo. There is no specified order + of construction across object files (it's one of those pesky NP + problems that make life so interesting), so one copy in each object + file means that the stream objects are guaranteed to be set up before + any of your code which uses them could run, thereby meeting the + requirements of the standard. +

    +

    The penalty, of course, is that after the first copy of + __foo is constructed, all the others are just wasted + processor time. The time spent is merely for an increment-and-test + inside a function call, but over several dozen or hundreds of object + files, that time can add up. (It's not in a tight loop, either.) +

    +

    The lesson? Only include <iostream> when you need to use one of + the standard objects in that source file; you'll pay less startup + time. Only include the header files you need to in general; your + compile times will go down when there's less parsing work to do. +

    + diff --git a/libstdc++-v3/docs/html/documentation.html b/libstdc++-v3/docs/html/documentation.html index a4a79e3..8c40fb0 100644 --- a/libstdc++-v3/docs/html/documentation.html +++ b/libstdc++-v3/docs/html/documentation.html @@ -66,7 +66,7 @@ diff --git a/libstdc++-v3/docs/html/ext/lwg-active.html b/libstdc++-v3/docs/html/ext/lwg-active.html index c8d33f3..a69d6c6 100644 --- a/libstdc++-v3/docs/html/ext/lwg-active.html +++ b/libstdc++-v3/docs/html/ext/lwg-active.html @@ -5,11 +5,11 @@ - + - + @@ -17,10 +17,10 @@ - +
    Doc. no.J16/02-0027 = WG21 N1369J16/02-0048 = WG21 N1390
    Date:10 May 200210 Sep 2002
    Project:
    Reply to:Matt Austern <austern@research.att.com>Matt Austern <austern@apple.com>
    -

    C++ Standard Library Active Issues List (Revision 22)

    +

    C++ Standard Library Active Issues List (Revision 23)

    Reference ISO/IEC IS 14882:1998(E)

    Also see:

      @@ -78,7 +78,7 @@

      Public information as to how to obtain a copy of the C++ Standard, join the standards committee, submit an issue, or comment on an issue can be found in the C++ FAQ at http://www.research.att.com/~austern/csc/faq.html. - Public discussion of C++ Standard related issues occurs on news:comp.std.c++. + Public discussion of C++ Standard related issues occurs on news:comp.std.c++.

      For committee members, files available on the committee's private @@ -88,6 +88,10 @@ directory as the issues list files.

      Revision History

        +
      • R23: +Pre-Santa Cruz mailing. Added new issues 367-382. +Moved issues in the TC to TC status. +
      • R22: Post-Curaçao mailing. Added new issues 362-366.
        • @@ -1486,7 +1490,7 @@ specified. Both resolutions are consistent with the behavior of existing implementations.

        225. std:: algorithms use of other unqualified algorithms

        -Section: 17.4.4.3 [lib.global.functions]  Status: Open  Submitter: Dave Abrahams  Date: 01 Apr 2000

        +Section: 17.4.4.3 [lib.global.functions]  Status: Review  Submitter: Dave Abrahams  Date: 01 Apr 2000

        Are algorithms in std:: allowed to use other algorithms without qualification, so functions in user namespaces might be found through Koenig lookup?

        For example, a popular standard library implementation includes this @@ -1586,13 +1590,14 @@ should have any effect.]

        [Curaçao: An LWG-subgroup spent an afternoon working on issues 225, 226, and 229. Their conclusion was that the issues should be -separated into an LWG portion (Howard will write a proposal), and a +separated into an LWG portion (Howard's paper, N1387=02-0045), and a EWG portion (Dave will write a proposal). The LWG and EWG had -(separate) discussions of this plan the next day.]

        +(separate) discussions of this plan the next day. The proposed +resolution for this issue is in accordance with Howard's paper.]

        226. User supplied specializations or overloads of namespace std function templates

        -Section: 17.4.3.1 [lib.reserved.names]  Status: Open  Submitter: Dave Abrahams  Date: 01 Apr 2000

        +Section: 17.4.3.1 [lib.reserved.names]  Status: Review  Submitter: Dave Abrahams  Date: 01 Apr 2000

        The issues are: 

        1. How can a 3rd party library implementor (lib1) write a version of a standard algorithm which is specialized to work with his own class template? 

        @@ -1677,6 +1682,9 @@ not provide an operator<< for std::pair<>.

        Proposed resolution:

        +

        Adopt the wording in the Customization Points section of +Howard Hinnant's paper, N1387=02-0045.

        +

        [Tokyo: Summary, "There is no conforming way to extend std::swap for user defined templates."  The LWG agrees that there is a problem.  Would like more information before @@ -1734,13 +1742,14 @@ try to put together a proposal before the next meeting.]

        [Curaçao: An LWG-subgroup spent an afternoon working on issues 225, 226, and 229. Their conclusion was that the issues should be -separated into an LWG portion (Howard will write a proposal), and a +separated into an LWG portion (Howard's paper, N1387=02-0045), and a EWG portion (Dave will write a proposal). The LWG and EWG had -(separate) discussions of this plan the next day.]

        +(separate) discussions of this plan the next day. The proposed +resolution is the one proposed by Howard.]

        229. Unqualified references of other library entities

        -Section: 17.4.1.1 [lib.contents]  Status: Open  Submitter: Steve Clamage  Date: 19 Apr 2000

        +Section: 17.4.1.1 [lib.contents]  Status: Review  Submitter: Steve Clamage  Date: 19 Apr 2000

        Throughout the library chapters, the descriptions of library entities refer to other library entities without necessarily qualifying the names.

        @@ -1784,13 +1793,15 @@ but that the wording may not be clear enough to fall under

        [Curaçao: An LWG-subgroup spent an afternoon working on issues 225, 226, and 229. Their conclusion was that the issues should be -separated into an LWG portion (Howard will write a proposal), and a +separated into an LWG portion (Howard's paper, N1387=02-0045), and a EWG portion (Dave will write a proposal). The LWG and EWG had -(separate) discussions of this plan the next day.]

        +(separate) discussions of this plan the next day. This paper resolves +issues 225 and 226. In light of that resolution, the proposed +resolution for the current issue makes sense.]

        231. Precision in iostream?

        -Section: 22.2.2.2.2 [lib.facet.num.put.virtuals]  Status: Open  Submitter: James Kanze, Stephen Clamage  Date:  25 Apr 2000

        +Section: 22.2.2.2.2 [lib.facet.num.put.virtuals]  Status: Review  Submitter: James Kanze, Stephen Clamage  Date:  25 Apr 2000

        What is the following program supposed to output?

        #include <iostream>
 
@@ -1831,24 +1842,31 @@ etc. Plus, of course, if precision == 0 and flags & floatfield ==
 of the anomalies of printf:-).
        
 
        Proposed resolution:
        
 
        
-In 22.2.2.2.2  [lib.facet.num.put.virtuals], paragraph 11, change 
-"if (flags & fixed) != 0" to 
-"if (flags & floatfield) == fixed ||
-        (flags & floatfield) == scientific"
+Replace 22.2.2.2.2  [lib.facet.num.put.virtuals], paragraph 11, with the following 
+sentence:
 
        
+
        
+For conversion from a floating-point type,
+str.precision() is specified in the conversion
+specification.
+
        
 
        Rationale:
        
 
        The floatfield determines whether numbers are formatted as if
 with %f, %e, or %g.  If the fixed bit is set, it's %f,
 if scientific it's %e, and if both bits are set, or 
-neither, it's %e.
        
+neither, it's %g.
        
 
        Turning to the C standard, a precision of 0 is meaningful
-for %f and %e, but not for %g: for %g, precision 0 is taken
-to be the same as precision 1.
        
-
        The proposed resolution has the effect that the output of
-the above program will be "1e+00".
        
-
-
        [Curaçao: Howard will send Matt improved wording dealing with
-case not covered by current PR.]
        
+for %f and %e.  For %g, precision 0 is taken to be the same as 
+precision 1.
        
+
        The proposed resolution has the effect that if neither
+fixed nor scientific is set we'll be
+specifying a precision of 0, which will be internally
+turned into 1.  There's no need to call it out as a special
+case.
        
+
        The output of the above program will be "1e+00".
        
+
+
        [Post-Curaçao: Howard provided improved wording covering the case
+where precision is 0 and mode is %g.]
        
 
 
        
 
        233. Insertion hints in associative containers
        
@@ -2354,6 +2372,28 @@ throw, the string must compare equal to the argument.
 
        (Not all of these options are mutually exclusive.)
        
 
 
        Proposed resolution:
        
+
        NAD/Future
        
+
        Rationale:
        
+
+
        Throwing a bad_alloc while trying to construct a message for another
+exception-derived class is not necessarily a bad thing.  And the
+bad_alloc constructor already has a no throw spec on it (18.4.2.1).
        
+
+
        
+The copy constructors of all exception-derived classes already have a
+no throw spec.  Reference 18.6.1,  19.1 and 15.4/13.
+
        
+
+
        Future:
        
+
+
        All involved would like to see const char* constructors added, but
+this should probably be done for C++0X as opposed to a DR.
        
+
+
        I believe the no throw specs currently decorating these functions
+could be improved by some kind of static no throw spec checking
+mechanism (in a future C++ language).  As they stand, the copy
+constructors might fail via a call to unexpected.  I think what is
+intended here is that the copy constructors can't fail.
        
 
 
        [Toronto: some LWG members thought this was merely a QoI issue,
 but most believed that it was at least a borderline defect.  There was
@@ -2361,11 +2401,9 @@ more support for nonnormative advice to implementors than for a
 normative change.]
        
 
 
        [Redmond: discussed, without definite conclusion.  Most LWG
-members thought there was a real defect lurking here.  A small group
-(Herb, Kevlin, Howard, Martin, Dave) will try to make a
-recommendation.]
        
-
-
        [Curaçao: Howard will nag the others to work on a recommendation.]
        
+members thought there was a real defect lurking here.  The above
+proposed resolution/rationale is from Howard, Herb, Kevlin,  Martin,
+and Dave.]
        
 
 
        
 
        258. Missing allocator requirement
        
@@ -2553,7 +2591,7 @@ desirable to provide this feature in a different way.
 
 
        
 
        282. What types does numpunct grouping refer to?
        
-Section: 22.2.2.2.2  [lib.facet.num.put.virtuals]  Status: Open  Submitter: Howard Hinnant  Date: 5 Dec 2000
        
+Section: 22.2.2.2.2  [lib.facet.num.put.virtuals]  Status: Review  Submitter: Howard Hinnant  Date: 5 Dec 2000
        
 
        
 Paragraph 16 mistakenly singles out integral types for inserting 
 thousands_sep() characters.  This conflicts with the syntax for floating 
@@ -2593,8 +2631,8 @@ floating-point input even though this is unambiguously required by the
 standard.
 ]
        
 
-
        [Curaçao: Howard will email Bill and other implementors to try to
-move the issue forward.]
        
+
        [Post-Curaçao: the above proposed resolution is the consensus of
+Howard, Bill, Pete, Benjamin, Nathan, Dietmar, Boris, and Martin.]
        
 
 
        
 
        283. std::replace() requirement incorrect/insufficient
        
@@ -3099,22 +3137,42 @@ note in p24 (below) is that x be empty after the merge which is surely
 unintended in this case.
 
        
 
        Proposed resolution:
        
+
        In 23.2.2.4  [lib.list.ops], replace paragraps 23-25 with:
        
+
        
 
        
-Change 23.2.2.4, p23 to:
+23 Effects: if (&x == this) does nothing; otherwise, merges the two
+sorted ranges [begin(), end()) and [x.begin(), x.end()).  The result
+is a range in which the elements will be sorted in non-decreasing
+order according to the ordering defined by comp; that is, for every
+iterator i in the range other than the first, the condition comp(*i,
+*(i - 1)) will be false.
 
        
-
        
-Effects: If &x == this, does nothing; otherwise, merges the
-argument list into the list.
+
+
        
+24 Notes: Stable: if (&x != this), then for equivalent elements in the
+two original ranges, the elements from the original range [begin(),
+end()) always precede the elements from the original range [x.begin(),
+x.end()).  If (&x != this) the range [x.begin(), x.end()) is empty
+after the merge.
+
        
+
+
        
+25 Complexity: At most size() + x.size() - 1 applications of comp if
+(&x !  = this); otherwise, no applications of comp are performed.  If
+an exception is thrown other than by a comparison there are no
+effects.
+
        
+
 
        
 
-
        [Copenhagen: The proposed resolution does not fix all of the
-problems in 23.2.2.4  [lib.list.ops], p22-25.  Three different
+
        [Copenhagen: The original proposed resolution did not fix all of
+the problems in 23.2.2.4  [lib.list.ops], p22-25.  Three different
 paragraphs (23, 24, 25) describe the effects of merge.
 Changing p23, without changing the other two, appears to introduce
 contradictions.  Additionally, "merges the argument list into the
 list" is excessively vague.]
        
 
-
        [Curaçao: Robert Klarer volunteers to work on this issue.]
        
+
        [Post-Curaçao: Robert Klarer provided new wording.]
        
 
 
        
 
        304. Must *a return an lvalue when a is an input iterator?
        
@@ -5283,6 +5341,648 @@ rationale.
   basic_filebuf<charT,traits>* rdbuf();
   const basic_filebuf<charT,traits>* rdbuf() const;
        +
        +

        367. remove_copy/remove_copy_if and Input Iterators

        +Section: 25.2.7 [lib.alg.remove]  Status: New  Submitter: Anthony Williams  Date: 13 May 2002

        +

        +remove_copy and remove_copy_if (25.2.7 [lib.alg.remove]) permit their +input range to be marked with Input Iterators. However, since two +operations are required against the elements to copy (comparison and +assigment), when the input range uses Input Iterators, a temporary +copy must be taken to avoid dereferencing the iterator twice. This +therefore requires the value type of the InputIterator to be +CopyConstructible. If the iterators are at least Forward Iterators, +then the iterator can be dereferenced twice, or a reference to the +result maintained, so the temporary is not required. +

        +

        Proposed resolution:

        +

        +Add "If InputIterator does not meet the requirements of forward +iterator, then the value type of InputIterator must be copy +constructible. Otherwise copy constructible is not required." to +25.2.7 [lib.alg.remove] paragraph 6. +

        +
        +

        368. basic_string::replace has two "Throws" paragraphs

        +Section: 21.3.5.6 [lib.string::replace]  Status: New  Submitter: Beman Dawes  Date: 3 Jun 2002

        +

        +21.3.5.6 [lib.string::replace] basic_string::replace, second +signature, given in paragraph 1, has two "Throws" paragraphs (3 and +5). +

        + +

        +In addition, the second "Throws" paragraph (5) includes specification +(beginning with "Otherwise, the function replaces ...") that should be +part of the "Effects" paragraph. +

        +

        Proposed resolution:

        +
        +

        369. io stream objects and static ctors

        +Section: 27.3 [lib.iostream.objects]  Status: New  Submitter: Ruslan Abdikeev  Date: 8 Jul 2002

        +

        +Is it safe to use standard iostream objects from constructors of +static objects? Are standard iostream objects constructed and are +their associations established at that time? +

        + +

        Surpisingly enough, Standard does NOT require that.

        + +

        +27.3/2 [lib.iostream.objects] guarantees that standard iostream +objects are constructed and their associations are established before +the body of main() begins execution. It also refers to ios_base::Init +class as the panacea for constructors of static objects. +

        + +

        +However, there's nothing in 27.3 [lib.iostream.objects], +in 27.4.2 [lib.ios.base], and in 27.4.2.1.6 [lib.ios::Init], +that would require implementations to allow access to standard +iostream objects from constructors of static objects. +

        + +

        Details:

        + +

        Core text refers to some magic object ios_base::Init, which will +be discussed below:

        + +
        + "The [standard iostream] objects are constructed, and their + associations are established at some time prior to or during + first time an object of class basic_ios<charT,traits>::Init + is constructed, and in any case before the body of main + begins execution." (27.3/2 [lib.iostream.objects]) +
        + +

        +The first non-normative footnote encourages implementations +to initialize standard iostream objects earlier than required. +

        + +

        However, the second non-normative footnote makes an explicit +and unsupported claim:

        + +
        + "Constructors and destructors for static objects can access these + [standard iostream] objects to read input from stdin or write output + to stdout or stderr." (27.3/2 footnote 265 [lib.iostream.objects]) +
        + +

        +The only bit of magic is related to that ios_base::Init class. AFAIK, +the rationale behind ios_base::Init was to bring an instance of this +class to each translation unit which #included <iostream> or +related header. Such an inclusion would support the claim of footnote +quoted above, because in order to use some standard iostream object it +is necessary to #include <iostream>. +

        + +

        +However, while Standard explicitly describes ios_base::Init as +an appropriate class for doing the trick, I failed to found a +mention of an _instance_ of ios_base::Init in Standard. +

        +

        Proposed resolution:

        +

        +At the end of header <iostream> synopsis in 27.3 [lib.iostream.objects] +

        + +
        +       namespace std
+       {
+          ... extern istream cin; ...
+
        + +

        add the following lines

        + +
        +          namespace
+          {
+             ios_base::Init <some_implementation_defined_name>;
+          }
+        }
+
        +
        +

        370. Minor error in basic_istream::get

        +Section: 27.6.1.3 [lib.istream.unformatted]  Status: New  Submitter: Ray Lischner  Date: 15 Jul 2002

        +

        Defect report for description of basic_istream::get (section 27.6.1.3 [lib.istream.unformatted]), paragraph 15. The description for the get function +with the following signature:

        + +
        +  basic_istream<charT,traits>& get(basic_streambuf<char_type,traits>&
+  sb);
+
        + +

        is incorrect. It reads

        + +
        + Effects: Calls get(s,n,widen('\n')) +
        + +

        which I believe should be:

        + +
        + Effects: Calls get(sb,widen('\n')) +
        +

        Proposed resolution:

        +

        Change the Effects paragraph to:

        +
        + Effects: Calls get(sb,widen('\n')) +
        +
        +

        371. Stability of multiset and multimap member functions

        +Section: 23.1 [lib.container.requirements]  Status: New  Submitter: Frank Compagner  Date: 20 Jul 2002

        +

        +The requirements for multiset and multimap containers (23.1 +[lib.containers.requirements], 23.1.2 [lib.associative.reqmnts], +23.3.2 [lib.multimap] and 23.3.4 [lib.multiset]) make no mention of +the stability of the required (mutating) member functions. It appears +the standard allows these functions to reorder equivalent elements of +the container at will, yet the pervasive red-black tree implementation +appears to provide stable behaviour. +

        + +

        This is of most concern when considering the behaviour of erase(). +A stability requirement would guarantee the correct working of the +following 'idiom' that removes elements based on a certain predicate +function. +

        + +
        +  multimap<int, int> m;
+  multimap<int, int>::iterator i = m.begin();
+  while (i != m.end()) {
+      if (pred(i))
+          m.erase (i++);
+      else
+          ++i;
+  }
+
        + +

        +Although clause 23.1.2/8 guarantees that i remains a valid iterator +througout this loop, absence of the stability requirement could +potentially result in elements being skipped. This would make +this code incorrect, and, furthermore, means that there is no way +of erasing these elements without iterating first over the entire +container, and second over the elements to be erased. This would +be unfortunate, and have a negative impact on both performance and +code simplicity. +

        + +

        +If the stability requirement is intended, it should be made explicit +(probably through an extra paragraph in clause 23.1.2). +

        +

        +If it turns out stability cannot be guaranteed, i'd argue that a +remark or footnote is called for (also somewhere in clause 23.1.2) to +warn against relying on stable behaviour (as demonstrated by the code +above). If most implementations will display stable behaviour, any +problems emerging on an implementation without stable behaviour will +be hard to track down by users. This would also make the need for an +erase_if() member function that much greater. +

        + +

        This issue is somewhat related to LWG issue 130.

        +

        Proposed resolution:

        +
        +

        372. Inconsistent description of stdlib exceptions

        +Section: 17.4.4.8 [lib.res.on.exception.handling], 18.6.1 [lib.exception],   Status: New  Submitter: Randy Maddox  Date: 22 Jul 2002

        + +

        Paragraph 3 under clause 17.4.4.8 [lib.res.on.exception.handling], Restrictions on +Exception Handling, states that "Any other functions defined in the +C++ Standard Library that do not have an exception-specification may +throw implementation-defined exceptions unless otherwise specified." +This statement is followed by a reference to footnote 178 at the +bottom of that page which states, apparently in reference to the C++ +Standard Library, that "Library implementations are encouraged (but +not required) to report errors by throwing exceptions from (or derived +from) the standard exceptions."

        + +

        These statements appear to be in direct contradiction to clause +18.6.1 [lib.exception], which states "The class exception defines the +base class for the types of objects thrown as exceptions by the C++ +Standard library components ...".

        + +

        Is this inconsistent?

        + +

        Proposed resolution:

        +
        +

        373. Are basic_istream and basic_ostream to use (exceptions()&badbit) != 0 ?

        +Section: 27.6.1.2.1 [lib.istream.formatted.reqmts], 27.6.2.5.1 [lib.ostream.formatted.reqmts]  Status: New  Submitter: Keith Baker  Date: 23 Jul 2002

        + +

        +In 27.6.1.2.1 [lib.istream.formatted.reqmts] and 27.6.2.5.1 [lib.ostream.formatted.reqmts] +(exception()&badbit) != 0 is used in testing for rethrow, yet +exception() is the constructor to class std::exception in 18.6.1 [lib.exception] that has no return type. Should member function +exceptions() found in 27.4.4 [lib.ios] be used instead? +

        + +

        Proposed resolution:

        +

        +

        +
        +

        374. moneypunct::frac_digits returns int not unsigned

        +Section: 22.2.6.3.1 [lib.locale.moneypunct.members], 22.2.6.3.2 [lib.locale.moneypunct.virtuals]  Status: New  Submitter: Ray Lischner  Date: 8 Aug 2002

        +

        +In section 22.2.6.3.1 [lib.locale.moneypunct.members], frac_digits() returns type +"int". This implies that frac_digits() might return a negative value, +but a negative value is nonsensical. It should return "unsigned". +

        + +

        +Similarly, in section 22.2.6.3.2 [lib.locale.moneypunct.virtuals], do_frac_digits() +should return "unsigned". +

        + +

        Proposed resolution:

        +
        +

        375. basic_ios should be ios_base in 27.7.1.3

        +Section: 27.7.1.3 [lib.stringbuf.virtuals]  Status: New  Submitter: Ray Lischner  Date: 14 Aug 2002

        +

        +In Section 27.7.1.3 [lib.stringbuf.virtuals]: Table 90, Table 91, and paragraph +14 all contain references to "basic_ios::" which should be +"ios_base::". +

        +

        Proposed resolution:

        +

        +Change all references to "basic_ios" in Table 90, Table 91, and +paragraph 14 to "ios_base". +

        +
        +

        376. basic_streambuf semantics

        +Section: 27.7.1.3 [lib.stringbuf.virtuals]  Status: New  Submitter: Ray Lischner  Date: 14 Aug 2002

        +

        +In Section 27.7.1.3 [lib.stringbuf.virtuals], Table 90, the implication is that +the four conditions should be mutually exclusive, but they are not. +The first two cases, as written, are subcases of the third. I think it +would be clearer if the conditions were rewritten as follows: +

        + +
        +

        + (which & (ios_base::in|ios_base::out)) == ios_base::in +

        + +

        + (which & (ios_base::in|ios_base::out)) == ios_base::out +

        + +

        + (which & (ios_base::in|ios_base::out)) == +(ios_base::in|ios_base::out) + and way == either ios_base::beg or ios_base::end +

        + +

        Otherwise

        +
        + +

        +As written, it is unclear what should be the result if cases 1 & 2 +are true, but case 3 is false, e.g., +

        + +
        + seekoff(0, ios_base::cur, ios_base::in | ios_base::out) +
        + +

        Proposed resolution:

        +
        +

        377. basic_string::insert and length_error

        +Section: 21.3.5.4 [lib.string::insert]  Status: New  Submitter: Ray Lischner  Date: 16 Aug 2002

        +

        +Section 21.3.5.4 [lib.string::insert], paragraph 4, contains the following, +"Then throws length_error if size() >= npos - rlen." +

        + +

        +Related to DR 83, this sentence should probably be removed. +

        +

        Proposed resolution:

        +
        +

        378. locale immutability and locale::operator=()

        +Section: 22.1.1 [lib.locale]  Status: New  Submitter: Martin Sebor  Date: 6 Sep 2002

        +

        +I think there is a problem with 22.1.1, p6 which says that +

        +
        +    -6- An instance of locale is immutable; once a facet reference
+        is obtained from it, that reference remains usable as long
+        as the locale value itself exists.
+
        +

        +and 22.1.1.2, p4: +

        +
        +    const locale& operator=(const locale& other) throw();
+
+    -4- Effects: Creates a copy of other, replacing the current value.
+
        +

        +How can a reference to a facet obtained from a locale object remain +valid after an assignment that clearly must replace all the facets +in the locale object? Imagine a program such as this +

        +
        +    std::locale loc ("de_DE");
+    const std::ctype<char> &r0 = std::use_facet<std::ctype<char> >(loc);
+    loc = std::locale ("en_US");
+    const std::ctype<char> &r1 = std::use_facet<std::ctype<char> >(loc);
+
        +

        +Is r0 really supposed to be preserved and destroyed only when loc goes +out of scope? +

        +

        Proposed resolution:

        +

        +Suggest to replace 22.1.1 [lib.locale], p6 with +

        +
        +    -6- Unless assigned a new value, locale objects are immutable;
+        once a facet reference is obtained from it, that reference
+        remains usable as long as the locale object itself exists
+        or until the locale object is assigned the value of another,
+        distinct locale object.
+
        +
        +

        379. nonsensical ctype::do_widen() requirement

        +Section: 22.2.1.1.2 [lib.locale.ctype.virtuals]  Status: New  Submitter: Martin Sebor  Date: 6 Sep 2002

        +

        +The last sentence in 22.2.1.1.2, p11 below doesn't seem to make sense. +

        +
        +  charT do_widen (char c) const;
+
+  -11- Effects: Applies the simplest reasonable transformation from
+       a char value or sequence of char values to the corresponding
+       charT value or values. The only characters for which unique
+       transformations are required are those in the basic source
+       character set (2.2). For any named ctype category with a
+       ctype<charT> facet ctw and valid ctype_base::mask value
+       M (is(M, c) || !ctw.is(M, do_widen(c))) is true.
+
        +

        +Shouldn't the last sentence instead read +

        +
        +       For any named ctype category with a ctype<char> facet ctc
+       and valid ctype_base::mask value M
+       (ctc.is(M, c) || !is(M, do_widen(c))) is true.
+
        +

        +I.e., if the narrow character c is not a member of a class of +characters then neither is the widened form of c. (To paraphrase +footnote 224.) +

        +

        Proposed resolution:

        +

        +Replace the last sentence of 22.2.1.1.2 [lib.locale.ctype.virtuals], p11 with the +following text: +

        +
        +       For any named ctype category with a ctype<char> facet ctc
+       and valid ctype_base::mask value M
+       (ctc.is(M, c) || !is(M, do_widen(c))) is true.
+
        +
        +

        380. typos in codecvt tables 53 and 54

        +Section: 22.2.1.5.2 [lib.locale.codecvt.virtuals]  Status: New  Submitter: Martin Sebor  Date: 6 Sep 2002

        +

        +Tables 53 and 54 in 22.2.1.5.2 [lib.locale.codecvt.virtuals] are both titled "convert +result values," when surely "do_in/do_out result values" must have +been intended for Table 53 and "do_unshift result values" for Table +54. +

        +

        +Table 54, row 3 says that the meaning of partial is "more characters +needed to be supplied to complete termination." The function is not +supplied any characters, it is given a buffer which it fills with +characters or, more precisely, destination elements (i.e., an escape +sequence). So partial means that space for more than (to_limit - to) +destination elements was needed to terminate a sequence given the +value of state. +

        +

        Proposed resolution:

        +

        +Change the title of Table 53 to "do_in/do_out result values" and +the title of Table 54 to "do_unshift result values." +

        +

        +Change the text in Table 54, row 3, under the heading Meaning to +"space for more than (to_limit - to) destination elements was +needed to terminate a sequence given the value of state." +

        +
        +

        381. detection of invalid mbstate_t in codecvt

        +Section: 22.2.1.5.2 [lib.locale.codecvt.virtuals]  Status: New  Submitter: Martin Sebor  Date: 6 Sep 2002

        +

        +All but one codecvt member functions that take a state_type argument +list as one of their preconditions that the state_type argument have +a valid value. However, according to 22.2.1.5.2, p6, +codecvt::do_unshift() is the only codecvt member that is supposed to +return error if the state_type object is invalid. +

        + +

        +It seems to me that the treatment of state_type by all codecvt member +functions should be the same and the current requirements should be +changed. Since the detection of invalid state_type values may be +difficult in general or computationally expensive in some specific +cases, I propose the following: +

        +

        Proposed resolution:

        +

        +Add a new paragraph before 22.2.1.5.2, p5, and after the function +declaration below +

        +
        +    result do_unshift(stateT& state,
+    externT* to, externT* to_limit, externT*& to_next) const;
+
        +

        +as follows: +

        +
        +    Requires: (to <= to_end) well defined and true; state initialized,
+    if at the beginning of a sequence, or else equal to the result of
+    converting the preceding characters in the sequence.
+
        +

        +and change the text in Table 54, row 4, under the heading Meaning +from +

        +
        +    state has invalid value
+
        +

        +to +

        +
        +    an unspecified error has occurred
+
        +

        +The return value of error should allow implementers to detect and +report invalid state values but shouldn't require it, hence the +word "unspecified" in the new wording. +

        +
        +

        382. codecvt do_in/out result

        +Section: 22.2.1.5 [lib.locale.codecvt]  Status: New  Submitter: Martin Sebor  Date: 30 Aug 2002

        +

        +It seems that the descriptions of codecvt do_in() and do_out() leave +sufficient room for interpretation so that two implementations of +codecvt may not work correctly with the same filebuf. Specifically, +the following seems less than adequately specified: +

        + +
          +
        1. + the conditions under which the functions terminate +
          2. +
        2. + precisely when the functions return ok +
          3. +
        3. + precisely when the functions return partial +
          4. +
        4. + the full set of conditions when the functions return error +
          5. +
        + +
          +
        1. + 22.2.1.5.2 [lib.locale.codecvt.virtuals], p2 says this about the effects of the + function: ...Stops if it encounters a character it cannot + convert... This assumes that there *is* a character to + convert. What happens when there is a sequence that doesn't form a + valid source character, such as an unassigned or invalid UNICODE + character, or a sequence that cannot possibly form a character + (e.g., the sequence "\xc0\xff" in UTF-8)? +
          2. +
        2. + Table 53 says that the function returns codecvt_base::ok + to indicate that the function(s) "completed the conversion." + Suppose that the source sequence is "\xc0\x80" in UTF-8, + with from pointing to '\xc0' and (from_end==from + 1). + It is not clear whether the return value should be ok + or partial (see below). +
          3. +
        3. + Table 53 says that the function returns codecvt_base::partial + if "not all source characters converted." With the from pointers + set up the same way as above, it is not clear whether the return + value should be partial or ok (see above). +
          4. +
        4. + Table 53, in the row describing the meaning of error mistakenly + refers to a "from_type" character, without the symbol from_type + having been defined. Most likely, the word "source" character + is intended, although that is not sufficient. The functions + may also fail when they encounter an invalid source sequence + that cannot possibly form a valid source character (e.g., as + explained in bullet 1 above). +
          5. +
        +

        +Finally, the conditions described at the end of 22.2.1.5.2 [lib.locale.codecvt.virtuals], p4 don't seem to be possible: +

        +
        + "A return value of partial, if (from_next == from_end), + indicates that either the destination sequence has not + absorbed all the available destination elements, or that + additional source elements are needed before another + destination element can be produced." +
        +

        +If the value is partial, it's not clear to me that (from_next +==from_end) could ever hold if there isn't enough room +in the destination buffer. In order for (from_next==from_end) to +hold, all characters in that range must have been successfully +converted (according to 22.2.1.5.2 [lib.locale.codecvt.virtuals], p2) and since there are no +further source characters to convert, no more room in the +destination buffer can be needed. +

        +

        +It's also not clear to me that (from_next==from_end) could ever +hold if additional source elements are needed to produce another +destination character (not element as incorrectly stated in the +text). partial is returned if "not all source characters have +been converted" according to Table 53, which also implies that +(from_next==from) does NOT hold. +

        +

        +Could it be that the intended qualifying condition was actually +(from_next != from_end), i.e., that the sentence was supposed +to read +

        +
        + "A return value of partial, if (from_next != from_end),..." +
        +

        +which would make perfect sense, since, as far as I understand it, +partial can only occur if (from_next != from_end)? +

        +

        Proposed resolution:

        +

        +To address these issues, I propose that paragraphs 2, 3, and 4 +be rewritten as follows. The proposal incorporates the accepted +resolution of lwg issue 19. +

        +
        +-2- Effects: Converts characters in the range of source elements
+    [from, from_end), placing the results in sequential positions
+    starting at destination to. Converts no more than (from_end­from)
+    source elements, and stores no more than (to_limit­to)
+    destination elements.
+
+    Stops if it encounters a sequence of source elements it cannot
+    convert to a valid destination character. It always leaves the
+    from_next and to_next pointers pointing one beyond the last
+    element successfully converted.
+
+    [Note: If returns noconv, internT and externT are the same type
+    and the converted sequence is identical to the input sequence
+    [from, from_next). to_next is set equal to to, the value of
+    state is unchanged, and there are no changes to the values in
+    [to, to_limit). --end note]
+
+-3- Notes: Its operations on state are unspecified.
+    [Note: This argument can be used, for example, to maintain shift
+    state, to specify conversion options (such as count only), or to
+    identify a cache of seek offsets. --end note]
+
+-4- Returns: An enumeration value, as summarized in Table 53:
+
+    Table 53 -- do_in/do_out result values
+
+     Value      Meaning
+    +---------+----------------------------------------------------+
+    | ok      | successfully completed the conversion of all       |
+    |         | complete characters in the source range            |
+    +---------+----------------------------------------------------+
+    | partial | the characters in the source range would, after    |
+    |         | conversion, require space greater than that        |
+    |         | available in the destination range                 |
+    +---------+----------------------------------------------------+
+    | error   | encountered either a sequence of elements in the   |
+    |         | source range forming a valid source character that |
+    |         | could not be converted to a destination character, |
+    |         | or a sequence of elements in the source range that |
+    |         | could not possibly form a valid source character   |
+    +---------+----------------------------------------------------+
+    | noconv  | internT and externT are the same type, and input   |
+    |         | sequence is identical to converted sequence        |
+    +---------+----------------------------------------------------+
+
+    A return value of partial, i.e., if (from_next != from_end),
+    indicates that either the destination sequence has not absorbed
+    all the available destination elements, or that additional
+    source elements are needed before another destination character
+    can be produced.
+

        ----- End of document -----

        diff --git a/libstdc++-v3/docs/html/ext/lwg-defects.html b/libstdc++-v3/docs/html/ext/lwg-defects.html index eea548b..41ae2f8 100644 --- a/libstdc++-v3/docs/html/ext/lwg-defects.html +++ b/libstdc++-v3/docs/html/ext/lwg-defects.html @@ -5,11 +5,11 @@ - + - + @@ -17,10 +17,10 @@ - +
        Doc. no.J16/02-0028 = WG21 N1370J16/02-0049 = WG21 N1391
        Date:10 May 200210 Sep 2002
        Project:
        Reply to:Matt Austern <austern@research.att.com>Matt Austern <austern@apple.com>
        -

        C++ Standard Library Defect Report List (Revision 22)

        +

        C++ Standard Library Defect Report List (Revision 23)

        Reference ISO/IEC IS 14882:1998(E)

        Also see:

          @@ -42,6 +42,10 @@ document.

          Revision History

            +
          • R23: +Pre-Santa Cruz mailing. Added new issues 367-382. +Moved issues in the TC to TC status. +
          • R22: Post-Curaçao mailing. Added new issues 362-366.
            • @@ -204,7 +208,7 @@ format, 64 title. (17 Sep 98)

            Defect Reports

            1. C library linkage editing oversight

            -Section: 17.4.2.2 [lib.using.linkage]  Status: DR  Submitter: Beman Dawes  Date: 16 Nov 1997

            +Section: 17.4.2.2 [lib.using.linkage]  Status: TC  Submitter: Beman Dawes  Date: 16 Nov 1997

            The change specified in the proposed resolution below did not make it into the Standard. This change was accepted in principle at the London meeting, and the exact wording below was accepted at the @@ -229,7 +233,7 @@ from:

            3. Atexit registration during atexit() call is not described

            -Section: 18.3 [lib.support.start.term]  Status: DR  Submitter: Steve Clamage  Date: 12 Dec 1997

            +Section: 18.3 [lib.support.start.term]  Status: TC  Submitter: Steve Clamage  Date: 12 Dec 1997

            We appear not to have covered all the possibilities of exit processing with respect to atexit registration.
            @@ -349,7 +353,7 @@ committee decides.

            supporting to the proposed resolution.

            5. String::compare specification questionable

            -Section: 21.3.6.8 [lib.string::compare]  Status: DR  Submitter: Jack Reeves  Date: 11 Dec 1997

            +Section: 21.3.6.8 [lib.string::compare]  Status: TC  Submitter: Jack Reeves  Date: 11 Dec 1997

            At the very end of the basic_string class definition is the signature: int compare(size_type pos1, size_type n1, const charT* s, size_type n2 = npos) const; In the following text this is defined as: returns @@ -432,7 +436,7 @@ the Standard which must be fixed.  The same problem was also identified in issues 7 (item 5) and 87.

            7. String clause minor problems

            -Section: 21 [lib.strings]  Status: DR  Submitter: Matt Austern  Date: 15 Dec 1997

            +Section: 21 [lib.strings]  Status: TC  Submitter: Matt Austern  Date: 15 Dec 1997

            (1) In 21.3.5.4 [lib.string::insert], the description of template <class InputIterator> insert(iterator, InputIterator, InputIterator) makes no sense. It refers to a member function that @@ -503,7 +507,7 @@ with:
            s+n) overlap."

            8. Locale::global lacks guarantee

            -Section: 22.1.1.5 [lib.locale.statics]  Status: DR  Submitter: Matt Austern  Date: 24 Dec 1997

            +Section: 22.1.1.5 [lib.locale.statics]  Status: TC  Submitter: Matt Austern  Date: 24 Dec 1997

            It appears there's an important guarantee missing from clause 22. We're told that invoking locale::global(L) sets the C locale if L has a name. However, we're not told whether or not invoking @@ -522,7 +526,7 @@ paragraph 2: 

            9. Operator new(0) calls should not yield the same pointer

            -Section: 18.4.1 [lib.new.delete]  Status: DR  Submitter: Steve Clamage  Date: 4 Jan 1998

            +Section: 18.4.1 [lib.new.delete]  Status: TC  Submitter: Steve Clamage  Date: 4 Jan 1998

            Scott Meyers, in a comp.std.c++ posting: I just noticed that section 3.7.3.1 of CD2 seems to allow for the possibility that all calls to operator new(0) yield the same pointer, an implementation @@ -577,7 +581,7 @@ list maintainer's note: the IS is the same.]

            supporting to the proposed resolution.

            11. Bitset minor problems

            -Section: 23.3.5 [lib.template.bitset]  Status: DR  Submitter: Matt Austern  Date: 22 Jan 1998

            +Section: 23.3.5 [lib.template.bitset]  Status: TC  Submitter: Matt Austern  Date: 22 Jan 1998

            (1) bitset<>::operator[] is mentioned in the class synopsis (23.3.5), but it is not documented in 23.3.5.2.

            @@ -625,7 +629,7 @@ input" implies the desired semantics. See 27.6.1.2

            13. Eos refuses to die

            -Section: 27.6.1.2.3 [lib.istream::extractors]  Status: DR  Submitter: William M. Miller  Date: 3 Mar 1998

            +Section: 27.6.1.2.3 [lib.istream::extractors]  Status: TC  Submitter: William M. Miller  Date: 3 Mar 1998

            In 27.6.1.2.3, there is a reference to "eos", which is the only one in the whole draft (at least using Acrobat search), so it's undefined.

            @@ -634,7 +638,7 @@ it's undefined.

            "charT()"

            14. Locale::combine should be const

            -Section: 22.1.1.3 [lib.locale.members]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

            +Section: 22.1.1.3 [lib.locale.members]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998

            locale::combine is the only member function of locale (other than constructors and destructor) that is not const. There is no reason for it not to be const, and good reasons why it should have been const. Furthermore, leaving it non-const conflicts with 22.1.1 @@ -653,7 +657,7 @@ time, but the omission was not noticed.

            15. Locale::name requirement inconsistent

            -Section: 22.1.1.3 [lib.locale.members]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

            +Section: 22.1.1.3 [lib.locale.members]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998

            locale::name() is described as returning a string that can be passed to a locale constructor, but there is no matching constructor.

            Proposed resolution:

            @@ -663,7 +667,7 @@ constructor, but there is no matching constructor.

            16. Bad ctype_byname<char> decl

            -Section: 22.2.1.4 [lib.locale.ctype.byname.special]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

            +Section: 22.2.1.4 [lib.locale.ctype.byname.special]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998

            The new virtual members ctype_byname<char>::do_widen and do_narrow did not get edited in properly. Instead, the member do_widen appears four times, with wrong argument lists.

            @@ -673,7 +677,7 @@ lists.

            from 22.2.1.3 [lib.facet.ctype.special].

            17. Bad bool parsing

            -Section: 22.2.2.1.2 [lib.facet.num.get.virtuals]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

            +Section: 22.2.2.1.2 [lib.facet.num.get.virtuals]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998

            This section describes the process of parsing a text boolean value from the input stream. It does not say it recognizes either of the sequences "true" or "false" and returns the corresponding bool value; instead, it says it recognizes @@ -753,7 +757,7 @@ change "&&" to "&".

            18. Get(...bool&) omitted

            -Section: 22.2.2.1.1 [lib.facet.num.get.members]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

            +Section: 22.2.2.1.1 [lib.facet.num.get.members]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998

            In the list of num_get<> non-virtual members on page 22-23, the member that parses bool values was omitted from the list of definitions of non-virtual members, though it is listed in the class definition and the corresponding @@ -764,7 +768,7 @@ another get member for bool&, copied from the entry in 22.2.2.1 [lib.locale.num.get].

            19. "Noconv" definition too vague

            -Section: 22.2.1.5.2 [lib.locale.codecvt.virtuals]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

            +Section: 22.2.1.5.2 [lib.locale.codecvt.virtuals]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998

            In the definitions of codecvt<>::do_out and do_in, they are specified to return noconv if "no conversion is @@ -790,7 +794,7 @@ Change the entry for noconv in the table under paragraph 4 in section

            20. Thousands_sep returns wrong type

            -Section: 22.2.3.1.2 [lib.facet.numpunct.virtuals]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

            +Section: 22.2.3.1.2 [lib.facet.numpunct.virtuals]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998

            The synopsis for numpunct<>::do_thousands_sep, and the definition of numpunct<>::thousands_sep which calls it, specify that it returns a value of type char_type. Here it is erroneously @@ -800,7 +804,7 @@ described as returning a "string_type".

            "string_type" to "char_type".

            21. Codecvt_byname<> instantiations

            -Section: 22.1.1.1.1 [lib.locale.category]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

            +Section: 22.1.1.1.1 [lib.locale.category]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998

            In the second table in the section, captioned "Required instantiations", the instantiations for codecvt_byname<> have been omitted. These are necessary to allow users to construct a @@ -816,7 +820,7 @@ codecvt_byname<wchar_t,char,mbstate_t>

            22. Member open vs. flags

            -Section: 27.8.1.7 [lib.ifstream.members]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

            +Section: 27.8.1.7 [lib.ifstream.members]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998

            The description of basic_istream<>::open leaves unanswered questions about how it responds to or changes flags in the error status for the stream. A strict reading indicates that it ignores the bits and does not change them, which confuses users who do @@ -843,7 +847,7 @@ believes to have been the original intent.

            24. "do_convert" doesn't exist

            -Section: 22.2.1.5.2 [lib.locale.codecvt.virtuals]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

            +Section: 22.2.1.5.2 [lib.locale.codecvt.virtuals]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998

            The description of codecvt<>::do_out and do_in mentions a symbol "do_convert" which is not defined in the standard. This is a leftover from an edit, and should be "do_in @@ -854,7 +858,7 @@ and do_out".

            or do_out".

            25. String operator<< uses width() value wrong

            -Section: 21.3.7.9 [lib.string.io]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

            +Section: 21.3.7.9 [lib.string.io]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998

            In the description of operator<< applied to strings, the standard says that uses the smaller of os.width() and str.size(), to pad "as described in stage 3" elsewhere; but this is inconsistent, as this allows no possibility of space for padding.

            @@ -870,7 +874,7 @@ to:
            ..."

            26. Bad sentry example

            -Section: 27.6.1.1.2 [lib.istream::sentry]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

            +Section: 27.6.1.1.2 [lib.istream::sentry]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998

            In paragraph 6, the code in the example: 

              template <class charT, class traits = char_traits<charT> >
@@ -905,7 +909,7 @@ decided that it would be counter-productive to include such a lengthy
 example, which might well still contain errors.
            
 
            
 
            27. String::erase(range) yields wrong iterator
            
-Section: 21.3.5.5  [lib.string::erase]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998
            
+Section: 21.3.5.5  [lib.string::erase]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998
            
 
            The string::erase(iterator first, iterator last) is specified to return an element one
 place beyond the next element after the last one erased. E.g. for the string
 "abcde", erasing the range ['b'..'d') would yield an iterator for element 'e',
@@ -926,7 +930,7 @@ while 'd' has not been erased. 
            
 
 
            
 
            28. Ctype<char>is ambiguous
            
-Section: 22.2.1.3.2  [lib.facet.ctype.char.members]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998
            
+Section: 22.2.1.3.2  [lib.facet.ctype.char.members]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998
            
 
            The description of the vector form of ctype<char>::is can be interpreted to mean
 something very different from what was intended. Paragraph 4 says 
            
 
@@ -946,7 +950,7 @@ vec[]. 
            
 
 
            
 
            29. Ios_base::init doesn't exist
            
-Section: 27.3.1  [lib.narrow.stream.objects]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998
            
+Section: 27.3.1  [lib.narrow.stream.objects]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998
            
 
            Sections 27.3.1  [lib.narrow.stream.objects] and 27.3.2  [lib.wide.stream.objects] mention
 a function ios_base::init, which is not defined. Probably they mean
 basic_ios<>::init, defined in 27.4.4.1  [lib.basic.ios.cons],
@@ -974,7 +978,7 @@ should read 
            
 
 
            
 
            30. Wrong header for LC_*
            
-Section: 22.1.1.1.1  [lib.locale.category]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998
            
+Section: 22.1.1.1.1  [lib.locale.category]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998
            
 
            Paragraph 2 implies that the C macros LC_CTYPE etc. are defined in <cctype>,
 where they are in fact defined elsewhere to appear in <clocale>. 
            
 
            Proposed resolution:
            
@@ -982,7 +986,7 @@ where they are in fact defined elsewhere to appear in <clocale>. 
            
 "<cctype>" to read "<clocale>". 
            
 
            
 
            31. Immutable locale values
            
-Section: 22.1.1  [lib.locale]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998
            
+Section: 22.1.1  [lib.locale]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998
            
 
            Paragraph 6, says "An instance of locale is
 immutable; once a facet reference is obtained from it,
 ...". This has caused some confusion, because locale variables
@@ -1006,7 +1010,7 @@ are manifestly assignable. 
            
 
 
            
 
            32. Pbackfail description inconsistent
            
-Section: 27.5.2.4.4  [lib.streambuf.virt.pback]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998
            
+Section: 27.5.2.4.4  [lib.streambuf.virt.pback]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998
            
 
            The description of the required state before calling virtual member
 basic_streambuf<>::pbackfail requirements is inconsistent with the conditions
 described in 27.5.2.2.4 [lib.streambuf.pub.pback] where member sputbackc calls it.
@@ -1037,7 +1041,7 @@ Specifically, the latter says it calls pbackfail if: 
            
 the argument value.
            
 
            
 
            33. Codecvt<> mentions from_type
            
-Section: 22.2.1.5.2  [lib.locale.codecvt.virtuals]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998
            
+Section: 22.2.1.5.2  [lib.locale.codecvt.virtuals]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998
            
 
            In the table defining the results from do_out and do_in, the specification for the
 result error says 
            
 
@@ -1056,7 +1060,7 @@ in the table for the case of _error_ with 
            
 
 
            
 
            34. True/falsename() not in ctype<>
            
-Section: 22.2.2.2.2  [lib.facet.num.put.virtuals]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998
            
+Section: 22.2.2.2.2  [lib.facet.num.put.virtuals]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998
            
 
            In paragraph 19, Effects:, members truename() and falsename are used from facet
 ctype<charT>, but it has no such members. Note that this is also a problem in
 22.2.2.1.2, addressed in (4). 
            
@@ -1071,7 +1075,7 @@ string_type s = val ? np.truename() : np.falsename();

            35. No manipulator unitbuf in synopsis

            -Section: 27.4 [lib.iostreams.base]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

            +Section: 27.4 [lib.iostreams.base]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998

            In 27.4.5.1 [lib.fmtflags.manip], we have a definition for a manipulator named "unitbuf". Unlike other manipulators, it's not listed in synopsis. Similarly for "nounitbuf".

            @@ -1085,7 +1089,7 @@ ios_base& nounitbuf(ios_base& str);

            36. Iword & pword storage lifetime omitted

            -Section: 27.4.2.5 [lib.ios.base.storage]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

            +Section: 27.4.2.5 [lib.ios.base.storage]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998

            In the definitions for ios_base::iword and pword, the lifetime of the storage is specified badly, so that an implementation which only keeps the last value stored appears to conform. In particular, it says:

            @@ -1115,7 +1119,7 @@ paragraph 4, replace the sentence:

            substituting "iword" or "pword" as appropriate.

            37. Leftover "global" reference

            -Section: 22.1.1 [lib.locale]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

            +Section: 22.1.1 [lib.locale]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998

            In the overview of locale semantics, paragraph 4, is the sentence

            @@ -1134,7 +1138,7 @@ expression

            38. Facet definition incomplete

            -Section: 22.1.2 [lib.locale.global.templates]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

            +Section: 22.1.2 [lib.locale.global.templates]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998

            It has been noticed by Esa Pulkkinen that the definition of "facet" is incomplete. In particular, a class derived from another facet, but which does not define a member id, cannot @@ -1165,7 +1169,7 @@ contains (not inherits) the public static member

            39. istreambuf_iterator<>::operator++(int) definition garbled

            -Section: 24.5.3.4 [lib.istreambuf.iterator::op++]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

            +Section: 24.5.3.4 [lib.istreambuf.iterator::op++]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998

            Following the definition of istreambuf_iterator<>::operator++(int) in paragraph 3, the standard contains three lines of garbage text left over from a previous edit.

            @@ -1175,11 +1179,11 @@ sbuf_->sbumpc(); return(tmp);

            Proposed resolution:

            -

            In 24.5.3.4 [lib.istreambuf.iterator::op++], delete the three lines of code at the +

            In 24.5.3.4 [lib.istreambuf.iterator::op++], delete the three lines of code at the end of paragraph 3.

            40. Meaningless normative paragraph in examples

            -Section: 22.2.8 [lib.facets.examples]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

            +Section: 22.2.8 [lib.facets.examples]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998

            Paragraph 3 of the locale examples is a description of part of an implementation technique that has lost its referent, and doesn't mean anything.

            @@ -1190,7 +1194,7 @@ editor's option) replace it with a place-holder to keep the paragraph numbering the same.

            41. Ios_base needs clear(), exceptions()

            -Section: 27.4.2 [lib.ios.base]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

            +Section: 27.4.2 [lib.ios.base]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998

            The description of ios_base::iword() and pword() in 27.4.2.4 [lib.ios.members.static], say that if they fail, they "set badbit, which may throw an exception". However, ios_base offers no interface to set or to test badbit; those interfaces are defined in @@ -1217,7 +1221,7 @@ setstate(badbit).]

            42. String ctors specify wrong default allocator

            -Section: 21.3 [lib.basic.string]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

            +Section: 21.3 [lib.basic.string]  Status: TC  Submitter: Nathan Myers  Date: 6 Aug 1998

            The basic_string<> copy constructor: 

            basic_string(const basic_string& str, size_type pos = 0,
@@ -1291,7 +1295,7 @@ reflects the LWG consensus.
 ]
            
 
            
 
            46. Minor Annex D errors
            
-Section: D.7  [depr.str.strstreams]  Status: DR  Submitter: Brendan Kehoe  Date:  1 Jun 1998
            
+Section: D.7  [depr.str.strstreams]  Status: TC  Submitter: Brendan Kehoe  Date:  1 Jun 1998
            
 
            See lib-6522 and edit-814.
            
 
            Proposed resolution:
            
 
            Change D.7.1  [depr.strstreambuf] (since streambuf is a typedef of
@@ -1316,7 +1320,7 @@ int_type:
            
          typedef typename char_traits<char>::pos_type pos_type;

            47. Imbue() and getloc() Returns clauses swapped

            -Section: 27.4.2.3 [lib.ios.base.locales]  Status: DR  Submitter: Matt Austern  Date: 21 Jun 1998

            +Section: 27.4.2.3 [lib.ios.base.locales]  Status: TC  Submitter: Matt Austern  Date: 21 Jun 1998

            Section 27.4.2.3 specifies how imbue() and getloc() work. That section has two RETURNS clauses, and they make no sense as stated. They make perfect sense, though, if you swap them. Am I @@ -1326,7 +1330,7 @@ accident?

            In 27.4.2.3 [lib.ios.base.locales] swap paragraphs 2 and 4.

            48. Use of non-existent exception constructor

            -Section: 27.4.2.1.1 [lib.ios::failure]  Status: DR  Submitter: Matt Austern  Date: 21 Jun 1998

            +Section: 27.4.2.1.1 [lib.ios::failure]  Status: TC  Submitter: Matt Austern  Date: 21 Jun 1998

            27.4.2.1.1, paragraph 2, says that class failure initializes the base class, exception, with exception(msg). Class exception (see 18.6.1) has no such constructor.

            @@ -1421,7 +1425,7 @@ text was added in the non-normative footnote to say that operations on the two streams can be mixed arbitrarily.]

            50. Copy constructor and assignment operator of ios_base

            -Section: 27.4.2 [lib.ios.base]  Status: DR  Submitter: Matt Austern  Date: 21 Jun 1998

            +Section: 27.4.2 [lib.ios.base]  Status: TC  Submitter: Matt Austern  Date: 21 Jun 1998

            As written, ios_base has a copy constructor and an assignment operator. (Nothing in the standard says it doesn't have one, and all classes have copy constructors and assignment operators unless you @@ -1448,7 +1452,7 @@ constructor and operator= members as being private.

            outweighs any benefit of allowing ios_base objects to be copyable.

            51. Requirement to not invalidate iterators missing

            -Section: 23.1 [lib.container.requirements]  Status: DR  Submitter: David Vandevoorde  Date: 23 Jun 1998

            +Section: 23.1 [lib.container.requirements]  Status: TC  Submitter: David Vandevoorde  Date: 23 Jun 1998

            The std::sort algorithm can in general only sort a given sequence by moving around values. The list<>::sort() member on the other hand could move around values or just update internal pointers. Either @@ -1495,7 +1499,7 @@ particularly the addition of the phrase "or change the values of"

            52. Small I/O problems

            -Section: 27.4.3.2 [lib.fpos.operations]  Status: DR  Submitter: Matt Austern  Date: 23 Jun 1998

            +Section: 27.4.3.2 [lib.fpos.operations]  Status: TC  Submitter: Matt Austern  Date: 23 Jun 1998

            First, 27.4.4.1 [lib.basic.ios.cons], table 89. This is pretty obvious: it should be titled "basic_ios<>() effects", not "ios_base() effects".

            @@ -1523,7 +1527,7 @@ arithmetic is possible.)

            effects".

            53. Basic_ios destructor unspecified

            -Section: 27.4.4.1 [lib.basic.ios.cons]  Status: DR  Submitter: Matt Austern  Date: 23 Jun 1998

            +Section: 27.4.4.1 [lib.basic.ios.cons]  Status: TC  Submitter: Matt Austern  Date: 23 Jun 1998

            There's nothing in 27.4.4 saying what basic_ios's destructor does. The important question is whether basic_ios::~basic_ios() destroys rdbuf().

            @@ -1544,7 +1548,7 @@ footnote which incorrectly said "rdbuf(0) does not set badbit".

            54. Basic_streambuf's destructor

            -Section: 27.5.2.1 [lib.streambuf.cons]  Status: DR  Submitter: Matt Austern  Date: 25 Jun 1998

            +Section: 27.5.2.1 [lib.streambuf.cons]  Status: TC  Submitter: Matt Austern  Date: 25 Jun 1998

            The class synopsis for basic_streambuf shows a (virtual) destructor, but the standard doesn't say what that destructor does. My assumption is that it does nothing, but the standard should say so @@ -1559,7 +1563,7 @@ explicitly.

            55. Invalid stream position is undefined

            -Section: 27 [lib.input.output]  Status: DR  Submitter: Matt Austern  Date: 26 Jun 1998

            +Section: 27 [lib.input.output]  Status: TC  Submitter: Matt Austern  Date: 26 Jun 1998

            Several member functions in clause 27 are defined in certain circumstances to return an "invalid stream position", a term that is defined nowhere in the standard. Two places (27.5.2.4.2, @@ -1618,7 +1622,7 @@ stores an invalid stream position" to "the return value is pos_type(off_type(-1))"

            56. Showmanyc's return type

            -Section: 27.5.2 [lib.streambuf]  Status: DR  Submitter: Matt Austern  Date: 29 Jun 1998

            +Section: 27.5.2 [lib.streambuf]  Status: TC  Submitter: Matt Austern  Date: 29 Jun 1998

            The class summary for basic_streambuf<>, in 27.5.2, says that showmanyc has return type int. However, 27.5.2.4.3 says that its return type is streamsize.

            @@ -1627,7 +1631,7 @@ return type is streamsize.

            27.5.2 [lib.streambuf] class summary to streamsize.

            57. Mistake in char_traits

            -Section: 21.1.3.2 [lib.char.traits.specializations.wchar.t]  Status: DR  Submitter: Matt Austern  Date: 1 Jul 1998

            +Section: 21.1.3.2 [lib.char.traits.specializations.wchar.t]  Status: TC  Submitter: Matt Austern  Date: 1 Jul 1998

            21.1.3.2, paragraph 3, says "The types streampos and wstreampos may be different if the implementation supports no shift encoding in narrow-oriented iostreams but supports one or more shift @@ -1646,7 +1650,7 @@ begins "The types streampos and wstreampos may be different..." .

            59. Ambiguity in specification of gbump

            -Section: 27.5.2.3.1 [lib.streambuf.get.area]  Status: DR  Submitter: Matt Austern  Date: 28 Jul 1998

            +Section: 27.5.2.3.1 [lib.streambuf.get.area]  Status: TC  Submitter: Matt Austern  Date: 28 Jul 1998

            27.5.2.3.1 says that basic_streambuf::gbump() "Advances the next pointer for the input sequence by n."

            @@ -1675,7 +1679,7 @@ former interpretation.)

            effects.

            60. What is a formatted input function?

            -Section: 27.6.1.2.1 [lib.istream.formatted.reqmts]  Status: DR  Submitter: Matt Austern  Date: 3 Aug 1998

            +Section: 27.6.1.2.1 [lib.istream.formatted.reqmts]  Status: TC  Submitter: Matt Austern  Date: 3 Aug 1998

            Paragraph 1 of 27.6.1.2.1 contains general requirements for all formatted input functions. Some of the functions defined in section 27.6.1.2 explicitly say that those requirements apply ("Behaves @@ -1972,7 +1976,7 @@ by Judy Ward and Matt Austern. This proposed resolution is section VI of that paper.

            61. Ambiguity in iostreams exception policy

            -Section: 27.6.1.3 [lib.istream.unformatted]  Status: DR  Submitter: Matt Austern  Date: 6 Aug 1998

            +Section: 27.6.1.3 [lib.istream.unformatted]  Status: TC  Submitter: Matt Austern  Date: 6 Aug 1998

            The introduction to the section on unformatted input (27.6.1.3) says that every unformatted input function catches all exceptions that were thrown during input, sets badbit, and then conditionally rethrows @@ -2008,7 +2012,7 @@ parenthetical comment: "(Exceptions thrown from resolution as better standardese.

            62. Sync's return value

            -Section: 27.6.1.3 [lib.istream.unformatted]  Status: DR  Submitter: Matt Austern  Date: 6 Aug 1998

            +Section: 27.6.1.3 [lib.istream.unformatted]  Status: TC  Submitter: Matt Austern  Date: 6 Aug 1998

            The Effects clause for sync() (27.6.1.3, paragraph 36) says that it "calls rdbuf()->pubsync() and, if that function returns -1 ... returns traits::eof()."

            @@ -2021,7 +2025,7 @@ traits::int_type while the return type of sync() is int.

            63. Exception-handling policy for unformatted output

            -Section: 27.6.2.6 [lib.ostream.unformatted]  Status: DR  Submitter: Matt Austern  Date: 11 Aug 1998

            +Section: 27.6.2.6 [lib.ostream.unformatted]  Status: TC  Submitter: Matt Austern  Date: 11 Aug 1998

            Clause 27 details an exception-handling policy for formatted input, unformatted input, and formatted output. It says nothing for unformatted output (27.6.2.6). 27.6.2.6 should either include the same @@ -2052,7 +2056,7 @@ input, unformatted input, and formatted output.

            64. Exception handling in basic_istream::operator>>(basic_streambuf*)

            -Section: 27.6.1.2.3 [lib.istream::extractors]  Status: DR  Submitter: Matt Austern  Date: 11 Aug 1998

            +Section: 27.6.1.2.3 [lib.istream::extractors]  Status: TC  Submitter: Matt Austern  Date: 11 Aug 1998

            27.6.1.2.3, paragraph 13, is ambiguous. It can be interpreted two different ways, depending on whether the second sentence is read as an elaboration of the first.

            @@ -2070,7 +2074,7 @@ elaboration of the first.

            66. Strstreambuf::setbuf

            -Section: D.7.1.3 [depr.strstreambuf.virtuals]  Status: DR  Submitter: Matt Austern  Date: 18 Aug 1998

            +Section: D.7.1.3 [depr.strstreambuf.virtuals]  Status: TC  Submitter: Matt Austern  Date: 18 Aug 1998

            D.7.1.3, paragraph 19, says that strstreambuf::setbuf "Performs an operation that is defined separately for each class derived from strstreambuf". This is obviously an incorrect @@ -2089,7 +2093,7 @@ with:

            68. Extractors for char* should store null at end

            -Section: 27.6.1.2.3 [lib.istream::extractors]  Status: DR  Submitter: Angelika Langer  Date: 14 Jul 1998

            +Section: 27.6.1.2.3 [lib.istream::extractors]  Status: TC  Submitter: Angelika Langer  Date: 14 Jul 1998

            Extractors for char* (27.6.1.2.3) do not store a null character after the extracted character sequence whereas the unformatted functions like get() do. Why is this?

            @@ -2116,7 +2120,7 @@ item from:

            69. Must elements of a vector be contiguous?

            -Section: 23.2.4 [lib.vector]  Status: DR  Submitter: Andrew Koenig  Date: 29 Jul 1998

            +Section: 23.2.4 [lib.vector]  Status: TC  Submitter: Andrew Koenig  Date: 29 Jul 1998

            The issue is this: Must the elements of a vector be in contiguous memory?

            (Please note that this is entirely separate from the question of @@ -2150,7 +2154,7 @@ directly defined in the standard. Discussion included:

          70. Uncaught_exception() missing throw() specification

          -Section: 18.6 [lib.support.exception], 18.6.4 [lib.uncaught]  Status: DR  Submitter: Steve Clamage  Date: Unknown

          +Section: 18.6 [lib.support.exception], 18.6.4 [lib.uncaught]  Status: TC  Submitter: Steve Clamage  Date: Unknown

          In article 3E04@pratique.fr, Valentin Bonnard writes:

          uncaught_exception() doesn't have a throw specification.

          @@ -2164,7 +2168,7 @@ exception safety is very important.

          In 15.5.3 [except.uncaught], paragraph 1, 18.6 [lib.support.exception], and 18.6.4 [lib.uncaught], add "throw()" to uncaught_exception().

          71. Do_get_monthname synopsis missing argument

          -Section: 22.2.5.1 [lib.locale.time.get]  Status: DR  Submitter: Nathan Myers  Date: 13 Aug 1998

          +Section: 22.2.5.1 [lib.locale.time.get]  Status: TC  Submitter: Nathan Myers  Date: 13 Aug 1998

          The locale facet member time_get<>::do_get_monthname is described in 22.2.5.1.2 [lib.locale.time.get.virtuals] with five arguments, consistent with do_get_weekday and with its specified use by member @@ -2180,7 +2184,7 @@ the declaration of member do_monthname as follows:

          74. Garbled text for codecvt::do_max_length

          -Section: 22.2.1.5.2 [lib.locale.codecvt.virtuals]  Status: DR  Submitter: Matt Austern  Date: 8 Sep 1998

          +Section: 22.2.1.5.2 [lib.locale.codecvt.virtuals]  Status: TC  Submitter: Matt Austern  Date: 8 Sep 1998

          The text of codecvt::do_max_length's "Returns" clause (22.2.1.5.2, paragraph 11) is garbled. It has unbalanced parentheses and a spurious n.

          @@ -2197,7 +2201,7 @@ following:

          75. Contradiction in codecvt::length's argument types

          -Section: 22.2.1.5 [lib.locale.codecvt]  Status: DR  Submitter:  Matt +Section: 22.2.1.5 [lib.locale.codecvt]  Status: TC  Submitter:  Matt Austern  Date:  18 Sep 1998

          The class synopses for classes codecvt<> (22.2.1.5) and codecvt_byname<> (22.2.1.6) say that the first @@ -2349,14 +2353,14 @@ return value.]

          78. Typo: event_call_back

          -Section: 27.4.2 [lib.ios.base]  Status: DR  Submitter: Nico Josuttis  Date: 29 Sep 1998

          +Section: 27.4.2 [lib.ios.base]  Status: TC  Submitter: Nico Josuttis  Date: 29 Sep 1998

          typo: event_call_back should be event_callback  

          Proposed resolution:

          In the 27.4.2 [lib.ios.base] synopsis change "event_call_back" to "event_callback".

          79. Inconsistent declaration of polar()

          -Section: 26.2.1 [lib.complex.synopsis], 26.2.7 [lib.complex.value.ops]  Status: DR  Submitter: Nico Josuttis  Date: 29 Sep 1998

          +Section: 26.2.1 [lib.complex.synopsis], 26.2.7 [lib.complex.value.ops]  Status: TC  Submitter: Nico Josuttis  Date: 29 Sep 1998

          In 26.2.1 [lib.complex.synopsis] polar is declared as follows:

             template<class T> complex<T> polar(const T&, const T&);
          @@ -2372,14 +2376,14 @@ return value.]

             template<class T> complex<T> polar(const T& rho, const T& theta = 0);

          80. Global Operators of complex declared twice

          -Section: 26.2.1 [lib.complex.synopsis], 26.2.2 [lib.complex]  Status: DR  Submitter: Nico Josuttis  Date: 29 Sep 1998

          +Section: 26.2.1 [lib.complex.synopsis], 26.2.2 [lib.complex]  Status: TC  Submitter: Nico Josuttis  Date: 29 Sep 1998

          Both 26.2.1 and 26.2.2 contain declarations of global operators for class complex. This redundancy should be removed.

          Proposed resolution:

          Reduce redundancy according to the general style of the standard.

          83. String::npos vs. string::max_size()

          -Section: 21.3 [lib.basic.string]  Status: DR  Submitter: Nico Josuttis  Date: 29 Sep 1998

          +Section: 21.3 [lib.basic.string]  Status: TC  Submitter: Nico Josuttis  Date: 29 Sep 1998

          Many string member functions throw if size is getting or exceeding npos. However, I wonder why they don't throw if size is getting or exceeding max_size() instead of npos. May be npos is known at compile @@ -2399,7 +2403,7 @@ described in this clause...") add a new paragraph:

          The LWG believes length_error is the correct exception to throw.

          86. String constructors don't describe exceptions

          -Section: 21.3.1 [lib.string.cons]  Status: DR  Submitter: Nico Josuttis  Date: 29 Sep 1998

          +Section: 21.3.1 [lib.string.cons]  Status: TC  Submitter: Nico Josuttis  Date: 29 Sep 1998

          The constructor from a range:

          template<class InputIterator> 
@@ -2419,7 +2423,7 @@ because they are subsumed by the general wording added by the
 resolution for issue 83.
          
 
          
 
          90. Incorrect description of operator >> for strings
          
-Section: 21.3.7.9  [lib.string.io]  Status: DR  Submitter: Nico Josuttis  Date: 29 Sep 1998
          
+Section: 21.3.7.9  [lib.string.io]  Status: TC  Submitter: Nico Josuttis  Date: 29 Sep 1998
          
 
          The effect of operator >> for strings contain the following item:
          
 
 
              isspace(c,getloc()) is true for the next available input
@@ -2553,7 +2557,7 @@ conversion from iterator to const_iterator.
 
          [Tokyo: The LWG crafted the proposed resolution and rationale.]
          
 
          
 
          106. Numeric library private members are implementation defined
          
-Section: 26.3.5  [lib.template.slice.array]  Status: DR  Submitter: AFNOR  Date: 7 Oct 1998
          
+Section: 26.3.5  [lib.template.slice.array]  Status: TC  Submitter: AFNOR  Date: 7 Oct 1998
          
 
          This is the only place in the whole standard where the implementation has to document
 something private.
          
 
          Proposed resolution:
          
@@ -2573,7 +2577,7 @@ Remove the comment which says "// remainder implementation defined" fr

        108. Lifetime of exception::what() return unspecified

        -Section: 18.6.1 [lib.exception]  Status: DR  Submitter: AFNOR  Date: 7 Oct 1998

        +Section: 18.6.1 [lib.exception]  Status: TC  Submitter: AFNOR  Date: 7 Oct 1998

        In 18.6.1, paragraphs 8-9, the lifetime of the return value of exception::what() is left unspecified. This issue has implications with exception safety of exception handling: some exceptions should @@ -2701,7 +2705,7 @@ Leave open - 1.]

        110. istreambuf_iterator::equal not const

        -Section: 24.5.3 [lib.istreambuf.iterator], 24.5.3.5 [lib.istreambuf.iterator::equal]  Status: DR  Submitter: Nathan Myers  Date: 15 Oct 1998

        +Section: 24.5.3 [lib.istreambuf.iterator], 24.5.3.5 [lib.istreambuf.iterator::equal]  Status: TC  Submitter: Nathan Myers  Date: 15 Oct 1998

        Member istreambuf_iterator<>::equal is not declared "const", yet 24.5.3.6 [lib.istreambuf.iterator::op==] says that operator==, which is const, calls it. This is contradictory.

        @@ -2720,7 +2724,7 @@ replace:

        112. Minor typo in ostreambuf_iterator constructor

        -Section: 24.5.4.1 [lib.ostreambuf.iter.cons]  Status: DR  Submitter: Matt Austern  Date: 20 Oct 1998

        +Section: 24.5.4.1 [lib.ostreambuf.iter.cons]  Status: TC  Submitter: Matt Austern  Date: 20 Oct 1998

        The requires clause for ostreambuf_iterator's constructor from an ostream_type (24.5.4.1, paragraph 1) reads "s is not null". However, s is a @@ -2740,7 +2744,7 @@ reading:

        114. Placement forms example in error twice

        -Section: 18.4.1.3 [lib.new.delete.placement]  Status: DR  Submitter: Steve Clamage  Date: 28 Oct 1998

        +Section: 18.4.1.3 [lib.new.delete.placement]  Status: TC  Submitter: Steve Clamage  Date: 28 Oct 1998

        Section 18.4.1.3 contains the following example: 

        [Example: This can be useful for constructing an object at a known address:
@@ -2766,7 +2770,7 @@ likely to fail.
        
 
 
        
 
        115. Typo in strstream constructors
        
-Section: D.7.4.1  [depr.strstream.cons]  Status: DR  Submitter: Steve Clamage  Date: 2 Nov 1998
        
+Section: D.7.4.1  [depr.strstream.cons]  Status: TC  Submitter: Steve Clamage  Date: 2 Nov 1998
        
 
        D.7.4.1 strstream constructors paragraph 2 says: 
        
 
 
        
@@ -2958,7 +2962,7 @@ operator>>(int& val);

        [Post-Tokyo: PJP provided the above wording.]

        119. Should virtual functions be allowed to strengthen the exception specification?

        -Section: 17.4.4.8 [lib.res.on.exception.handling]  Status: DR  Submitter: Judy Ward  Date: 15 Dec 1998

        +Section: 17.4.4.8 [lib.res.on.exception.handling]  Status: TC  Submitter: Judy Ward  Date: 15 Dec 1998

        Section 17.4.4.8 [lib.res.on.exception.handling] states:

        "An implementation may strengthen the exception-specification @@ -2992,7 +2996,7 @@ exception-specification for a function"

        exception-specification for a non-virtual function".

        122. streambuf/wstreambuf description should not say they are specializations

        -Section: 27.5.2 [lib.streambuf]  Status: DR  Submitter: Judy Ward  Date: 15 Dec 1998

        +Section: 27.5.2 [lib.streambuf]  Status: TC  Submitter: Judy Ward  Date: 15 Dec 1998

        Section 27.5.2 describes the streambuf classes this way:

        @@ -3016,7 +3020,7 @@ sentences).

        typedefs and that is sufficient.

        124. ctype_byname<charT>::do_scan_is & do_scan_not return type should be const charT*

        -Section: 22.2.1.2 [lib.locale.ctype.byname]  Status: DR  Submitter: Judy Ward  Date: 15 Dec 1998

        +Section: 22.2.1.2 [lib.locale.ctype.byname]  Status: TC  Submitter: Judy Ward  Date: 15 Dec 1998

        In Section 22.2.1.2 [lib.locale.ctype.byname] ctype_byname<charT>::do_scan_is() and do_scan_not() are declared to return a const char* not a const charT*.

        @@ -3026,7 +3030,7 @@ to return a const char* not a const charT*.

        charT*.

        125. valarray<T>::operator!() return type is inconsistent

        -Section: 26.3.2 [lib.template.valarray]  Status: DR  Submitter: Judy Ward  Date: 15 Dec 1998

        +Section: 26.3.2 [lib.template.valarray]  Status: TC  Submitter: Judy Ward  Date: 15 Dec 1998

        In Section 26.3.2 [lib.template.valarray] valarray<T>::operator!() is declared to return a valarray<T>, but in Section 26.3.2.5 [lib.valarray.unary] it is declared to return a valarray<bool>. The latter appears to be correct.

        @@ -3036,7 +3040,7 @@ latter appears to be correct.

        valarray<bool>.

        126. typos in Effects clause of ctype::do_narrow()

        -Section: 22.2.1.1.2 [lib.locale.ctype.virtuals]  Status: DR  Submitter: Judy Ward  Date: 15 Dec 1998

        +Section: 22.2.1.1.2 [lib.locale.ctype.virtuals]  Status: TC  Submitter: Judy Ward  Date: 15 Dec 1998

        Typos in 22.2.1.1.2 need to be fixed.

        Proposed resolution:

        In Section 22.2.1.1.2 [lib.locale.ctype.virtuals] change:

        @@ -3056,7 +3060,7 @@ latter appears to be correct. 

           (is(M,c) || !ctc.is(M, do_narrow(c,dfault)) )

        127. auto_ptr<> conversion issues

        -Section: 20.4.5 [lib.auto.ptr]  Status: DR  Submitter: Greg Colvin  Date: 17 Feb 1999

        +Section: 20.4.5 [lib.auto.ptr]  Status: TC  Submitter: Greg Colvin  Date: 17 Feb 1999

        There are two problems with the current auto_ptr wording in the standard:

        @@ -3122,7 +3126,7 @@ a public assignment operator to the auto_ptr definition:

        129. Need error indication from seekp() and seekg()

        -Section: 27.6.1.3 [lib.istream.unformatted], 27.6.2.4 [lib.ostream.seeks]  Status: DR  Submitter: Angelika Langer  Date: 22 Feb 1999

        +Section: 27.6.1.3 [lib.istream.unformatted], 27.6.2.4 [lib.ostream.seeks]  Status: TC  Submitter: Angelika Langer  Date: 22 Feb 1999

        Currently, the standard does not specify how seekg() and seekp() indicate failure. They are not required to set failbit, and they can't return an error indication because they must return *this, i.e. the @@ -3146,7 +3150,7 @@ stream state in case of failure.

        Setting failbit is the usual error reporting mechanism for streams

        132. list::resize description uses random access iterators

        -Section: 23.2.2.2 [lib.list.capacity]  Status: DR  Submitter: Howard Hinnant  Date: 6 Mar 1999

        +Section: 23.2.2.2 [lib.list.capacity]  Status: TC  Submitter: Howard Hinnant  Date: 6 Mar 1999

        The description reads:

        -1- Effects:

        @@ -3178,7 +3182,7 @@ with David Abrahams. They had a discussion and believe there is no issue of exception safety with the proposed resolution.]

        133. map missing get_allocator()

        -Section: 23.3.1 [lib.map]  Status: DR  Submitter: Howard Hinnant  Date: 6 Mar 1999

        +Section: 23.3.1 [lib.map]  Status: TC  Submitter: Howard Hinnant  Date: 6 Mar 1999

        The title says it all.

        Proposed resolution:

        Insert in 23.3.1 [lib.map], paragraph 2, @@ -3187,7 +3191,7 @@ after operator= in the map declaration:

            allocator_type get_allocator() const;

        134. vector constructors over specified

        -Section: 23.2.4.1 [lib.vector.cons]  Status: DR  Submitter: Howard Hinnant  Date: 6 Mar 1999

        +Section: 23.2.4.1 [lib.vector.cons]  Status: TC  Submitter: Howard Hinnant  Date: 6 Mar 1999

        The complexity description says: "It does at most 2N calls to the copy constructor of T and logN reallocations if they are just input iterators ...".

        @@ -3272,7 +3276,7 @@ for basic_streambuf<>::seekpos, or for basic_filebuf<>::seekoff or basic_filebuf<>::seekpos.]

        137. Do use_facet and has_facet look in the global locale?

        -Section: 22.1.1 [lib.locale]  Status: DR  Submitter: Angelika Langer  Date: 17 Mar 1999

        +Section: 22.1.1 [lib.locale]  Status: TC  Submitter: Angelika Langer  Date: 17 Mar 1999

        Section 22.1.1 [lib.locale] says:

        -4- In the call to use_facet<Facet>(loc), the type argument @@ -3301,7 +3305,7 @@ from section 22.1.1.

        in the standard.

        139. Optional sequence operation table description unclear

        -Section: 23.1.1 [lib.sequence.reqmts]  Status: DR  Submitter: Andrew Koenig  Date: 30 Mar 1999

        +Section: 23.1.1 [lib.sequence.reqmts]  Status: TC  Submitter: Andrew Koenig  Date: 30 Mar 1999

        The sentence introducing the Optional sequence operation table (23.1.1 paragraph 12) has two problems:

        @@ -3325,7 +3329,7 @@ with:

        141. basic_string::find_last_of, find_last_not_of say pos instead of xpos

        -Section: 21.3.6.4 [lib.string::find.last.of], 21.3.6.6 [lib.string::find.last.not.of]  Status: DR  Submitter: Arch Robison  Date: 28 Apr 1999

        +Section: 21.3.6.4 [lib.string::find.last.of], 21.3.6.6 [lib.string::find.last.not.of]  Status: TC  Submitter: Arch Robison  Date: 28 Apr 1999

        Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1 surely have misprints where they say:

        @@ -3347,7 +3351,7 @@ proposed resolution.]

        142. lexicographical_compare complexity wrong

        -Section: 25.3.8 [lib.alg.lex.comparison]  Status: DR  Submitter: Howard Hinnant  Date: 20 Jun 1999

        +Section: 25.3.8 [lib.alg.lex.comparison]  Status: TC  Submitter: Howard Hinnant  Date: 20 Jun 1999

        The lexicographical_compare complexity is specified as:

             "At most min((last1 - first1), (last2 - first2)) @@ -3381,7 +3385,7 @@ right! (and Matt states this complexity in his book)

        144. Deque constructor complexity wrong

        -Section: 23.2.1.1 [lib.deque.cons]  Status: DR  Submitter: Herb Sutter  Date: 9 May 1999

        +Section: 23.2.1.1 [lib.deque.cons]  Status: TC  Submitter: Herb Sutter  Date: 9 May 1999

        In 23.2.1.1 paragraph 6, the deque ctor that takes an iterator range appears to have complexity requirements which are incorrect, and which contradict the complexity requirements for insert(). I suspect that the text in question, @@ -3413,7 +3417,7 @@ typo):

        146. complex<T> Inserter and Extractor need sentries

        -Section: 26.2.6 [lib.complex.ops]  Status: DR  Submitter: Angelika Langer  Date: 12 May 1999

        +Section: 26.2.6 [lib.complex.ops]  Status: TC  Submitter: Angelika Langer  Date: 12 May 1999

        The extractor for complex numbers is specified as: 

        @@ -3488,7 +3492,7 @@ follows an "all-or-none" rule.

        as written.

        147. Library Intro refers to global functions that aren't global

        -Section: 17.4.4.3 [lib.global.functions]  Status: DR  Submitter: Lois Goldthwaite  Date: 4 Jun 1999

        +Section: 17.4.4.3 [lib.global.functions]  Status: TC  Submitter: Lois Goldthwaite  Date: 4 Jun 1999

        The library had many global functions until 17.4.1.1 [lib.contents] paragraph 2 was added:

        @@ -3552,7 +3556,7 @@ was changed from "non-member" to "global or non-member.

        148. Functions in the example facet BoolNames should be const

        -Section: 22.2.8 [lib.facets.examples]  Status: DR  Submitter: Jeremy Siek  Date: 3 Jun 1999

        +Section: 22.2.8 [lib.facets.examples]  Status: TC  Submitter: Jeremy Siek  Date: 3 Jun 1999

        In 22.2.8 [lib.facets.examples] paragraph 13, the do_truename() and do_falsename() functions in the example facet BoolNames should be const. The functions they are overriding in @@ -3566,7 +3570,7 @@ two places:

        150. Find_first_of says integer instead of iterator

        -Section: 25.1.4 [lib.alg.find.first.of]  Status: DR  Submitter: Matt McClure  Date: 30 Jun 1999

        +Section: 25.1.4 [lib.alg.find.first.of]  Status: TC  Submitter: Matt McClure  Date: 30 Jun 1999

        Proposed resolution:

        Change 25.1.4 [lib.alg.find.first.of] paragraph 2 from:

        @@ -3583,7 +3587,7 @@ that for some iterator j in the range [first2, last2) ...

        151. Can't currently clear() empty container

        -Section: 23.1.1 [lib.sequence.reqmts]  Status: DR  Submitter: Ed Brey  Date: 21 Jun 1999

        +Section: 23.1.1 [lib.sequence.reqmts]  Status: TC  Submitter: Ed Brey  Date: 21 Jun 1999

        For both sequences and associative containers, a.clear() has the semantics of erase(a.begin(),a.end()), which is undefined for an empty container since erase(q1,q2) requires that q1 be dereferenceable @@ -3622,7 +3626,7 @@ iterators or certain kinds of iterators is unnecessary.

        152. Typo in scan_is() semantics

        -Section: 22.2.1.1.2 [lib.locale.ctype.virtuals]  Status: DR  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        +Section: 22.2.1.1.2 [lib.locale.ctype.virtuals]  Status: TC  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        The semantics of scan_is() (paragraphs 4 and 6) is not exactly described because there is no function is() which only takes a character as argument. Also, in the effects clause (paragraph 3), the semantic is also kept @@ -3684,7 +3688,7 @@ same paragraphs.]

        154. Missing double specifier for do_get()

        -Section: 22.2.2.1.2 [lib.facet.num.get.virtuals]  Status: DR  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        +Section: 22.2.2.1.2 [lib.facet.num.get.virtuals]  Status: TC  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        The table in paragraph 7 for the length modifier does not list the length modifier l to be applied if the type is double. Thus, the standard asks the implementation to do undefined things when using scanf() @@ -3699,7 +3703,7 @@ Modifier table to say that for double a length modifier

        155. Typo in naming the class defining the class Init

        -Section: 27.3 [lib.iostream.objects]  Status: DR  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        +Section: 27.3 [lib.iostream.objects]  Status: TC  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        There are conflicting statements about where the class Init is defined. According to 27.3 [lib.iostream.objects] paragraph 2 it is defined as basic_ios::Init, according to 27.4.2 [lib.ios.base] it is defined as ios_base::Init.

        @@ -3712,7 +3716,7 @@ it is defined as basic_ios::Init, according to 27.4.2

        156. Typo in imbue() description

        -Section: 27.4.2.3 [lib.ios.base.locales]  Status: DR  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        +Section: 27.4.2.3 [lib.ios.base.locales]  Status: TC  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        There is a small discrepancy between the declarations of imbue(): in 27.4.2 [lib.ios.base] the argument is passed as locale const& (correct), in 27.4.2.3 [lib.ios.base.locales] it @@ -3725,7 +3729,7 @@ const&".

        158. Underspecified semantics for setbuf()

        -Section: 27.5.2.4.2 [lib.streambuf.virt.buffer]  Status: DR  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        +Section: 27.5.2.4.2 [lib.streambuf.virt.buffer]  Status: TC  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        The default behavior of setbuf() is described only for the situation that gptr() != 0 && gptr() != egptr(): namely to do nothing. What has to be done in other situations  @@ -3742,7 +3746,7 @@ to: "Default behavior: Does nothing. Returns this."

        159. Strange use of underflow()

        -Section: 27.5.2.4.3 [lib.streambuf.virt.get]  Status: DR  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        +Section: 27.5.2.4.3 [lib.streambuf.virt.get]  Status: TC  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        The description of the meaning of the result of showmanyc() seems to be rather strange: It uses calls to underflow(). Using underflow() is strange because @@ -3757,7 +3761,7 @@ stream".

        160. Typo: Use of non-existing function exception()

        -Section: 27.6.1.1 [lib.istream]  Status: DR  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        +Section: 27.6.1.1 [lib.istream]  Status: TC  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        The paragraph 4 refers to the function exception() which is not defined. Probably, the referred function is basic_ios<>::exceptions().

        @@ -3772,7 +3776,7 @@ is the correct spelling.]

        161. Typo: istream_iterator vs. istreambuf_iterator

        -Section: 27.6.1.2.2 [lib.istream.formatted.arithmetic]  Status: DR  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        +Section: 27.6.1.2.2 [lib.istream.formatted.arithmetic]  Status: TC  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        The note in the second paragraph pretends that the first argument is an object of type istream_iterator. This is wrong: It is an object of type istreambuf_iterator.

        @@ -3787,7 +3791,7 @@ an object of type istreambuf_iterator.

        164. do_put() has apparently unused fill argument

        -Section: 22.2.5.3.2 [lib.locale.time.put.virtuals]  Status: DR  Submitter: Angelika Langer  Date: 23 Jul 1999

        +Section: 22.2.5.3.2 [lib.locale.time.put.virtuals]  Status: TC  Submitter: Angelika Langer  Date: 23 Jul 1999

        In 22.2.5.3.2 [lib.locale.time.put.virtuals] the do_put() function is specified as taking a fill character as an argument, but the description of the function does not say whether the character is used at all and, if so, @@ -3857,7 +3861,7 @@ called from what functions and eg to state specifically that flush() is allowed to call sync() while other functions are not.]

        168. Typo: formatted vs. unformatted

        -Section: 27.6.2.6 [lib.ostream.unformatted]  Status: DR  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        +Section: 27.6.2.6 [lib.ostream.unformatted]  Status: TC  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        The first paragraph begins with a descriptions what has to be done in formatted output functions. Probably this is a typo and the paragraph really want to describe unformatted output functions...

        @@ -3872,7 +3876,7 @@ sentences, change the word "formatted" to

        169. Bad efficiency of overflow() mandated

        -Section: 27.7.1.3 [lib.stringbuf.virtuals]  Status: DR  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        +Section: 27.7.1.3 [lib.stringbuf.virtuals]  Status: TC  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        Paragraph 8, Notes, of this section seems to mandate an extremely inefficient way of buffer handling for basic_stringbuf, especially in view of the restriction that basic_ostream @@ -3894,7 +3898,7 @@ solution is to handle this in underflow().

        170. Inconsistent definition of traits_type

        -Section: 27.7.4 [lib.stringstream]  Status: DR  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        +Section: 27.7.4 [lib.stringstream]  Status: TC  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        The classes basic_stringstream (27.7.4 [lib.stringstream]), basic_istringstream (27.7.2 [lib.istringstream]), and basic_ostringstream (27.7.3 [lib.ostringstream]) are inconsistent @@ -3964,7 +3968,7 @@ paragraph 14 from:

        172. Inconsistent types for basic_istream::ignore()

        -Section: 27.6.1.3 [lib.istream.unformatted]  Status: DR  Submitter: Greg Comeau, Dietmar Kühl  Date: 23 Jul 1999

        +Section: 27.6.1.3 [lib.istream.unformatted]  Status: TC  Submitter: Greg Comeau, Dietmar Kühl  Date: 23 Jul 1999

        In 27.6.1.1 [lib.istream] the function ignore() gets an object of type streamsize as first argument. However, in 27.6.1.3 [lib.istream.unformatted] @@ -3989,7 +3993,7 @@ of int in the description of ignore() to

        173. Inconsistent types for basic_filebuf::setbuf()

        -Section: 27.8.1.4 [lib.filebuf.virtuals]  Status: DR  Submitter: Greg Comeau, Dietmar Kühl  Date: 23 Jul 1999

        +Section: 27.8.1.4 [lib.filebuf.virtuals]  Status: TC  Submitter: Greg Comeau, Dietmar Kühl  Date: 23 Jul 1999

        In 27.8.1.1 [lib.filebuf] the function setbuf() gets an @@ -4013,7 +4017,7 @@ as described in issue 172.

        174. Typo: OFF_T vs. POS_T

        -Section: D.6 [depr.ios.members]  Status: DR  Submitter: Dietmar Kühl  Date: 23 Jul 1999

        +Section: D.6 [depr.ios.members]  Status: TC  Submitter: Dietmar Kühl  Date: 23 Jul 1999

        According to paragraph 1 of this section, streampos is the type OFF_T, the same type as streamoff. However, in paragraph 6 the streampos gets the type POS_T @@ -4024,7 +4028,7 @@ OFF_T streampos;" to "typedef POS_T streampos;"

        175. Ambiguity for basic_streambuf::pubseekpos() and a few other functions.

        -Section: D.6 [depr.ios.members]  Status: DR  Submitter: Dietmar Kühl  Date: 23 Jul 1999

        +Section: D.6 [depr.ios.members]  Status: TC  Submitter: Dietmar Kühl  Date: 23 Jul 1999

        According to paragraph 8 of this section, the methods basic_streambuf::pubseekpos(), basic_ifstream::open(), and basic_ofstream::open @@ -4044,7 +4048,7 @@ argument is not specified.

        176. exceptions() in ios_base...?

        -Section: D.6 [depr.ios.members]  Status: DR  Submitter: Dietmar Kühl  Date: 23 Jul 1999

        +Section: D.6 [depr.ios.members]  Status: TC  Submitter: Dietmar Kühl  Date: 23 Jul 1999

        The "overload" for the function exceptions() in paragraph 8 gives the impression that there is another function of this function defined in class ios_base. However, this is not @@ -4056,7 +4060,7 @@ in clause 27 [lib.input.output]exceptions()into class basic_ios.

        181. make_pair() unintended behavior

        -Section: 20.2.2 [lib.pairs]  Status: DR  Submitter: Andrew Koenig  Date: 3 Aug 1999

        +Section: 20.2.2 [lib.pairs]  Status: TC  Submitter: Andrew Koenig  Date: 3 Aug 1999

        The claim has surfaced in Usenet that expressions such as

               make_pair("abc", 3)
        @@ -4549,7 +4553,7 @@ the case that users cannot rely on the type of a pointer to a nonvirtual member of a standard library class.

        189. setprecision() not specified correctly

        -Section: 27.4.2.2 [lib.fmtflags.state]  Status: DR  Submitter: Andrew Koenig  Date: 25 Aug 1999

        +Section: 27.4.2.2 [lib.fmtflags.state]  Status: TC  Submitter: Andrew Koenig  Date: 25 Aug 1999

        27.4.2.2 paragraph 9 claims that setprecision() sets the precision, and includes a parenthetical note saying that it is the number of digits after the decimal point.
        @@ -4566,7 +4570,7 @@ correct the statement in 27.4.2.2

        "(number of digits after the decimal point)".

        193. Heap operations description incorrect

        -Section: 25.3.6 [lib.alg.heap.operations]  Status: DR  Submitter: Markus Mauhart  Date: 24 Sep 1999

        +Section: 25.3.6 [lib.alg.heap.operations]  Status: TC  Submitter: Markus Mauhart  Date: 24 Sep 1999

        25.3.6 [lib.alg.heap.operations] states two key properties of a heap [a,b), the first of them is

        @@ -4593,7 +4597,7 @@ resolution.

        195. Should basic_istream::sentry's constructor ever set eofbit?

        -Section: 27.6.1.1.2 [lib.istream::sentry]  Status: DR  Submitter: Matt Austern  Date: 13 Oct 1999

        +Section: 27.6.1.1.2 [lib.istream::sentry]  Status: TC  Submitter: Matt Austern  Date: 13 Oct 1999

        Suppose that is.flags() & ios_base::skipws is nonzero. What should basic_istream<>::sentry's constructor do if it reaches eof while skipping whitespace? 27.6.1.1.2/5 suggests it @@ -4768,7 +4772,7 @@ predefined iterators are as strong as users expect.

        199. What does allocate(0) return?

        -Section: 20.1.5 [lib.allocator.requirements]  Status: DR  Submitter: Matt Austern  Date: 19 Nov 1999

        +Section: 20.1.5 [lib.allocator.requirements]  Status: TC  Submitter: Matt Austern  Date: 19 Nov 1999

        Suppose that A is a class that conforms to the Allocator requirements of Table 32, and a is an @@ -4791,7 +4795,7 @@ would be over-specification to mandate the return value.

        208. Unnecessary restriction on past-the-end iterators

        -Section: 24.1 [lib.iterator.requirements]  Status: DR  Submitter: Stephen Cleary  Date: 02 Feb 2000

        +Section: 24.1 [lib.iterator.requirements]  Status: TC  Submitter: Stephen Cleary  Date: 02 Feb 2000

        In 24.1 paragraph 5, it is stated ". . . Dereferenceable and past-the-end values are always non-singular."

        This places an unnecessary restriction on past-the-end iterators for @@ -4818,7 +4822,7 @@ iterators. Null pointers are singular.

        209. basic_string declarations inconsistent

        -Section: 21.3 [lib.basic.string]  Status: DR  Submitter: Igor Stauder  Date: 11 Feb 2000

        +Section: 21.3 [lib.basic.string]  Status: TC  Submitter: Igor Stauder  Date: 11 Feb 2000

        In Section 21.3 [lib.basic.string] the basic_string member function declarations use a consistent style except for the following functions:

        @@ -4848,7 +4852,7 @@ change.

        210. distance first and last confused

        -Section: 25 [lib.algorithms]  Status: DR  Submitter: Lisa Lippincott  Date: 15 Feb 2000

        +Section: 25 [lib.algorithms]  Status: TC  Submitter: Lisa Lippincott  Date: 15 Feb 2000

        In paragraph 9 of section 25 [lib.algorithms], it is written:

        In the description of the algorithms operators + and - are used @@ -4869,7 +4873,7 @@ or change the return to distance(b,a). The LWG preferred the former for consistency.

        211. operator>>(istream&, string&) doesn't set failbit

        -Section: 21.3.7.9 [lib.string.io]  Status: DR  Submitter: Scott Snyder  Date: 4 Feb 2000

        +Section: 21.3.7.9 [lib.string.io]  Status: TC  Submitter: Scott Snyder  Date: 4 Feb 2000

        The description of the stream extraction operator for std::string (section 21.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in the case that the operator fails to extract any characters from the input @@ -4897,7 +4901,7 @@ is.setstate(ios::failbit) which may throw ios_base::failure

        212. Empty range behavior unclear for several algorithms

        -Section: 25.3.7 [lib.alg.min.max]  Status: DR  Submitter: Nico Josuttis  Date: 26 Feb 2000

        +Section: 25.3.7 [lib.alg.min.max]  Status: TC  Submitter: Nico Josuttis  Date: 26 Feb 2000

        The standard doesn't specify what min_element() and max_element() shall return if the range is empty (first equals last). The usual implementations return last. This problem seems also apply to partition(), stable_partition(), @@ -4940,7 +4944,7 @@ extending the proposed resolution to lower_bound, upper_bound, and equal_range.]

        217. Facets example (Classifying Japanese characters) contains errors

        -Section: 22.2.8 [lib.facets.examples]  Status: DR  Submitter: Martin Sebor  Date: 29 Feb 2000

        +Section: 22.2.8 [lib.facets.examples]  Status: TC  Submitter: Martin Sebor  Date: 29 Feb 2000

        The example in 22.2.8, paragraph 11 contains the following errors:

        1) The member function `My::JCtype::is_kanji()' is non-const; the function must be const in order for it to be callable on a const object (a reference to @@ -4984,7 +4988,7 @@ declared above. }

        220. ~ios_base() usage valid?

        -Section: 27.4.2.7 [lib.ios.base.cons]  Status: DR  Submitter: Jonathan Schilling, Howard Hinnant  Date: 13 Mar 2000

        +Section: 27.4.2.7 [lib.ios.base.cons]  Status: TC  Submitter: Jonathan Schilling, Howard Hinnant  Date: 13 Mar 2000

        The pre-conditions for the ios_base destructor are described in 27.4.2.7 paragraph 2:

        @@ -5060,7 +5064,7 @@ of digits will not be recognized. This design decision was made deliberately, with full knowledge of that limitation.

        222. Are throw clauses necessary if a throw is already implied by the effects clause?

        -Section: 17.3.1.3 [lib.structure.specifications]  Status: DR  Submitter: Judy Ward  Date: 17 Mar 2000

        +Section: 17.3.1.3 [lib.structure.specifications]  Status: TC  Submitter: Judy Ward  Date: 17 Mar 2000

        Section 21.3.6.8 describes the basic_string::compare function this way:

        21.3.6.8 - basic_string::compare [lib.string::compare]
@@ -5102,7 +5106,7 @@ non-normative. The proposed resolution from the LWG clarifies the
 footnote.
        
 
        
 
        223. reverse algorithm should use iter_swap rather than swap
        
-Section: 25.2.9  [lib.alg.reverse]  Status: DR  Submitter: Dave Abrahams  Date: 21 Mar 2000
        
+Section: 25.2.9  [lib.alg.reverse]  Status: TC  Submitter: Dave Abrahams  Date: 21 Mar 2000
        
 
        Shouldn't the effects say "applies iter_swap to all pairs..."?
        
 
        Proposed resolution:
        
 
        In 25.2.9  [lib.alg.reverse], replace:
        
@@ -5117,7 +5121,7 @@ footnote.

        224. clear() complexity for associative containers refers to undefined N

        -Section: 23.1.2 [lib.associative.reqmts]  Status: DR  Submitter: Ed Brey  Date: 23 Mar 2000

        +Section: 23.1.2 [lib.associative.reqmts]  Status: TC  Submitter: Ed Brey  Date: 23 Mar 2000

        In the associative container requirements table in 23.1.2 paragraph 7, a.clear() has complexity "log(size()) + N". However, the meaning of N is not defined.

        @@ -5132,7 +5136,7 @@ log(N)). The text in the standard is probably an incorrect cut-and-paste from the range version of erase.

        227. std::swap() should require CopyConstructible or DefaultConstructible arguments

        -Section: 25.2.2 [lib.alg.swap]  Status: DR  Submitter: Dave Abrahams  Date: 09 Apr 2000

        +Section: 25.2.2 [lib.alg.swap]  Status: TC  Submitter: Dave Abrahams  Date: 09 Apr 2000

        25.2.2 reads:

        diff --git a/libstdc++-v3/docs/html/faq/index.html b/libstdc++-v3/docs/html/faq/index.html index 6e5266c..f7a9b0a 100644 --- a/libstdc++-v3/docs/html/faq/index.html +++ b/libstdc++-v3/docs/html/faq/index.html @@ -70,7 +70,8 @@

      • _XOPEN_SOURCE / _GNU_SOURCE / etc is always defined
        • -
      • OS X ctype.h is broken! How can I hack it?
        • +
      • OS X ctype.h is broken! How can I hack it?
        • +
      • Threading is broken on i386
        • @@ -498,6 +499,18 @@ which is no longer available, thanks deja...-->

        +

        Threading is broken on i386

        +

        Support for atomic integer operations is/was broken on i386 + platforms. The assembly code accidentally used opcodes that are + only available on the i486 and later. So if you configured GCC + to target, for example, i386-linux, but actually used the programs + on an i686, then you would encounter no problems. Only when + actually running the code on a i386 will the problem appear. +

        +

        This is fixed in 3.2.2. +

        + +

        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 diff --git a/libstdc++-v3/docs/html/faq/index.txt b/libstdc++-v3/docs/html/faq/index.txt index b3ca4fc..3ea9059 100644 --- a/libstdc++-v3/docs/html/faq/index.txt +++ b/libstdc++-v3/docs/html/faq/index.txt @@ -1,8 +1,8 @@ libstdc++ Frequently Asked Questions - The latest version of this document is always available at - [1]http://gcc.gnu.org/onlinedocs/libstdc++/faq/. The main + The latest version of this document is always available at + [1]http://gcc.gnu.org/onlinedocs/libstdc++/faq/. The main documentation page is at [2]http://gcc.gnu.org/onlinedocs/libstdc++/documentation.html. @@ -34,31 +34,32 @@ 4. [24]I can't use 'long long' on Solaris 5. [25]_XOPEN_SOURCE / _GNU_SOURCE / etc is always defined 6. [26]OS X ctype.h is broken! How can I hack it? - 4. [27]Known Bugs and Non-Bugs - 1. [28]What works already? - 2. [29]Bugs in gcc/g++ (not libstdc++-v3) - 3. [30]Bugs in the C++ language/lib specification - 4. [31]Things in libstdc++ that only look like bugs - o [32]reopening a stream fails - o [33]-Weffc++ complains too much - o [34]"ambiguous overloads" after including an old-style + 7. [27]Threading is broken on i386 + 4. [28]Known Bugs and Non-Bugs + 1. [29]What works already? + 2. [30]Bugs in gcc/g++ (not libstdc++-v3) + 3. [31]Bugs in the C++ language/lib specification + 4. [32]Things in libstdc++ that only look like bugs + o [33]reopening a stream fails + o [34]-Weffc++ complains too much + o [35]"ambiguous overloads" after including an old-style header - o [35]The g++-3 headers are not ours - o [36]compilation errors from streambuf.h - o [37]errors about *Concept and constraints in the STL... - o [38]program crashes when using library code in a + o [36]The g++-3 headers are not ours + o [37]compilation errors from streambuf.h + o [38]errors about *Concept and constraints in the STL... + o [39]program crashes when using library code in a dynamically-loaded library - 5. [39]Aw, that's easy to fix! - 5. [40]Miscellaneous - 1. [41]string::iterator is not char*; vector::iterator is not + 5. [40]Aw, that's easy to fix! + 5. [41]Miscellaneous + 1. [42]string::iterator is not char*; vector::iterator is not T* - 2. [42]What's next after libstdc++-v3? - 3. [43]What about the STL from SGI? - 4. [44]Extensions and Backward Compatibility - 5. [45][removed] - 6. [46]Is libstdc++-v3 thread-safe? - 7. [47]How do I get a copy of the ISO C++ Standard? - 8. [48]What's an ABI and why is it so messy? + 2. [43]What's next after libstdc++-v3? + 3. [44]What about the STL from SGI? + 4. [45]Extensions and Backward Compatibility + 5. [46][removed] + 6. [47]Is libstdc++-v3 thread-safe? + 7. [48]How do I get a copy of the ISO C++ Standard? + 8. [49]What's an ABI and why is it so messy? _________________________________________________________________ 1.0 General Information @@ -66,117 +67,117 @@ 1.1 What is libstdc++-v3? The GNU Standard C++ Library v3 is an ongoing project to implement the - ISO 14882 Standard C++ library as described in chapters 17 through 27 + 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 latest release is [49]the fourteenth + a snapshot and released. The latest release is [50]the fourteenth snapshot but newer versions have been included in recent GCC releases. - 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 [50]1.4 below). + 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 [51]1.4 below). - The older libstdc++-v2 project is no longer maintained; the code has - been completely replaced and rewritten. [51]If you are using V2, then + The older libstdc++-v2 project is no longer maintained; the code has + been completely replaced and rewritten. [52]If you are using V2, then you need to report bugs to your system vendor, not to the V3 list. A more formal description of the V3 goals can be found in the official - [52]design document. + [53]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 + 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 + 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 [53]GCC team. All of - the rapid development and near-legendary [54]portability that are the + development has recently been taken over by the [54]GCC team. All of + the rapid development and near-legendary [55]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 + 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 incompatibilities. _________________________________________________________________ 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, Ulrich Drepper, Loren James Rittle, and Paolo + the world, in the same way as GCC or Linux. Benjamin Kosnik, Gabriel + Dos Reis, Phil Edwards, Ulrich Drepper, Loren James Rittle, and Paolo Carlini are the lead maintainers of the 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 [55]homepage. + 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 [56]homepage. If you have questions, ideas, code, or are just curious, sign up! _________________________________________________________________ 1.4 How do I get libstdc++? - The fourteenth (and latest) snapshot of libstdc++-v3 is [56]available + The fourteenth (and latest) snapshot of libstdc++-v3 is [57]available via ftp. - The [57]homepage has instructions for retrieving the latest CVS + The [58]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 final release of the SGI + The subset commonly known as the Standard Template Library (chapters + 23 through 25, mostly) is adapted from the final release of the SGI STL. _________________________________________________________________ 1.5 When is libstdc++ going to be finished? - Nathan Myers gave the best of all possible answers, responding to a + 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 [58]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. + Here is [59]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 + 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 + 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) + 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 + 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 + 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 + 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 [59]Boost site houses free C++ libraries that do varying things, - and happened to be started by members of the Standards Committee. + (The [60]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 [60]GCC FAQ describes where to find + For the bold and/or desperate, the [61]GCC FAQ describes where to find the last libg++ source. _________________________________________________________________ @@ -184,65 +185,65 @@ 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 [61]libstdc++@gcc.gnu.org. + 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 [62]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 [62]Phil - Edwards or [63]Gabriel Dos Reis. + If you have a question that you think should be included here, or if + you have a question about a question/answer here, contact [63]Phil + Edwards or [64]Gabriel Dos Reis. _________________________________________________________________ 1.9 What are the license terms for libstdc++-v3? - See [64]our license description for these and related questions. + See [65]our license description for these and related questions. _________________________________________________________________ 2.0 Installation 2.1 How do I install libstdc++-v3? - Complete instructions are not given here (this is a FAQ, not an + Complete instructions are not given here (this is a FAQ, not an installation document), but the tools required are few: - * A 3.x release of GCC. Note that building GCC is much easier and + * A 3.x release of GCC. Note that building GCC is much easier and more automated than building the GCC 2.[78] series was. If you are - using GCC 2.95, you can still build earlier snapshots of + using GCC 2.95, you can still build earlier snapshots of libstdc++. * GNU Make is recommended, but should not be required. * The GNU Autotools are needed if you are messing with the configury or makefiles. - The file [65]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, as well as patches and instructions for working with GCC + The file [66]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, as well as patches and instructions for working with GCC 2.95. - The top-level install.html and [66]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/" + The top-level install.html and [67]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 [removed] - This question has become moot and has been removed. The stub is here + This question has become moot and has been removed. The stub is here to preserve numbering (and hence links/bookmarks). _________________________________________________________________ 2.3 What is this CVS thing that you keep mentioning? - The Concurrent Versions System is one of several revision control + 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 [67]CVS entry in the GNU - software catalogue has a better description as well as a [68]link to + free (beer), and very high quality. The [68]CVS entry in the GNU + software catalogue has a better description as well as a [69]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" + After the first of April, American users will have a "/pharmacy" command-line option... _________________________________________________________________ @@ -251,61 +252,61 @@ libstdc++-v3 comes with its own testsuite. You do not need to actually install the library ("make install") to run the testsuite. - To run the testsuite on the library after building it, use "make - check" while in your build directory. To run the testsuite on the - library after building and installing it, use "make check-install" + To run the testsuite on the library after building it, use "make + check" while in your build directory. To run the testsuite on the + library after building and installing it, use "make check-install" instead. 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 + of a new test program that should be added to the suite, please write up your idea and send it to the list! _________________________________________________________________ 2.4 This library is HUGE! And what's libsupc++? - Usually the size of libraries on disk isn't noticeable. When a link - editor (or simply "linker") pulls things from a static archive - library, only the necessary object files are copied into your - executable, not the entire library. Unfortunately, even if you only - need a single function or variable from an object file, the entire - object file is extracted. (There's nothing unique to C++ or - libstdc++-v3 about this; it's just common behavior, given here for + Usually the size of libraries on disk isn't noticeable. When a link + editor (or simply "linker") pulls things from a static archive + library, only the necessary object files are copied into your + executable, not the entire library. Unfortunately, even if you only + need a single function or variable from an object file, the entire + object file is extracted. (There's nothing unique to C++ or + libstdc++-v3 about this; it's just common behavior, given here for background reasons.) - Some of the object files which make up libstdc++.a are rather large. + Some of the object files which make up libstdc++.a are rather large. If you create a statically-linked executable with -static, those large - object files are suddenly part of your executable. Historically the - best way around this was to only place a very few functions (often - only a single one) in each source/object file; then extracting a - single function is the same as extracting a single .o file. For - libstdc++-v3 this is only possible to a certain extent; the object - files in question contain template classes and template functions, - pre-instantiated, and splitting those up causes severe maintenance + object files are suddenly part of your executable. Historically the + best way around this was to only place a very few functions (often + only a single one) in each source/object file; then extracting a + single function is the same as extracting a single .o file. For + libstdc++-v3 this is only possible to a certain extent; the object + files in question contain template classes and template functions, + pre-instantiated, and splitting those up causes severe maintenance headaches. - It's not a bug, and it's not really a problem. Nevertheless, some + It's not a bug, and it's not really a problem. Nevertheless, some people don't like it, so here are two pseudo-solutions: - If the only functions from libstdc++.a which you need are language - support functions (those listed in [69]clause 18 of the standard, - e.g., new and delete), then try linking against libsupc++.a (usually - specifying -lsupc++ when calling g++ for the final link step will do + If the only functions from libstdc++.a which you need are language + support functions (those listed in [70]clause 18 of the standard, + e.g., new and delete), then try linking against libsupc++.a (usually + specifying -lsupc++ when calling g++ for the final link step will do it). This library contains only those support routines, one per object file. But if you are using anything from the rest of the library, such - as IOStreams or vectors, then you'll still need pieces from + as IOStreams or vectors, then you'll still need pieces from libstdc++.a. The second method is one we hope to incorporate into the library build - process. Some platforms can place each function and variable into its - own section in a .o file. The GNU linker can then perform garbage - collection on unused sections; this reduces the situation to only - copying needed functions into the executable, as before, but all + process. Some platforms can place each function and variable into its + own section in a .o file. The GNU linker can then perform garbage + collection on unused sections; this reduces the situation to only + copying needed functions into the executable, as before, but all happens automatically. - Unfortunately the garbage collection in GNU ld is buggy; sections - (corresponding to functions and variables) which are used are - mistakenly removed, leading to horrible crashes when your executable - starts up. For the time being, this feature is not used when building + Unfortunately the garbage collection in GNU ld is buggy; sections + (corresponding to functions and variables) which are used are + mistakenly removed, leading to horrible crashes when your executable + starts up. For the time being, this feature is not used when building the library. _________________________________________________________________ @@ -315,39 +316,39 @@ 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 + 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 + Since the goal of ISO Standardization is for all C++ implementations + to be able to share code, the final libstdc++ should, in theory, be usable under any ISO-compliant compiler. It will still be targeted and optimized for GCC/g++, however. _________________________________________________________________ 3.2 [removed] - This question has become moot and has been removed. The stub is here + This question has become moot and has been removed. The stub is here to preserve numbering (and hence links/bookmarks). _________________________________________________________________ 3.3 [removed] - This question has become moot and has been removed. The stub is here + This question has become moot and has been removed. The stub is here to preserve numbering (and hence links/bookmarks). _________________________________________________________________ 3.4 I can't use 'long long' on Solaris - By default we try to support the C99 long long type. This requires + By default we try to support the C99 long long type. This requires that certain functions from your C library be present. - Up through release 3.0.2 the tests performed were too general, and - this feature was disabled when it did not need to be. The most + Up through release 3.0.2 the tests performed were too general, and + this feature was disabled when it did not need to be. The most commonly reported platform affected was Solaris. This has been fixed for 3.0.3 and onwards. @@ -355,72 +356,84 @@ 3.5 _XOPEN_SOURCE / _GNU_SOURCE / etc is always defined - On Solaris, g++ (but not gcc) always defines the preprocessor macro - _XOPEN_SOURCE. On GNU/Linux, the same happens with _GNU_SOURCE. (This - is not an exhaustive list; other macros and other platforms are also + On Solaris, g++ (but not gcc) always defines the preprocessor macro + _XOPEN_SOURCE. On GNU/Linux, the same happens with _GNU_SOURCE. (This + is not an exhaustive list; other macros and other platforms are also affected.) - These macros are typically used in C library headers, guarding new - versions of functions from their older versions. The C++ standard - library includes the C standard library, but it requires the C90 - version, which for backwards-compatability reasons is often not the + These macros are typically used in C library headers, guarding new + versions of functions from their older versions. The C++ standard + library includes the C standard library, but it requires the C90 + version, which for backwards-compatability reasons is often not the default for many vendors. - More to the point, the C++ standard requires behavior which is only - available on certain platforms after certain symbols are defined. - Usually the issue involves I/O-related typedefs. In order to ensure + More to the point, the C++ standard requires behavior which is only + available on certain platforms after certain symbols are defined. + Usually the issue involves I/O-related typedefs. In order to ensure correctness, the compiler simply predefines those symbols. - Note that it's not enough to #define them only when the library is - being built (during installation). Since we don't have an 'export' - keyword, much of the library exists as headers, which means that the + Note that it's not enough to #define them only when the library is + being built (during installation). Since we don't have an 'export' + keyword, much of the library exists as headers, which means that the symbols must also be defined as your programs are parsed and compiled. - To see which symbols are defined, look for CPLUSPLUS_CPP_SPEC in the - gcc config headers for your target (and try changing them to see what - happens when building complicated code). You can also run "g++ -E -dM - - < /dev/null" to display a list of predefined macros for any + To see which symbols are defined, look for CPLUSPLUS_CPP_SPEC in the + gcc config headers for your target (and try changing them to see what + happens when building complicated code). You can also run "g++ -E -dM + - < /dev/null" to display a list of predefined macros for any particular installation. - This has been discussed on the mailing lists [70]quite a bit. + This has been discussed on the mailing lists [71]quite a bit. - This method is something of a wart. We'd like to find a cleaner + This method is something of a wart. We'd like to find a cleaner solution, but nobody yet has contributed the time. _________________________________________________________________ 3.6 OS X ctype.h is broken! How can I hack it? - This is a long-standing bug in the OS X support. Fortunately, the - patch is quite simple, and well-known. [71]Here's a link to the + This is a long-standing bug in the OS X support. Fortunately, the + patch is quite simple, and well-known. [72]Here's a link to the solution. _________________________________________________________________ +Threading is broken on i386 + + Support for atomic integer operations is/was broken on i386 platforms. + The assembly code accidentally used opcodes that are only available on + the i486 and later. So if you configured GCC to target, for example, + i386-linux, but actually used the programs on an i686, then you would + encounter no problems. Only when actually running the code on a i386 + will the problem appear. + + This is fixed in 3.2.2. + _________________________________________________________________ + 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 + 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. - For 3.0.1, the most common "bug" is an apparently missing "../" in + For 3.0.1, the most common "bug" is an apparently missing "../" in include/Makefile, resulting in files like gthr.h and gthr-single.h not - being found. Please read [72]the configuration instructions for GCC, + being found. Please read [73]the configuration instructions for GCC, specifically the part about configuring in a separate build directory, - and how strongly recommended it is. Building in the source directory - is fragile, is rarely tested, and tends to break, as in this case. + and how strongly recommended it is. Building in the source directory + is fragile, is rarely tested, and tends to break, as in this case. This was fixed for 3.0.2. - For 3.1, the most common "bug" is a parse error when using , - ending with a message, "bits/basic_file.h:52: parse error before `{' - token." Please read [73]the installation instructions for GCC, - specifically the part about not installing newer versions on top of - older versions. If you install 3.1 over a 3.0.x release, then the - wrong basic_file.h header will be found (its location changed between + For 3.1, the most common "bug" is a parse error when using , + ending with a message, "bits/basic_file.h:52: parse error before `{' + token." Please read [74]the installation instructions for GCC, + specifically the part about not installing newer versions on top of + older versions. If you install 3.1 over a 3.0.x release, then the + wrong basic_file.h header will be found (its location changed between releases). Please do not report these as bugs. We know about them. Reporting this - -- or any other problem that's already been fixed -- hinders the - development of GCC, because we have to take time to respond to your + -- or any other problem that's already been fixed -- hinders the + development of GCC, because we have to take time to respond to your report. Thank you. 4.1 What works already? @@ -476,51 +489,51 @@ New: 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 + 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. - Before reporting a bug, examine the [74]bugs database with the - category set to "libstdc++". The BUGS file in the source tree also + Before reporting a bug, examine the [75]bugs database with the + category set to "libstdc++". The BUGS file in the source tree also tracks known serious problems. - * Debugging is problematic, due to bugs in line-number generation + * Debugging is problematic, due to bugs in line-number generation (mostly fixed in the compiler) and gdb lagging behind the compiler - (lack of personnel). We recommend configuring the compiler using - --with-dwarf2 if the DWARF2 debugging format is not already the - default on your platform. Also, [75]changing your GDB settings can + (lack of personnel). We recommend configuring the compiler using + --with-dwarf2 if the DWARF2 debugging format is not already the + default on your platform. Also, [76]changing your GDB settings can have a profound effect on your C++ debugging experiences. :-) _________________________________________________________________ 4.3 Bugs in the C++ language/lib specification - Yes, unfortunately, there are some. In a [76]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 [77]posted on his website. - Developers who are having problems interpreting the Standard may wish + Yes, unfortunately, there are some. In a [77]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 [78]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 [78]here. - Some of these have resulted in [79]code changes. + 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 [79]here. + Some of these have resulted in [80]code changes. _________________________________________________________________ 4.4 Things in libstdc++ that only 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++, + 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! Please do not report these as bugs. - -Weffc++ 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, + -Weffc++ 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. - reopening a stream fails Did I just say that -Weffc++ was our biggest - false-bug report? I lied. (It used to be.) Today it seems to be + reopening a stream fails Did I just say that -Weffc++ was our biggest + false-bug report? I lied. (It used to be.) Today it seems to be reports that after executing a sequence like #include ... @@ -531,43 +544,43 @@ New: fs.close(); fs.open("a_new_file"); - all operations on the re-opened fs will fail, or at least act very - strangely. Yes, they often will, especially if fs reached the EOF + all operations on the re-opened fs will fail, or at least act very + strangely. Yes, they often will, especially if fs reached the EOF state on the previous file. The reason is that the state flags are not cleared on a successful call to open(). The standard unfortunately did - not specify behavior in this case, and to everybody's great sorrow, - the [80]proposed LWG resolution (see DR #22) is to leave the flags - unchanged. You must insert a call to fs.clear() between the calls to - close() and open(), and then everything will work like we all expect + not specify behavior in this case, and to everybody's great sorrow, + the [81]proposed LWG resolution (see DR #22) is to leave the flags + unchanged. You must insert a call to fs.clear() between the calls to + close() and open(), and then everything will work like we all expect it to work. - rel_ops Another is the rel_ops namespace and the template comparison - operator functions contained therein. If they become visible in the - same namespace as other comparison functions (e.g., 'using' them and - the header), then you will suddenly be faced with huge - numbers of ambiguity errors. This was discussed on the -v3 list; - Nathan Myers [81]sums things up here. The collisions with + rel_ops Another is the rel_ops namespace and the template comparison + operator functions contained therein. If they become visible in the + same namespace as other comparison functions (e.g., 'using' them and + the header), then you will suddenly be faced with huge + numbers of ambiguity errors. This was discussed on the -v3 list; + Nathan Myers [82]sums things up here. The collisions with vector/string iterator types have been fixed for 3.1. The g++-3 headers are not ours - If you have found an extremely broken header file which is causing - problems for you, look carefully before submitting a "high" priority - bug report (which you probably shouldn't do anyhow; see the last - paragraph of the page describing [82]the GCC bug database). + 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 [83]the GCC bug database). - If the headers are in ${prefix}/include/g++-3, or if the installed + If the headers are in ${prefix}/include/g++-3, or if the installed library's name looks like libstdc++-2.10.a or libstdc++-libc6-2.10.so, - then you are using the old libstdc++-v2 library, which is nonstandard - and unmaintained. Do not report problems with -v2 to the -v3 mailing + 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 [83]the question has not yet been decided. + 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 [84]the question has not yet been decided. - glibc If you're on a GNU/Linux system and have just upgraded to glibc - 2.2, but are still using gcc 2.95.2, then you should have read the + glibc If you're on a GNU/Linux system and have just upgraded to glibc + 2.2, but are still using gcc 2.95.2, then you should have read the glibc FAQ, specifically 2.34: 2.34. When compiling C++ programs, I get a compilation error in streambuf.h. @@ -577,23 +590,23 @@ type has changed in glibc 2.2. The patch is at http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff - Note that 2.95.x shipped with the [84]old v2 library which is no - longer maintained. Also note that gcc 2.95.3 fixes this problem, but + Note that 2.95.x shipped with the [85]old v2 library which is no + longer maintained. Also note that gcc 2.95.3 fixes this problem, but requires a separate patch for libstdc++-v3. concept checks If you see compilation errors containing messages about - fooConcept and a constraints member function, then most likely you - have violated one of the requirements for types used during - instantiation of template containers and functions. For example, - EqualityComparableConcept appears if your types must be comparable - with == and you have not provided this capability (a typo, or wrong + fooConcept and a constraints member function, then most likely you + have violated one of the requirements for types used during + instantiation of template containers and functions. For example, + EqualityComparableConcept appears if your types must be comparable + with == and you have not provided this capability (a typo, or wrong visibility, or you just plain forgot, etc). - More information, including how to optionally enable/disable the - checks, is available [85]here. + More information, including how to optionally enable/disable the + checks, is available [86]here. - dlopen/dlsym If you are using the C++ library across - dynamically-loaded objects, make certain that you are passing the + dlopen/dlsym If you are using the C++ library across + dynamically-loaded objects, make certain that you are passing the correct options when compiling and linking: // compile the library components g++ -fPIC -c a.cc @@ -610,18 +623,18 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff 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 - [86]submitting patches that covers the procedure, but for libstdc++ - you should also send the patch to our mailing list in addition to the - GCC patches mailing list. The libstdc++ [87]contributors' page also + 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 + [87]submitting patches that covers the procedure, but for libstdc++ + you should also send the patch to our mailing list in addition to the + GCC patches mailing list. The libstdc++ [88]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 [88]testsuite -- but only if such a test + 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 [89]testsuite -- but only if such a test exists. _________________________________________________________________ @@ -629,61 +642,61 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff 5.1 string::iterator is not char*; vector::iterator is not T* - If you have code that depends on container iterators being + 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 + 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* + by making iterators a real class rather than a typedef for T* outweighs nearly all opposing arguments. Code which does assume that a vector iterator i is a pointer can often - be fixed by changing i in certain expressions to &*i . Future - revisions of the Standard are expected to bless this usage for + be fixed by changing i in certain expressions to &*i . Future + revisions of the Standard are expected to bless this usage for vector<> (but not for basic_string<>). _________________________________________________________________ 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 + 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. However: - 1. The ISO Committee will meet periodically to review Defect Reports - in the C++ Standard. Undoubtedly 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. Those additions are listed in [89]the + 1. The ISO Committee will meet periodically to review Defect Reports + in the C++ Standard. Undoubtedly 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. Those additions are listed in [90]the extensions page. - 2. Performance tuning. Lots of performance tuning. This too is - already underway for post-3.0 releases, starting with memory - expansion in container classes and buffer usage in synchronized + 2. Performance tuning. Lots of performance tuning. This too is + already underway for post-3.0 releases, starting with memory + expansion in container classes and buffer usage in synchronized stream objects. - 3. An ABI for libstdc++ is being developed, so that multiple - binary-incompatible copies of the library can be replaced with a + 3. An ABI for libstdc++ is being developed, so that multiple + binary-incompatible copies of the library can be replaced with a single backwards-compatible library, like libgcc_s.so is. - 4. The current libstdc++ contains extensions to the Library which + 4. 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 + 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. - [90]This question about the next libstdc++ prompted some brief but - interesting [91]speculation. + [91]This question about the next libstdc++ prompted some brief but + interesting [92]speculation. _________________________________________________________________ 5.3 What about the STL from SGI? - The [92]STL from SGI, version 3.3, was the most recent merge of the - STL codebase. The code in libstdc++ contains many fixes and changes, - and it is very likely that the SGI code is no longer under active + The [93]STL from SGI, version 3.3, was the most recent merge of the + STL codebase. The code in libstdc++ contains many fixes and changes, + and it is very likely that the SGI code is no longer under active development. We expect that no future merges will take place. In particular, string is not from SGI and makes no use of their "rope" - class (which is included as an optional extension), nor is valarray + 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 @@ -692,34 +705,34 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff 5.4 Extensions and Backward Compatibility - Headers in the ext and backward subdirectories should be referred to + Headers in the ext and backward subdirectories should be referred to by their relative paths: #include - rather than using -I or other options. This is more portable and - forward-compatible. (The situation is the same as that of other - headers whose directories are not searched directly, e.g., + rather than using -I or other options. This is more portable and + forward-compatible. (The situation is the same as that of other + headers whose directories are not searched directly, e.g., , . - Extensions to the library have [93]their own page. + Extensions to the library have [94]their own page. _________________________________________________________________ 5.5 [removed] - This question has become moot and has been removed. The stub is here + This question has become moot and has been removed. The stub is here to preserve numbering (and hence links/bookmarks). _________________________________________________________________ 5.6 Is libstdc++-v3 thread-safe? - When the system's libc is itself thread-safe, a non-generic - implementation of atomicity.h exists for the architecture, and gcc - itself reports a thread model other than single; libstdc++-v3 strives - to be thread-safe. The user-code must guard against concurrent method - calls which may access any particular library object's state. + When the system's libc is itself thread-safe, a non-generic + implementation of atomicity.h exists for the architecture, and gcc + itself reports a thread model other than single; libstdc++-v3 strives + to be thread-safe. The user-code must guard against concurrent method + calls which may access any particular library object's state. Typically, the application programmer may infer what object locks must - be held based on the objects referenced in a method call. Without - getting into great detail, here is an example which requires + be held based on the objects referenced in a method call. Without + getting into great detail, here is an example which requires user-level locks: library_class_a shared_object_a; @@ -733,8 +746,8 @@ a // Multiple copies of thread_main() are started in independent threads. - Under the assumption that object_a and object_b are never exposed to - another thread, here is an example that should not require any + Under the assumption that object_a and object_b are never exposed to + another thread, here is an example that should not require any user-level locks: thread_main () { library_class_a object_a; @@ -745,80 +758,80 @@ a All library objects are safe to use in a multithreaded program as long as each thread carefully locks out access by any other thread while it - uses any object visible to another thread. In general, this - requirement includes both read and write access to objects; unless - otherwise documented as safe, do not assume that two threads may + uses any object visible to another thread. In general, this + requirement includes both read and write access to objects; unless + otherwise documented as safe, do not assume that two threads may access a shared standard library object at the same time. - See chapters [94]17 (library introduction), [95]23 (containers), and - [96]27 (I/O) for more information. + See chapters [95]17 (library introduction), [96]23 (containers), and + [97]27 (I/O) for more information. _________________________________________________________________ 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 + 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 [97]here. (And if you've already registered with them, clicking - this link will take you to directly to the place where you can [98]buy + right [98]here. (And if you've already registered with them, clicking + this link will take you to directly to the place where you can [99]buy the standard on-line. - Who is your country's member body? Visit the [99]ISO homepage and find - out! + Who is your country's member body? Visit the [100]ISO homepage and + find out! _________________________________________________________________ 5.8 What's an ABI and why is it so messy? - "ABI" stands for "Application Binary Interface." Conventionally, it - refers to a great mass of details about how arguments are arranged on + "ABI" stands for "Application Binary Interface." Conventionally, it + refers to a great mass of details about how arguments are arranged on the call stack and/or in registers, and how various types are arranged - and padded in structs. A single CPU design may suffer multiple ABIs - designed by different development tool vendors who made different - choices, or even by the same vendor for different target applications + and padded in structs. A single CPU design may suffer multiple ABIs + designed by different development tool vendors who made different + choices, or even by the same vendor for different target applications or compiler versions. In ideal circumstances the CPU designer presents - one ABI and all the OSes and compilers use it. In practice every ABI + one ABI and all the OSes and compilers use it. In practice every ABI omits details that compiler implementers (consciously or accidentally) must choose for themselves. - That ABI definition suffices for compilers to generate code so a + That ABI definition suffices for compilers to generate code so a program can interact safely with an OS and its lowest-level libraries. Users usually want an ABI to encompass more detail, allowing libraries - built with different compilers (or different releases of the same - compiler!) to be linked together. For C++, this includes many more - details than for C, and CPU designers (for good reasons elaborated - below) have not stepped up to publish C++ ABIs. The details include - virtual function implementation, struct inheritance layout, name + built with different compilers (or different releases of the same + compiler!) to be linked together. For C++, this includes many more + details than for C, and CPU designers (for good reasons elaborated + below) have not stepped up to publish C++ ABIs. The details include + virtual function implementation, struct inheritance layout, name mangling, and exception handling. Such an ABI has been defined for GNU - C++, and is immediately useful for embedded work relying only on a - "free-standing implementation" that doesn't include (much of) the + C++, and is immediately useful for embedded work relying only on a + "free-standing implementation" that doesn't include (much of) the standard library. It is a good basis for the work to come. - A useful C++ ABI must also incorporate many details of the standard - library implementation. For a C ABI, the layouts of a few structs - (such as FILE, stat, jmpbuf, and the like) and a few macros suffice. - For C++, the details include the complete set of names of functions - and types used, the offsets of class members and virtual functions, - and the actual definitions of all inlines. C++ exposes many more - library details to the caller than C does. It makes defining a - complete ABI a much bigger undertaking, and requires not just - documenting library implementation details, but carefully designing - those details so that future bug fixes and optimizations don't force + A useful C++ ABI must also incorporate many details of the standard + library implementation. For a C ABI, the layouts of a few structs + (such as FILE, stat, jmpbuf, and the like) and a few macros suffice. + For C++, the details include the complete set of names of functions + and types used, the offsets of class members and virtual functions, + and the actual definitions of all inlines. C++ exposes many more + library details to the caller than C does. It makes defining a + complete ABI a much bigger undertaking, and requires not just + documenting library implementation details, but carefully designing + those details so that future bug fixes and optimizations don't force breaking the ABI. There are ways to help isolate library implementation details from the - ABI, but they trade off against speed. Library details used in inner - loops (e.g., getchar) must be exposed and frozen for all time, but - many others may reasonably be kept hidden from user code, so they may + ABI, but they trade off against speed. Library details used in inner + loops (e.g., getchar) must be exposed and frozen for all time, but + many others may reasonably be kept hidden from user code, so they may later be changed. Deciding which, and implementing the decisions, must - happen before you can reasonably document a candidate C++ ABI that + happen before you can reasonably document a candidate C++ ABI that encompasses the standard library. _________________________________________________________________ - See [100]license.html for copying conditions. Comments and suggestions - are welcome, and may be sent to [101]the libstdc++ mailing list. + See [101]license.html for copying conditions. Comments and suggestions + are welcome, and may be sent to [102]the libstdc++ mailing list. References @@ -848,78 +861,79 @@ References 24. ../faq/index.html#3_4 25. ../faq/index.html#3_5 26. ../faq/index.html#3_6 - 27. ../faq/index.html#4_0 - 28. ../faq/index.html#4_1 - 29. ../faq/index.html#4_2 - 30. ../faq/index.html#4_3 - 31. ../faq/index.html#4_4 - 32. ../faq/index.html#4_4_iostreamclear - 33. ../faq/index.html#4_4_Weff - 34. ../faq/index.html#4_4_rel_ops - 35. ../faq/index.html#4_4_interface - 36. ../faq/index.html#4_4_glibc - 37. ../faq/index.html#4_4_checks - 38. ../faq/index.html#4_4_dlsym - 39. ../faq/index.html#4_5 - 40. ../faq/index.html#5_0 - 41. ../faq/index.html#5_1 - 42. ../faq/index.html#5_2 - 43. ../faq/index.html#5_3 - 44. ../faq/index.html#5_4 - 45. ../faq/index.html#5_5 - 46. ../faq/index.html#5_6 - 47. ../faq/index.html#5_7 - 48. ../faq/index.html#5_8 - 49. http://gcc.gnu.org/libstdc++/index.html#download - 50. ../faq/index.html#1_4 - 51. ../faq/index.html#4_4_interface - 52. ../17_intro/DESIGN - 53. http://gcc.gnu.org/ - 54. http://gcc.gnu.org/gcc-3.0/buildstat.html - 55. http://gcc.gnu.org/libstdc++/ - 56. http://gcc.gnu.org/libstdc++/index.html#download - 57. http://gcc.gnu.org/libstdc++/ - 58. ../17_intro/contribute.html - 59. http://www.boost.org/ - 60. http://gcc.gnu.org/fom_serv/cache/33.html - 61. mailto:libstdc++@gcc.gnu.org - 62. mailto:pme@gcc.gnu.org - 63. mailto:gdr@gcc.gnu.org - 64. ../17_intro/license.html - 65. ../documentation.html - 66. ../17_intro/RELEASE-NOTES - 67. http://www.gnu.org/software/cvs/cvs.html - 68. http://www.cvshome.org/ - 69. ../18_support/howto.html - 70. http://gcc.gnu.org/cgi-bin/htsearch?method=and&format=builtin-long&sort=score&words=_XOPEN_SOURCE+Solaris - 71. http://gcc.gnu.org/ml/gcc/2002-03/msg00817.html - 72. http://gcc.gnu.org/install/configure.html - 73. http://gcc.gnu.org/install/ - 74. http://gcc.gnu.org/bugs.html - 75. http://gcc.gnu.org/ml/libstdc++/2002-02/msg00034.html - 76. http://gcc.gnu.org/ml/libstdc++/1998/msg00006.html - 77. http://www.cantrip.org/draft-bugs.txt - 78. http://anubis.dkuug.dk/jtc1/sc22/wg21/ - 79. ../faq/index.html#5_2 - 80. ../ext/howto.html#5 - 81. http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html - 82. http://gcc.gnu.org/gnatswrite.html - 83. http://gcc.gnu.org/ml/gcc/2000-10/msg00732.html - 84. ../faq/index.html#4_4_interface - 85. ../19_diagnostics/howto.html#3 - 86. http://gcc.gnu.org/contribute.html - 87. ../17_intro/contribute.html - 88. ../faq/index.html#2_4 - 89. ../ext/howto.html#5 - 90. http://gcc.gnu.org/ml/libstdc++/1999/msg00080.html - 91. http://gcc.gnu.org/ml/libstdc++/1999/msg00084.html - 92. http://www.sgi.com/Technology/STL/ - 93. ../ext/howto.html - 94. ../17_intro/howto.html#3 - 95. ../23_containers/howto.html#3 - 96. ../27_io/howto.html#9 - 97. http://www.ansi.org/ - 98. http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%2D1998 - 99. http://www.iso.ch/ - 100. ../17_intro/license.html - 101. mailto:libstdc++@gcc.gnu.org + 27. ../faq/index.html#3_7 + 28. ../faq/index.html#4_0 + 29. ../faq/index.html#4_1 + 30. ../faq/index.html#4_2 + 31. ../faq/index.html#4_3 + 32. ../faq/index.html#4_4 + 33. ../faq/index.html#4_4_iostreamclear + 34. ../faq/index.html#4_4_Weff + 35. ../faq/index.html#4_4_rel_ops + 36. ../faq/index.html#4_4_interface + 37. ../faq/index.html#4_4_glibc + 38. ../faq/index.html#4_4_checks + 39. ../faq/index.html#4_4_dlsym + 40. ../faq/index.html#4_5 + 41. ../faq/index.html#5_0 + 42. ../faq/index.html#5_1 + 43. ../faq/index.html#5_2 + 44. ../faq/index.html#5_3 + 45. ../faq/index.html#5_4 + 46. ../faq/index.html#5_5 + 47. ../faq/index.html#5_6 + 48. ../faq/index.html#5_7 + 49. ../faq/index.html#5_8 + 50. http://gcc.gnu.org/libstdc++/index.html#download + 51. ../faq/index.html#1_4 + 52. ../faq/index.html#4_4_interface + 53. ../17_intro/DESIGN + 54. http://gcc.gnu.org/ + 55. http://gcc.gnu.org/gcc-3.0/buildstat.html + 56. http://gcc.gnu.org/libstdc++/ + 57. http://gcc.gnu.org/libstdc++/index.html#download + 58. http://gcc.gnu.org/libstdc++/ + 59. ../17_intro/contribute.html + 60. http://www.boost.org/ + 61. http://gcc.gnu.org/fom_serv/cache/33.html + 62. mailto:libstdc++@gcc.gnu.org + 63. mailto:pme@gcc.gnu.org + 64. mailto:gdr@gcc.gnu.org + 65. ../17_intro/license.html + 66. ../documentation.html + 67. ../17_intro/RELEASE-NOTES + 68. http://www.gnu.org/software/cvs/cvs.html + 69. http://www.cvshome.org/ + 70. ../18_support/howto.html + 71. http://gcc.gnu.org/cgi-bin/htsearch?method=and&format=builtin-long&sort=score&words=_XOPEN_SOURCE+Solaris + 72. http://gcc.gnu.org/ml/gcc/2002-03/msg00817.html + 73. http://gcc.gnu.org/install/configure.html + 74. http://gcc.gnu.org/install/ + 75. http://gcc.gnu.org/bugs.html + 76. http://gcc.gnu.org/ml/libstdc++/2002-02/msg00034.html + 77. http://gcc.gnu.org/ml/libstdc++/1998/msg00006.html + 78. http://www.cantrip.org/draft-bugs.txt + 79. http://anubis.dkuug.dk/jtc1/sc22/wg21/ + 80. ../faq/index.html#5_2 + 81. ../ext/howto.html#5 + 82. http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html + 83. http://gcc.gnu.org/gnatswrite.html + 84. http://gcc.gnu.org/ml/gcc/2000-10/msg00732.html + 85. ../faq/index.html#4_4_interface + 86. ../19_diagnostics/howto.html#3 + 87. http://gcc.gnu.org/contribute.html + 88. ../17_intro/contribute.html + 89. ../faq/index.html#2_4 + 90. ../ext/howto.html#5 + 91. http://gcc.gnu.org/ml/libstdc++/1999/msg00080.html + 92. http://gcc.gnu.org/ml/libstdc++/1999/msg00084.html + 93. http://www.sgi.com/Technology/STL/ + 94. ../ext/howto.html + 95. ../17_intro/howto.html#3 + 96. ../23_containers/howto.html#3 + 97. ../27_io/howto.html#9 + 98. http://www.ansi.org/ + 99. http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%2D1998 + 100. http://www.iso.ch/ + 101. ../17_intro/license.html + 102. mailto:libstdc++@gcc.gnu.org -- 2.7.4