2002-11-21 Phil Edwards <pme@gcc.gnu.org>
+ * 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 <pme@gcc.gnu.org>
+
* 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,
H1 { text-align: center; }
+CAPTION { font-weight: bold }
A.qindex {}
A.qindexRef {}
A.el { text-decoration: none; font-weight: bold }
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 }
-# 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
# 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
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
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).
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.
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.
# 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
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
# 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.
# 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.
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.
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
# 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
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.
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).
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.
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
#---------------------------------------------------------------------------
### 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="//" \
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').
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
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
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.
on the --enable-libio choice: for stdio, if the written data is
already in the stdio buffer, the data may be completely safe!
</p>
- <p><strong>I/O sentry ctor/dtor</strong> They can perform additional work
- than the minimum required. I don't think we're currently taking
+ <p><strong>[27.6.1.1.2]</strong>,<br />
+ <strong>[27.6.2.3]</strong> The I/O sentry ctor and dtor can perform
+ additional work than the minimum required. We are not currently taking
advantage of this yet.
</p>
<p><strong>[27.7.1.3]/16</strong>,<br />
<li><a href="#7">More on binary I/O</a></li>
<li><a href="#8">Pathetic performance? Ditch C.</a></li>
<li><a href="#9">Threads and I/O</a></li>
+ <li><a href="#10">Which header?</a></li>
</ul>
<hr />
"interesting" problems.
</p>
+<hr />
+<h2><a name="10">Which header?</a></h2>
+ <p>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 <em>penalize
+ your runtime as well.</em> Here are some tips on which header to use
+ for which situations, starting with the simplest.
+ </p>
+ <p><strong><iosfwd></strong> should be included whenever you simply
+ need the <em>name</em> 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,
+ </p>
+ <pre>
+ #include <iosfwd>
+
+ class MyClass
+ {
+ ....
+ std::ifstream input_file;
+ };
+
+ extern std::ostream& operator<< (std::ostream&, MyClass&);
+ </pre>
+ <p><strong><ios></strong> 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.
+ </p>
+ <p>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.
+ </p>
+ <p>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.
+ </p>
+ <p><strong><streambuf></strong> 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.
+ </p>
+ <p><strong><istream></strong>/<strong><ostream></strong> are
+ the headers to include when you are using the >>/<<
+ interface, or any of the other abstract stream formatting functions.
+ For example,
+ </p>
+ <pre>
+ #include <istream>
+
+ std::ostream& operator<< (std::ostream& os, MyClass& c)
+ {
+ return os << c.data1() << c.data2();
+ }
+ </pre>
+ <p>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.
+ </p>
+ <p><strong><iomanip></strong> 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 <code>os << setw(3);</code> or
+ <code>is >> setbase(8);</code>, you must include <iomanip>.
+ </p>
+ <p><strong><sstream></strong>/<strong><fstream></strong>
+ declare the six stringstream and fstream classes. As they are the
+ standard concrete descendants of istream and ostream, you will already
+ know about them.
+ </p>
+ <p>Finally, <strong><iostream></strong> 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
+ </p>
+ <pre>
+ #include <ostream>
+ #include <istream>
+
+ namespace std
+ {
+ extern istream cin;
+ extern ostream cout;
+ ....
+
+ // this is explained below
+ <strong>static ios_base::Init __foo;</strong> // not its real name
+ }
+ </pre>
+ <p>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.
+ </p>
+ <p>How does it work? Because the header is included before any of your
+ code, the <strong>__foo</strong> 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.
+ </p>
+ <p>The <code>static</code> keyword means that each object file compiled
+ from a source file containing <iostream> will have its own
+ private copy of <strong>__foo</strong>. 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.
+ </p>
+ <p>The penalty, of course, is that after the first copy of
+ <strong>__foo</strong> 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.)
+ </p>
+ <p>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.
+ </p>
+
<!-- ####################################################### -->
<ul>
<li><a href="libstdc++-html-USERS-3.1/index.html">for the 3.1 release</a>
</li>
- <li><a href="libstdc++-html-USERS-3.2/index.html">for the 3.2 release</a>
+ <li><a href="libstdc++-html-USERS-3.2/index.html">for the 3.2.x release</a>
</li>
<li><a href="latest-doxygen/index.html">"the latest collection"</a>
(for the snapshot or later; see the date on the first page)
<li><a href="27_io/howto.html#7">More on binary I/O</a></li>
<li><a href="27_io/howto.html#8">Pathetic performance? Ditch C.</a></li>
<li><a href="27_io/howto.html#9">Threads and I/O</a></li>
+ <li><a href="27_io/howto.html#10">Which header?</a></li>
</ul>
</li>
<table>
<tr>
<td align="left">Doc. no.</td>
-<td align="left">J16/02-0027 = WG21 N1369</td>
+<td align="left">J16/02-0048 = WG21 N1390</td>
</tr>
<tr>
<td align="left">Date:</td>
-<td align="left">10 May 2002</td>
+<td align="left">10 Sep 2002</td>
</tr>
<tr>
<td align="left">Project:</td>
</tr>
<tr>
<td align="left">Reply to:</td>
-<td align="left">Matt Austern <austern@research.att.com></td>
+<td align="left">Matt Austern <austern@apple.com></td>
</tr>
</table>
-<h1>C++ Standard Library Active Issues List (Revision 22)</h1>
+<h1>C++ Standard Library Active Issues List (Revision 23)</h1>
<p>Reference ISO/IEC IS 14882:1998(E)</p>
<p>Also see:</p>
<ul>
<p>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 <a href="http://www.research.att.com/~austern/csc/faq.html">http://www.research.att.com/~austern/csc/faq.html</a>.
- Public discussion of C++ Standard related issues occurs on <a href="news:comp.std.c++">news:comp.std.c++</a>.
+ Public discussion of C++ Standard related issues occurs on <a href="news:comp.std.c%2B%2B">news:comp.std.c++</a>.
</p>
<p>For committee members, files available on the committee's private
directory as the issues list files. </p>
<h2>Revision History</h2>
<ul>
+<li>R23:
+Pre-Santa Cruz mailing. Added new issues <a href="lwg-active.html#367">367</a>-<a href="lwg-active.html#382">382</a>.
+Moved issues in the TC to TC status.
+</li>
<li>R22:
Post-Curaçao mailing. Added new issues <a href="lwg-active.html#362">362</a>-<a href="lwg-active.html#366">366</a>.
</li>
existing implementations.</p>
<hr>
<a name="225"><h3>225. std:: algorithms use of other unqualified algorithms</h3></a><p>
-<b>Section:</b> 17.4.4.3 <a href="lib-intro.html#lib.global.functions"> [lib.global.functions]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 01 Apr 2000</p>
+<b>Section:</b> 17.4.4.3 <a href="lib-intro.html#lib.global.functions"> [lib.global.functions]</a> <b>Status:</b> <a href="lwg-active.html#Review">Review</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 01 Apr 2000</p>
<p>Are algorithms in std:: allowed to use other algorithms without qualification, so functions in
user namespaces might be found through Koenig lookup?</p>
<p>For example, a popular standard library implementation includes this
<p><i>[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.]</i></p>
+(separate) discussions of this plan the next day. The proposed
+resolution for this issue is in accordance with Howard's paper.]</i></p>
<hr>
<a name="226"><h3>226. User supplied specializations or overloads of namespace std function templates</h3></a><p>
-<b>Section:</b> 17.4.3.1 <a href="lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 01 Apr 2000</p>
+<b>Section:</b> 17.4.3.1 <a href="lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a> <b>Status:</b> <a href="lwg-active.html#Review">Review</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 01 Apr 2000</p>
<p>The issues are: </p>
<p>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? </p>
<p><b>Proposed resolution:</b></p>
+<p>Adopt the wording in the <b>Customization Points</b> section of
+Howard Hinnant's paper, N1387=02-0045.</p>
+
<p><i>[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
<p><i>[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.]</i></p>
+(separate) discussions of this plan the next day. The proposed
+resolution is the one proposed by Howard.]</i></p>
<hr>
<a name="229"><h3>229. Unqualified references of other library entities</h3></a><p>
-<b>Section:</b> 17.4.1.1 <a href="lib-intro.html#lib.contents"> [lib.contents]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 19 Apr 2000</p>
+<b>Section:</b> 17.4.1.1 <a href="lib-intro.html#lib.contents"> [lib.contents]</a> <b>Status:</b> <a href="lwg-active.html#Review">Review</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 19 Apr 2000</p>
<p>Throughout the library chapters, the descriptions of library entities refer
to other library entities without necessarily qualifying the names.</p>
<p><i>[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.]</i></p>
+(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.]</i></p>
<hr>
<a name="231"><h3>231. Precision in iostream?</h3></a><p>
-<b>Section:</b> 22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> James Kanze, Stephen Clamage <b>Date:</b> 25 Apr 2000</p>
+<b>Section:</b> 22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#Review">Review</a> <b>Submitter:</b> James Kanze, Stephen Clamage <b>Date:</b> 25 Apr 2000</p>
<p>What is the following program supposed to output?</p>
<pre>#include <iostream>
of the anomalies of printf:-).</p>
<p><b>Proposed resolution:</b></p>
<p>
-In 22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>, paragraph 11, change
-"if <tt>(flags & fixed) != 0</tt>" to
-"if <tt>(flags & floatfield) == fixed ||
- (flags & floatfield) == scientific</tt>"
+Replace 22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>, paragraph 11, with the following
+sentence:
</p>
+<blockquote>
+For conversion from a floating-point type,
+<tt><i>str</i>.precision()</tt> is specified in the conversion
+specification.
+</blockquote>
<p><b>Rationale:</b></p>
<p>The floatfield determines whether numbers are formatted as if
with %f, %e, or %g. If the <tt>fixed</tt> bit is set, it's %f,
if <tt>scientific</tt> it's %e, and if both bits are set, or
-neither, it's %e.</p>
+neither, it's %g.</p>
<p>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.</p>
-<p>The proposed resolution has the effect that the output of
-the above program will be "1e+00".</p>
-
-<p><i>[Curaçao: Howard will send Matt improved wording dealing with
-case not covered by current PR.]</i></p>
+for %f and %e. For %g, precision 0 is taken to be the same as
+precision 1.</p>
+<p>The proposed resolution has the effect that if neither
+<tt>fixed</tt> nor <tt>scientific</tt> 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.</p>
+<p>The output of the above program will be "1e+00".</p>
+
+<p><i>[Post-Curaçao: Howard provided improved wording covering the case
+where precision is 0 and mode is %g.]</i></p>
<hr>
<a name="233"><h3>233. Insertion hints in associative containers</h3></a><p>
<p>(Not all of these options are mutually exclusive.)</p>
<p><b>Proposed resolution:</b></p>
+<p>NAD/Future</p>
+<p><b>Rationale:</b></p>
+
+<p>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).</p>
+
+<p>
+The copy constructors of all exception-derived classes already have a
+no throw spec. Reference 18.6.1, 19.1 and 15.4/13.
+</p>
+
+<p><b>Future:</b></p>
+
+<p>All involved would like to see const char* constructors added, but
+this should probably be done for C++0X as opposed to a DR.</p>
+
+<p>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.</p>
<p><i>[Toronto: some LWG members thought this was merely a QoI issue,
but most believed that it was at least a borderline defect. There was
normative change.]</i></p>
<p><i>[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.]</i></p>
-
-<p><i>[Curaçao: Howard will nag the others to work on a recommendation.]</i></p>
+members thought there was a real defect lurking here. The above
+proposed resolution/rationale is from Howard, Herb, Kevlin, Martin,
+and Dave.]</i></p>
<hr>
<a name="258"><h3>258. Missing allocator requirement</h3></a><p>
<hr>
<a name="282"><h3>282. What types does numpunct grouping refer to?</h3></a><p>
-<b>Section:</b> 22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#Open">Open</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 5 Dec 2000</p>
+<b>Section:</b> 22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#Review">Review</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 5 Dec 2000</p>
<p>
Paragraph 16 mistakenly singles out integral types for inserting
thousands_sep() characters. This conflicts with the syntax for floating
standard.
]</i></p>
-<p><i>[Curaçao: Howard will email Bill and other implementors to try to
-move the issue forward.]</i></p>
+<p><i>[Post-Curaçao: the above proposed resolution is the consensus of
+Howard, Bill, Pete, Benjamin, Nathan, Dietmar, Boris, and Martin.]</i></p>
<hr>
<a name="283"><h3>283. std::replace() requirement incorrect/insufficient</h3></a><p>
unintended in this case.
</p>
<p><b>Proposed resolution:</b></p>
+<p>In 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, replace paragraps 23-25 with:</p>
+<blockquote>
<p>
-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.
</p>
-<blockquote>
-<b>Effects</b>: If &x == this, does nothing; otherwise, merges the
-argument list into the list.
+
+<p>
+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.
+</p>
+
+<p>
+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.
+</p>
+
</blockquote>
-<p><i>[Copenhagen: The proposed resolution does not fix all of the
-problems in 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, p22-25. Three different
+<p><i>[Copenhagen: The original proposed resolution did not fix all of
+
the problems in 23.2.2.4 <a href="lib-containers.html#lib.list.ops"> [lib.list.ops]</a>, p22-25. Three different
paragraphs (23, 24, 25) describe the effects of <tt>merge</tt>.
Changing p23, without changing the other two, appears to introduce
contradictions. Additionally, "merges the argument list into the
list" is excessively vague.]</i></p>
-<p><i>[Curaçao: Robert Klarer volunteers to work on this issue.]</i></p>
+<p><i>[Post-Curaçao: Robert Klarer provided new wording.]</i></p>
<hr>
<a name="304"><h3>304. Must <tt>*a</tt> return an lvalue when <tt>a</tt> is an input iterator?</h3></a><p>
basic_filebuf<charT,traits>* rdbuf();
const basic_filebuf<charT,traits>* rdbuf() const;
</pre>
+<hr>
+<a name="367"><h3>367. remove_copy/remove_copy_if and Input Iterators</h3></a><p>
+<b>Section:</b> 25.2.7 <a href="lib-algorithms.html#lib.alg.remove"> [lib.alg.remove]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Anthony Williams <b>Date:</b> 13 May 2002</p>
+<p>
+remove_copy and remove_copy_if (25.2.7 <a href="lib-algorithms.html#lib.alg.remove"> [lib.alg.remove]</a>) 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.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+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 <a href="lib-algorithms.html#lib.alg.remove"> [lib.alg.remove]</a> paragraph 6.
+</p>
+<hr>
+<a name="368"><h3>368. basic_string::replace has two "Throws" paragraphs</h3></a><p>
+<b>Section:</b> 21.3.5.6 <a href="lib-strings.html#lib.string::replace"> [lib.string::replace]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 3 Jun 2002</p>
+<p>
+21.3.5.6 <a href="lib-strings.html#lib.string::replace"> [lib.string::replace]</a> basic_string::replace, second
+signature, given in paragraph 1, has two "Throws" paragraphs (3 and
+5).
+</p>
+
+<p>
+In addition, the second "Throws" paragraph (5) includes specification
+(beginning with "Otherwise, the function replaces ...") that should be
+part of the "Effects" paragraph.
+</p>
+<p><b>Proposed resolution:</b></p>
+<hr>
+<a name="369"><h3>369. io stream objects and static ctors</h3></a><p>
+<b>Section:</b> 27.3 <a href="lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Ruslan Abdikeev <b>Date:</b> 8 Jul 2002</p>
+<p>
+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?
+</p>
+
+<p>Surpisingly enough, Standard does NOT require that.</p>
+
+<p>
+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.
+</p>
+
+<p>
+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.
+</p>
+
+<p>Details:</p>
+
+<p>Core text refers to some magic object ios_base::Init, which will
+be discussed below:</p>
+
+<blockquote>
+ "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])
+</blockquote>
+
+<p>
+The first <i>non-normative</i> footnote encourages implementations
+to initialize standard iostream objects earlier than required.
+</p>
+
+<p>However, the second <i>non-normative</i> footnote makes an explicit
+and unsupported claim:</p>
+
+<blockquote>
+ "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])
+</blockquote>
+
+<p>
+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>.
+</p>
+
+<p>
+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.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+At the end of header <iostream> synopsis in 27.3 <a href="lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>
+</p>
+
+<pre>
+ namespace std
+ {
+ ... extern istream cin; ...
+</pre>
+
+<p>add the following lines</p>
+
+<pre>
+ namespace
+ {
+ ios_base::Init <some_implementation_defined_name>;
+ }
+ }
+</pre>
+<hr>
+<a name="370"><h3>370. Minor error in basic_istream::get</h3></a><p>
+<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 15 Jul 2002</p>
+<p>Defect report for description of basic_istream::get (section 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>), paragraph 15. The description for the get function
+with the following signature:</p>
+
+<pre>
+ basic_istream<charT,traits>& get(basic_streambuf<char_type,traits>&
+ sb);
+</pre>
+
+<p>is incorrect. It reads</p>
+
+<blockquote>
+ Effects: Calls get(s,n,widen('\n'))
+</blockquote>
+
+<p>which I believe should be:</p>
+
+<blockquote>
+ Effects: Calls get(sb,widen('\n'))
+</blockquote>
+<p><b>Proposed resolution:</b></p>
+<p>Change the <b>Effects</b> paragraph to:</p>
+<blockquote>
+ Effects: Calls get(sb,widen('\n'))
+</blockquote>
+<hr>
+<a name="371"><h3>371. Stability of multiset and multimap member functions</h3></a><p>
+<b>Section:</b> 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Frank Compagner <b>Date:</b> 20 Jul 2002</p>
+<p>
+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.
+</p>
+
+<p>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.
+</p>
+
+<pre>
+ multimap<int, int> m;
+ multimap<int, int>::iterator i = m.begin();
+ while (i != m.end()) {
+ if (pred(i))
+ m.erase (i++);
+ else
+ ++i;
+ }
+</pre>
+
+<p>
+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.
+</p>
+
+<p>
+If the stability requirement is intended, it should be made explicit
+(probably through an extra paragraph in clause 23.1.2).
+</p>
+<p>
+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.
+</p>
+
+<p>This issue is somewhat related to LWG issue <a href="lwg-closed.html#130">130</a>.</p>
+<p><b>Proposed resolution:</b></p>
+<hr>
+<a name="372"><h3>372. Inconsistent description of stdlib exceptions</h3></a><p>
+<b>Section:</b> 17.4.4.8 <a href="lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a>, 18.6.1 <a href="lib-support.html#lib.exception"> [lib.exception]</a>, <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Randy Maddox <b>Date:</b> 22 Jul 2002</p>
+
+<p>Paragraph 3 under clause 17.4.4.8 <a href="lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a>, 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."</p>
+
+<p>These statements appear to be in direct contradiction to clause
+18.6.1 <a href="lib-support.html#lib.exception"> [lib.exception]</a>, which states "The class exception defines the
+base class for the types of objects thrown as exceptions by the C++
+Standard library components ...".</p>
+
+<p>Is this inconsistent?</p>
+
+<p><b>Proposed resolution:</b></p>
+<hr>
+<a name="373"><h3>373. Are basic_istream and basic_ostream to use (exceptions()&badbit) != 0 ?</h3></a><p>
+<b>Section:</b> 27.6.1.2.1 <a href="lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a>, 27.6.2.5.1 <a href="lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Keith Baker <b>Date:</b> 23 Jul 2002</p>
+
+<p>
+In 27.6.1.2.1 <a href="lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a> and 27.6.2.5.1 <a href="lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a>
+(exception()&badbit) != 0 is used in testing for rethrow, yet
+exception() is the constructor to class std::exception in 18.6.1 <a href="lib-support.html#lib.exception"> [lib.exception]</a> that has no return type. Should member function
+exceptions() found in 27.4.4 <a href="lib-iostreams.html#lib.ios"> [lib.ios]</a> be used instead?
+</p>
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+<hr>
+<a name="374"><h3>374. moneypunct::frac_digits returns int not unsigned</h3></a><p>
+<b>Section:</b> 22.2.6.3.1 <a href="lib-locales.html#lib.locale.moneypunct.members"> [lib.locale.moneypunct.members]</a>, 22.2.6.3.2 <a href="lib-locales.html#lib.locale.moneypunct.virtuals"> [lib.locale.moneypunct.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 8 Aug 2002</p>
+<p>
+In section 22.2.6.3.1 <a href="lib-locales.html#lib.locale.moneypunct.members"> [lib.locale.moneypunct.members]</a>, 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".
+</p>
+
+<p>
+Similarly, in section 22.2.6.3.2 <a href="lib-locales.html#lib.locale.moneypunct.virtuals"> [lib.locale.moneypunct.virtuals]</a>, do_frac_digits()
+should return "unsigned".
+</p>
+
+<p><b>Proposed resolution:</b></p>
+<hr>
+<a name="375"><h3>375. basic_ios should be ios_base in 27.7.1.3</h3></a><p>
+<b>Section:</b> 27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 14 Aug 2002</p>
+<p>
+In Section 27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>: Table 90, Table 91, and paragraph
+14 all contain references to "basic_ios::" which should be
+"ios_base::".
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Change all references to "basic_ios" in Table 90, Table 91, and
+paragraph 14 to "ios_base".
+</p>
+<hr>
+<a name="376"><h3>376. basic_streambuf semantics</h3></a><p>
+<b>Section:</b> 27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 14 Aug 2002</p>
+<p>
+In Section 27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>, 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:
+</p>
+
+<blockquote>
+<p>
+ (which & (ios_base::in|ios_base::out)) == ios_base::in
+</p>
+
+<p>
+ (which & (ios_base::in|ios_base::out)) == ios_base::out
+</p>
+
+<p>
+ (which & (ios_base::in|ios_base::out)) ==
+(ios_base::in|ios_base::out)
+ and way == either ios_base::beg or ios_base::end
+</p>
+
+<p>Otherwise</p>
+</blockquote>
+
+<p>
+As written, it is unclear what should be the result if cases 1 & 2
+are true, but case 3 is false, e.g.,
+</p>
+
+<blockquote>
+ seekoff(0, ios_base::cur, ios_base::in | ios_base::out)
+</blockquote>
+
+<p><b>Proposed resolution:</b></p>
+<hr>
+<a name="377"><h3>377. basic_string::insert and length_error</h3></a><p>
+<b>Section:</b> 21.3.5.4 <a href="lib-strings.html#lib.string::insert"> [lib.string::insert]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 16 Aug 2002</p>
+<p>
+Section 21.3.5.4 <a href="lib-strings.html#lib.string::insert"> [lib.string::insert]</a>, paragraph 4, contains the following,
+"Then throws length_error if size() >= npos - rlen."
+</p>
+
+<p>
+Related to DR 83, this sentence should probably be removed.
+</p>
+<p><b>Proposed resolution:</b></p>
+<hr>
+<a name="378"><h3>378. locale immutability and locale::operator=()</h3></a><p>
+<b>Section:</b> 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 6 Sep 2002</p>
+<p>
+I think there is a problem with 22.1.1, p6 which says that
+</p>
+<pre>
+ -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.
+</pre>
+<p>
+and 22.1.1.2, p4:
+</p>
+<pre>
+ const locale& operator=(const locale& other) throw();
+
+ -4- Effects: Creates a copy of other, replacing the current value.
+</pre>
+<p>
+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
+</p>
+<pre>
+ 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);
+</pre>
+<p>
+Is r0 really supposed to be preserved and destroyed only when loc goes
+out of scope?
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Suggest to replace 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a>, p6 with
+</p>
+<pre>
+ -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.
+</pre>
+<hr>
+<a name="379"><h3>379. nonsensical ctype::do_widen() requirement</h3></a><p>
+<b>Section:</b> 22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 6 Sep 2002</p>
+<p>
+The last sentence in 22.2.1.1.2, p11 below doesn't seem to make sense.
+</p>
+<pre>
+ 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.
+</pre>
+<p>
+Shouldn't the last sentence instead read
+</p>
+<pre>
+ 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.
+</pre>
+<p>
+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.)
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Replace the last sentence of 22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a>, p11 with the
+following text:
+</p>
+<pre>
+ 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.
+</pre>
+<hr>
+<a name="380"><h3>380. typos in codecvt tables 53 and 54</h3></a><p>
+<b>Section:</b> 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 6 Sep 2002</p>
+<p>
+Tables 53 and 54 in 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> 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.
+</p>
+<p>
+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.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the title of Table 53 to "do_in/do_out result values" and
+the title of Table 54 to "do_unshift result values."
+</p>
+<p>
+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."
+</p>
+<hr>
+<a name="381"><h3>381. detection of invalid mbstate_t in codecvt</h3></a><p>
+<b>Section:</b> 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 6 Sep 2002</p>
+<p>
+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.
+</p>
+
+<p>
+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:
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Add a new paragraph before 22.2.1.5.2, p5, and after the function
+declaration below
+</p>
+<pre>
+ result do_unshift(stateT& state,
+ externT* to, externT* to_limit, externT*& to_next) const;
+</pre>
+<p>
+as follows:
+</p>
+<pre>
+ 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.
+</pre>
+<p>
+and change the text in Table 54, row 4, under the heading Meaning
+from
+</p>
+<pre>
+ state has invalid value
+</pre>
+<p>
+to
+</p>
+<pre>
+ an unspecified error has occurred
+</pre>
+<p>
+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.
+</p>
+<hr>
+<a name="382"><h3>382. codecvt do_in/out result</h3></a><p>
+<b>Section:</b> 22.2.1.5 <a href="lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 30 Aug 2002</p>
+<p>
+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:
+</p>
+
+<ol>
+<li>
+ the conditions under which the functions terminate
+</li>
+<li>
+ precisely when the functions return ok
+</li>
+<li>
+ precisely when the functions return partial
+</li>
+<li>
+ the full set of conditions when the functions return error
+</li>
+</ol>
+
+<ol>
+<li>
+ 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, 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)?
+</li>
+<li>
+ 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).
+</li>
+<li>
+ 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).
+</li>
+<li>
+ 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).
+</li>
+</ol>
+<p>
+Finally, the conditions described at the end of 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, p4 don't seem to be possible:
+</p>
+<blockquote>
+ "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."
+</blockquote>
+<p>
+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 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, p2) and since there are no
+further source characters to convert, no more room in the
+destination buffer can be needed.
+</p>
+<p>
+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.
+</p>
+<p>
+Could it be that the intended qualifying condition was actually
+(from_next != from_end), i.e., that the sentence was supposed
+to read
+</p>
+<blockquote>
+ "A return value of partial, if (from_next != from_end),..."
+</blockquote>
+<p>
+which would make perfect sense, since, as far as I understand it,
+partial can only occur if (from_next != from_end)?
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+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.
+</p>
+<pre>
+-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.
+</pre>
<p>----- End of document -----</p>
</body>
</html>
<table>
<tr>
<td align="left">Doc. no.</td>
-<td align="left">J16/02-0028 = WG21 N1370</td>
+<td align="left">J16/02-0049 = WG21 N1391</td>
</tr>
<tr>
<td align="left">Date:</td>
-<td align="left">10 May 2002</td>
+<td align="left">10 Sep 2002</td>
</tr>
<tr>
<td align="left">Project:</td>
</tr>
<tr>
<td align="left">Reply to:</td>
-<td align="left">Matt Austern <austern@research.att.com></td>
+<td align="left">Matt Austern <austern@apple.com></td>
</tr>
</table>
-<h1>C++ Standard Library Defect Report List (Revision 22)</h1>
+<h1>C++ Standard Library Defect Report List (Revision 23)</h1>
<p>Reference ISO/IEC IS 14882:1998(E)</p>
<p>Also see:</p>
<ul>
document.</p>
<h2>Revision History</h2>
<ul>
+<li>R23:
+Pre-Santa Cruz mailing. Added new issues <a href="lwg-active.html#367">367</a>-<a href="lwg-active.html#382">382</a>.
+Moved issues in the TC to TC status.
+</li>
<li>R22:
Post-Curaçao mailing. Added new issues <a href="lwg-active.html#362">362</a>-<a href="lwg-active.html#366">366</a>.
</li>
<h2>Defect Reports</h2>
<hr>
<a name="1"><h3>1. C library linkage editing oversight</h3></a><p>
-<b>Section:</b> 17.4.2.2 <a href="lib-intro.html#lib.using.linkage"> [lib.using.linkage]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 16 Nov 1997</p>
+<b>Section:</b> 17.4.2.2 <a href="lib-intro.html#lib.using.linkage"> [lib.using.linkage]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 16 Nov 1997</p>
<p>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
</blockquote>
<hr>
<a name="3"><h3>3. Atexit registration during atexit() call is not described</h3></a><p>
-<b>Section:</b> 18.3 <a href="lib-support.html#lib.support.start.term"> [lib.support.start.term]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 12 Dec 1997</p>
+<b>Section:</b> 18.3 <a href="lib-support.html#lib.support.start.term"> [lib.support.start.term]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 12 Dec 1997</p>
<p>We appear not to have covered all the possibilities of
exit processing with respect to
atexit registration. <br>
supporting to the proposed resolution.</p>
<hr>
<a name="5"><h3>5. String::compare specification questionable</h3></a><p>
-<b>Section:</b> 21.3.6.8 <a href="lib-strings.html#lib.string::compare"> [lib.string::compare]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Jack Reeves <b>Date:</b> 11 Dec 1997</p>
+<b>Section:</b> 21.3.6.8 <a href="lib-strings.html#lib.string::compare"> [lib.string::compare]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Jack Reeves <b>Date:</b> 11 Dec 1997</p>
<p>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
identified in issues 7 (item 5) and 87.</p>
<hr>
<a name="7"><h3>7. String clause minor problems</h3></a><p>
-<b>Section:</b> 21 <a href="lib-strings.html#lib.strings"> [lib.strings]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 15 Dec 1997</p>
+<b>Section:</b> 21 <a href="lib-strings.html#lib.strings"> [lib.strings]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 15 Dec 1997</p>
<p>(1) In 21.3.5.4 <a href="lib-strings.html#lib.string::insert"> [lib.string::insert]</a>, the description of template
<class InputIterator> insert(iterator, InputIterator,
InputIterator) makes no sense. It refers to a member function that
s+n) overlap."</p>
<hr>
<a name="8"><h3>8. Locale::global lacks guarantee</h3></a><p>
-<b>Section:</b> 22.1.1.5 <a href="lib-locales.html#lib.locale.statics"> [lib.locale.statics]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 24 Dec 1997</p>
+<b>Section:</b> 22.1.1.5 <a href="lib-locales.html#lib.locale.statics"> [lib.locale.statics]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 24 Dec 1997</p>
<p>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
</blockquote>
<hr>
<a name="9"><h3>9. Operator new(0) calls should not yield the same pointer</h3></a><p>
-<b>Section:</b> 18.4.1 <a href="lib-support.html#lib.new.delete"> [lib.new.delete]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 4 Jan 1998</p>
+<b>Section:</b> 18.4.1 <a href="lib-support.html#lib.new.delete"> [lib.new.delete]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 4 Jan 1998</p>
<p>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
supporting to the proposed resolution.</p>
<hr>
<a name="11"><h3>11. Bitset minor problems</h3></a><p>
-<b>Section:</b> 23.3.5 <a href="lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 22 Jan 1998</p>
+<b>Section:</b> 23.3.5 <a href="lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 22 Jan 1998</p>
<p>(1) bitset<>::operator[] is mentioned in the class synopsis (23.3.5), but it is
not documented in 23.3.5.2. </p>
</p>
<hr>
<a name="13"><h3>13. Eos refuses to die</h3></a><p>
-<b>Section:</b> 27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> William M. Miller <b>Date:</b> 3 Mar 1998</p>
+<b>Section:</b> 27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> William M. Miller <b>Date:</b> 3 Mar 1998</p>
<p>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. </p>
"charT()"</p>
<hr>
<a name="14"><h3>14. Locale::combine should be const</h3></a><p>
-<b>Section:</b> 22.1.1.3 <a href="lib-locales.html#lib.locale.members"> [lib.locale.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 22.1.1.3 <a href="lib-locales.html#lib.locale.members"> [lib.locale.members]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
<p>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
</blockquote>
<hr>
<a name="15"><h3>15. Locale::name requirement inconsistent</h3></a><p>
-<b>Section:</b> 22.1.1.3 <a href="lib-locales.html#lib.locale.members"> [lib.locale.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 22.1.1.3 <a href="lib-locales.html#lib.locale.members"> [lib.locale.members]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
<p>locale::name() is described as returning a string that can be passed to a locale
constructor, but there is no matching constructor. </p>
<p><b>Proposed resolution:</b></p>
</p>
<hr>
<a name="16"><h3>16. Bad ctype_byname<char> decl</h3></a><p>
-<b>Section:</b> 22.2.1.4 <a href="lib-locales.html#lib.locale.ctype.byname.special"> [lib.locale.ctype.byname.special]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 22.2.1.4 <a href="lib-locales.html#lib.locale.ctype.byname.special"> [lib.locale.ctype.byname.special]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
<p>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. </p>
from 22.2.1.3 <a href="lib-locales.html#lib.facet.ctype.special"> [lib.facet.ctype.special]</a>.</p>
<hr>
<a name="17"><h3>17. Bad bool parsing</h3></a><p>
-<b>Section:</b> 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
<p>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
</blockquote>
<hr>
<a name="18"><h3>18. Get(...bool&) omitted</h3></a><p>
-<b>Section:</b> 22.2.2.1.1 <a href="lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 22.2.2.1.1 <a href="lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
<p>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
22.2.2.1 <a href="lib-locales.html#lib.locale.num.get"> [lib.locale.num.get]</a>.</p>
<hr>
<a name="19"><h3>19. "Noconv" definition too vague</h3></a><p>
-<b>Section:</b> 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
<p>
In the definitions of codecvt<>::do_out and do_in, they are
specified to return noconv if "no conversion is
</blockquote>
<hr>
<a name="20"><h3>20. Thousands_sep returns wrong type</h3></a><p>
-<b>Section:</b> 22.2.3.1.2 <a href="lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 22.2.3.1.2 <a href="lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
<p>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
"string_type" to "char_type". </p>
<hr>
<a name="21"><h3>21. Codecvt_byname<> instantiations</h3></a><p>
-<b>Section:</b> 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
<p>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
</blockquote>
<hr>
<a name="22"><h3>22. Member open vs. flags</h3></a><p>
-<b>Section:</b> 27.8.1.7 <a href="lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 27.8.1.7 <a href="lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
<p>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
<hr>
<a name="24"><h3>24. "do_convert" doesn't exist</h3></a><p>
-<b>Section:</b> 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
<p>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
or do_out". </p>
<hr>
<a name="25"><h3>25. String operator<< uses width() value wrong</h3></a><p>
-<b>Section:</b> 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
<p>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. </p>
..."</p>
<hr>
<a name="26"><h3>26. Bad sentry example</h3></a><p>
-<b>Section:</b> 27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
<p>In paragraph 6, the code in the example: </p>
<pre> template <class charT, class traits = char_traits<charT> >
example, which might well still contain errors.</p>
<hr>
<a name="27"><h3>27. String::erase(range) yields wrong iterator</h3></a><p>
-<b>Section:</b> 21.3.5.5 <a href="lib-strings.html#lib.string::erase"> [lib.string::erase]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 21.3.5.5 <a href="lib-strings.html#lib.string::erase"> [lib.string::erase]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
<p>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',
</blockquote>
<hr>
<a name="28"><h3>28. Ctype<char>is ambiguous</h3></a><p>
-<b>Section:</b> 22.2.1.3.2 <a href="lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 22.2.1.3.2 <a href="lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
<p>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 </p>
</blockquote>
<hr>
<a name="29"><h3>29. Ios_base::init doesn't exist</h3></a><p>
-<b>Section:</b> 27.3.1 <a href="lib-iostreams.html#lib.narrow.stream.objects"> [lib.narrow.stream.objects]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 27.3.1 <a href="lib-iostreams.html#lib.narrow.stream.objects"> [lib.narrow.stream.objects]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
<p>Sections 27.3.1 <a href="lib-iostreams.html#lib.narrow.stream.objects"> [lib.narrow.stream.objects]</a> and 27.3.2 <a href="lib-iostreams.html#lib.wide.stream.objects"> [lib.wide.stream.objects]</a> mention
a function ios_base::init, which is not defined. Probably they mean
basic_ios<>::init, defined in 27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a>,
</blockquote>
<hr>
<a name="30"><h3>30. Wrong header for LC_*</h3></a><p>
-<b>Section:</b> 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 22.1.1.1.1 <a href="lib-locales.html#lib.locale.category"> [lib.locale.category]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
<p>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>. </p>
<p><b>Proposed resolution:</b></p>
"<cctype>" to read "<clocale>". </p>
<hr>
<a name="31"><h3>31. Immutable locale values</h3></a><p>
-<b>Section:</b> 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
<p>Paragraph 6, says "An instance of <tt>locale</tt> is
<i>immutable</i>; once a facet reference is obtained from it,
...". This has caused some confusion, because locale variables
</blockquote>
<hr>
<a name="32"><h3>32. Pbackfail description inconsistent</h3></a><p>
-<b>Section:</b> 27.5.2.4.4 <a href="lib-iostreams.html#lib.streambuf.virt.pback"> [lib.streambuf.virt.pback]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 27.5.2.4.4 <a href="lib-iostreams.html#lib.streambuf.virt.pback"> [lib.streambuf.virt.pback]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
<p>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.
the argument value.</p>
<hr>
<a name="33"><h3>33. Codecvt<> mentions from_type</h3></a><p>
-<b>Section:</b> 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
<p>In the table defining the results from do_out and do_in, the specification for the
result <i>error</i> says </p>
</blockquote>
<hr>
<a name="34"><h3>34. True/falsename() not in ctype<></h3></a><p>
-<b>Section:</b> 22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
<p>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). </p>
</blockquote>
<hr>
<a name="35"><h3>35. No manipulator unitbuf in synopsis</h3></a><p>
-<b>Section:</b> 27.4 <a href="lib-iostreams.html#lib.iostreams.base"> [lib.iostreams.base]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 27.4 <a href="lib-iostreams.html#lib.iostreams.base"> [lib.iostreams.base]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
<p>In 27.4.5.1 <a href="lib-iostreams.html#lib.fmtflags.manip"> [lib.fmtflags.manip]</a>, we have a definition for a manipulator
named "unitbuf". Unlike other manipulators, it's not listed
in synopsis. Similarly for "nounitbuf". </p>
</blockquote>
<hr>
<a name="36"><h3>36. Iword & pword storage lifetime omitted</h3></a><p>
-<b>Section:</b> 27.4.2.5 <a href="lib-iostreams.html#lib.ios.base.storage"> [lib.ios.base.storage]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 27.4.2.5 <a href="lib-iostreams.html#lib.ios.base.storage"> [lib.ios.base.storage]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
<p>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: </p>
<p>substituting "iword" or "pword" as appropriate. </p>
<hr>
<a name="37"><h3>37. Leftover "global" reference</h3></a><p>
-<b>Section:</b> 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
<p>In the overview of locale semantics, paragraph 4, is the sentence </p>
<blockquote>
</blockquote>
<hr>
<a name="38"><h3>38. Facet definition incomplete</h3></a><p>
-<b>Section:</b> 22.1.2 <a href="lib-locales.html#lib.locale.global.templates"> [lib.locale.global.templates]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 22.1.2 <a href="lib-locales.html#lib.locale.global.templates"> [lib.locale.global.templates]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
<p>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 <i>id</i>, cannot
<hr>
<a name="39"><h3>39. istreambuf_iterator<>::operator++(int) definition garbled</h3></a><p>
-<b>Section:</b> 24.5.3.4 <a href="lib-iterators.html#lib.istreambuf.iterator::op++"> [lib.istreambuf.iterator::op++]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 24.5.3.4 <a href="lib-iterators.html#lib.istreambuf.iterator::op%2B%2B"> [lib.istreambuf.iterator::op++]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
<p>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. </p>
return(tmp); </pre>
</blockquote>
<p><b>Proposed resolution:</b></p>
-<p>In 24.5.3.4 <a href="lib-iterators.html#lib.istreambuf.iterator::op++"> [lib.istreambuf.iterator::op++]</a>, delete the three lines of code at the
+<p>In 24.5.3.4 <a href="lib-iterators.html#lib.istreambuf.iterator::op%2B%2B"> [lib.istreambuf.iterator::op++]</a>, delete the three lines of code at the
end of paragraph 3. </p>
<hr>
<a name="40"><h3>40. Meaningless normative paragraph in examples</h3></a><p>
-<b>Section:</b> 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
<p>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. </p>
numbering the same. </p>
<hr>
<a name="41"><h3>41. Ios_base needs clear(), exceptions()</h3></a><p>
-<b>Section:</b> 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
<p>The description of ios_base::iword() and pword() in 27.4.2.4 <a href="lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>, 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
<hr>
<a name="42"><h3>42. String ctors specify wrong default allocator</h3></a><p>
-<b>Section:</b> 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
<p>The basic_string<> copy constructor: </p>
<pre>basic_string(const basic_string& str, size_type pos = 0,
]</i></p>
<hr>
<a name="46"><h3>46. Minor Annex D errors</h3></a><p>
-<b>Section:</b> D.7 <a href="future.html#depr.str.strstreams"> [depr.str.strstreams]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Brendan Kehoe <b>Date:</b> 1 Jun 1998</p>
+<b>Section:</b> D.7 <a href="future.html#depr.str.strstreams"> [depr.str.strstreams]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Brendan Kehoe <b>Date:</b> 1 Jun 1998</p>
<p>See lib-6522 and edit-814.</p>
<p><b>Proposed resolution:</b></p>
<p>Change D.7.1 <a href="future.html#depr.strstreambuf"> [depr.strstreambuf]</a> (since streambuf is a typedef of
typedef typename char_traits<char>::pos_type pos_type;</pre>
<hr>
<a name="47"><h3>47. Imbue() and getloc() Returns clauses swapped</h3></a><p>
-<b>Section:</b> 27.4.2.3 <a href="lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 21 Jun 1998</p>
+<b>Section:</b> 27.4.2.3 <a href="lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 21 Jun 1998</p>
<p>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
<p>In 27.4.2.3 <a href="lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> swap paragraphs 2 and 4.</p>
<hr>
<a name="48"><h3>48. Use of non-existent exception constructor</h3></a><p>
-<b>Section:</b> 27.4.2.1.1 <a href="lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 21 Jun 1998</p>
+<b>Section:</b> 27.4.2.1.1 <a href="lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 21 Jun 1998</p>
<p>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.</p>
on the two streams can be mixed arbitrarily.]</i></p>
<hr>
<a name="50"><h3>50. Copy constructor and assignment operator of ios_base</h3></a><p>
-<b>Section:</b> 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 21 Jun 1998</p>
+<b>Section:</b> 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 21 Jun 1998</p>
<p>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
outweighs any benefit of allowing ios_base objects to be copyable.</p>
<hr>
<a name="51"><h3>51. Requirement to not invalidate iterators missing</h3></a><p>
-<b>Section:</b> 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> David Vandevoorde <b>Date:</b> 23 Jun 1998</p>
+<b>Section:</b> 23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> David Vandevoorde <b>Date:</b> 23 Jun 1998</p>
<p>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
of"</p>
<hr>
<a name="52"><h3>52. Small I/O problems</h3></a><p>
-<b>Section:</b> 27.4.3.2 <a href="lib-iostreams.html#lib.fpos.operations"> [lib.fpos.operations]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 23 Jun 1998</p>
+<b>Section:</b> 27.4.3.2 <a href="lib-iostreams.html#lib.fpos.operations"> [lib.fpos.operations]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 23 Jun 1998</p>
<p>First, 27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a>, table 89. This is pretty obvious:
it should be titled "basic_ios<>() effects", not
"ios_base() effects". </p>
effects". </p>
<hr>
<a name="53"><h3>53. Basic_ios destructor unspecified</h3></a><p>
-<b>Section:</b> 27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 23 Jun 1998</p>
+<b>Section:</b> 27.4.4.1 <a href="lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 23 Jun 1998</p>
<p>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().</p>
<tt>badbit</tt>".</p>
<hr>
<a name="54"><h3>54. Basic_streambuf's destructor</h3></a><p>
-<b>Section:</b> 27.5.2.1 <a href="lib-iostreams.html#lib.streambuf.cons"> [lib.streambuf.cons]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 25 Jun 1998</p>
+<b>Section:</b> 27.5.2.1 <a href="lib-iostreams.html#lib.streambuf.cons"> [lib.streambuf.cons]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 25 Jun 1998</p>
<p>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
</blockquote>
<hr>
<a name="55"><h3>55. Invalid stream position is undefined</h3></a><p>
-<b>Section:</b> 27 <a href="lib-iostreams.html#lib.input.output"> [lib.input.output]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 26 Jun 1998</p>
+<b>Section:</b> 27 <a href="lib-iostreams.html#lib.input.output"> [lib.input.output]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 26 Jun 1998</p>
<p>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,
<tt>pos_type(off_type(-1))</tt>"</p>
<hr>
<a name="56"><h3>56. Showmanyc's return type</h3></a><p>
-<b>Section:</b> 27.5.2 <a href="lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 29 Jun 1998</p>
+<b>Section:</b> 27.5.2 <a href="lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 29 Jun 1998</p>
<p>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. </p>
27.5.2 <a href="lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> class summary to <tt>streamsize</tt>.</p>
<hr>
<a name="57"><h3>57. Mistake in char_traits</h3></a><p>
-<b>Section:</b> 21.1.3.2 <a href="lib-strings.html#lib.char.traits.specializations.wchar.t"> [lib.char.traits.specializations.wchar.t]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 1 Jul 1998</p>
+<b>Section:</b> 21.1.3.2 <a href="lib-strings.html#lib.char.traits.specializations.wchar.t"> [lib.char.traits.specializations.wchar.t]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 1 Jul 1998</p>
<p>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
different..." . </p>
<hr>
<a name="59"><h3>59. Ambiguity in specification of gbump</h3></a><p>
-<b>Section:</b> 27.5.2.3.1 <a href="lib-iostreams.html#lib.streambuf.get.area"> [lib.streambuf.get.area]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 28 Jul 1998</p>
+<b>Section:</b> 27.5.2.3.1 <a href="lib-iostreams.html#lib.streambuf.get.area"> [lib.streambuf.get.area]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 28 Jul 1998</p>
<p>27.5.2.3.1 says that basic_streambuf::gbump() "Advances the
next pointer for the input sequence by n." </p>
effects.</p>
<hr>
<a name="60"><h3>60. What is a formatted input function?</h3></a><p>
-<b>Section:</b> 27.6.1.2.1 <a href="lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 3 Aug 1998</p>
+<b>Section:</b> 27.6.1.2.1 <a href="lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 3 Aug 1998</p>
<p>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
VI of that paper.</p>
<hr>
<a name="61"><h3>61. Ambiguity in iostreams exception policy</h3></a><p>
-<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 6 Aug 1998</p>
<p>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
resolution as better standardese.</p>
<hr>
<a name="62"><h3>62. <tt>Sync</tt>'s return value</h3></a><p>
-<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 6 Aug 1998</p>
+<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 6 Aug 1998</p>
<p>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()." </p>
</p>
<hr>
<a name="63"><h3>63. Exception-handling policy for unformatted output</h3></a><p>
-<b>Section:</b> 27.6.2.6 <a href="lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 11 Aug 1998</p>
+<b>Section:</b> 27.6.2.6 <a href="lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 11 Aug 1998</p>
<p>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
<hr>
<a name="64"><h3>64. Exception handling in <tt>basic_istream::operator>>(basic_streambuf*)</tt>
</h3></a><p>
-<b>Section:</b> 27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 11 Aug 1998 </p>
+<b>Section:</b> 27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 11 Aug 1998 </p>
<p>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. </p>
</blockquote>
<hr>
<a name="66"><h3>66. Strstreambuf::setbuf</h3></a><p>
-<b>Section:</b> D.7.1.3 <a href="future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 18 Aug 1998</p>
+<b>Section:</b> D.7.1.3 <a href="future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 18 Aug 1998</p>
<p>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
</blockquote>
<hr>
<a name="68"><h3>68. Extractors for char* should store null at end</h3></a><p>
-<b>Section:</b> 27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 14 Jul 1998</p>
+<b>Section:</b> 27.6.1.2.3 <a href="lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 14 Jul 1998</p>
<p>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?</p>
</blockquote>
<hr>
<a name="69"><h3>69. Must elements of a vector be contiguous?</h3></a><p>
-<b>Section:</b> 23.2.4 <a href="lib-containers.html#lib.vector"> [lib.vector]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 29 Jul 1998</p>
+<b>Section:</b> 23.2.4 <a href="lib-containers.html#lib.vector"> [lib.vector]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 29 Jul 1998</p>
<p>The issue is this: Must the elements of a vector be in contiguous memory?</p>
<p>(Please note that this is entirely separate from the question of
</ul>
<hr>
<a name="70"><h3>70. Uncaught_exception() missing throw() specification</h3></a><p>
-<b>Section:</b> 18.6 <a href="lib-support.html#lib.support.exception"> [lib.support.exception]</a>, 18.6.4 <a href="lib-support.html#lib.uncaught"> [lib.uncaught]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> Unknown</p>
+<b>Section:</b> 18.6 <a href="lib-support.html#lib.support.exception"> [lib.support.exception]</a>, 18.6.4 <a href="lib-support.html#lib.uncaught"> [lib.uncaught]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> Unknown</p>
<p>In article 3E04@pratique.fr, Valentin Bonnard writes: </p>
<p>uncaught_exception() doesn't have a throw specification.</p>
<p>In 15.5.3 <a href="except.html#except.uncaught"> [except.uncaught]</a>, paragraph 1, 18.6 <a href="lib-support.html#lib.support.exception"> [lib.support.exception]</a>, and 18.6.4 <a href="lib-support.html#lib.uncaught"> [lib.uncaught]</a>, add "throw()" to uncaught_exception().</p>
<hr>
<a name="71"><h3>71. Do_get_monthname synopsis missing argument</h3></a><p>
-<b>Section:</b> 22.2.5.1 <a href="lib-locales.html#lib.locale.time.get"> [lib.locale.time.get]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 13 Aug 1998</p>
+<b>Section:</b> 22.2.5.1 <a href="lib-locales.html#lib.locale.time.get"> [lib.locale.time.get]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 13 Aug 1998</p>
<p>The locale facet member <tt>time_get<>::do_get_monthname</tt>
is described in 22.2.5.1.2 <a href="lib-locales.html#lib.locale.time.get.virtuals"> [lib.locale.time.get.virtuals]</a> with five arguments,
consistent with do_get_weekday and with its specified use by member
<hr>
<a name="74"><h3>74. Garbled text for <tt>codecvt::do_max_length</tt>
</h3></a><p>
-<b>Section:</b> 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 8 Sep 1998</p>
+<b>Section:</b> 22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 8 Sep 1998</p>
<p>The text of <tt>codecvt::do_max_length</tt>'s "Returns"
clause (22.2.1.5.2, paragraph 11) is garbled. It has unbalanced
parentheses and a spurious <b>n</b>.</p>
</blockquote>
<hr>
<a name="75"><h3>75. Contradiction in <tt>codecvt::length</tt>'s argument types</h3></a><p>
-<b>Section:</b> 22.2.1.5 <a href="lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt
+<b>Section:</b> 22.2.1.5 <a href="lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt
Austern <b>Date:</b> 18 Sep 1998</p>
<p>The class synopses for classes <tt>codecvt<></tt> (22.2.1.5)
and <tt>codecvt_byname<></tt> (22.2.1.6) say that the first
</p>
<hr>
<a name="78"><h3>78. Typo: event_call_back</h3></a><p>
-<b>Section:</b> 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
+<b>Section:</b> 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
<p>typo: event_call_back should be event_callback </p>
<p><b>Proposed resolution:</b></p>
<p>In the 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> synopsis change
"event_call_back" to "event_callback". </p>
<hr>
<a name="79"><h3>79. Inconsistent declaration of polar()</h3></a><p>
-<b>Section:</b> 26.2.1 <a href="lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, 26.2.7 <a href="lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
+<b>Section:</b> 26.2.1 <a href="lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, 26.2.7 <a href="lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
<p>In 26.2.1 <a href="lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a> polar is declared as follows:</p>
<pre> template<class T> complex<T> polar(const T&, const T&); </pre>
<pre> template<class T> complex<T> polar(const T& rho, const T& theta = 0); </pre>
<hr>
<a name="80"><h3>80. Global Operators of complex declared twice</h3></a><p>
-<b>Section:</b> 26.2.1 <a href="lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, 26.2.2 <a href="lib-numerics.html#lib.complex"> [lib.complex]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
+<b>Section:</b> 26.2.1 <a href="lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, 26.2.2 <a href="lib-numerics.html#lib.complex"> [lib.complex]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
<p>Both 26.2.1 and 26.2.2 contain declarations of global operators for
class complex. This redundancy should be removed.</p>
<p><b>Proposed resolution:</b></p>
<p>Reduce redundancy according to the general style of the standard. </p>
<hr>
<a name="83"><h3>83. String::npos vs. string::max_size()</h3></a><p>
-<b>Section:</b> 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
+<b>Section:</b> 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
<p>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
<p>The LWG believes length_error is the correct exception to throw.</p>
<hr>
<a name="86"><h3>86. String constructors don't describe exceptions</h3></a><p>
-<b>Section:</b> 21.3.1 <a href="lib-strings.html#lib.string.cons"> [lib.string.cons]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
+<b>Section:</b> 21.3.1 <a href="lib-strings.html#lib.string.cons"> [lib.string.cons]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
<p>The constructor from a range:</p>
<pre>template<class InputIterator>
resolution for issue <a href="lwg-defects.html#83">83</a>.</p>
<hr>
<a name="90"><h3>90. Incorrect description of operator >> for strings</h3></a><p>
-<b>Section:</b> 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
+<b>Section:</b> 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
<p>The effect of operator >> for strings contain the following item:</p>
<p> <tt>isspace(c,getloc())</tt> is true for the next available input
<p><i>[Tokyo: The LWG crafted the proposed resolution and rationale.]</i></p>
<hr>
<a name="106"><h3>106. Numeric library private members are implementation defined</h3></a><p>
-<b>Section:</b> 26.3.5 <a href="lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p>
+<b>Section:</b> 26.3.5 <a href="lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p>
<p>This is the only place in the whole standard where the implementation has to document
something private.</p>
<p><b>Proposed resolution:</b></p>
</ul>
<hr>
<a name="108"><h3>108. Lifetime of exception::what() return unspecified</h3></a><p>
-<b>Section:</b> 18.6.1 <a href="lib-support.html#lib.exception"> [lib.exception]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p>
+<b>Section:</b> 18.6.1 <a href="lib-support.html#lib.exception"> [lib.exception]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p>
<p>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
<hr>
<a name="110"><h3>110. istreambuf_iterator::equal not const</h3></a><p>
-<b>Section:</b> 24.5.3 <a href="lib-iterators.html#lib.istreambuf.iterator"> [lib.istreambuf.iterator]</a>, 24.5.3.5 <a href="lib-iterators.html#lib.istreambuf.iterator::equal"> [lib.istreambuf.iterator::equal]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 15 Oct 1998</p>
+<b>Section:</b> 24.5.3 <a href="lib-iterators.html#lib.istreambuf.iterator"> [lib.istreambuf.iterator]</a>, 24.5.3.5 <a href="lib-iterators.html#lib.istreambuf.iterator::equal"> [lib.istreambuf.iterator::equal]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 15 Oct 1998</p>
<p>Member istreambuf_iterator<>::equal is not declared
"const", yet 24.5.3.6 <a href="lib-iterators.html#lib.istreambuf.iterator::op=="> [lib.istreambuf.iterator::op==]</a> says that operator==,
which is const, calls it. This is contradictory. </p>
</blockquote>
<hr>
<a name="112"><h3>112. Minor typo in <tt>ostreambuf_iterator</tt> constructor</h3></a><p>
-<b>Section:</b> 24.5.4.1 <a href="lib-iterators.html#lib.ostreambuf.iter.cons"> [lib.ostreambuf.iter.cons]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 20 Oct 1998</p>
+<b>Section:</b> 24.5.4.1 <a href="lib-iterators.html#lib.ostreambuf.iter.cons"> [lib.ostreambuf.iter.cons]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 20 Oct 1998</p>
<p>The <b>requires</b> clause for <tt>ostreambuf_iterator</tt>'s
constructor from an <tt>ostream_type</tt> (24.5.4.1, paragraph 1)
reads "<i>s</i> is not null". However, <i>s</i> is a
</blockquote>
<hr>
<a name="114"><h3>114. Placement forms example in error twice</h3></a><p>
-<b>Section:</b> 18.4.1.3 <a href="lib-support.html#lib.new.delete.placement"> [lib.new.delete.placement]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 28 Oct 1998</p>
+<b>Section:</b> 18.4.1.3 <a href="lib-support.html#lib.new.delete.placement"> [lib.new.delete.placement]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 28 Oct 1998</p>
<p>Section 18.4.1.3 contains the following example: </p>
<pre>[Example: This can be useful for constructing an object at a known address:
</blockquote>
<hr>
<a name="115"><h3>115. Typo in strstream constructors</h3></a><p>
-<b>Section:</b> D.7.4.1 <a href="future.html#depr.strstream.cons"> [depr.strstream.cons]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 2 Nov 1998</p>
+<b>Section:</b> D.7.4.1 <a href="future.html#depr.strstream.cons"> [depr.strstream.cons]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 2 Nov 1998</p>
<p>D.7.4.1 strstream constructors paragraph 2 says: </p>
<blockquote>
<p><i>[Post-Tokyo: PJP provided the above wording.]</i></p>
<hr>
<a name="119"><h3>119. Should virtual functions be allowed to strengthen the exception specification?</h3></a><p>
-<b>Section:</b> 17.4.4.8 <a href="lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
+<b>Section:</b> 17.4.4.8 <a href="lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
<p>Section 17.4.4.8 <a href="lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> states: </p>
<p>"An implementation may strengthen the exception-specification
exception-specification for a non-virtual function". </p>
<hr>
<a name="122"><h3>122. streambuf/wstreambuf description should not say they are specializations</h3></a><p>
-<b>Section:</b> 27.5.2 <a href="lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
+<b>Section:</b> 27.5.2 <a href="lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
<p>Section 27.5.2 describes the streambuf classes this way: </p>
<blockquote>
typedefs and that is sufficient. </p>
<hr>
<a name="124"><h3>124. ctype_byname<charT>::do_scan_is & do_scan_not return type should be const charT*</h3></a><p>
-<b>Section:</b> 22.2.1.2 <a href="lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
+<b>Section:</b> 22.2.1.2 <a href="lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
<p>In Section 22.2.1.2 <a href="lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a>
ctype_byname<charT>::do_scan_is() and do_scan_not() are declared
to return a const char* not a const charT*. </p>
charT*</tt>. </p>
<hr>
<a name="125"><h3>125. valarray<T>::operator!() return type is inconsistent</h3></a><p>
-<b>Section:</b> 26.3.2 <a href="lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
+<b>Section:</b> 26.3.2 <a href="lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
<p>In Section 26.3.2 <a href="lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> valarray<T>::operator!() is
declared to return a valarray<T>, but in Section 26.3.2.5 <a href="lib-numerics.html#lib.valarray.unary"> [lib.valarray.unary]</a> it is declared to return a valarray<bool>. The
latter appears to be correct. </p>
<tt>valarray<bool></tt>. </p>
<hr>
<a name="126"><h3>126. typos in Effects clause of ctype::do_narrow()</h3></a><p>
-<b>Section:</b> 22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
+<b>Section:</b> 22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
<p>Typos in 22.2.1.1.2 need to be fixed.</p>
<p><b>Proposed resolution:</b></p>
<p>In Section 22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> change: </p>
<pre> (is(M,c) || !ctc.is(M, do_narrow(c,dfault)) )</pre>
<hr>
<a name="127"><h3>127. auto_ptr<> conversion issues</h3></a><p>
-<b>Section:</b> 20.4.5 <a href="lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Greg Colvin <b>Date:</b> 17 Feb 1999</p>
+<b>Section:</b> 20.4.5 <a href="lib-utilities.html#lib.auto.ptr"> [lib.auto.ptr]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Greg Colvin <b>Date:</b> 17 Feb 1999</p>
<p>There are two problems with the current <tt>auto_ptr</tt> wording
in the standard: </p>
</blockquote>
<hr>
<a name="129"><h3>129. Need error indication from seekp() and seekg()</h3></a><p>
-<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>, 27.6.2.4 <a href="lib-iostreams.html#lib.ostream.seeks"> [lib.ostream.seeks]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 22 Feb 1999</p>
+<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>, 27.6.2.4 <a href="lib-iostreams.html#lib.ostream.seeks"> [lib.ostream.seeks]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 22 Feb 1999</p>
<p>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
<p>Setting failbit is the usual error reporting mechanism for streams</p>
<hr>
<a name="132"><h3>132. list::resize description uses random access iterators</h3></a><p>
-<b>Section:</b> 23.2.2.2 <a href="lib-containers.html#lib.list.capacity"> [lib.list.capacity]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 6 Mar 1999</p>
+<b>Section:</b> 23.2.2.2 <a href="lib-containers.html#lib.list.capacity"> [lib.list.capacity]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 6 Mar 1999</p>
<p>The description reads:</p>
<p>-1- Effects:</p>
no issue of exception safety with the proposed resolution.]</i></p>
<hr>
<a name="133"><h3>133. map missing get_allocator()</h3></a><p>
-<b>Section:</b> 23.3.1 <a href="lib-containers.html#lib.map"> [lib.map]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 6 Mar 1999</p>
+<b>Section:</b> 23.3.1 <a href="lib-containers.html#lib.map"> [lib.map]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 6 Mar 1999</p>
<p>The title says it all.</p>
<p><b>Proposed resolution:</b></p>
<p>Insert in 23.3.1 <a href="lib-containers.html#lib.map"> [lib.map]</a>, paragraph 2,
<pre> allocator_type get_allocator() const;</pre>
<hr>
<a name="134"><h3>134. vector constructors over specified</h3></a><p>
-<b>Section:</b> 23.2.4.1 <a href="lib-containers.html#lib.vector.cons"> [lib.vector.cons]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 6 Mar 1999</p>
+<b>Section:</b> 23.2.4.1 <a href="lib-containers.html#lib.vector.cons"> [lib.vector.cons]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 6 Mar 1999</p>
<p>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 ...".</p>
basic_filebuf<>::seekpos.]</i></p>
<hr>
<a name="137"><h3>137. Do use_facet and has_facet look in the global locale?</h3></a><p>
-<b>Section:</b> 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 17 Mar 1999</p>
+<b>Section:</b> 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 17 Mar 1999</p>
<p>Section 22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a> says:</p>
<p>-4- In the call to use_facet<Facet>(loc), the type argument
in the standard.</p>
<hr>
<a name="139"><h3>139. Optional sequence operation table description unclear</h3></a><p>
-<b>Section:</b> 23.1.1 <a href="lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 30 Mar 1999</p>
+<b>Section:</b> 23.1.1 <a href="lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 30 Mar 1999</p>
<p>The sentence introducing the Optional sequence operation table
(23.1.1 paragraph 12) has two problems:</p>
</blockquote>
<hr>
<a name="141"><h3>141. basic_string::find_last_of, find_last_not_of say pos instead of xpos</h3></a><p>
-<b>Section:</b> 21.3.6.4 <a href="lib-strings.html#lib.string::find.last.of"> [lib.string::find.last.of]</a>, 21.3.6.6 <a href="lib-strings.html#lib.string::find.last.not.of"> [lib.string::find.last.not.of]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Arch Robison <b>Date:</b> 28 Apr 1999</p>
+<b>Section:</b> 21.3.6.4 <a href="lib-strings.html#lib.string::find.last.of"> [lib.string::find.last.of]</a>, 21.3.6.6 <a href="lib-strings.html#lib.string::find.last.not.of"> [lib.string::find.last.not.of]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Arch Robison <b>Date:</b> 28 Apr 1999</p>
<p>Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1 surely have misprints where they
say:<br>
<br>
</p>
<hr>
<a name="142"><h3>142. lexicographical_compare complexity wrong</h3></a><p>
-<b>Section:</b> 25.3.8 <a href="lib-algorithms.html#lib.alg.lex.comparison"> [lib.alg.lex.comparison]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 20 Jun 1999</p>
+<b>Section:</b> 25.3.8 <a href="lib-algorithms.html#lib.alg.lex.comparison"> [lib.alg.lex.comparison]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 20 Jun 1999</p>
<p>The lexicographical_compare complexity is specified as:<br>
<br>
"At most min((last1 - first1), (last2 - first2))
</blockquote>
<hr>
<a name="144"><h3>144. Deque constructor complexity wrong </h3></a><p>
-<b>Section:</b> 23.2.1.1 <a href="lib-containers.html#lib.deque.cons"> [lib.deque.cons]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Herb Sutter <b>Date:</b> 9 May 1999</p>
+<b>Section:</b> 23.2.1.1 <a href="lib-containers.html#lib.deque.cons"> [lib.deque.cons]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Herb Sutter <b>Date:</b> 9 May 1999</p>
<p>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,
</blockquote>
<hr>
<a name="146"><h3>146. complex<T> Inserter and Extractor need sentries</h3></a><p>
-<b>Section:</b> 26.2.6 <a href="lib-numerics.html#lib.complex.ops"> [lib.complex.ops]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 12 May 1999</p>
+<b>Section:</b> 26.2.6 <a href="lib-numerics.html#lib.complex.ops"> [lib.complex.ops]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 12 May 1999</p>
<p>The <u> extractor</u> for complex numbers is specified as: </p>
<blockquote>
as written.</p>
<hr>
<a name="147"><h3>147. Library Intro refers to global functions that aren't global</h3></a><p>
-<b>Section:</b> 17.4.4.3 <a href="lib-intro.html#lib.global.functions"> [lib.global.functions]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Lois Goldthwaite <b>Date:</b> 4 Jun 1999</p>
+<b>Section:</b> 17.4.4.3 <a href="lib-intro.html#lib.global.functions"> [lib.global.functions]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Lois Goldthwaite <b>Date:</b> 4 Jun 1999</p>
<p>The library had many global functions until 17.4.1.1 [lib.contents]
paragraph 2 was added: </p>
</p>
<hr>
<a name="148"><h3>148. Functions in the example facet BoolNames should be const</h3></a><p>
-<b>Section:</b> 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Jeremy Siek <b>Date:</b> 3 Jun 1999</p>
+<b>Section:</b> 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Jeremy Siek <b>Date:</b> 3 Jun 1999</p>
<p>In 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> paragraph 13, the do_truename() and
do_falsename() functions in the example facet BoolNames should be
const. The functions they are overriding in
</blockquote>
<hr>
<a name="150"><h3>150. Find_first_of says integer instead of iterator </h3></a><p>
-<b>Section:</b> 25.1.4 <a href="lib-algorithms.html#lib.alg.find.first.of"> [lib.alg.find.first.of]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt McClure <b>Date:</b> 30 Jun 1999</p>
+<b>Section:</b> 25.1.4 <a href="lib-algorithms.html#lib.alg.find.first.of"> [lib.alg.find.first.of]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt McClure <b>Date:</b> 30 Jun 1999</p>
<p><b>Proposed resolution:</b></p>
<p>Change 25.1.4 <a href="lib-algorithms.html#lib.alg.find.first.of"> [lib.alg.find.first.of]</a> paragraph 2 from:</p>
</blockquote>
<hr>
<a name="151"><h3>151. Can't currently clear() empty container</h3></a><p>
-<b>Section:</b> 23.1.1 <a href="lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Ed Brey <b>Date:</b> 21 Jun 1999</p>
+<b>Section:</b> 23.1.1 <a href="lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Ed Brey <b>Date:</b> 21 Jun 1999</p>
<p>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
</blockquote>
<hr>
<a name="152"><h3>152. Typo in <tt>scan_is()</tt> semantics</h3></a><p>
-<b>Section:</b> 22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
+<b>Section:</b> 22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
<p>The semantics of <tt>scan_is()</tt> (paragraphs 4 and 6) is not exactly described
because there is no function <tt>is()</tt> which only takes a character as
argument. Also, in the effects clause (paragraph 3), the semantic is also kept
<hr>
<a name="154"><h3>154. Missing <tt>double</tt> specifier for <tt>do_get()</tt>
</h3></a><p>
-<b>Section:</b> 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
+<b>Section:</b> 22.2.2.1.2 <a href="lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
<p>The table in paragraph 7 for the length modifier does not list the length
modifier <tt>l</tt> to be applied if the type is <tt>double</tt>. Thus, the
standard asks the implementation to do undefined things when using <tt>scanf()</tt>
<hr>
<a name="155"><h3>155. Typo in naming the class defining the class <tt>Init</tt>
</h3></a><p>
-<b>Section:</b> 27.3 <a href="lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
+<b>Section:</b> 27.3 <a href="lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
<p>There are conflicting statements about where the class
<tt>Init</tt> is defined. According to 27.3 <a href="lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> paragraph 2
it is defined as <tt>basic_ios::Init</tt>, according to 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> it is defined as <tt>ios_base::Init</tt>.</p>
the change.</p>
<hr>
<a name="156"><h3>156. Typo in <tt>imbue()</tt> description</h3></a><p>
-<b>Section:</b> 27.4.2.3 <a href="lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
+<b>Section:</b> 27.4.2.3 <a href="lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
<p>There is a small discrepancy between the declarations of
<tt>imbue()</tt>: in 27.4.2 <a href="lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> the argument is passed as
<tt>locale const&</tt> (correct), in 27.4.2.3 <a href="lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> it
<hr>
<a name="158"><h3>158. Underspecified semantics for <tt>setbuf()</tt>
</h3></a><p>
-<b>Section:</b> 27.5.2.4.2 <a href="lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
+<b>Section:</b> 27.5.2.4.2 <a href="lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
<p>The default behavior of <tt>setbuf()</tt> is described only for the
situation that <tt>gptr() != 0 && gptr() != egptr()</tt>:
namely to do nothing. What has to be done in other situations
<hr>
<a name="159"><h3>159. Strange use of <tt>underflow()</tt>
</h3></a><p>
-<b>Section:</b> 27.5.2.4.3 <a href="lib-iostreams.html#lib.streambuf.virt.get"> [lib.streambuf.virt.get]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
+<b>Section:</b> 27.5.2.4.3 <a href="lib-iostreams.html#lib.streambuf.virt.get"> [lib.streambuf.virt.get]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
<p>The description of the meaning of the result of
<tt>showmanyc()</tt> seems to be rather strange: It uses calls to
<tt>underflow()</tt>. Using <tt>underflow()</tt> is strange because
<hr>
<a name="160"><h3>160. Typo: Use of non-existing function <tt>exception()</tt>
</h3></a><p>
-<b>Section:</b> 27.6.1.1 <a href="lib-iostreams.html#lib.istream"> [lib.istream]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
+<b>Section:</b> 27.6.1.1 <a href="lib-iostreams.html#lib.istream"> [lib.istream]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
<p>The paragraph 4 refers to the function <tt>exception()</tt> which
is not defined. Probably, the referred function is
<tt>basic_ios<>::exceptions()</tt>.</p>
<hr>
<a name="161"><h3>161. Typo: <tt>istream_iterator</tt> vs. <tt>istreambuf_iterator</tt>
</h3></a><p>
-<b>Section:</b> 27.6.1.2.2 <a href="lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
+<b>Section:</b> 27.6.1.2.2 <a href="lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
<p>The note in the second paragraph pretends that the first argument
is an object of type <tt>istream_iterator</tt>. This is wrong: It is
an object of type <tt>istreambuf_iterator</tt>.</p>
</blockquote>
<hr>
<a name="164"><h3>164. do_put() has apparently unused fill argument</h3></a><p>
-<b>Section:</b> 22.2.5.3.2 <a href="lib-locales.html#lib.locale.time.put.virtuals"> [lib.locale.time.put.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 23 Jul 1999</p>
+<b>Section:</b> 22.2.5.3.2 <a href="lib-locales.html#lib.locale.time.put.virtuals"> [lib.locale.time.put.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 23 Jul 1999</p>
<p>In 22.2.5.3.2 <a href="lib-locales.html#lib.locale.time.put.virtuals"> [lib.locale.time.put.virtuals]</a> 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,
is allowed to call sync() while other functions are not.]</i></p>
<hr>
<a name="168"><h3>168. Typo: formatted vs. unformatted</h3></a><p>
-<b>Section:</b> 27.6.2.6 <a href="lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
+<b>Section:</b> 27.6.2.6 <a href="lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
<p>The first paragraph begins with a descriptions what has to be done
in <i>formatted</i> output functions. Probably this is a typo and the
paragraph really want to describe unformatted output functions...</p>
</blockquote>
<hr>
<a name="169"><h3>169. Bad efficiency of <tt>overflow()</tt> mandated</h3></a><p>
-<b>Section:</b> 27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
+<b>Section:</b> 27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
<p>Paragraph 8, Notes, of this section seems to mandate an extremely
inefficient way of buffer handling for <tt>basic_stringbuf</tt>,
especially in view of the restriction that <tt>basic_ostream</tt>
<hr>
<a name="170"><h3>170. Inconsistent definition of <tt>traits_type</tt>
</h3></a><p>
-<b>Section:</b> 27.7.4 <a href="lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
+<b>Section:</b> 27.7.4 <a href="lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
<p>The classes <tt>basic_stringstream</tt> (27.7.4 <a href="lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a>),
<tt>basic_istringstream</tt> (27.7.2 <a href="lib-iostreams.html#lib.istringstream"> [lib.istringstream]</a>), and
<tt>basic_ostringstream</tt> (27.7.3 <a href="lib-iostreams.html#lib.ostringstream"> [lib.ostringstream]</a>) are inconsistent
<hr>
<a name="172"><h3>172. Inconsistent types for <tt>basic_istream::ignore()</tt>
</h3></a><p>
-<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
+<b>Section:</b> 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
<p>In 27.6.1.1 <a href="lib-iostreams.html#lib.istream"> [lib.istream]</a> the function
<tt>ignore()</tt> gets an object of type <tt>streamsize</tt> as first
argument. However, in 27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>
<hr>
<a name="173"><h3>173. Inconsistent types for <tt>basic_filebuf::setbuf()</tt>
</h3></a><p>
-<b>Section:</b> 27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
+<b>Section:</b> 27.8.1.4 <a href="lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
<p>
In 27.8.1.1 <a href="lib-iostreams.html#lib.filebuf"> [lib.filebuf]</a> the function <tt>setbuf()</tt> gets an
<hr>
<a name="174"><h3>174. Typo: <tt>OFF_T</tt> vs. <tt>POS_T</tt>
</h3></a><p>
-<b>Section:</b> D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
+<b>Section:</b> D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
<p>According to paragraph 1 of this section, <tt>streampos</tt> is the
type <tt>OFF_T</tt>, the same type as <tt>streamoff</tt>. However, in
paragraph 6 the <tt>streampos</tt> gets the type <tt>POS_T</tt>
streampos;</tt>"</p>
<hr>
<a name="175"><h3>175. Ambiguity for <tt>basic_streambuf::pubseekpos()</tt> and a few other functions.</h3></a><p>
-<b>Section:</b> D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
+<b>Section:</b> D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
<p>According to paragraph 8 of this section, the methods
<tt>basic_streambuf::pubseekpos()</tt>,
<tt>basic_ifstream::open()</tt>, and <tt>basic_ofstream::open</tt>
</p>
<hr>
<a name="176"><h3>176. <tt>exceptions()</tt> in <tt>ios_base</tt>...?</h3></a><p>
-<b>Section:</b> D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
+<b>Section:</b> D.6 <a href="future.html#depr.ios.members"> [depr.ios.members]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
<p>The "overload" for the function <tt>exceptions()</tt> in
paragraph 8 gives the impression that there is another function of
this function defined in class <tt>ios_base</tt>. However, this is not
function <tt>exceptions()</tt>into class <tt>basic_ios</tt>.</p>
<hr>
<a name="181"><h3>181. make_pair() unintended behavior</h3></a><p>
-<b>Section:</b> 20.2.2 <a href="lib-utilities.html#lib.pairs"> [lib.pairs]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 3 Aug 1999</p>
+<b>Section:</b> 20.2.2 <a href="lib-utilities.html#lib.pairs"> [lib.pairs]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 3 Aug 1999</p>
<p>The claim has surfaced in Usenet that expressions such as<br>
<br>
<tt>make_pair("abc", 3)</tt><br>
nonvirtual member of a standard library class.</p>
<hr>
<a name="189"><h3>189. setprecision() not specified correctly</h3></a><p>
-<b>Section:</b> 27.4.2.2 <a href="lib-iostreams.html#lib.fmtflags.state"> [lib.fmtflags.state]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 25 Aug 1999</p>
+<b>Section:</b> 27.4.2.2 <a href="lib-iostreams.html#lib.fmtflags.state"> [lib.fmtflags.state]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 25 Aug 1999</p>
<p>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.<br>
"(number of digits after the decimal point)".</p>
<hr>
<a name="193"><h3>193. Heap operations description incorrect</h3></a><p>
-<b>Section:</b> 25.3.6 <a href="lib-algorithms.html#lib.alg.heap.operations"> [lib.alg.heap.operations]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Markus Mauhart <b>Date:</b> 24 Sep 1999</p>
+<b>Section:</b> 25.3.6 <a href="lib-algorithms.html#lib.alg.heap.operations"> [lib.alg.heap.operations]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Markus Mauhart <b>Date:</b> 24 Sep 1999</p>
<p>25.3.6 [lib.alg.heap.operations] states two key properties of a heap [a,b), the first of them
is<br>
<br>
</blockquote>
<hr>
<a name="195"><h3>195. Should <tt>basic_istream::sentry</tt>'s constructor ever set eofbit?</h3></a><p>
-<b>Section:</b> 27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 13 Oct 1999</p>
+<b>Section:</b> 27.6.1.1.2 <a href="lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 13 Oct 1999</p>
<p>Suppose that <tt>is.flags() & ios_base::skipws</tt> is nonzero.
What should <tt>basic_istream<>::sentry</tt>'s constructor do if it
reaches eof while skipping whitespace? 27.6.1.1.2/5 suggests it
<hr>
<a name="199"><h3>199. What does <tt>allocate(0)</tt> return?</h3></a><p>
-<b>Section:</b> 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 19 Nov 1999</p>
+<b>Section:</b> 20.1.5 <a href="lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 19 Nov 1999</p>
<p>
Suppose that <tt>A</tt> is a class that conforms to the
Allocator requirements of Table 32, and <tt>a</tt> is an
</p>
<hr>
<a name="208"><h3>208. Unnecessary restriction on past-the-end iterators</h3></a><p>
-<b>Section:</b> 24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Stephen Cleary <b>Date:</b> 02 Feb 2000</p>
+<b>Section:</b> 24.1 <a href="lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Stephen Cleary <b>Date:</b> 02 Feb 2000</p>
<p>In 24.1 paragraph 5, it is stated ". . . Dereferenceable and
past-the-end values are always non-singular."</p>
<p>This places an unnecessary restriction on past-the-end iterators for
</p>
<hr>
<a name="209"><h3>209. basic_string declarations inconsistent</h3></a><p>
-<b>Section:</b> 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Igor Stauder <b>Date:</b> 11 Feb 2000</p>
+<b>Section:</b> 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Igor Stauder <b>Date:</b> 11 Feb 2000</p>
<p>In Section 21.3 <a href="lib-strings.html#lib.basic.string"> [lib.basic.string]</a> the basic_string member function
declarations use a consistent style except for the following functions:</p>
<blockquote>
</p>
<hr>
<a name="210"><h3>210. distance first and last confused</h3></a><p>
-<b>Section:</b> 25 <a href="lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Lisa Lippincott <b>Date:</b> 15 Feb 2000</p>
+<b>Section:</b> 25 <a href="lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Lisa Lippincott <b>Date:</b> 15 Feb 2000</p>
<p>In paragraph 9 of section 25 <a href="lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a>, it is written:</p>
<blockquote>
<p> In the description of the algorithms operators + and - are used
former for consistency.</p>
<hr>
<a name="211"><h3>211. operator>>(istream&, string&) doesn't set failbit</h3></a><p>
-<b>Section:</b> 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Scott Snyder <b>Date:</b> 4 Feb 2000</p>
+<b>Section:</b> 21.3.7.9 <a href="lib-strings.html#lib.string.io"> [lib.string.io]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Scott Snyder <b>Date:</b> 4 Feb 2000</p>
<p>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
</blockquote>
<hr>
<a name="212"><h3>212. Empty range behavior unclear for several algorithms</h3></a><p>
-<b>Section:</b> 25.3.7 <a href="lib-algorithms.html#lib.alg.min.max"> [lib.alg.min.max]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 26 Feb 2000</p>
+<b>Section:</b> 25.3.7 <a href="lib-algorithms.html#lib.alg.min.max"> [lib.alg.min.max]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 26 Feb 2000</p>
<p>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(),
equal_range.]</i></p>
<hr>
<a name="217"><h3>217. Facets example (Classifying Japanese characters) contains errors</h3></a><p>
-<b>Section:</b> 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 29 Feb 2000</p>
+<b>Section:</b> 22.2.8 <a href="lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 29 Feb 2000</p>
<p>The example in 22.2.8, paragraph 11 contains the following errors:</p>
<p>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
}</pre>
<hr>
<a name="220"><h3>220. ~ios_base() usage valid?</h3></a><p>
-<b>Section:</b> 27.4.2.7 <a href="lib-iostreams.html#lib.ios.base.cons"> [lib.ios.base.cons]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Jonathan Schilling, Howard Hinnant <b>Date:</b> 13 Mar 2000</p>
+<b>Section:</b> 27.4.2.7 <a href="lib-iostreams.html#lib.ios.base.cons"> [lib.ios.base.cons]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Jonathan Schilling, Howard Hinnant <b>Date:</b> 13 Mar 2000</p>
<p>The pre-conditions for the ios_base destructor are described in 27.4.2.7
paragraph 2:</p>
<blockquote>
deliberately, with full knowledge of that limitation.</p>
<hr>
<a name="222"><h3>222. Are throw clauses necessary if a throw is already implied by the effects clause?</h3></a><p>
-<b>Section:</b> 17.3.1.3 <a href="lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 17 Mar 2000</p>
+<b>Section:</b> 17.3.1.3 <a href="lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 17 Mar 2000</p>
<p>Section 21.3.6.8 describes the basic_string::compare function this way:</p>
<blockquote>
<pre>21.3.6.8 - basic_string::compare [lib.string::compare]
footnote.</p>
<hr>
<a name="223"><h3>223. reverse algorithm should use iter_swap rather than swap</h3></a><p>
-<b>Section:</b> 25.2.9 <a href="lib-algorithms.html#lib.alg.reverse"> [lib.alg.reverse]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 21 Mar 2000</p>
+<b>Section:</b> 25.2.9 <a href="lib-algorithms.html#lib.alg.reverse"> [lib.alg.reverse]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 21 Mar 2000</p>
<p>Shouldn't the effects say "applies iter_swap to all pairs..."?</p>
<p><b>Proposed resolution:</b></p>
<p>In 25.2.9 <a href="lib-algorithms.html#lib.alg.reverse"> [lib.alg.reverse]</a>, replace:</p>
</blockquote>
<hr>
<a name="224"><h3>224. clear() complexity for associative containers refers to undefined N</h3></a><p>
-<b>Section:</b> 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Ed Brey <b>Date:</b> 23 Mar 2000</p>
+<b>Section:</b> 23.1.2 <a href="lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Ed Brey <b>Date:</b> 23 Mar 2000</p>
<p>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.</p>
cut-and-paste from the range version of <tt>erase</tt>.</p>
<hr>
<a name="227"><h3>227. std::swap() should require CopyConstructible or DefaultConstructible arguments</h3></a><p>
-<b>Section:</b> 25.2.2 <a href="lib-algorithms.html#lib.alg.swap"> [lib.alg.swap]</a> <b>Status:</b> <a href="lwg-active.html#DR">DR</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 09 Apr 2000</p>
+<b>Section:</b> 25.2.2 <a href="lib-algorithms.html#lib.alg.swap"> [lib.alg.swap]</a> <b>Status:</b> <a href="lwg-active.html#TC">TC</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 09 Apr 2000</p>
<p>25.2.2 reads:</p>
<blockquote>
<p>
<li><a href="#3_5"><code>_XOPEN_SOURCE</code> /
<code>_GNU_SOURCE</code> / etc is always defined</a>
</li>
- <li><a href="#3_6">OS X ctype.h is broken! How can I hack it?</a> </li>
+ <li><a href="#3_6">OS X ctype.h is broken! How can I hack it?</a></li>
+ <li><a href="#3_7">Threading is broken on i386</a></li>
</ol>
</li>
</p>
<hr />
+ <h2><a name="3_7">Threading is broken on i386</a></h2>
+ <p>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.
+ </p>
+ <p>This is fixed in 3.2.2.
+ </p>
+
+<hr />
<h1><a name="4_0">4.0 Known Bugs and Non-Bugs</a></h1>
<em>Note that this section can get rapdily outdated -- such is the
nature of an open-source project. For the latest information, join
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.
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<T>::iterator is not
+ 5. [40]Aw, that's easy to fix!
+ 5. [41]Miscellaneous
+ 1. [42]string::iterator is not char*; vector<T>::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
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/<pick-a-language> compiler (gcc, g++, etc) is
+ The GNU C/C++/FORTRAN/<pick-a-language> compiler (gcc, g++, etc) is
widely considered to be one of the leading compilers in the world. Its
- development has recently been taken over by the [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<T> 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<T> and do not need to be created by genclass. (For that matter,
+ templates exist now and are well-supported, whereas genclass (mostly)
predates them.)
- There are other classes in libg++ that are not specified in the ISO
+ 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.
_________________________________________________________________
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...
_________________________________________________________________
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.
_________________________________________________________________
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.
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 <fstream>,
- 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 <fstream>,
+ 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?
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 <fstream>
...
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 <iterator> 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 <iterator> 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.
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
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.
_________________________________________________________________
5.1 string::iterator is not char*; vector<T>::iterator is not T*
- If you have code that depends on container<T> iterators being
+ If you have code that depends on container<T> iterators being
implemented as pointer-to-T, your code is broken.
- While there are arguments for iterators to be implemented in that
- manner, A) they aren't very good ones in the long term, and B) they
+ 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
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 <ext/hash_map>
- 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.,
<sys/stat.h>, <X11/Xlib.h>.
- 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;
// 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;
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
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
projects / platform / upstream / linaro-gcc.git / commitdiff