+2003-01-23 Phil Edwards <pme@gcc.gnu.org>
+
+ Bulk documentation merge (copy) from trunk.
+ * docs/doxygen/TODO, docs/doxygen/run_doxygen,
+ docs/doxygen/stdheader.cc, docs/doxygen/style.css,
+ docs/doxygen/tables.html, docs/doxygen/user.cfg.in,
+ docs/html/configopts.html, docs/html/debug.html,
+ docs/html/documentation.html, docs/html/explanations.html,
+ docs/html/install.html, docs/html/17_intro/contribute.html,
+ docs/html/17_intro/howto.html, docs/html/17_intro/license.html,
+ docs/html/17_intro/porting.html, docs/html/17_intro/porting.texi,
+ docs/html/18_support/howto.html, docs/html/19_diagnostics/howto.html,
+ docs/html/20_util/howto.html, docs/html/21_strings/howto.html,
+ docs/html/22_locale/codecvt.html, docs/html/22_locale/ctype.html,
+ docs/html/22_locale/howto.html, docs/html/22_locale/locale.html,
+ docs/html/22_locale/messages.html, docs/html/24_iterators/howto.html,
+ docs/html/25_algorithms/howto.html, docs/html/26_numerics/howto.html,
+ docs/html/27_io/howto.html, docs/html/ext/lwg-active.html,
+ docs/html/ext/lwg-defects.html, docs/html/ext/sgiexts.html,
+ docs/html/faq/index.html, docs/html/faq/index.txt: Merge from trunk.
+
2003-01-23 Petur Runolfsson <peturr02@ru.is>
PR libstdc++/9322
stream iterators
c25 stl_algo.h (lots of stuff)
c26 <complex>, <valarray>, stl_numeric.h[26.4], Note A
-c27 Untouched
+c27 ios_base callbacks and local storage
+ basic_ios::copyfmt()
+ std_streambuf.h's __copy_streambufs()
+ " " _M_* protected memfns (data has been done)
+ fstream and sstream protected members
backward/* Not scanned by doxygen. Should it be? Doubtful.
problematic=`egrep -l '#include <.*_.*>' [a-z]*.3`
for f in $problematic; do
# this is also slow, but safe and easy to debug
- oldh=`sed -n '/#include </s/.*<\(.*\)>.*/\1/p' $f`
+ oldh=`sed -n '/fC#include </s/.*<\(.*\)>.*/\1/p' $f`
newh=`echo $oldh | ./stdheader`
sed "s=${oldh}=${newh}=" $f > TEMP
mv TEMP $f
{
std::string::size_type start = 0;
+ // if it doesn't contain a "." then it's already a std header
+ if (longheader.find(".") == std::string::npos)
+ {
+ std::cout << longheader << '\n';
+ return;
+ }
+
if (longheader.substr(start,5) == "bits/") start += 5;
if ((longheader.substr(start,4) == "stl_") ||
(longheader.substr(start,4) == "std_"))
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 }
are also noted or incorporated.
</p>
-<p class="smallertext">This will probably be incomplete for a while because
-filling out the tables is mind-frothingly boring. Also, the HTML table
-rendering is ugly. (Update: mozilla 0.9.9 looks MUCH better.)</p>
-
<hr />
<a name="65"><p>
-# Doxyfile 1.2.12
+# Doxyfile 1.3-rc2
# 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 HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any
+# documentation blocks found inside the body of a function.
+# If set to NO (the default) these blocks will be appended to the
+# function's detailed documentation block.
+
+HIDE_IN_BODY_DOCS = 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).
BRIEF_MEMBER_DESC = YES
# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend
-# the brief description of a member or function before the detailed description.
+# the brief description of a member or function before the detailed description.
# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the
# brief descriptions will be completely suppressed.
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.
INTERNAL_DOCS = NO
-# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct
-# doxygen to hide any special comment blocks from generated source code
-# fragments. Normal C and C++ comments will always remain visible.
-
-STRIP_CODE_COMMENTS = YES
-
# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate
# file names in lower case letters. If set to YES upper case letters are also
# allowed. This is useful if you have classes or files whose names only differ
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.
WARN_IF_UNDOCUMENTED = NO
+# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for
+# potential errors in the documentation, such as not documenting some
+# parameters in a documented function, or documenting parameters that
+# don't exist or using markup commands wrongly.
+
+WARN_IF_DOC_ERROR = NO
+
# The WARN_FORMAT tag determines the format of the warning messages that
# doxygen can produce. The string should contain the $file, $line, and $text
# tags, which will be replaced by the file and line number from which the
# excluded from the INPUT source files. This way you can easily exclude a
# subdirectory from a directory tree whose root is specified with the INPUT tag.
-EXCLUDE = Makefile CVS
+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
INLINE_SOURCES = NO
+# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct
+# doxygen to hide any special comment blocks from generated source code
+# fragments. Normal C and C++ comments will always remain visible.
+
+STRIP_CODE_COMMENTS = YES
+
# If the REFERENCED_BY_RELATION tag is set to YES (the default)
# then for each documented function all documented
# functions referencing it will be listed.
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.
MAN_EXTENSION = .3
-# If the MAN_LINKS tag is set to YES and Doxygen generates man output,
-# then it will generate one additional man file for each entity
-# documented in the real man page(s). These additional files
-# only source the real man page, but without them the man command
+# If the MAN_LINKS tag is set to YES and Doxygen generates man output,
+# then it will generate one additional man file for each entity
+# documented in the real man page(s). These additional files
+# only source the real man page, but without them the man command
# would be unable to find the correct page. The default is NO.
MAN_LINKS = NO
GENERATE_XML = NO
+# The XML_SCHEMA tag can be used to specify an XML schema,
+# which can be used by a validating XML parser to check the
+# syntax of the XML files.
+
+XML_SCHEMA =
+
+# The XML_DTD tag can be used to specify an XML DTD,
+# which can be used by a validating XML parser to check the
+# syntax of the XML files.
+
+XML_DTD =
+
+#---------------------------------------------------------------------------
+# configuration options for the AutoGen Definitions output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will
+# generate an AutoGen Definitions (see autogen.sf.net) file
+# that captures the structure of the code including all
+# documentation. Note that this feature is still experimental
+# and incomplete at the moment.
+
+GENERATE_AUTOGEN_DEF = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to the Perl module output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_PERLMOD tag is set to YES Doxygen will
+# generate a Perl module file that captures the structure of
+# the code including all documentation. Note that this
+# feature is still experimental and incomplete at the
+# moment.
+
+GENERATE_PERLMOD = NO
+
+# If the PERLMOD_LATEX tag is set to YES Doxygen will generate
+# the necessary Makefile rules, Perl scripts and LaTeX code to be able
+# to generate PDF and DVI output from the Perl module output.
+
+PERLMOD_LATEX = NO
+
+# If the PERLMOD_PRETTY tag is set to YES the Perl module output will be
+# nicely formatted so it can be parsed by a human reader. This is useful
+# if you want to understand what is going on. On the other hand, if this
+# tag is set to NO the size of the Perl module output will be much smaller
+# and Perl will parse it just the same.
+
+PERLMOD_PRETTY = YES
+
+# The names of the make variables in the generated doxyrules.make file
+# are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX.
+# This is useful so different doxyrules.make files included by the same
+# Makefile don't overwrite each other's variables.
+
+PERLMOD_MAKEVAR_PREFIX =
+
#---------------------------------------------------------------------------
# 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.
# the documentation for these projects as well.
EXT_DOC_PATHS =
-
-### End of file.
-
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>How to contribute</title>
</head>
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
<p>For each entry, we give the section number of the standard, when
applicable. This list is probably incomplet and inkorrekt.
</p>
+ <p><strong>[1.9]/11 #3</strong> If <code>isatty(3)</code> is true, then
+ interactive stream support is implied.
+ </p>
<p><strong>[17.4.4.5]</strong> Non-reentrant functions are probably best
discussed in the various sections on multithreading (see above).
</p>
here would defeat the purpose. :-)
</p>
<p><strong>[21.1.3.1]/5</strong> I don't really know about the mbstate_t
- stuff... see the chapter 22 notes for what does exist.
+ stuff... see the <a href="../22_locale/howto.html">chapter 22 notes</a>
+ for what does exist.
</p>
<p><strong>[22.*]</strong> Anything and everything we have on locale
implemenation will be described
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 />
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
<head>
<title>Porting libstdc++-v3</title>
<meta http-equiv="Content-Type" content="text/html">
-<meta name=description content="Porting libstdc++-v3">
-<meta name=generator content="makeinfo 4.2">
-<link href="http://www.gnu.org/software/texinfo/" rel=generator-home>
+<meta name="description" content="Porting libstdc++-v3">
+<meta name="generator" content="makeinfo 4.3">
+<link href="http://www.gnu.org/software/texinfo/" rel="generator-home">
+<!--
+Copyright © 2000, 2001, 2002 Free Software Foundation, Inc.
+
+ <p>Permission is granted to copy, distribute and/or modify this document
+under the terms of the GNU Free Documentation License, Version 1.1 or
+any later version published by the Free Software Foundation; with the
+Invariant Sections being "GNU General Public License", the Front-Cover
+texts being (a) (see below), and with the Back-Cover Texts being (b)
+(see below). A copy of the license is included in the section entitled
+"GNU Free Documentation License".
+
+ <p>(a) The FSF's Front-Cover Text is:
+
+ <p>A GNU Manual
+
+ <p>(b) The FSF's Back-Cover Text is:
+
+ <p>You have freedom to copy and modify this GNU Manual, like GNU
+ software. Copies published by the Free Software Foundation raise
+ funds for GNU development.-->
</head>
<body>
-<h1>Porting libstdc++-v3</h1>
+<h1 class="settitle">Porting libstdc++-v3</h1>
+<div class="node">
<p><hr>
Node:<a name="Top">Top</a>,
-Next:<a rel=next accesskey=n href="#Operating%20system">Operating system</a>,
-Up:<a rel=up accesskey=u href="#dir">(dir)</a>
+Next:<a rel="next" accesskey="n" href="#Operating%20system">Operating system</a>,
+Up:<a rel="up" accesskey="u" href="#dir">(dir)</a>
<br>
+</div>
-<h2>Porting libstdc++-v3</h2>
+<h2 class="unnumbered">Porting libstdc++-v3</h2>
-<p>This document explains how to port libstdc++-v3 (the GNU C++ library) to
+
<p>This document explains how to port libstdc++-v3 (the GNU C++ library) to
a new target.
-<p>In order to make the GNU C++ library (libstdc++-v3) work with a new
+
<p>In order to make the GNU C++ library (libstdc++-v3) work with a new
target, you must edit some configuration files and provide some new
header files. Unless this is done, libstdc++-v3 will use generic
settings which may not be correct for your target; even if they are
correct, they will likely be inefficient.
-<p>Before you get started, make sure that you have a working C library on
+
<p>Before you get started, make sure that you have a working C library on
your target. The C library need not precisely comply with any
particular standard, but should generally conform to the requirements
imposed by the ANSI/ISO standard.
-<p>In addition, you should try to verify that the C++ compiler generally
+
<p>In addition, you should try to verify that the C++ compiler generally
works. It is difficult to test the C++ compiler without a working
library, but you should at least try some minimal test cases.
-<p>Here are the primary steps required to port the library:
+
<p>Here are the primary steps required to port the library:
-<ul>
-<li><a accesskey=1 href="#Operating%20system">Operating system</a>: Configuring for your operating system.
-<li><a accesskey=2 href="#CPU">CPU</a>: Configuring for your processor chip.
-<li><a accesskey=3 href="#Character%20types">Character types</a>: Implementing character classification.
-<li><a accesskey=4 href="#Thread%20safety">Thread safety</a>: Implementing atomic operations.
-<li><a accesskey=5 href="#Numeric%20limits">Numeric limits</a>: Implementing numeric limits.
-<li><a accesskey=6 href="#Libtool">Libtool</a>: Using libtool.
-<li><a accesskey=7 href="#GNU%20Free%20Documentation%20License">GNU Free Documentation License</a>: How you can copy and share this manual.
+<ul class="menu">
+<li><a accesskey="1" href="#Operating%20system">Operating system</a>: Configuring for your operating system.
+<li><a accesskey="2" href="#CPU">CPU</a>: Configuring for your processor chip.
+<li><a accesskey="3" href="#Character%20types">Character types</a>: Implementing character classification.
+<li><a accesskey="4" href="#Thread%20safety">Thread safety</a>: Implementing atomic operations.
+<li><a accesskey="5" href="#Numeric%20limits">Numeric limits</a>: Implementing numeric limits.
+<li><a accesskey="6" href="#Libtool">Libtool</a>: Using libtool.
+<li><a accesskey="7" href="#GNU%20Free%20Documentation%20License">GNU Free Documentation License</a>: How you can copy and share this manual.
</ul>
+<div class="node">
<p><hr>
Node:<a name="Operating%20system">Operating system</a>,
-Next:<a rel=next accesskey=n href="#CPU">CPU</a>,
-Previous:<a rel=previous accesskey=p href="#Top">Top</a>,
-Up:<a rel=up accesskey=u href="#Top">Top</a>
+Next:<a rel="next" accesskey="n" href="#CPU">CPU</a>,
+Previous:<a rel="previous" accesskey="p" href="#Top">Top</a>,
+Up:<a rel="up" accesskey="u" href="#Top">Top</a>
<br>
+</div>
-<h2>Operating system</h2>
+<h2 class="chapter">Operating system</h2>
-<p>If you are porting to a new operating system (as opposed to a new chip
+
<p>If you are porting to a new operating system (as opposed to a new chip
using an existing operating system), you will need to create a new
directory in the <code>config/os</code> hierarchy. For example, the IRIX
configuration files are all in <code>config/os/irix</code>. There is no set
directory under <code>config/os</code> to store the files for your operating
system.
-<p>You'll have to change the <code>configure.target</code> file to ensure that
-your new directory is activated. Look for the switch statement that
-sets <code>os_include_dir</code>, and add a pattern to handle your operating
-system. The switch statement switches on only the OS portion of the
-standard target triplet; e.g., the <code>solaris2.8</code> in
-<code>sparc-sun-solaris2.8</code>.
+ <p>You might have to change the <code>configure.target</code> file to ensure that
+your new directory is activated. Look for the switch statement that sets
+<code>os_include_dir</code>, and add a pattern to handle your operating system
+if the default will not suffice. The switch statement switches on only
+the OS portion of the standard target triplet; e.g., the <code>solaris2.8</code>
+in <code>sparc-sun-solaris2.8</code>. If the new directory is named after the
+OS portion of the triplet (the default), then nothing needs to be changed.
-<p>The first file to create in this directory, should be called
+
<p>The first file to create in this directory, should be called
<code>os_defines.h</code>. This file contains basic macro definitions
that are required to allow the C++ library to work with your C library.
This file should provide macro definitions for <code>__off_t</code>,
<code>__off64_t</code>, and <code>__ssize_t</code>. Typically, this just looks
like:
-<br><pre>#define __off_t off_t
-#define __off64_t off64_t
-#define __ssize_t ssize_t
-</pre>
+<pre class="example"> #define __off_t off_t
+ #define __off64_t off64_t
+ #define __ssize_t ssize_t
+ </pre>
<p>You don't have to provide these definitions if your system library
already defines these types - but the only library known to provide
header file that defines <code>off_t</code>, or the other types; you simply
have to provide the macros.
-<p>In addition, several libstdc++-v3 source files unconditionally define
+
<p>In addition, several libstdc++-v3 source files unconditionally define
the macro <code>_POSIX_SOURCE</code>. On many systems, defining this macro
causes large portions of the C library header files to be eliminated
at preprocessing time. Therefore, you may have to <code>#undef</code> this
target. It will not work to simply define these macros in
<code>os_defines.h</code>.
-<p>At this time, there is one libstdc++-v3-specific macro which may be
+
<p>At this time, there is one libstdc++-v3-specific macro which may be
defined. <code>_G_USING_THUNKS</code> may be defined to 0 to express that the
port doesn't use thunks (although it is unclear that this is still
useful since libio support isn't currently working and the g++ v3 ABI
invalidates the assumption that some ports don't use thunks).
-<p>Finally, you should bracket the entire file in an include-guard, like
+
<p>Finally, you should bracket the entire file in an include-guard, like
this:
-<br><pre>#ifndef _GLIBCPP_OS_DEFINES
-#define _GLIBCPP_OS_DEFINES
-...
-#endif
-</pre>
+<pre class="example"> #ifndef _GLIBCPP_OS_DEFINES
+ #define _GLIBCPP_OS_DEFINES
+ ...
+ #endif
+ </pre>
-<p>We recommend copying an existing <code>os_defines.h</code> to use as a
+
<p>We recommend copying an existing <code>os_defines.h</code> to use as a
starting point.
+<div class="node">
<p><hr>
Node:<a name="CPU">CPU</a>,
-Next:<a rel=next accesskey=n href="#Character%20types">Character types</a>,
-Previous:<a rel=previous accesskey=p href="#Operating%20system">Operating system</a>,
-Up:<a rel=up accesskey=u href="#Top">Top</a>
+Next:<a rel="next" accesskey="n" href="#Character%20types">Character types</a>,
+Previous:<a rel="previous" accesskey="p" href="#Operating%20system">Operating system</a>,
+Up:<a rel="up" accesskey="u" href="#Top">Top</a>
<br>
+</div>
-<h2>CPU</h2>
+<h2 class="chapter">CPU</h2>
-<p>If you are porting to a new chip (as opposed to a new operating system
+
<p>If you are porting to a new chip (as opposed to a new operating system
running on an existing chip), you will need to create a new directory in the
<code>config/cpu</code> hierarchy. Much like the <a href="#Operating%20system">Operating system</a> setup,
there are no strict rules on how to organize the CPU configuration
directory, but careful naming choices will allow the configury to find your
setup files without explicit help.
-<p>We recommend that for a target triplet <code><CPU>-<vendor>-<OS></code>, you
+
<p>We recommend that for a target triplet <code><CPU>-<vendor>-<OS></code>, you
name your configuration directory <code>config/cpu/<CPU></code>. If you do this,
the configury will find the directory itself. Otherwise you will need to
edit the <code>configure.target</code> file and, in the switch statement that sets
<code>cpu_include_dir</code>, add a pattern to handle your chip.
-<p>Note that some chip families share a single configuration directory, for
+
<p>Note that some chip families share a single configuration directory, for
example, <code>alpha</code>, <code>alphaev5</code>, and <code>alphaev6</code> all use the
<code>config/cpu/alpha</code> directory, and there is an entry in the
<code>configure.target</code> switch statement to handle this.
-<p>The <code>cpu_include_dir</code> sets default locations for the files controlling
+
<p>The <code>cpu_include_dir</code> sets default locations for the files controlling
<a href="#Thread%20safety">Thread safety</a> and <a href="#Numeric%20limits">Numeric limits</a>, if the defaults are not
appropriate for your chip.
+<div class="node">
<p><hr>
Node:<a name="Character%20types">Character types</a>,
-Next:<a rel=next accesskey=n href="#Thread%20safety">Thread safety</a>,
-Previous:<a rel=previous accesskey=p href="#CPU">CPU</a>,
-Up:<a rel=up accesskey=u href="#Top">Top</a>
+Next:<a rel="next" accesskey="n" href="#Thread%20safety">Thread safety</a>,
+Previous:<a rel="previous" accesskey="p" href="#CPU">CPU</a>,
+Up:<a rel="up" accesskey="u" href="#Top">Top</a>
<br>
+</div>
-<h2>Character types</h2>
+<h2 class="chapter">Character types</h2>
-<p>The library requires that you provide three header files to implement
+
<p>The library requires that you provide three header files to implement
character classification, analogous to that provided by the C libraries
<code><ctype.h></code> header. You can model these on the files provided in
<code>config/os/generic</code>. However, these files will almost
certainly need some modification.
-<p>The first file to write is <code>ctype_base.h</code>. This file provides
+
<p>The first file to write is <code>ctype_base.h</code>. This file provides
some very basic information about character classification. The libstdc++-v3
library assumes that your C library implements <code><ctype.h></code> by using
a table (indexed by character code) containing integers, where each of
masks. You will have to peer at your own <code><ctype.h></code> to figure out
how to define the values required by this file.
-<p>The <code>ctype_base.h</code> header file does not need include guards.
+
<p>The <code>ctype_base.h</code> header file does not need include guards.
It should contain a single <code>struct</code> definition called
<code>ctype_base</code>. This <code>struct</code> should contain two type
declarations, and one enumeration declaration, like this example, taken
from the IRIX configuration:
-<br><pre>struct ctype_base
-{
- typedef unsigned int mask;
- typedef int* __to_type;
-
- enum
- {
- space = _ISspace,
- print = _ISprint,
- cntrl = _IScntrl,
- upper = _ISupper,
- lower = _ISlower,
- alpha = _ISalpha,
- digit = _ISdigit,
- punct = _ISpunct,
- xdigit = _ISxdigit,
- alnum = _ISalnum,
- graph = _ISgraph
- };
-};
-</pre>
+<pre class="example"> struct ctype_base
+ {
+ typedef unsigned int mask;
+ typedef int* __to_type;
+
+ enum
+ {
+ space = _ISspace,
+ print = _ISprint,
+ cntrl = _IScntrl,
+ upper = _ISupper,
+ lower = _ISlower,
+ alpha = _ISalpha,
+ digit = _ISdigit,
+ punct = _ISpunct,
+ xdigit = _ISxdigit,
+ alnum = _ISalnum,
+ graph = _ISgraph
+ };
+ };
+ </pre>
<p>The <code>mask</code> type is the type of the elements in the table. If your
C library uses a table to map lower-case numbers to upper-case numbers,
<code>tolower</code> in this way, you can pick any pointer-to-integer type,
but you must still define the type.
-<p>The enumeration should give definitions for all the values in the above
+
<p>The enumeration should give definitions for all the values in the above
example, using the values from your native <code><ctype.h></code>. They can
be given symbolically (as above), or numerically, if you prefer. You do
not have to include <code><ctype.h></code> in this header; it will always be
included before <code>ctype_base.h</code> is included.
-<p>The next file to write is <code>ctype_noninline.h</code>, which also does
+
<p>The next file to write is <code>ctype_noninline.h</code>, which also does
not require include guards. This file defines a few member functions
that will be included in <code>include/bits/locale_facets.h</code>. The first
function that must be written is the <code>ctype<char>::ctype</code>
constructor. Here is the IRIX example:
-<br><pre>ctype<char>::ctype(const mask* __table = 0, bool __del = false,
- size_t __refs = 0)
- : _Ctype_nois<char>(__refs), _M_del(__table != 0 && __del),
- _M_toupper(NULL),
- _M_tolower(NULL),
- _M_ctable(NULL),
- _M_table(!__table
- ? (const mask*) (__libc_attr._ctype_tbl->_class + 1)
- : __table)
- { }
-</pre>
+<pre class="example"> ctype<char>::ctype(const mask* __table = 0, bool __del = false,
+ size_t __refs = 0)
+ : _Ctype_nois<char>(__refs), _M_del(__table != 0 && __del),
+ _M_toupper(NULL),
+ _M_tolower(NULL),
+ _M_ctable(NULL),
+ _M_table(!__table
+ ? (const mask*) (__libc_attr._ctype_tbl->_class + 1)
+ : __table)
+ { }
+ </pre>
<p>There are two parts of this that you might choose to alter. The first,
and most important, is the line involving <code>__libc_attr</code>. That is
vice versa, you should initialize <code>_M_toupper</code> and
<code>_M_tolower</code> with those tables, in similar fashion.
-<p>Now, you have to write two functions to convert from upper-case to
+
<p>Now, you have to write two functions to convert from upper-case to
lower-case, and vice versa. Here are the IRIX versions:
-<br><pre>char
-ctype<char>::do_toupper(char __c) const
-{ return _toupper(__c); }
-
-char
-ctype<char>::do_tolower(char __c) const
-{ return _tolower(__c); }
-</pre>
+<pre class="example"> char
+ ctype<char>::do_toupper(char __c) const
+ { return _toupper(__c); }
+
+ char
+ ctype<char>::do_tolower(char __c) const
+ { return _tolower(__c); }
+ </pre>
<p>Your C library provides equivalents to IRIX's <code>_toupper</code> and
<code>_tolower</code>. If you initialized <code>_M_toupper</code> and
<code>_M_tolower</code> above, then you could use those tables instead.
-<p>Finally, you have to provide two utility functions that convert strings
+
<p>Finally, you have to provide two utility functions that convert strings
of characters. The versions provided here will always work - but you
could use specialized routines for greater performance if you have
machinery to do that on your system:
-<br><pre>const char*
-ctype<char>::do_toupper(char* __low, const char* __high) const
-{
- while (__low < __high)
- {
- *__low = do_toupper(*__low);
- ++__low;
- }
- return __high;
-}
-
-const char*
-ctype<char>::do_tolower(char* __low, const char* __high) const
-{
- while (__low < __high)
- {
- *__low = do_tolower(*__low);
- ++__low;
- }
- return __high;
-}
-</pre>
-
-<p>You must also provide the <code>ctype_inline.h</code> file, which
+<pre class="example"> const char*
+ ctype<char>::do_toupper(char* __low, const char* __high) const
+ {
+ while (__low < __high)
+ {
+ *__low = do_toupper(*__low);
+ ++__low;
+ }
+ return __high;
+ }
+
+ const char*
+ ctype<char>::do_tolower(char* __low, const char* __high) const
+ {
+ while (__low < __high)
+ {
+ *__low = do_tolower(*__low);
+ ++__low;
+ }
+ return __high;
+ }
+ </pre>
+
+
<p>You must also provide the <code>ctype_inline.h</code> file, which
contains a few more functions. On most systems, you can just copy
<code>config/os/generic/ctype_inline.h</code> and use it on your system.
-<p>In detail, the functions provided test characters for particular
+
<p>In detail, the functions provided test characters for particular
properties; they are analogous to the functions like <code>isalpha</code> and
<code>islower</code> provided by the C library.
-<p>The first function is implemented like this on IRIX:
+
<p>The first function is implemented like this on IRIX:
-<br><pre>bool
-ctype<char>::
-is(mask __m, char __c) const throw()
-{ return (_M_table)[(unsigned char)(__c)] & __m; }
-</pre>
+<pre class="example"> bool
+ ctype<char>::
+ is(mask __m, char __c) const throw()
+ { return (_M_table)[(unsigned char)(__c)] & __m; }
+ </pre>
<p>The <code>_M_table</code> is the table passed in above, in the constructor.
This is the table that contains the bitmasks for each character. The
implementation here should work on all systems.
-<p>The next function is:
+
<p>The next function is:
-<br><pre>const char*
-ctype<char>::
-is(const char* __low, const char* __high, mask* __vec) const throw()
-{
- while (__low < __high)
- *__vec++ = (_M_table)[(unsigned char)(*__low++)];
- return __high;
-}
-</pre>
+<pre class="example"> const char*
+ ctype<char>::
+ is(const char* __low, const char* __high, mask* __vec) const throw()
+ {
+ while (__low < __high)
+ *__vec++ = (_M_table)[(unsigned char)(*__low++)];
+ return __high;
+ }
+ </pre>
<p>This function is similar; it copies the masks for all the characters
from <code>__low</code> up until <code>__high</code> into the vector given by
<code>__vec</code>.
-<p>The last two functions again are entirely generic:
-
-<br><pre>const char*
-ctype<char>::
-scan_is(mask __m, const char* __low, const char* __high) const throw()
-{
- while (__low < __high && !this->is(__m, *__low))
- ++__low;
- return __low;
-}
-
-const char*
-ctype<char>::
-scan_not(mask __m, const char* __low, const char* __high) const throw()
-{
- while (__low < __high && this->is(__m, *__low))
- ++__low;
- return __low;
-}
-</pre>
-
+ <p>The last two functions again are entirely generic:
+
+<pre class="example"> const char*
+ ctype<char>::
+ scan_is(mask __m, const char* __low, const char* __high) const throw()
+ {
+ while (__low < __high && !this->is(__m, *__low))
+ ++__low;
+ return __low;
+ }
+
+ const char*
+ ctype<char>::
+ scan_not(mask __m, const char* __low, const char* __high) const throw()
+ {
+ while (__low < __high && this->is(__m, *__low))
+ ++__low;
+ return __low;
+ }
+ </pre>
+
+<div class="node">
<p><hr>
Node:<a name="Thread%20safety">Thread safety</a>,
-Next:<a rel=next accesskey=n href="#Numeric%20limits">Numeric limits</a>,
-Previous:<a rel=previous accesskey=p href="#Character%20types">Character types</a>,
-Up:<a rel=up accesskey=u href="#Top">Top</a>
+Next:<a rel="next" accesskey="n" href="#Numeric%20limits">Numeric limits</a>,
+Previous:<a rel="previous" accesskey="p" href="#Character%20types">Character types</a>,
+Up:<a rel="up" accesskey="u" href="#Top">Top</a>
<br>
+</div>
-<h2>Thread safety</h2>
+<h2 class="chapter">Thread safety</h2>
-<p>The C++ library string functionality requires a couple of atomic
+
<p>The C++ library string functionality requires a couple of atomic
operations to provide thread-safety. If you don't take any special
action, the library will use stub versions of these functions that are
not thread-safe. They will work fine, unless your applications are
multi-threaded.
-<p>If you want to provide custom, safe, versions of these functions, there
+
<p>If you want to provide custom, safe, versions of these functions, there
are two distinct approaches. One is to provide a version for your CPU,
using assembly language constructs. The other is to use the
thread-safety primitives in your operating system. In either case, you
make a file called <code>atomicity.h</code>, and the variable
<code>ATOMICITYH</code> must point to this file.
-<p>If you are using the assembly-language approach, put this code in
+
<p>If you are using the assembly-language approach, put this code in
<code>config/cpu/<chip>/atomicity.h</code>, where chip is the name of
your processor (see <a href="#CPU">CPU</a>). No additional changes are necessary to
locate the file in this case; <code>ATOMICITYH</code> will be set by default.
-<p>If you are using the operating system thread-safety primitives approach,
+
<p>If you are using the operating system thread-safety primitives approach,
you can also put this code in the same CPU directory, in which case no more
work is needed to locate the file. For examples of this approach,
see the <code>atomicity.h</code> file for IRIX or IA64.
-<p>Alternatively, if the primitives are more closely related to the OS
+
<p>Alternatively, if the primitives are more closely related to the OS
than they are to the CPU, you can put the <code>atomicity.h</code> file in
the <a href="#Operating%20system">Operating system</a> directory instead. In this case, you must
edit <code>configure.target</code>, and in the switch statement that handles
the appropriate <code>os_include_dir</code>. For examples of this approach,
see the <code>atomicity.h</code> file for AIX.
-<p>With those bits out of the way, you have to actually write
+
<p>With those bits out of the way, you have to actually write
<code>atomicity.h</code> itself. This file should be wrapped in an
include guard named <code>_BITS_ATOMICITY_H</code>. It should define one
type, and two functions.
-<p>The type is <code>_Atomic_word</code>. Here is the version used on IRIX:
+
<p>The type is <code>_Atomic_word</code>. Here is the version used on IRIX:
-<br><pre>typedef long _Atomic_word;
-</pre>
+<pre class="example"> typedef long _Atomic_word;
+ </pre>
<p>This type must be a signed integral type supporting atomic operations.
If you're using the OS approach, use the same type used by your system's
primitives. Otherwise, use the type for which your CPU provides atomic
primitives.
-<p>Then, you must provide two functions. The bodies of these functions
+
<p>Then, you must provide two functions. The bodies of these functions
must be equivalent to those provided here, but using atomic operations:
-<br><pre>static inline _Atomic_word
-__attribute__ ((__unused__))
-__exchange_and_add (_Atomic_word* __mem, int __val)
-{
- _Atomic_word __result = *__mem;
- *__mem += __val;
- return __result;
-}
-
-static inline void
-__attribute__ ((__unused__))
-__atomic_add (_Atomic_word* __mem, int __val)
-{
- *__mem += __val;
-}
-</pre>
-
+<pre class="example"> static inline _Atomic_word
+ __attribute__ ((__unused__))
+ __exchange_and_add (_Atomic_word* __mem, int __val)
+ {
+ _Atomic_word __result = *__mem;
+ *__mem += __val;
+ return __result;
+ }
+
+ static inline void
+ __attribute__ ((__unused__))
+ __atomic_add (_Atomic_word* __mem, int __val)
+ {
+ *__mem += __val;
+ }
+ </pre>
+
+<div class="node">
<p><hr>
Node:<a name="Numeric%20limits">Numeric limits</a>,
-Next:<a rel=next accesskey=n href="#Libtool">Libtool</a>,
-Previous:<a rel=previous accesskey=p href="#Thread%20safety">Thread safety</a>,
-Up:<a rel=up accesskey=u href="#Top">Top</a>
+Next:<a rel="next" accesskey="n" href="#Libtool">Libtool</a>,
+Previous:<a rel="previous" accesskey="p" href="#Thread%20safety">Thread safety</a>,
+Up:<a rel="up" accesskey="u" href="#Top">Top</a>
<br>
+</div>
-<h2>Numeric limits</h2>
+<h2 class="chapter">Numeric limits</h2>
-<p>The C++ library requires information about the fundamental data types,
+
<p>The C++ library requires information about the fundamental data types,
such as the minimum and maximum representable values of each type.
You can define each of these values individually, but it is usually
easiest just to indicate how many bits are used in each of the data
types and let the library do the rest. For information about the
macros to define, see the top of <code>include/bits/std_limits.h</code>.
-<p>If you need to define any macros, you can do so in <code>os_defines.h</code>.
+
<p>If you need to define any macros, you can do so in <code>os_defines.h</code>.
However, if all operating systems for your CPU are likely to use the
same values, you can provide a CPU-specific file instead so that you
do not have to provide the same definitions for each operating system.
To take that approach, create a new file called <code>cpu_limits.h</code> in
your CPU configuration directory (see <a href="#CPU">CPU</a>).
+<div class="node">
<p><hr>
Node:<a name="Libtool">Libtool</a>,
-Next:<a rel=next accesskey=n href="#GNU%20Free%20Documentation%20License">GNU Free Documentation License</a>,
-Previous:<a rel=previous accesskey=p href="#Numeric%20limits">Numeric limits</a>,
-Up:<a rel=up accesskey=u href="#Top">Top</a>
+Next:<a rel="next" accesskey="n" href="#GNU%20Free%20Documentation%20License">GNU Free Documentation License</a>,
+Previous:<a rel="previous" accesskey="p" href="#Numeric%20limits">Numeric limits</a>,
+Up:<a rel="up" accesskey="u" href="#Top">Top</a>
<br>
+</div>
-<h2>Libtool</h2>
+<h2 class="chapter">Libtool</h2>
-<p>The C++ library is compiled, archived and linked with libtool.
+
<p>The C++ library is compiled, archived and linked with libtool.
Explaining the full workings of libtool is beyond the scope of this
document, but there are a few, particular bits that are necessary for
porting.
-<p>Some parts of the libstdc++-v3 library are compiled with the libtool
+
<p>Some parts of the libstdc++-v3 library are compiled with the libtool
<code>--tags CXX</code> option (the C++ definitions for libtool). Therefore,
<code>ltcf-cxx.sh</code> in the top-level directory needs to have the correct
logic to compile and archive objects equivalent to the C version of libtool,
<code>ltcf-c.sh</code>. Some libtool targets have definitions for C but not
for C++, or C++ definitions which have not been kept up to date.
-<p>The C++ run-time library contains initialization code that needs to be
+
<p>The C++ run-time library contains initialization code that needs to be
run as the library is loaded. Often, that requires linking in special
object files when the C++ library is built as a shared library, or
taking other system-specific actions.
-<p>The libstdc++-v3 library is linked with the C version of libtool, even
+
<p>The libstdc++-v3 library is linked with the C version of libtool, even
though it is a C++ library. Therefore, the C version of libtool needs to
ensure that the run-time library initializers are run. The usual way to
do this is to build the library using <code>gcc -shared</code>.
-<p>If you need to change how the library is linked, look at
+
<p>If you need to change how the library is linked, look at
<code>ltcf-c.sh</code> in the top-level directory. Find the switch statement
that sets <code>archive_cmds</code>. Here, adjust the setting for your
operating system.
+<div class="node">
<p><hr>
Node:<a name="GNU%20Free%20Documentation%20License">GNU Free Documentation License</a>,
-Previous:<a rel=previous accesskey=p href="#Libtool">Libtool</a>,
-Up:<a rel=up accesskey=u href="#Top">Top</a>
+Previous:<a rel="previous" accesskey="p" href="#Libtool">Libtool</a>,
+Up:<a rel="up" accesskey="u" href="#Top">Top</a>
<br>
+</div>
-<h2>GNU Free Documentation License</h2>
+<h2 class="unnumbered">GNU Free Documentation License</h2>
<div align="center">Version 1.1, March 2000</div>
-<br><pre>Copyright © 2000 Free Software Foundation, Inc.
-59 Temple Place, Suite 330, Boston, MA 02111-1307, USA
+<pre class="display"> Copyright © 2000 Free Software Foundation, Inc.
+ 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA
+
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+ </pre>
-Everyone is permitted to copy and distribute verbatim copies
-of this license document, but changing it is not allowed.
-</pre>
+ <ol type=1 start=0>
+<li>PREAMBLE
-<ol type=1 start=0>
-</p><li>PREAMBLE
-
-<p>The purpose of this License is to make a manual, textbook, or other
+ <p>The purpose of this License is to make a manual, textbook, or other
written document <dfn>free</dfn> in the sense of freedom: to assure everyone
the effective freedom to copy and redistribute it, with or without
modifying it, either commercially or noncommercially. Secondarily,
credit for their work, while not being considered responsible for
modifications made by others.
-<p>This License is a kind of "copyleft", which means that derivative
+
<p>This License is a kind of "copyleft", which means that derivative
works of the document must themselves be free in the same sense. It
complements the GNU General Public License, which is a copyleft
license designed for free software.
-<p>We have designed this License in order to use it for manuals for free
+
<p>We have designed this License in order to use it for manuals for free
software, because free software needs free documentation: a free
program should come with manuals providing the same freedoms that the
software does. But this License is not limited to software manuals;
whether it is published as a printed book. We recommend this License
principally for works whose purpose is instruction or reference.
-</p><li>APPLICABILITY AND DEFINITIONS
+ </p><li>APPLICABILITY AND DEFINITIONS
-<p>This License applies to any manual or other work that contains a
+
<p>This License applies to any manual or other work that contains a
notice placed by the copyright holder saying it can be distributed
under the terms of this License. The "Document", below, refers to any
such manual or work. Any member of the public is a licensee, and is
addressed as "you".
-<p>A "Modified Version" of the Document means any work containing the
+
<p>A "Modified Version" of the Document means any work containing the
Document or a portion of it, either copied verbatim, or with
modifications and/or translated into another language.
-<p>A "Secondary Section" is a named appendix or a front-matter section of
+
<p>A "Secondary Section" is a named appendix or a front-matter section of
the Document that deals exclusively with the relationship of the
publishers or authors of the Document to the Document's overall subject
(or to related matters) and contains nothing that could fall directly
commercial, philosophical, ethical or political position regarding
them.
-<p>The "Invariant Sections" are certain Secondary Sections whose titles
+
<p>The "Invariant Sections" are certain Secondary Sections whose titles
are designated, as being those of Invariant Sections, in the notice
that says that the Document is released under this License.
-<p>The "Cover Texts" are certain short passages of text that are listed,
+
<p>The "Cover Texts" are certain short passages of text that are listed,
as Front-Cover Texts or Back-Cover Texts, in the notice that says that
the Document is released under this License.
-<p>A "Transparent" copy of the Document means a machine-readable copy,
+
<p>A "Transparent" copy of the Document means a machine-readable copy,
represented in a format whose specification is available to the
general public, whose contents can be viewed and edited directly and
straightforwardly with generic text editors or (for images composed of
subsequent modification by readers is not Transparent. A copy that is
not "Transparent" is called "Opaque".
-<p>Examples of suitable formats for Transparent copies include plain
+
<p>Examples of suitable formats for Transparent copies include plain
<small>ASCII</small> without markup, Texinfo input format, LaTeX input format,
<small>SGML</small> or <small>XML</small> using a publicly available
<small>DTD</small>, and standard-conforming simple <small>HTML</small> designed
and the machine-generated <small>HTML</small> produced by some word
processors for output purposes only.
-<p>The "Title Page" means, for a printed book, the title page itself,
+
<p>The "Title Page" means, for a printed book, the title page itself,
plus such following pages as are needed to hold, legibly, the material
this License requires to appear in the title page. For works in
formats which do not have any title page as such, "Title Page" means
the text near the most prominent appearance of the work's title,
preceding the beginning of the body of the text.
-</p><li>VERBATIM COPYING
+ </p><li>VERBATIM COPYING
-<p>You may copy and distribute the Document in any medium, either
+
<p>You may copy and distribute the Document in any medium, either
commercially or noncommercially, provided that this License, the
copyright notices, and the license notice saying this License applies
to the Document are reproduced in all copies, and that you add no other
compensation in exchange for copies. If you distribute a large enough
number of copies you must also follow the conditions in section 3.
-<p>You may also lend copies, under the same conditions stated above, and
+
<p>You may also lend copies, under the same conditions stated above, and
you may publicly display copies.
-</p><li>COPYING IN QUANTITY
+ </p><li>COPYING IN QUANTITY
-<p>If you publish printed copies of the Document numbering more than 100,
+
<p>If you publish printed copies of the Document numbering more than 100,
and the Document's license notice requires Cover Texts, you must enclose
the copies in covers that carry, clearly and legibly, all these Cover
Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on
the title of the Document and satisfy these conditions, can be treated
as verbatim copying in other respects.
-<p>If the required texts for either cover are too voluminous to fit
+
<p>If the required texts for either cover are too voluminous to fit
legibly, you should put the first ones listed (as many as fit
reasonably) on the actual cover, and continue the rest onto adjacent
pages.
-<p>If you publish or distribute Opaque copies of the Document numbering
+
<p>If you publish or distribute Opaque copies of the Document numbering
more than 100, you must either include a machine-readable Transparent
copy along with each Opaque copy, or state in or with each Opaque copy
a publicly-accessible computer-network location containing a complete
copy (directly or through your agents or retailers) of that edition to
the public.
-<p>It is requested, but not required, that you contact the authors of the
+
<p>It is requested, but not required, that you contact the authors of the
Document well before redistributing any large number of copies, to give
them a chance to provide you with an updated version of the Document.
-</p><li>MODIFICATIONS
+ </p><li>MODIFICATIONS
-<p>You may copy and distribute a Modified Version of the Document under
+
<p>You may copy and distribute a Modified Version of the Document under
the conditions of sections 2 and 3 above, provided that you release
the Modified Version under precisely this License, with the Modified
Version filling the role of the Document, thus licensing distribution
and modification of the Modified Version to whoever possesses a copy
of it. In addition, you must do these things in the Modified Version:
-<ol type=A start=1>
-</p><li>Use in the Title Page (and on the covers, if any) a title distinct
+<li>Use in the Title Page (and on the covers, if any) a title distinct
from that of the Document, and from those of previous versions
(which should, if there were any, be listed in the History section
of the Document). You may use the same title as a previous version
if the original publisher of that version gives permission.
-<li>List on the Title Page, as authors, one or more persons or entities
+ <li>List on the Title Page, as authors, one or more persons or entities
responsible for authorship of the modifications in the Modified
Version, together with at least five of the principal authors of the
Document (all of its principal authors, if it has less than five).
-<li>State on the Title page the name of the publisher of the
+ <li>State on the Title page the name of the publisher of the
Modified Version, as the publisher.
-<li>Preserve all the copyright notices of the Document.
+ <li>Preserve all the copyright notices of the Document.
-<li>Add an appropriate copyright notice for your modifications
+ <li>Add an appropriate copyright notice for your modifications
adjacent to the other copyright notices.
-<li>Include, immediately after the copyright notices, a license notice
+ <li>Include, immediately after the copyright notices, a license notice
giving the public permission to use the Modified Version under the
terms of this License, in the form shown in the Addendum below.
-<li>Preserve in that license notice the full lists of Invariant Sections
+ <li>Preserve in that license notice the full lists of Invariant Sections
and required Cover Texts given in the Document's license notice.
-<li>Include an unaltered copy of this License.
+ <li>Include an unaltered copy of this License.
-<li>Preserve the section entitled "History", and its title, and add to
+ <li>Preserve the section entitled "History", and its title, and add to
it an item stating at least the title, year, new authors, and
publisher of the Modified Version as given on the Title Page. If
there is no section entitled "History" in the Document, create one
given on its Title Page, then add an item describing the Modified
Version as stated in the previous sentence.
-<li>Preserve the network location, if any, given in the Document for
+ <li>Preserve the network location, if any, given in the Document for
public access to a Transparent copy of the Document, and likewise
the network locations given in the Document for previous versions
it was based on. These may be placed in the "History" section.
least four years before the Document itself, or if the original
publisher of the version it refers to gives permission.
-<li>In any section entitled "Acknowledgments" or "Dedications",
+ <li>In any section entitled "Acknowledgments" or "Dedications",
preserve the section's title, and preserve in the section all the
substance and tone of each of the contributor acknowledgments
and/or dedications given therein.
-<li>Preserve all the Invariant Sections of the Document,
+ <li>Preserve all the Invariant Sections of the Document,
unaltered in their text and in their titles. Section numbers
or the equivalent are not considered part of the section titles.
-<li>Delete any section entitled "Endorsements". Such a section
+ <li>Delete any section entitled "Endorsements". Such a section
may not be included in the Modified Version.
-<li>Do not retitle any existing section as "Endorsements"
+ <li>Do not retitle any existing section as "Endorsements"
or to conflict in title with any Invariant Section.
-</ol>
+ </ol>
-<p>If the Modified Version includes new front-matter sections or
+
<p>If the Modified Version includes new front-matter sections or
appendices that qualify as Secondary Sections and contain no material
copied from the Document, you may at your option designate some or all
of these sections as invariant. To do this, add their titles to the
list of Invariant Sections in the Modified Version's license notice.
These titles must be distinct from any other section titles.
-<p>You may add a section entitled "Endorsements", provided it contains
+
<p>You may add a section entitled "Endorsements", provided it contains
nothing but endorsements of your Modified Version by various
parties--for example, statements of peer review or that the text has
been approved by an organization as the authoritative definition of a
standard.
-<p>You may add a passage of up to five words as a Front-Cover Text, and a
+
<p>You may add a passage of up to five words as a Front-Cover Text, and a
passage of up to 25 words as a Back-Cover Text, to the end of the list
of Cover Texts in the Modified Version. Only one passage of
Front-Cover Text and one of Back-Cover Text may be added by (or
you may not add another; but you may replace the old one, on explicit
permission from the previous publisher that added the old one.
-<p>The author(s) and publisher(s) of the Document do not by this License
+
<p>The author(s) and publisher(s) of the Document do not by this License
give permission to use their names for publicity for or to assert or
imply endorsement of any Modified Version.
-</p><li>COMBINING DOCUMENTS
+ </p><li>COMBINING DOCUMENTS
-<p>You may combine the Document with other documents released under this
+
<p>You may combine the Document with other documents released under this
License, under the terms defined in section 4 above for modified
versions, provided that you include in the combination all of the
Invariant Sections of all of the original documents, unmodified, and
list them all as Invariant Sections of your combined work in its
license notice.
-<p>The combined work need only contain one copy of this License, and
+
<p>The combined work need only contain one copy of this License, and
multiple identical Invariant Sections may be replaced with a single
copy. If there are multiple Invariant Sections with the same name but
different contents, make the title of each such section unique by
Make the same adjustment to the section titles in the list of
Invariant Sections in the license notice of the combined work.
-<p>In the combination, you must combine any sections entitled "History"
+
<p>In the combination, you must combine any sections entitled "History"
in the various original documents, forming one section entitled
"History"; likewise combine any sections entitled "Acknowledgments",
and any sections entitled "Dedications". You must delete all sections
entitled "Endorsements."
-</p><li>COLLECTIONS OF DOCUMENTS
+ </p><li>COLLECTIONS OF DOCUMENTS
-<p>You may make a collection consisting of the Document and other documents
+
<p>You may make a collection consisting of the Document and other documents
released under this License, and replace the individual copies of this
License in the various documents with a single copy that is included in
the collection, provided that you follow the rules of this License for
verbatim copying of each of the documents in all other respects.
-<p>You may extract a single document from such a collection, and distribute
+
<p>You may extract a single document from such a collection, and distribute
it individually under this License, provided you insert a copy of this
License into the extracted document, and follow this License in all
other respects regarding verbatim copying of that document.
-</p><li>AGGREGATION WITH INDEPENDENT WORKS
+ </p><li>AGGREGATION WITH INDEPENDENT WORKS
-<p>A compilation of the Document or its derivatives with other separate
+
<p>A compilation of the Document or its derivatives with other separate
and independent documents or works, in or on a volume of a storage or
distribution medium, does not as a whole count as a Modified Version
of the Document, provided no compilation copyright is claimed for the
with the Document, on account of their being thus compiled, if they
are not themselves derivative works of the Document.
-<p>If the Cover Text requirement of section 3 is applicable to these
+
<p>If the Cover Text requirement of section 3 is applicable to these
copies of the Document, then if the Document is less than one quarter
of the entire aggregate, the Document's Cover Texts may be placed on
covers that surround only the Document within the aggregate.
Otherwise they must appear on covers around the whole aggregate.
-</p><li>TRANSLATION
+ </p><li>TRANSLATION
-<p>Translation is considered a kind of modification, so you may
+
<p>Translation is considered a kind of modification, so you may
distribute translations of the Document under the terms of section 4.
Replacing Invariant Sections with translations requires special
permission from their copyright holders, but you may include
between the translation and the original English version of this
License, the original English version will prevail.
-</p><li>TERMINATION
+ </p><li>TERMINATION
-<p>You may not copy, modify, sublicense, or distribute the Document except
+
<p>You may not copy, modify, sublicense, or distribute the Document except
as expressly provided for under this License. Any other attempt to
copy, modify, sublicense or distribute the Document is void, and will
automatically terminate your rights under this License. However,
License will not have their licenses terminated so long as such
parties remain in full compliance.
-</p><li>FUTURE REVISIONS OF THIS LICENSE
+ </p><li>FUTURE REVISIONS OF THIS LICENSE
-<p>The Free Software Foundation may publish new, revised versions
+
<p>The Free Software Foundation may publish new, revised versions
of the GNU Free Documentation License from time to time. Such new
versions will be similar in spirit to the present version, but may
differ in detail to address new problems or concerns. See
<a href="http://www.gnu.org/copyleft/">http://www.gnu.org/copyleft/</a>.
-<p>Each version of the License is given a distinguishing version number.
+
<p>Each version of the License is given a distinguishing version number.
If the Document specifies that a particular numbered version of this
License "or any later version" applies to it, you have the option of
following the terms and conditions either of that specified version or
Free Software Foundation. If the Document does not specify a version
number of this License, you may choose any version ever published (not
as a draft) by the Free Software Foundation.
-</ol>
+ </ol>
-<h3>ADDENDUM: How to use this License for your documents</h3>
+<h3 class="unnumberedsec">ADDENDUM: How to use this License for your documents</h3>
-<p>To use this License in a document you have written, include a copy of
+
<p>To use this License in a document you have written, include a copy of
the License in the document and put the following copyright and
license notices just after the title page:
-<br><pre> Copyright (C) <var>year</var> <var>your name</var>.
- Permission is granted to copy, distribute and/or modify this document
- under the terms of the GNU Free Documentation License, Version 1.1
- or any later version published by the Free Software Foundation;
- with the Invariant Sections being <var>list their titles</var>, with the
- Front-Cover Texts being <var>list</var>, and with the Back-Cover Texts being <var>list</var>.
- A copy of the license is included in the section entitled ``GNU
- Free Documentation License''.
-</pre>
-
-<p>If you have no Invariant Sections, write "with no Invariant Sections"
+<pre class="smallexample"> Copyright (C) <var>year</var> <var>your name</var>.
+ Permission is granted to copy, distribute and/or modify this document
+ under the terms of the GNU Free Documentation License, Version 1.1
+ or any later version published by the Free Software Foundation;
+ with the Invariant Sections being <var>list their titles</var>, with the
+ Front-Cover Texts being <var>list</var>, and with the Back-Cover Texts being <var>list</var>.
+ A copy of the license is included in the section entitled ``GNU
+ Free Documentation License''.
+ </pre>
+
+
<p>If you have no Invariant Sections, write "with no Invariant Sections"
instead of saying which ones are invariant. If you have no
Front-Cover Texts, write "no Front-Cover Texts" instead of
"Front-Cover Texts being <var>list</var>"; likewise for Back-Cover Texts.
-<p>If your document contains nontrivial examples of program code, we
+
<p>If your document contains nontrivial examples of program code, we
recommend releasing these examples in parallel under your choice of
free software license, such as the GNU General Public License,
to permit their use in free software.
+<div class="contents">
<h2>Table of Contents</h2>
<ul>
-<li><a name="toc_Top"></a>
- <a href="#Top">Porting libstdc++-v3</a>
-<li><a name="toc_Operating%20system"></a>
- <a href="#Operating%20system">Operating system</a>
-<li><a name="toc_CPU"></a>
- <a href="#CPU">CPU</a>
-<li><a name="toc_Character%20types"></a>
- <a href="#Character%20types">Character types</a>
-<li><a name="toc_Thread%20safety"></a>
- <a href="#Thread%20safety">Thread safety</a>
-<li><a name="toc_Numeric%20limits"></a>
- <a href="#Numeric%20limits">Numeric limits</a>
-<li><a name="toc_Libtool"></a>
- <a href="#Libtool">Libtool</a>
-<li><a name="toc_GNU%20Free%20Documentation%20License"></a>
- <a href="#GNU%20Free%20Documentation%20License">GNU Free Documentation License</a>
+<li><a name="toc_Top" href="#Top">Porting libstdc++-v3</a>
+<li><a name="toc_Operating%20system" href="#Operating%20system">Operating system</a>
+<li><a name="toc_CPU" href="#CPU">CPU</a>
+<li><a name="toc_Character%20types" href="#Character%20types">Character types</a>
+<li><a name="toc_Thread%20safety" href="#Thread%20safety">Thread safety</a>
+<li><a name="toc_Numeric%20limits" href="#Numeric%20limits">Numeric limits</a>
+<li><a name="toc_Libtool" href="#Libtool">Libtool</a>
+<li><a name="toc_GNU%20Free%20Documentation%20License" href="#GNU%20Free%20Documentation%20License">GNU Free Documentation License</a>
<ul>
<li><a href="#GNU%20Free%20Documentation%20License">ADDENDUM: How to use this License for your documents</a>
-</ul>
-</ul>
+</li></ul>
+</li></ul>
+</div>
-</body></html>
+ </body></html>
@settitle Porting libstdc++-v3
@setchapternewpage odd
-@ifinfo
-This file explains how to port libstdc++-v3 (the GNU C++ library) to
-a new target.
-
-Copyright (c) 2000, 2001, 2002 Free Software Foundation, Inc.
-@end ifinfo
-
-@c ---------------------------------------------------------------------
-@c Titlepage
-@c ---------------------------------------------------------------------
-
-@titlepage
-@title Porting libstdc++-v3
-@author Mark Mitchell
-@page
-@vskip 0pt plus 1filll
+@copying
Copyright @copyright{} 2000, 2001, 2002 Free Software Foundation, Inc.
Permission is granted to copy, distribute and/or modify this document
You have freedom to copy and modify this GNU Manual, like GNU
software. Copies published by the Free Software Foundation raise
funds for GNU development.
+@end copying
+
+@ifinfo
+This file explains how to port libstdc++-v3 (the GNU C++ library) to
+a new target.
+
+@insertcopying
+@end ifinfo
+
+@c ---------------------------------------------------------------------
+@c Titlepage
+@c ---------------------------------------------------------------------
+
+@titlepage
+@title Porting libstdc++-v3
+@author Mark Mitchell
+@page
+@vskip 0pt plus 1filll
+@insertcopying
@end titlepage
@c ---------------------------------------------------------------------
directory under @file{config/os} to store the files for your operating
system.
-You'll have to change the @file{configure.target} file to ensure that
-your new directory is activated. Look for the switch statement that
-sets @code{os_include_dir}, and add a pattern to handle your operating
-system. The switch statement switches on only the OS portion of the
-standard target triplet; e.g., the @code{solaris2.8} in
-@code{sparc-sun-solaris2.8}.
+You might have to change the @file{configure.target} file to ensure that
+your new directory is activated. Look for the switch statement that sets
+@code{os_include_dir}, and add a pattern to handle your operating system
+if the default will not suffice. The switch statement switches on only
+the OS portion of the standard target triplet; e.g., the @code{solaris2.8}
+in @code{sparc-sun-solaris2.8}. If the new directory is named after the
+OS portion of the triplet (the default), then nothing needs to be changed.
The first file to create in this directory, should be called
@file{os_defines.h}. This file contains basic macro definitions
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
%</pre>
<p>The 'Aborted' line comes from the call to abort(), of course.
</p>
+ <p><strong>UPDATE:</strong> Starting with GCC 3.4, this is the default
+ termination handler; nothing need be done to use it. To go back to
+ the previous "silent death" method, simply include
+ <code><exception><code> and <code><cstdlib><code>, and call
+ </p>
+ <pre>
+ std::set_terminate (std::abort);</pre>
<p>Return <a href="#top">to top of page</a> or
<a href="../faq/index.html">to the FAQ</a>.
</p>
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
handle member function templates:
</p>
<pre>
- template <class U, class V> pain (const pair<U,V>& p);
+ template <class U, class V> pair (const pair<U,V>& p);
</pre>
<p>The compiler will convert as necessary from U to T1 and from
V to T2 in order to perform the respective initializations.
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
#include <algorithm>
#include <cctype> // old <ctype.h>
- std::string s ("Some Kind Of Initial Input Goes Here");
+ struct ToLower
+ {
+ char operator() (char c) const { return std::tolower(c); }
+ };
- // Change everything into upper case
- std::transform (s.begin(), s.end(), s.begin(), toupper);
+ struct ToUpper
+ {
+ char operator() (char c) const { return std::toupper(c); }
+ };
+
+ int main()
+ {
+ std::string s ("Some Kind Of Initial Input Goes Here");
- // Change everything into lower case
- std::transform (s.begin(), s.end(), s.begin(), tolower);
+ // Change everything into upper case
+ std::transform (s.begin(), s.end(), s.begin(), ToUpper());
- // Change everything back into upper case, but store the
- // result in a different string
- std::string capital_s;
- capital_s.reserve(s.size());
- std::transform (s.begin(), s.end(), capital_s.begin(), tolower); </pre>
+ // Change everything into lower case
+ std::transform (s.begin(), s.end(), s.begin(), ToLower());
+
+ // Change everything back into upper case, but store the
+ // result in a different string
+ std::string capital_s;
+ capital_s.resize(s.size());
+ std::transform (s.begin(), s.end(), capital_s.begin(), ToUpper());
+ } </pre>
<p><span class="larger"><strong>Note</strong></span> that these calls all
involve the global C locale through the use of the C functions
<code>toupper/tolower</code>. This is absolutely guaranteed to work --
So, if all your input forevermore consists of only those 96
characters (hahahahahaha), then you're done.
</p>
- <p>At minimum, you can write short wrappers like
+ <p><span class="larger"><strong>Note</strong></span> that the
+ <code>ToUpper</code> and <code>ToLower</code> function objects
+ are needed because <code>toupper</code> and <code>tolower</code>
+ are overloaded names (declared in <code><cctype></code> and
+ <code><locale></code>) so the template-arguments for
+ <code>transform<></code> cannot be deduced, as explained in
+ <a href="http://gcc.gnu.org/ml/libstdc++/2002-11/msg00180.html">this
+ message</a>. <!-- section 14.8.2.4 clause 16 in ISO 14882:1998
+ if you're into that sort of thing -->
+ At minimum, you can write short wrappers like
</p>
<pre>
char toLower (char c)
{
- return tolower(static_cast<unsigned char>(c));
+ return std::tolower(c);
} </pre>
<p>The correct method is to use a facet for a particular locale
and call its conversion functions. These are discussed more in
Chapter 22; the specific part is
- <a href="../22_locale/howto.html#5">here</a>, which shows the
- final version of this code. (Thanks to James Kanze for assistance
- and suggestions on all of this.)
+ <a href="../22_locale/howto.html#7">Correct Transformations</a>,
+ which shows the final version of this code. (Thanks to James Kanze
+ for assistance and suggestions on all of this.)
</p>
<p>Another common operation is trimming off excess whitespace. Much
like transformations, this task is trivial with the use of string's
<hr />
<h2><a name="5">Making strings of arbitrary character types</a></h2>
- <p>how to work with char_traits -- in the archives, just need to
- go through and pull the examples together
+ <p>The <code>std::basic_string</code> is tantalizingly general, in that
+ it is parameterized on the type of the characters which it holds.
+ In theory, you could whip up a Unicode character class and instantiate
+ <code>std::basic_string<my_unicode_char></code>, or assuming
+ that integers are wider than characters on your platform, maybe just
+ declare variables of type <code>std::basic_string<int></code>.
+ </p>
+ <p>That's the theory. Remember however that basic_string has additional
+ type parameters, which take default arguments based on the character
+ type (called CharT here):
+ </p>
+ <pre>
+ template <typename CharT,
+ typename Traits = char_traits<CharT>,
+ typename Alloc = allocator<CharT> >
+ class basic_string { .... };</pre>
+ <p>Now, <code>allocator<CharT></code> will probably Do The Right
+ Thing by default, unless you need to implement your own allocator
+ for your characters.
+ </p>
+ <p>But <code>char_traits</code> takes more work. The char_traits
+ template is <em>declared</em> but not <em>defined</em>.
+ That means there is only
+ </p>
+ <pre>
+ template <typename CharT>
+ struct char_traits
+ {
+ static void foo (type1 x, type2 y);
+ ...
+ };</pre>
+ <p>and functions such as char_traits<CharT>::foo() are not
+ actually defined anywhere for the general case. The C++ standard
+ permits this, because writing such a definition to fit all possible
+ CharT's cannot be done. (For a time, in earlier versions of GCC,
+ there was a mostly-correct implementation that let programmers be
+ lazy. :-) But it broke under many situations, so it was removed.
+ You are no longer allowed to be lazy and non-portable.)
+ </p>
+ <p>The C++ standard also requires that char_traits be specialized for
+ instantiations of <code>char</code> and <code>wchar_t</code>, and it
+ is these template specializations that permit entities like
+ <code>basic_string<char,char_traits<char>></code> to work.
+ </p>
+ <p>If you want to use character types other than char and wchar_t,
+ such as <code>unsigned char</code> and <code>int</code>, you will
+ need to write specializations for them at the present time. If you
+ want to use your own special character class, then you have
+ <a href="http://gcc.gnu.org/ml/libstdc++/2002-08/msg00163.html">a lot
+ of work to do</a>, especially if you with to use i18n features
+ (facets require traits information but don't have a traits argument).
+ </p>
+ <p>One example of how to specialize char_traits is given
+ <a href="http://gcc.gnu.org/ml/libstdc++/2002-08/msg00260.html">in
+ this message</a>. We agree that the way it's used with basic_string
+ (scroll down to main()) doesn't look nice, but that's because
+ <a href="http://gcc.gnu.org/ml/libstdc++/2002-08/msg00236.html">the
+ nice-looking first attempt</a> turned out to
+ <a href="http://gcc.gnu.org/ml/libstdc++/2002-08/msg00242.html">not
+ be conforming C++</a>, due to the rule that CharT must be a POD.
+ (See how tricky this is?)
+ </p>
+ <p>Other approaches were suggested in that same thread, such as providing
+ more specializations and/or some helper types in the library to assist
+ users writing such code. So far nobody has had the time...
+ <a href="../17_intro/contribute.html">do you?</a>
</p>
<p>Return <a href="#top">to top of page</a> or
<a href="../faq/index.html">to the FAQ</a>.
</p>
-
<!-- ####################################################### -->
<hr />
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<meta name="AUTHOR" content="bkoz@redhat.com (Benjamin Kosnik)" />
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<meta name="AUTHOR" content="bkoz@redhat.com (Benjamin Kosnik)" />
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
#include <algorithm>
#include <cctype> // old <ctype.h>
- struct Toupper
+ struct ToUpper
{
- Toupper(std::locale const& l) : loc(l) {;}
- char operator() (char c) { return std::toupper(c,loc); }
+ ToUpper(std::locale const& l) : loc(l) {;}
+ char operator() (char c) const { return std::toupper(c,loc); }
private:
std::locale const& loc;
};
- struct Tolower
+ struct ToLower
{
- Tolower(std::locale const& l) : loc(l) {;}
- char operator() (char c) { return std::tolower(c,loc); }
+ ToLower(std::locale const& l) : loc(l) {;}
+ char operator() (char c) const { return std::tolower(c,loc); }
private:
std::locale const& loc;
};
int main ()
{
std::string s("Some Kind Of Initial Input Goes Here");
- std::locale loc_c("C");
- Toupper up(loc_c);
- Tolower down(loc_c);
+ std::locale loc_c("C");
+ ToUpper up(loc_c);
+ ToLower down(loc_c);
// Change everything into upper case.
std::transform(s.begin(), s.end(), s.begin(), up);
std::string capital_s;
std::transform(s.begin(), s.end(), std::back_inserter(capital_s), up);
}</pre>
+ <p>The <code>ToUpper</code> and <code>ToLower</code> structs can be
+ generalized for other character types by making <code>operator()</code>
+ a member function template.
+ </p>
<p>The final version of the code uses <code>bind2nd</code> to eliminate
the wrapper structs, but the resulting code is tricky. I have not
shown it here because no compilers currently available to me will
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<meta name="AUTHOR" content="bkoz@redhat.com (Benjamin Kosnik)" />
<p>
Provides an index for looking up specific facets.
-<p>
+</p>
<h2>
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<meta name="AUTHOR" content="bkoz@redhat.com (Benjamin Kosnik)" />
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
<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>
+
<!-- ####################################################### -->
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
<meta name="KEYWORDS" content="libstdc++, libstdc++-v3, GCC, g++" />
<dd><p>Adds support for named libstdc++ include directory. For instance,
the following puts all the libstdc++ headers into a directory
called "2.97-20001008" instead of the usual
- "g++-v3".
+ "c++/(version)".
</p>
<pre>
--with-gxx-include-dir=/foo/H-x86-gcc-3-c-gxx-inc/include/2.97-20001008</pre> </dd>
- <dt><code>--enable-debug </code></dt>
- <dd><p>The configure script will automatically detect the highest
- level of optimization that the compiler in use can use.
- This --enable flag will disable all optimizations and instruct
- the compiler to emit as much extra debugging information as it
- can, for use inside GDB. Note this make command, executed in
- the build directory, will do much the same thing, without the
- configuration difference:
- <code>make CXXFLAGS='-g -O0' all</code>
- </p>
- </dd>
-
<dt><code>--enable-cstdio </code></dt>
<dd><p>This is an abbreviated form of <code>'--enable-cstdio=stdio'</code>
(described next). This option can change the library ABI.
</p>
</dd>
+ <dt><code>--enable-debug </code></dt>
+ <dd><p>Build separate debug libraries in addition to what is normally built.
+ By default, the debug libraries are compiled with
+ <code> CXXFLAGS='-g3 -O0'</code>
+ , are installed in <code>${libdir}/debug</code>, and have the
+ same names and versioning information as the non-debug
+ libraries. This option is off by default.
+ <p>
+ Note this make command, executed in
+ the build directory, will do much the same thing, without the
+ configuration difference and without building everything twice:
+ <code>make CXXFLAGS='-g3 -O0' all</code>
+ </p>
+ </p>
+ </dd>
+
+ <dt><code>--enable-debug-flags=FLAGS</code></dt>
+
+ <dd><p>This option is only valid when <code> --enable-debug </code>
+ is also specified, and applies to the debug builds only. With
+ this option, you can pass a specific string of flags to the
+ compiler to use when building the debug versions of libstdc++.
+ FLAGS is a quoted string of options, like
+ </p>
+ <pre>
+ --enable-debug-flags='-g3 -O1 -gdwarf-2'</pre>
+ </dd>
+
<dt><code>--enable-cxx-flags=FLAGS</code></dt>
<dd><p>With this option, you can pass a string of -f (functionality)
flags to the compiler to use when building libstdc++. This
</dd>
<dt><code>--enable-symvers[=style] </code></dt>
- <dd><p>In 3.1, tries to turn on symbol versioning in the shared library (if a
- shared library has been requested). The only 'style' currently
- supported is 'gnu' which requires that a recent version of the GNU
- linker be in use. With no style given, the configure script will
- try to guess if the 'gnu' style can be used, and if so, will turn it
- on. Hopefully people will volunteer to do other 'style' options.
+ <dd><p>In 3.1 and later, tries to turn on symbol versioning in the
+ shared library (if a shared library has been requested). The
+ only 'style' currently supported is 'gnu' which requires that
+ a recent version of the GNU linker be in use. With no style
+ given, the configure script will try to guess if the 'gnu'
+ style can be used, and if so, will turn it on. Hopefully
+ people will volunteer to do other 'style' options.
</p>
</dd>
</dl>
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta name="KEYWORDS"
content="libstdc++, homepage, home, C++, library, c++, std, g++, ABI, STL" />
- latest version info, recent changes and news</li>
<li><a href="17_intro/TODO">TODO</a>
- tasks yet undone</li>
+ <li><a href="faq/index.html">FAQ (HTML)</a>,
+ <a href="faq/index.txt">FAQ (text)</a></li>
</ul>
<hr />
<ul>
<li><a href="configopts.html">Configure options</a></li>
<li><a href="install.html">Getting started: configure, build, install</a>
+ <li><a href="debug.html">Debugging schemes and strategies</a>
</li>
</ul>
<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.1/index.html">for the 3.2.1 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>
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
<meta name="KEYWORDS" content="libstdc++, libstdc++-v3, GCC, g++" />
<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>
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
<meta name="KEYWORDS" content="libstdc++, libstdc++-v3, GCC, g++, STL, SGI" />
for a description). Not every chapter may have extensions, and the
extensions may come and go. Also, this page is incomplete because the
author is pressed for time. Check back often; the latest change was on
- $Date: 2002/09/05 15:47:53 $ (UTC).
+ $Date: 2002/12/16 18:22:57 $ (UTC).
</p>
<p>Descriptions range from the scanty to the verbose. You should also check
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<meta name="KEYWORDS" content="libstdc++, libstdc++-v3, GCC, g++, libg++, STL" />
<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>
ongoing project to implement the ISO 14882 Standard C++ library
as described in chapters 17 through 27 and annex D. As the
library reaches stable plateaus, it is captured in a snapshot
- and released. The current release is
+ and released. The latest release is
<a href="http://gcc.gnu.org/libstdc++/index.html#download">the
- fourteenth snapshot</a>. For those who want to see exactly how
+ fourteenth snapshot</a> 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 below).
+ anonymous CVS, and can even be browsed over the Web (see
+ <a href="#1_4">1.4</a> below).
</p>
<p>The older libstdc++-v2 project is no longer maintained; the code
has been completely replaced and rewritten.
link to the solution.</a>
</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
that of other headers whose directories are not searched directly,
e.g., <code><sys/stat.h></code>, <code><X11/Xlib.h></code>.
</p>
+
+ <p>The extensions are no longer in the global or <code>std</code>
+ namespaces, instead they are declared in the <code>__gnu_cxx</code>
+ namespace. For maximum portability, consider defining a namespace
+ alias to use to talk about extensions, e.g.:
+ </p>
+ <pre>
+ #ifdef __GNUC__
+ #if __GNUC__ < 3
+ #include <hash_map.h>
+ namespace Sgi { using ::hash_map; }; // inherit globals
+ #else
+ #include <ext/hash_map>
+ #if __GNUC_MINOR__ == 0
+ namespace Sgi = std; // GCC 3.0
+ #else
+ namespace Sgi = ::__gnu_cxx; // GCC 3.1 and later
+ #endif
+ #endif
+ #else // ... there are other compilers, right?
+ namespace Sgi = std;
+ #endif
+
+ Sgi::hash_map<int,int> my_map; </pre>
+ <p>This is a bit cleaner than defining typedefs for all the
+ instantiations you might need.
+ </p>
+
<p>Extensions to the library have
<a href="../ext/howto.html">their own page</a>.
</p>
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
The GNU Standard C++ Library v3 is an ongoing project to implement the
ISO 14882 Standard C++ library as described in chapters 17 through 27
and annex D. As the library reaches stable plateaus, it is captured in
- a snapshot and released. The current release is [49]the fourteenth
- snapshot. For those who want to see exactly how far the project has
- come, or just want the latest bleeding-edge code, the up-to-date
- source is available over anonymous CVS, and can even be browsed over
- the Web (see below).
+ a 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 [51]1.4 below).
The older libstdc++-v2 project is no longer maintained; the code has
- been completely replaced and rewritten. [50]If you are using V2, then
+ 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
- [51]design document.
+ [53]design document.
_________________________________________________________________
1.2 Why should I use libstdc++?
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 [52]GCC team. All of
- the rapid development and near-legendary [53]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
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 [54]homepage.
+ 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 [55]available
+ The fourteenth (and latest) snapshot of libstdc++-v3 is [57]available
via ftp.
- The [56]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
1.6 How do I contribute to the effort?
- Here is [57]a page devoted to this topic. Subscribing to the mailing
+ 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
extracted into an updated utilities library, but nobody has stated
such a project yet.
- (The [58]Boost site houses free C++ libraries that do varying things,
+ (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 [59]GCC FAQ describes where to find
+ For the bold and/or desperate, the [61]GCC FAQ describes where to find
the last libg++ source.
_________________________________________________________________
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 [60]libstdc++@gcc.gnu.org.
+ 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 [61]Phil
- Edwards or [62]Gabriel Dos Reis.
+ 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 [63]our license description for these and related questions.
+ See [65]our license description for these and related questions.
_________________________________________________________________
2.0 Installation
* The GNU Autotools are needed if you are messing with the configury
or makefiles.
- The file [64]documentation.html provides a good overview of the steps
+ 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 [65]RELEASE-NOTES files contain the
+ 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/"
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 [66]CVS entry in the GNU
- software catalogue has a better description as well as a [67]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
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 [68]clause 18 of the standard,
+ 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
- < /dev/null" to display a list of predefined macros for any
particular installation.
- This has been discussed on the mailing lists [69]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
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. [70]Here's a link to 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
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 [71]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.
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 [72]the installation instructions for GCC,
+ 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
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 [73]bugs database with the
+ 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
(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, [74]changing your GDB settings can
+ 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 [75]message to the list,
+ 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 [76]posted on his website.
+ 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 [77]here.
- Some of these have resulted in [78]code changes.
+ 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
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 [79]proposed LWG resolution (see DR #22) is to leave the flags
+ 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.
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 [80]sums things up here. The collisions with
+ 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 [81]the GCC bug database).
+ paragraph of the page describing [83]the GCC bug database).
If the headers are in ${prefix}/include/g++-3, or if the installed
library's name looks like libstdc++-2.10.a or libstdc++-libc6-2.10.so,
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 [82]the question has not yet been decided.
+ 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
http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
- Note that 2.95.x shipped with the [83]old v2 library which is no
+ 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.
visibility, or you just plain forgot, etc).
More information, including how to optionally enable/disable the
- checks, is available [84]here.
+ 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
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
- [85]submitting patches that covers the procedure, but for libstdc++
+ [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++ [86]contributors' page also
+ 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 [87]testsuite -- but only if such a test
+ caught immediately by the [89]testsuite -- but only if such a test
exists.
_________________________________________________________________
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 [88]the
+ 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
type from C99.) Bugfixes and rewrites (to improve or fix thread
safety, for instance) will of course be a continuing task.
- [89]This question about the next libstdc++ prompted some brief but
- interesting [90]speculation.
+ [91]This question about the next libstdc++ prompted some brief but
+ interesting [92]speculation.
_________________________________________________________________
5.3 What about the STL from SGI?
- The [91]STL from SGI, version 3.3, was the most recent merge of the
+ 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.
headers whose directories are not searched directly, e.g.,
<sys/stat.h>, <X11/Xlib.h>.
- Extensions to the library have [92]their own page.
+ Extensions to the library have [94]their own page.
_________________________________________________________________
5.5 [removed]
otherwise documented as safe, do not assume that two threads may
access a shared standard library object at the same time.
- See chapters [93]17 (library introduction), [94]23 (containers), and
- [95]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?
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 [96]here. (And if you've already registered with them, clicking
- this link will take you to directly to the place where you can [97]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 [98]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?
encompasses the standard library.
_________________________________________________________________
- See [99]license.html for copying conditions. Comments and suggestions
- are welcome, and may be sent to [100]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#4_4_interface
- 51. ../17_intro/DESIGN
- 52. http://gcc.gnu.org/
- 53. http://gcc.gnu.org/gcc-3.0/buildstat.html
- 54. http://gcc.gnu.org/libstdc++/
- 55. http://gcc.gnu.org/libstdc++/index.html#download
+ 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. ../17_intro/contribute.html
- 58. http://www.boost.org/
- 59. http://gcc.gnu.org/fom_serv/cache/33.html
- 60. mailto:libstdc++@gcc.gnu.org
- 61. mailto:pme@gcc.gnu.org
- 62. mailto:gdr@gcc.gnu.org
- 63. ../17_intro/license.html
- 64. ../documentation.html
- 65. ../17_intro/RELEASE-NOTES
- 66. http://www.gnu.org/software/cvs/cvs.html
- 67. http://www.cvshome.org/
- 68. ../18_support/howto.html
- 69. http://gcc.gnu.org/cgi-bin/htsearch?method=and&format=builtin-long&sort=score&words=_XOPEN_SOURCE+Solaris
- 70. http://gcc.gnu.org/ml/gcc/2002-03/msg00817.html
- 71. http://gcc.gnu.org/install/configure.html
- 72. http://gcc.gnu.org/install/
- 73. http://gcc.gnu.org/bugs.html
- 74. http://gcc.gnu.org/ml/libstdc++/2002-02/msg00034.html
- 75. http://gcc.gnu.org/ml/libstdc++/1998/msg00006.html
- 76. http://www.cantrip.org/draft-bugs.txt
- 77. http://anubis.dkuug.dk/jtc1/sc22/wg21/
- 78. ../faq/index.html#5_2
- 79. ../ext/howto.html#5
- 80. http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html
- 81. http://gcc.gnu.org/gnatswrite.html
- 82. http://gcc.gnu.org/ml/gcc/2000-10/msg00732.html
- 83. ../faq/index.html#4_4_interface
- 84. ../19_diagnostics/howto.html#3
- 85. http://gcc.gnu.org/contribute.html
- 86. ../17_intro/contribute.html
- 87. ../faq/index.html#2_4
- 88. ../ext/howto.html#5
- 89. http://gcc.gnu.org/ml/libstdc++/1999/msg00080.html
- 90. http://gcc.gnu.org/ml/libstdc++/1999/msg00084.html
- 91. http://www.sgi.com/Technology/STL/
- 92. ../ext/howto.html
- 93. ../17_intro/howto.html#3
- 94. ../23_containers/howto.html#3
- 95. ../27_io/howto.html#9
- 96. http://www.ansi.org/
- 97. http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%2D1998
- 98. http://www.iso.ch/
- 99. ../17_intro/license.html
- 100. mailto:libstdc++@gcc.gnu.org
+ 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
-<html>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)" />
<meta name="KEYWORDS" content="libstdc++, libstdc++-v3, GCC, g++" />
interest to library maintainers and system integrators. As such,
these tests may not work on all cpu and host combinations. These
options include, but are not necessarily limited to, the following:
+ </p>
<p>The library ABI can be tested using</p>
<pre>
the default dejagnu test harness</p>
<pre>
make check-script</pre>
- or
+ <p>or</p>
<pre>
make check-script-install</pre>
projects / thirdparty / gcc.git / commitdiff
