Skip to content

R
riscv-gcc-1
Commit 664ce870 by Phil Edwards
Options

style.css: Update. 

2002-11-21  Phil Edwards  <pme@gcc.gnu.org>

	* docs/doxygen/style.css:  Update.
	* docs/doxygen/user.cfg.in:  Update.
	* docs/html/documentation.html:  Regenerate.
	* docs/html/17_intro/howto.html:  Tweak I/O sentry entry.
	* docs/html/27_io/howto.html:  New section on headers.
	* docs/html/faq/index.html:  Add i386 threading entry.
	* docs/html/faq/index.txt:  Regenerate.

	* docs/html/ext/lwg-active.html, docs/html/ext/lwg-defects.html:
	Import R23.

From-SVN: r59326
parent 840ceb34
Showing with 1507 additions and 480 deletions
libstdc++-v3/ChangeLog
2002-11-21 Phil Edwards <pme@gcc.gnu.org>
* docs/doxygen/style.css: Update.
* docs/doxygen/user.cfg.in: Update.
* docs/html/documentation.html: Regenerate.
* docs/html/17_intro/howto.html: Tweak I/O sentry entry.
* docs/html/27_io/howto.html: New section on headers.
* docs/html/faq/index.html: Add i386 threading entry.
* docs/html/faq/index.txt: Regenerate.
* docs/html/ext/lwg-active.html, docs/html/ext/lwg-defects.html:
Import R23.
2002-11-21 Phil Edwards <pme@gcc.gnu.org>
* docs/doxygen/TODO: Note change in clause 27 docs.
* include/bits/basic_ios.h, include/bits/fpos.h,
include/bits/ios_base.h, include/bits/stl_deque.h,
......
libstdc++-v3/docs/doxygen/style.css
H1 { text-align: center; }
CAPTION { font-weight: bold }
A.qindex {}
A.qindexRef {}
A.el { text-decoration: none; font-weight: bold }
......@@ -10,15 +11,39 @@ DL.el { margin-left: -1cm }
DIV.fragment { width: 100%; border: none; background-color: #eeeeee }
DIV.ah { background-color: black; font-weight: bold; color: #ffffff; margin-bottom: 3px; margin-top: 3px }
TD.md { background-color: #f2f2ff; font-weight: bold; }
TD.mdname1 { background-color: #f2f2ff; font-weight: bold; font-style: italic; }
TD.mdname { background-color: #f2f2ff; font-weight: bold; font-style: italic; width: 600px; }
TD.mdname1 { background-color: #f2f2ff; font-weight: bold; color: #602020; }
TD.mdname { background-color: #f2f2ff; font-weight: bold; color: #602020; width: 600px; }
DIV.groupHeader { margin-left: 16px; margin-top: 12px; margin-bottom: 6px; font-weight: bold }
DIV.groupText { margin-left: 16px; font-style: italic; font-size: smaller }
FONT.keyword { color: #008000 }
FONT.keywordtype { color: #604020 }
FONT.keywordflow { color: #e08000 }
FONT.comment { color: #800000 }
FONT.preprocessor { color: #806020 }
FONT.stringliteral { color: #002080 }
FONT.charliteral { color: #008080 }
.smallertext { font-size: smaller }
BODY { background: white }
TD.indexkey {
background-color: #eeeeff;
font-weight: bold;
padding-right : 10px;
padding-top : 2px;
padding-left : 10px;
padding-bottom : 2px;
margin-left : 0px;
margin-right : 0px;
margin-top : 2px;
margin-bottom : 2px
}
TD.indexvalue {
background-color: #eeeeff;
font-style: italic;
padding-right : 10px;
padding-top : 2px;
padding-left : 10px;
padding-bottom : 2px;
margin-left : 0px;
margin-right : 0px;
margin-top : 2px;
margin-bottom : 2px
}
span.keyword { color: #008000 }
span.keywordtype { color: #604020 }
span.keywordflow { color: #e08000 }
span.comment { color: #800000 }
span.preprocessor { color: #806020 }
span.stringliteral { color: #002080 }
span.charliteral { color: #008080 }
libstdc++-v3/docs/doxygen/user.cfg.in
# Doxyfile 1.2.12
# Doxyfile 1.2.18
# This file describes the settings to be used by the documentation system
# doxygen (www.doxygen.org) for a project
......@@ -43,9 +43,11 @@ OUTPUT_DIRECTORY = @outdir@
# documentation generated by doxygen is written. Doxygen will use this
# information to generate all constant output in the proper language.
# The default language is English, other supported languages are:
# Brazilian, Chinese, Croatian, Czech, Danish, Dutch, Finnish, French,
# German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish,
# Portuguese, Romanian, Russian, Slovak, Slovene, Spanish and Swedish.
# Brazilian, Catalan, Chinese, Chinese-Traditional, Croatian, Czech, Danish, Dutch,
# Finnish, French, German, Greek, Hungarian, Italian, Japanese, Japanese-en
# (Japanese with english messages), Korean, Norwegian, Polish, Portuguese,
# Romanian, Russian, Serbian, Slovak, Slovene, Spanish, Swedish and Ukrainian.
OUTPUT_LANGUAGE = English
......@@ -66,6 +68,12 @@ EXTRACT_PRIVATE = YES
EXTRACT_STATIC = YES
# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs)
# defined locally in source files will be included in the documentation.
# If set to NO only classes defined in header files are included.
EXTRACT_LOCAL_CLASSES = NO
# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all
# undocumented members of documented classes, files or namespaces.
# If set to NO (the default) these members will be included in the
......@@ -81,6 +89,13 @@ HIDE_UNDOC_MEMBERS = YES
HIDE_UNDOC_CLASSES = YES
# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all
# friend (class|struct|union) declarations.
# If set to NO (the default) these declarations will be included in the
# documentation.
HIDE_FRIEND_COMPOUNDS = NO
# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will
# include brief member descriptions after the members that are listed in
# the file and class documentation (similar to JavaDoc).
......@@ -101,6 +116,14 @@ REPEAT_BRIEF = YES
ALWAYS_DETAILED_SEC = YES
# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all inherited
# members of a class in the documentation of that class as if those members were
# ordinary class members. Constructors, destructors and assignment operators of
# the base classes will not be shown.
INLINE_INHERITED_MEMB = NO
# pedwards -- this is useful, but ch27 gets huge
# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full
# path before files name in the file list and in the header files. If set
# to NO the shortest path that makes the file name unique will be used.
......@@ -167,6 +190,21 @@ SHOW_INCLUDE_FILES = YES
JAVADOC_AUTOBRIEF = NO
# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen
# treat a multi-line C++ special comment block (i.e. a block of //! or ///
# comments) as a brief description. This used to be the default behaviour.
# The new default is to treat a multi-line C++ comment block as a detailed
# description. Set this tag to YES if you prefer the old behaviour instead.
MULTILINE_CPP_IS_BRIEF = YES
# If the DETAILS_AT_TOP tag is set to YES then Doxygen
# will output the detailed description near the top, like JavaDoc.
# If set to NO, the detailed description appears after the member
# documentation.
DETAILS_AT_TOP = NO
# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented
# member inherits the documentation from any documented member that it
# reimplements.
......@@ -183,7 +221,7 @@ INLINE_INFO = YES
# alphabetically by member name. If set to NO the members will appear in
# declaration order.
SORT_MEMBER_DOCS = NO
SORT_MEMBER_DOCS = YES
# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC
# tag is set to YES, then doxygen will reuse the documentation of the first
......@@ -215,6 +253,12 @@ GENERATE_TESTLIST = NO
GENERATE_BUGLIST = YES
# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or
# disable (NO) the deprecated list. This list is created by putting
# \deprecated commands in the documentation.
GENERATE_DEPRECATEDLIST= YES
# This tag can be used to specify a number of aliases that acts
# as commands in the documentation. An alias has the form "name=value".
# For example adding "sideeffect=\par Side Effects:\n" will allow you to
......@@ -222,7 +266,8 @@ GENERATE_BUGLIST = YES
# will result in a user defined paragraph with heading "Side Effects:".
# You can put \n's in the value part of an alias to insert newlines.
ALIASES = "doctodo=@todo\nDoc me! See docs/doxygen/TODO and http://gcc.gnu.org/ml/libstdc++/2002-02/msg00003.html for more."
ALIASES = "doctodo=@todo\nDoc me! See docs/doxygen/TODO and http://gcc.gnu.org/ml/libstdc++/2002-02/msg00003.html for more." \
"isiosfwd=One of the @link s27_2_iosfwd I/O forward declarations @endlink"
# The ENABLED_SECTIONS tag can be used to enable conditional
# documentation sections, marked by \if sectionname ... \endif.
......@@ -237,7 +282,7 @@ ENABLED_SECTIONS = @enabled_sections@
# documentation can be controlled using \showinitializer or \hideinitializer
# command in the documentation regardless of this setting.
MAX_INITIALIZER_LINES = 30
MAX_INITIALIZER_LINES = 0
# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources
# only. Doxygen will then generate output that is more tailored for C.
......@@ -246,6 +291,13 @@ MAX_INITIALIZER_LINES = 30
OPTIMIZE_OUTPUT_FOR_C = NO
# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java sources
# only. Doxygen will then generate output that is more tailored for Java.
# For instance namespaces will be presented as packages, qualified scopes
# will look different, etc.
OPTIMIZE_OUTPUT_JAVA = NO
# Set the SHOW_USED_FILES tag to NO to disable the list of files generated
# at the bottom of the documentation of classes and structs. If set to YES the
# list will mention the files that were used to generate the documentation.
......@@ -325,12 +377,18 @@ RECURSIVE = YES
EXCLUDE = Makefile CVS
# The EXCLUDE_SYMLINKS tag can be used select whether or not files or directories
# that are symbolic links (a Unix filesystem feature) are excluded from the input.
EXCLUDE_SYMLINKS = NO
# If the value of the INPUT tag contains directories, you can use the
# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude
# certain files from those directories.
EXCLUDE_PATTERNS = CVS \
stamp-*
stamp-* \
Makefile
# The EXAMPLE_PATH tag can be used to specify one or more files or
# directories that contain example code fragments that are included (see
......@@ -369,7 +427,7 @@ INPUT_FILTER =
# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using
# INPUT_FILTER) will be used to filter the input files when producing source
# files to browse.
# files to browse (i.e. when SOURCE_BROWSER is set to YES).
FILTER_SOURCE_FILES = NO
......@@ -437,6 +495,12 @@ GENERATE_HTML = @do_html@
HTML_OUTPUT = @html_output_dir@
# The HTML_FILE_EXTENSION tag can be used to specify the file extension for
# each generated HTML page (for example: .htm,.php,.asp). If it is left blank
# doxygen will generate files with .html extension.
HTML_FILE_EXTENSION = .html
# The HTML_HEADER tag can be used to specify a personal HTML header for
# each generated HTML page. If it is left blank doxygen will generate a
# standard header.
......@@ -469,6 +533,20 @@ HTML_ALIGN_MEMBERS = YES
GENERATE_HTMLHELP = NO
# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can
# be used to specify the file name of the resulting .chm file. You
# can add a path in front of the file if the result should not be
# written to the html output dir.
CHM_FILE =
# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can
# be used to specify the location (absolute path including file name) of
# the HTML help compiler (hhc.exe). If non empty doxygen will try to run
# the html help compiler on the generated index.hhp.
HHC_LOCATION =
# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag
# controls if a separate .chi index file is generated (YES) or that
# it should be included in the master .chm file (NO).
......@@ -528,6 +606,17 @@ GENERATE_LATEX = NO
LATEX_OUTPUT = latex
# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to
# be invoked. If left blank `latex' will be used as the default command name.
LATEX_CMD_NAME = latex
# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to
# generate index for LaTeX. If left blank `makeindex' will be used as the
# default command name.
MAKEINDEX_CMD_NAME = makeindex
# If the COMPACT_LATEX tag is set to YES Doxygen generates more compact
# LaTeX documents. This may be useful for small projects and may help to
# save some trees in general.
......@@ -654,6 +743,30 @@ MAN_LINKS = NO
GENERATE_XML = NO
# The XML_SCHEMA tag can be used to specify an XML schema,
# which can be used by a validating XML parser to check the
# syntax of the XML files.
XML_SCHEMA =
# The XML_DTD tag can be used to specify an XML DTD,
# which can be used by a validating XML parser to check the
# syntax of the XML files.
XML_DTD =
#---------------------------------------------------------------------------
# configuration options for the AutoGen Definitions output
#---------------------------------------------------------------------------
# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will
# generate an AutoGen Definitions (see autogen.sf.net) file
# that captures the structure of the code including all
# documentation. Note that this feature is still experimental
# and incomplete at the moment.
GENERATE_AUTOGEN_DEF = NO
#---------------------------------------------------------------------------
# Configuration options related to the preprocessor
#---------------------------------------------------------------------------
......@@ -707,6 +820,8 @@ INCLUDE_FILE_PATTERNS =
### completely broken, and the presence of the macros confuses the parser.
PREDEFINED = _GLIBCPP_DEPRECATED \
_GLIBCPP_USE_WCHAR_T \
_GLIBCPP_USE_LONG_LONG \
__glibcpp_class_requires="//" \
__glibcpp_class_requires2="//" \
__glibcpp_class_requires3="//" \
......@@ -745,6 +860,12 @@ GENERATE_TAGFILE =
ALLEXTERNALS = YES
# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed
# in the modules index. If set to NO, only the current project's groups will
# be listed.
EXTERNAL_GROUPS = YES
# The PERL_PATH should be the absolute path and name of the perl script
# interpreter (i.e. the result of `which perl').
......@@ -762,6 +883,12 @@ PERL_PATH = /usr/bin/perl
CLASS_DIAGRAMS = YES
# If set to YES, the inheritance and collaboration graphs will hide
# inheritance and usage relations if the target is undocumented
# or is not a class.
HIDE_UNDOC_RELATIONS = YES
# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is
# available from the path. This tool is part of Graphviz, a graph visualization
# toolkit from AT&T and Lucent Bell Labs. The other options in this section
......@@ -788,12 +915,6 @@ COLLABORATION_GRAPH = YES
TEMPLATE_RELATIONS = YES
# If set to YES, the inheritance and collaboration graphs will hide
# inheritance and usage relations if the target is undocumented
# or is not a class.
HIDE_UNDOC_RELATIONS = YES
# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT
# tags are set to YES then doxygen will generate a graph for each documented
# file showing the direct and indirect include dependencies of the file with
......@@ -813,6 +934,12 @@ INCLUDED_BY_GRAPH = YES
GRAPHICAL_HIERARCHY = YES
# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images
# generated by dot. Possible values are png, jpg, or gif
# If left blank png will be used.
DOT_IMAGE_FORMAT = png
# The tag DOT_PATH can be used to specify the path where the dot tool can be
# found. If left blank, it is assumed the dot tool can be found on the path.
......
libstdc++-v3/docs/html/17_intro/howto.html
......@@ -261,8 +261,9 @@
on the --enable-libio choice: for stdio, if the written data is
already in the stdio buffer, the data may be completely safe!
</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 />
......
libstdc++-v3/docs/html/27_io/howto.html
......@@ -34,6 +34,7 @@
<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 />
......@@ -558,6 +559,138 @@
&quot;interesting&quot; 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
&lt;iostream&gt; 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>&lt;iosfwd&gt;</strong> should be included whenever you simply
need the <em>name</em> of an I/O-related class, such as
&quot;ofstream&quot; or &quot;basic_streambuf&quot;. Like the name
implies, these are forward declarations. (A word to all you fellow
old school programmers: trying to forward declare classes like
&quot;class istream;&quot; won't work. Look in the iosfwd header if
you'd like to know why.) For example,
</p>
<pre>
#include &lt;iosfwd&gt;
class MyClass
{
....
std::ifstream input_file;
};
extern std::ostream&amp; operator&lt;&lt; (std::ostream&amp;, MyClass&amp;);
</pre>
<p><strong>&lt;ios&gt;</strong> declares the base classes for the entire
I/O stream hierarchy, std::ios_base and std::basic_ios&lt;charT&gt;, 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>&lt;streambuf&gt;</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>&lt;istream&gt;</strong>/<strong>&lt;ostream&gt;</strong> are
the headers to include when you are using the &gt;&gt;/&lt;&lt;
interface, or any of the other abstract stream formatting functions.
For example,
</p>
<pre>
#include &lt;istream&gt;
std::ostream&amp; operator&lt;&lt; (std::ostream&amp; os, MyClass&amp; c)
{
return os &lt;&lt; c.data1() &lt;&lt; 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>&lt;iomanip&gt;</strong> provides &quot;extractors and inserters
that alter information maintained by class ios_base and its dervied
classes,&quot; such as std::setprecision and std::setw. If you need
to write expressions like <code>os &lt;&lt; setw(3);</code> or
<code>is &gt;&gt; setbase(8);</code>, you must include &lt;iomanip&gt;.
</p>
<p><strong>&lt;sstream&gt;</strong>/<strong>&lt;fstream&gt;</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>&lt;iostream&gt;</strong> provides the eight standard
global objects (cin, cout, etc). To do this correctly, this header
also provides the contents of the &lt;istream&gt; and &lt;ostream&gt;
headers, but nothing else. The contents of this header look like
</p>
<pre>
#include &lt;ostream&gt;
#include &lt;istream&gt;
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 &lt;iostream&gt; 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 &lt;iostream&gt; 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>
<!-- ####################################################### -->
......
libstdc++-v3/docs/html/documentation.html
......@@ -66,7 +66,7 @@
<ul>
<li><a href="libstdc++-html-USERS-3.1/index.html">for the 3.1 release</a>
</li>
<li><a href="libstdc++-html-USERS-3.2/index.html">for the 3.2 release</a>
<li><a href="libstdc++-html-USERS-3.2/index.html">for the 3.2.x release</a>
</li>
<li><a href="latest-doxygen/index.html">&quot;the latest collection&quot;</a>
(for the snapshot or later; see the date on the first page)
......@@ -208,6 +208,7 @@
<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>
......
libstdc++-v3/docs/html/ext/lwg-active.html
......@@ -5,11 +5,11 @@
<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>
......@@ -17,10 +17,10 @@
</tr>
<tr>
<td align="left">Reply to:</td>
<td align="left">Matt Austern &lt;austern@research.att.com&gt;</td>
<td align="left">Matt Austern &lt;austern@apple.com&gt;</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>
......@@ -78,7 +78,7 @@
<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
......@@ -88,6 +88,10 @@
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&ccedil;ao mailing. Added new issues <a href="lwg-active.html#362">362</a>-<a href="lwg-active.html#366">366</a>.
</li>
......@@ -1486,7 +1490,7 @@ specified. Both resolutions are consistent with the behavior of
existing implementations.</p>
<hr>
<a name="225"><h3>225.&nbsp;std:: algorithms use of other unqualified algorithms</h3></a><p>
<b>Section:</b>&nbsp;17.4.4.3 <a href="lib-intro.html#lib.global.functions"> [lib.global.functions]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;01 Apr 2000</p>
<b>Section:</b>&nbsp;17.4.4.3 <a href="lib-intro.html#lib.global.functions"> [lib.global.functions]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;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
......@@ -1586,13 +1590,14 @@ should have any effect.]</i></p>
<p><i>[Cura&ccedil;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.&nbsp;User supplied specializations or overloads of namespace std function templates</h3></a><p>
<b>Section:</b>&nbsp;17.4.3.1 <a href="lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;01 Apr 2000</p>
<b>Section:</b>&nbsp;17.4.3.1 <a href="lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;01 Apr 2000</p>
<p>The issues are:&nbsp;</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?&nbsp;</p>
......@@ -1677,6 +1682,9 @@ not provide an operator&lt;&lt; for std::pair&lt;&gt;.
<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, &quot;There is no conforming way to extend
std::swap for user defined templates.&quot;&nbsp; The LWG agrees that
there is a problem.&nbsp; Would like more information before
......@@ -1734,13 +1742,14 @@ try to put together a proposal before the next meeting.]</i></p>
<p><i>[Cura&ccedil;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.&nbsp;Unqualified references of other library entities</h3></a><p>
<b>Section:</b>&nbsp;17.4.1.1 <a href="lib-intro.html#lib.contents"> [lib.contents]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;19 Apr 2000</p>
<b>Section:</b>&nbsp;17.4.1.1 <a href="lib-intro.html#lib.contents"> [lib.contents]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;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>
......@@ -1784,13 +1793,15 @@ but that the wording may not be clear enough to fall under
<p><i>[Cura&ccedil;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.&nbsp;Precision in iostream?</h3></a><p>
<b>Section:</b>&nbsp;22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze, Stephen Clamage&nbsp; <b>Date:</b>&nbsp; 25 Apr 2000</p>
<b>Section:</b>&nbsp;22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze, Stephen Clamage&nbsp; <b>Date:</b>&nbsp; 25 Apr 2000</p>
<p>What is the following program supposed to output?</p>
<pre>#include &lt;iostream&gt;
......@@ -1831,24 +1842,31 @@ etc. Plus, of course, if precision == 0 and flags &amp; floatfield ==
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
&quot;if <tt>(flags &amp; fixed) != 0</tt>&quot; to
&quot;if <tt>(flags &amp; floatfield) == fixed ||
(flags &amp; floatfield) == scientific</tt>&quot;
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 &quot;1e+00&quot;.</p>
<p><i>[Cura&ccedil;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 &quot;1e+00&quot;.</p>
<p><i>[Post-Cura&ccedil;ao: Howard provided improved wording covering the case
where precision is 0 and mode is %g.]</i></p>
<hr>
<a name="233"><h3>233.&nbsp;Insertion hints in associative containers</h3></a><p>
......@@ -2354,6 +2372,28 @@ throw, the string must compare equal to the argument.</li>
<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
......@@ -2361,11 +2401,9 @@ more support for nonnormative advice to implementors than for a
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&ccedil;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.&nbsp;Missing allocator requirement</h3></a><p>
......@@ -2553,7 +2591,7 @@ desirable to provide this feature in a different way.
<hr>
<a name="282"><h3>282.&nbsp;What types does numpunct grouping refer to?</h3></a><p>
<b>Section:</b>&nbsp;22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;5 Dec 2000</p>
<b>Section:</b>&nbsp;22.2.2.2.2 <a href="lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;5 Dec 2000</p>
<p>
Paragraph 16 mistakenly singles out integral types for inserting
thousands_sep() characters. This conflicts with the syntax for floating
......@@ -2593,8 +2631,8 @@ floating-point input even though this is unambiguously required by the
standard.
]</i></p>
<p><i>[Cura&ccedil;ao: Howard will email Bill and other implementors to try to
move the issue forward.]</i></p>
<p><i>[Post-Cura&ccedil;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.&nbsp;std::replace() requirement incorrect/insufficient</h3></a><p>
......@@ -3099,22 +3137,42 @@ note in p24 (below) is that x be empty after the merge which is surely
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 (&amp;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 &amp;x == this, does nothing; otherwise, merges the
argument list into the list.
<p>
24 Notes: Stable: if (&amp;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 (&amp;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
(&amp;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, &quot;merges the argument list into the
list&quot; is excessively vague.]</i></p>
<p><i>[Cura&ccedil;ao: Robert Klarer volunteers to work on this issue.]</i></p>
<p><i>[Post-Cura&ccedil;ao: Robert Klarer provided new wording.]</i></p>
<hr>
<a name="304"><h3>304.&nbsp;Must <tt>*a</tt> return an lvalue when <tt>a</tt> is an input iterator?</h3></a><p>
......@@ -5283,6 +5341,648 @@ rationale.
basic_filebuf&lt;charT,traits&gt;* rdbuf();
const basic_filebuf&lt;charT,traits&gt;* rdbuf() const;
</pre>
<hr>
<a name="367"><h3>367.&nbsp;remove_copy/remove_copy_if and Input Iterators</h3></a><p>
<b>Section:</b>&nbsp;25.2.7 <a href="lib-algorithms.html#lib.alg.remove"> [lib.alg.remove]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Anthony Williams&nbsp; <b>Date:</b>&nbsp;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 &quot;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.&quot; 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.&nbsp;basic_string::replace has two &quot;Throws&quot; paragraphs</h3></a><p>
<b>Section:</b>&nbsp;21.3.5.6 <a href="lib-strings.html#lib.string::replace"> [lib.string::replace]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;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 &quot;Throws&quot; paragraphs (3 and
5).
</p>
<p>
In addition, the second &quot;Throws&quot; paragraph (5) includes specification
(beginning with &quot;Otherwise, the function replaces ...&quot;) that should be
part of the &quot;Effects&quot; paragraph.
</p>
<p><b>Proposed resolution:</b></p>
<hr>
<a name="369"><h3>369.&nbsp;io stream objects and static ctors</h3></a><p>
<b>Section:</b>&nbsp;27.3 <a href="lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Ruslan Abdikeev&nbsp; <b>Date:</b>&nbsp;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>
&quot;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&lt;charT,traits&gt;::Init
is constructed, and in any case before the body of main
begins execution.&quot; (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>
&quot;Constructors and destructors for static objects can access these
[standard iostream] objects to read input from stdin or write output
to stdout or stderr.&quot; (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 &lt;iostream&gt; 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 &lt;iostream&gt;.
</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 &lt;iostream&gt; 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 &lt;some_implementation_defined_name&gt;;
}
}
</pre>
<hr>
<a name="370"><h3>370.&nbsp;Minor error in basic_istream::get</h3></a><p>
<b>Section:</b>&nbsp;27.6.1.3 <a href="lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;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&lt;charT,traits&gt;&amp; get(basic_streambuf&lt;char_type,traits&gt;&amp;
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.&nbsp;Stability of multiset and multimap member functions</h3></a><p>
<b>Section:</b>&nbsp;23.1 <a href="lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Frank Compagner&nbsp; <b>Date:</b>&nbsp;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&lt;int, int&gt; m;
multimap&lt;int, int&gt;::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.&nbsp;Inconsistent description of stdlib exceptions</h3></a><p>
<b>Section:</b>&nbsp;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>, &nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Randy Maddox&nbsp; <b>Date:</b>&nbsp;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 &quot;Any other functions defined in the
C++ Standard Library that do not have an exception-specification may
throw implementation-defined exceptions unless otherwise specified.&quot;
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 &quot;Library implementations are encouraged (but
not required) to report errors by throwing exceptions from (or derived
from) the standard exceptions.&quot;</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 &quot;The class exception defines the
base class for the types of objects thrown as exceptions by the C++
Standard library components ...&quot;.</p>
<p>Is this inconsistent?</p>
<p><b>Proposed resolution:</b></p>
<hr>
<a name="373"><h3>373.&nbsp;Are basic_istream and basic_ostream to use (exceptions()&amp;badbit) != 0 ?</h3></a><p>
<b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Keith Baker&nbsp; <b>Date:</b>&nbsp;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()&amp;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.&nbsp;moneypunct::frac_digits returns int not unsigned</h3></a><p>
<b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;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
&quot;int&quot;. This implies that frac_digits() might return a negative value,
but a negative value is nonsensical. It should return &quot;unsigned&quot;.
</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 &quot;unsigned&quot;.
</p>
<p><b>Proposed resolution:</b></p>
<hr>
<a name="375"><h3>375.&nbsp;basic_ios should be ios_base in 27.7.1.3</h3></a><p>
<b>Section:</b>&nbsp;27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;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 &quot;basic_ios::&quot; which should be
&quot;ios_base::&quot;.
</p>
<p><b>Proposed resolution:</b></p>
<p>
Change all references to &quot;basic_ios&quot; in Table 90, Table 91, and
paragraph 14 to &quot;ios_base&quot;.
</p>
<hr>
<a name="376"><h3>376.&nbsp;basic_streambuf semantics</h3></a><p>
<b>Section:</b>&nbsp;27.7.1.3 <a href="lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;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 &amp; (ios_base::in|ios_base::out)) == ios_base::in
</p>
<p>
(which &amp; (ios_base::in|ios_base::out)) == ios_base::out
</p>
<p>
(which &amp; (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 &amp; 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.&nbsp;basic_string::insert and length_error</h3></a><p>
<b>Section:</b>&nbsp;21.3.5.4 <a href="lib-strings.html#lib.string::insert"> [lib.string::insert]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;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,
&quot;Then throws length_error if size() &gt;= npos - rlen.&quot;
</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.&nbsp;locale immutability and locale::operator=()</h3></a><p>
<b>Section:</b>&nbsp;22.1.1 <a href="lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;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&amp; operator=(const locale&amp; 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 (&quot;de_DE&quot;);
const std::ctype&lt;char&gt; &amp;r0 = std::use_facet&lt;std::ctype&lt;char&gt; &gt;(loc);
loc = std::locale (&quot;en_US&quot;);
const std::ctype&lt;char&gt; &amp;r1 = std::use_facet&lt;std::ctype&lt;char&gt; &gt;(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.&nbsp;nonsensical ctype::do_widen() requirement</h3></a><p>
<b>Section:</b>&nbsp;22.2.1.1.2 <a href="lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;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&lt;charT&gt; 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&lt;char&gt; 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&lt;char&gt; 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.&nbsp;typos in codecvt tables 53 and 54</h3></a><p>
<b>Section:</b>&nbsp;22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;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 &quot;convert
result values,&quot; when surely &quot;do_in/do_out result values&quot; must have
been intended for Table 53 and &quot;do_unshift result values&quot; for Table
54.
</p>
<p>
Table 54, row 3 says that the meaning of partial is &quot;more characters
needed to be supplied to complete termination.&quot; 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 &quot;do_in/do_out result values&quot; and
the title of Table 54 to &quot;do_unshift result values.&quot;
</p>
<p>
Change the text in Table 54, row 3, under the heading Meaning to
&quot;space for more than (to_limit - to) destination elements was
needed to terminate a sequence given the value of state.&quot;
</p>
<hr>
<a name="381"><h3>381.&nbsp;detection of invalid mbstate_t in codecvt</h3></a><p>
<b>Section:</b>&nbsp;22.2.1.5.2 <a href="lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;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&amp; state,
externT* to, externT* to_limit, externT*&amp; to_next) const;
</pre>
<p>
as follows:
</p>
<pre>
Requires: (to &lt;= 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 &quot;unspecified&quot; in the new wording.
</p>
<hr>
<a name="382"><h3>382.&nbsp;codecvt do_in/out result</h3></a><p>
<b>Section:</b>&nbsp;22.2.1.5 <a href="lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a>&nbsp; <b>Status:</b>&nbsp;<a href="lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;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 &quot;\xc0\xff&quot; in UTF-8)?
</li>
<li>
Table 53 says that the function returns codecvt_base::ok
to indicate that the function(s) &quot;completed the conversion.&quot;
Suppose that the source sequence is &quot;\xc0\x80&quot; 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 &quot;not all source characters converted.&quot; 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 &quot;from_type&quot; character, without the symbol from_type
having been defined. Most likely, the word &quot;source&quot; 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>
&quot;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.&quot;
</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 &quot;not all source characters have
been converted&quot; 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>
&quot;A return value of partial, if (from_next != from_end),...&quot;
</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&shy;from)
source elements, and stores no more than (to_limit&shy;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>
libstdc++-v3/docs/html/ext/lwg-defects.html
This source diff could not be displayed because it is too large. You can view the blob instead.
libstdc++-v3/docs/html/faq/index.html
......@@ -70,7 +70,8 @@
<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>
......@@ -498,6 +499,18 @@ which is no longer available, thanks deja...-->
</p>
<hr />
<h2><a name="3_7">Threading is broken on i386</a></h2>
<p>Support for atomic integer operations is/was broken on i386
platforms. The assembly code accidentally used opcodes that are
only available on the i486 and later. So if you configured GCC
to target, for example, i386-linux, but actually used the programs
on an i686, then you would encounter no problems. Only when
actually running the code on a i386 will the problem appear.
</p>
<p>This is fixed in 3.2.2.
</p>
<hr />
<h1><a name="4_0">4.0 Known Bugs and Non-Bugs</a></h1>
<em>Note that this section can get rapdily outdated -- such is the
nature of an open-source project. For the latest information, join
......
libstdc++-v3/docs/html/faq/index.txt
libstdc++ Frequently Asked Questions
The latest version of this document is always available at
[1]http://gcc.gnu.org/onlinedocs/libstdc++/faq/. The main
The latest version of this document is always available at
[1]http://gcc.gnu.org/onlinedocs/libstdc++/faq/. The main
documentation page is at
[2]http://gcc.gnu.org/onlinedocs/libstdc++/documentation.html.
......@@ -34,31 +34,32 @@
4. [24]I can't use 'long long' on Solaris
5. [25]_XOPEN_SOURCE / _GNU_SOURCE / etc is always defined
6. [26]OS X ctype.h is broken! How can I hack it?
4. [27]Known Bugs and Non-Bugs
1. [28]What works already?
2. [29]Bugs in gcc/g++ (not libstdc++-v3)
3. [30]Bugs in the C++ language/lib specification
4. [31]Things in libstdc++ that only look like bugs
o [32]reopening a stream fails
o [33]-Weffc++ complains too much
o [34]"ambiguous overloads" after including an old-style
7. [27]Threading is broken on i386
4. [28]Known Bugs and Non-Bugs
1. [29]What works already?
2. [30]Bugs in gcc/g++ (not libstdc++-v3)
3. [31]Bugs in the C++ language/lib specification
4. [32]Things in libstdc++ that only look like bugs
o [33]reopening a stream fails
o [34]-Weffc++ complains too much
o [35]"ambiguous overloads" after including an old-style
header
o [35]The g++-3 headers are not ours
o [36]compilation errors from streambuf.h
o [37]errors about *Concept and constraints in the STL...
o [38]program crashes when using library code in a
o [36]The g++-3 headers are not ours
o [37]compilation errors from streambuf.h
o [38]errors about *Concept and constraints in the STL...
o [39]program crashes when using library code in a
dynamically-loaded library
5. [39]Aw, that's easy to fix!
5. [40]Miscellaneous
1. [41]string::iterator is not char*; vector<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
......@@ -66,117 +67,117 @@
1.1 What is libstdc++-v3?
The GNU Standard C++ Library v3 is an ongoing project to implement the
ISO 14882 Standard C++ library as described in chapters 17 through 27
ISO 14882 Standard C++ library as described in chapters 17 through 27
and annex D. As the library reaches stable plateaus, it is captured in
a snapshot and released. The latest release is [49]the fourteenth
a snapshot and released. The latest release is [50]the fourteenth
snapshot but newer versions have been included in recent GCC releases.
For those who want to see exactly how far the project has come, or
just want the latest bleeding-edge code, the up-to-date source is
available over anonymous CVS, and can even be browsed over the Web
(see [50]1.4 below).
For those who want to see exactly how far the project has come, or
just want the latest bleeding-edge code, the up-to-date source is
available over anonymous CVS, and can even be browsed over the Web
(see [51]1.4 below).
The older libstdc++-v2 project is no longer maintained; the code has
been completely replaced and rewritten. [51]If you are using V2, then
The older libstdc++-v2 project is no longer maintained; the code has
been completely replaced and rewritten. [52]If you are using V2, then
you need to report bugs to your system vendor, not to the V3 list.
A more formal description of the V3 goals can be found in the official
[52]design document.
[53]design document.
_________________________________________________________________
1.2 Why should I use libstdc++?
The completion of the ISO C++ standardization gave the C++ community a
powerful set of reuseable tools in the form of the C++ Standard
Library. However, all existing C++ implementations are (as the Draft
Standard used to say) "incomplet and incorrekt," and many suffer from
powerful set of reuseable tools in the form of the C++ Standard
Library. However, all existing C++ implementations are (as the Draft
Standard used to say) "incomplet and incorrekt," and many suffer from
limitations of the compilers that use them.
The GNU C/C++/FORTRAN/<pick-a-language> compiler (gcc, g++, etc) is
The GNU C/C++/FORTRAN/<pick-a-language> compiler (gcc, g++, etc) is
widely considered to be one of the leading compilers in the world. Its
development has recently been taken over by the [53]GCC team. All of
the rapid development and near-legendary [54]portability that are the
development has recently been taken over by the [54]GCC team. All of
the rapid development and near-legendary [55]portability that are the
hallmarks of an open-source project are being applied to libstdc++.
That means that all of the Standard classes and functions (such as
string, vector<>, iostreams, and algorithms) will be freely available
and fully compliant. Programmers will no longer need to "roll their
That means that all of the Standard classes and functions (such as
string, vector<>, iostreams, and algorithms) will be freely available
and fully compliant. Programmers will no longer need to "roll their
own" nor be worried about platform-specific incompatibilities.
_________________________________________________________________
1.3 Who's in charge of it?
The libstdc++ project is contributed to by several developers all over
the world, in the same way as GCC or Linux. Benjamin Kosnik, Gabriel
Dos Reis, Phil Edwards, Ulrich Drepper, Loren James Rittle, and Paolo
the world, in the same way as GCC or Linux. Benjamin Kosnik, Gabriel
Dos Reis, Phil Edwards, Ulrich Drepper, Loren James Rittle, and Paolo
Carlini are the lead maintainers of the CVS archive.
Development and discussion is held on the libstdc++ mailing list.
Subscribing to the list, or searching the list archives, is open to
everyone. You can read instructions for doing so on the [55]homepage.
Development and discussion is held on the libstdc++ mailing list.
Subscribing to the list, or searching the list archives, is open to
everyone. You can read instructions for doing so on the [56]homepage.
If you have questions, ideas, code, or are just curious, sign up!
_________________________________________________________________
1.4 How do I get libstdc++?
The fourteenth (and latest) snapshot of libstdc++-v3 is [56]available
The fourteenth (and latest) snapshot of libstdc++-v3 is [57]available
via ftp.
The [57]homepage has instructions for retrieving the latest CVS
The [58]homepage has instructions for retrieving the latest CVS
sources, and for browsing the CVS sources over the web.
The subset commonly known as the Standard Template Library (chapters
23 through 25, mostly) is adapted from the final release of the SGI
The subset commonly known as the Standard Template Library (chapters
23 through 25, mostly) is adapted from the final release of the SGI
STL.
_________________________________________________________________
1.5 When is libstdc++ going to be finished?
Nathan Myers gave the best of all possible answers, responding to a
Nathan Myers gave the best of all possible answers, responding to a
Usenet article asking this question: Sooner, if you help.
_________________________________________________________________
1.6 How do I contribute to the effort?
Here is [58]a page devoted to this topic. Subscribing to the mailing
list (see above, or the homepage) is a very good idea if you have
something to contribute, or if you have spare time and want to help.
Here is [59]a page devoted to this topic. Subscribing to the mailing
list (see above, or the homepage) is a very good idea if you have
something to contribute, or if you have spare time and want to help.
Contributions don't have to be in the form of source code; anybody who
is willing to help write documentation, for example, or has found a
is willing to help write documentation, for example, or has found a
bug in code that we all thought was working, is more than welcome!
_________________________________________________________________
1.7 What happened to libg++? I need that!
The most recent libg++ README states that libg++ is no longer being
actively maintained. It should not be used for new projects, and is
The most recent libg++ README states that libg++ is no longer being
actively maintained. It should not be used for new projects, and is
only being kicked along to support older code.
The libg++ was designed and created when there was no Standard to
provide guidance. Classes like linked lists are now provided for by
list<T> and do not need to be created by genclass. (For that matter,
templates exist now and are well-supported, whereas genclass (mostly)
The libg++ was designed and created when there was no Standard to
provide guidance. Classes like linked lists are now provided for by
list<T> and do not need to be created by genclass. (For that matter,
templates exist now and are well-supported, whereas genclass (mostly)
predates them.)
There are other classes in libg++ that are not specified in the ISO
There are other classes in libg++ that are not specified in the ISO
Standard (e.g., statistical analysis). While there are a lot of really
useful things that are used by a lot of people (e.g., statistics :-),
the Standards Committee couldn't include everything, and so a lot of
useful things that are used by a lot of people (e.g., statistics :-),
the Standards Committee couldn't include everything, and so a lot of
those "obvious" classes didn't get included.
Since libstdc++ is an implementation of the Standard Library, we have
no plans at this time to include non-Standard utilities in the
implementation, however handy they are. (The extensions provided in
the SGI STL aren't maintained by us and don't get a lot of our
attention, because they don't require a lot of our time.) It is
entirely plausable that the "useful stuff" from libg++ might be
extracted into an updated utilities library, but nobody has stated
Since libstdc++ is an implementation of the Standard Library, we have
no plans at this time to include non-Standard utilities in the
implementation, however handy they are. (The extensions provided in
the SGI STL aren't maintained by us and don't get a lot of our
attention, because they don't require a lot of our time.) It is
entirely plausable that the "useful stuff" from libg++ might be
extracted into an updated utilities library, but nobody has stated
such a project yet.
(The [59]Boost site houses free C++ libraries that do varying things,
and happened to be started by members of the Standards Committee.
(The [60]Boost site houses free C++ libraries that do varying things,
and happened to be started by members of the Standards Committee.
Certain "useful stuff" classes will probably migrate there.)
For the bold and/or desperate, the [60]GCC FAQ describes where to find
For the bold and/or desperate, the [61]GCC FAQ describes where to find
the last libg++ source.
_________________________________________________________________
......@@ -184,65 +185,65 @@
If you have read the README and RELEASE-NOTES files, and your question
remains unanswered, then just ask the mailing list. At present, you do
not need to be subscribed to the list to send a message to it. More
information is available on the homepage (including how to browse the
list archives); to send to the list, use [61]libstdc++@gcc.gnu.org.
not need to be subscribed to the list to send a message to it. More
information is available on the homepage (including how to browse the
list archives); to send to the list, use [62]libstdc++@gcc.gnu.org.
If you have a question that you think should be included here, or if
you have a question about a question/answer here, contact [62]Phil
Edwards or [63]Gabriel Dos Reis.
If you have a question that you think should be included here, or if
you have a question about a question/answer here, contact [63]Phil
Edwards or [64]Gabriel Dos Reis.
_________________________________________________________________
1.9 What are the license terms for libstdc++-v3?
See [64]our license description for these and related questions.
See [65]our license description for these and related questions.
_________________________________________________________________
2.0 Installation
2.1 How do I install libstdc++-v3?
Complete instructions are not given here (this is a FAQ, not an
Complete instructions are not given here (this is a FAQ, not an
installation document), but the tools required are few:
* A 3.x release of GCC. Note that building GCC is much easier and
* A 3.x release of GCC. Note that building GCC is much easier and
more automated than building the GCC 2.[78] series was. If you are
using GCC 2.95, you can still build earlier snapshots of
using GCC 2.95, you can still build earlier snapshots of
libstdc++.
* GNU Make is recommended, but should not be required.
* The GNU Autotools are needed if you are messing with the configury
or makefiles.
The file [65]documentation.html provides a good overview of the steps
necessary to build, install, and use the library. Instructions for
configuring the library with new flags such as --enable-threads are
there also, as well as patches and instructions for working with GCC
The file [66]documentation.html provides a good overview of the steps
necessary to build, install, and use the library. Instructions for
configuring the library with new flags such as --enable-threads are
there also, as well as patches and instructions for working with GCC
2.95.
The top-level install.html and [66]RELEASE-NOTES files contain the
exact build and installation instructions. You may wish to browse
those files over CVSweb ahead of time to get a feel for what's
required. RELEASE-NOTES is located in the ".../docs/17_intro/"
The top-level install.html and [67]RELEASE-NOTES files contain the
exact build and installation instructions. You may wish to browse
those files over CVSweb ahead of time to get a feel for what's
required. RELEASE-NOTES is located in the ".../docs/17_intro/"
directory of the distribution.
_________________________________________________________________
2.2 [removed]
This question has become moot and has been removed. The stub is here
This question has become moot and has been removed. The stub is here
to preserve numbering (and hence links/bookmarks).
_________________________________________________________________
2.3 What is this CVS thing that you keep mentioning?
The Concurrent Versions System is one of several revision control
The Concurrent Versions System is one of several revision control
packages. It was selected for GNU projects because it's free (speech),
free (beer), and very high quality. The [67]CVS entry in the GNU
software catalogue has a better description as well as a [68]link to
free (beer), and very high quality. The [68]CVS entry in the GNU
software catalogue has a better description as well as a [69]link to
the makers of CVS.
The "anonymous client checkout" feature of CVS is similar to anonymous
FTP in that it allows anyone to retrieve the latest libstdc++ sources.
After the first of April, American users will have a "/pharmacy"
After the first of April, American users will have a "/pharmacy"
command-line option...
_________________________________________________________________
......@@ -251,61 +252,61 @@
libstdc++-v3 comes with its own testsuite. You do not need to actually
install the library ("make install") to run the testsuite.
To run the testsuite on the library after building it, use "make
check" while in your build directory. To run the testsuite on the
library after building and installing it, use "make check-install"
To run the testsuite on the library after building it, use "make
check" while in your build directory. To run the testsuite on the
library after building and installing it, use "make check-install"
instead.
If you find bugs in the testsuite programs themselves, or if you think
of a new test program that should be added to the suite, please write
of a new test program that should be added to the suite, please write
up your idea and send it to the list!
_________________________________________________________________
2.4 This library is HUGE! And what's libsupc++?
Usually the size of libraries on disk isn't noticeable. When a link
editor (or simply "linker") pulls things from a static archive
library, only the necessary object files are copied into your
executable, not the entire library. Unfortunately, even if you only
need a single function or variable from an object file, the entire
object file is extracted. (There's nothing unique to C++ or
libstdc++-v3 about this; it's just common behavior, given here for
Usually the size of libraries on disk isn't noticeable. When a link
editor (or simply "linker") pulls things from a static archive
library, only the necessary object files are copied into your
executable, not the entire library. Unfortunately, even if you only
need a single function or variable from an object file, the entire
object file is extracted. (There's nothing unique to C++ or
libstdc++-v3 about this; it's just common behavior, given here for
background reasons.)
Some of the object files which make up libstdc++.a are rather large.
Some of the object files which make up libstdc++.a are rather large.
If you create a statically-linked executable with -static, those large
object files are suddenly part of your executable. Historically the
best way around this was to only place a very few functions (often
only a single one) in each source/object file; then extracting a
single function is the same as extracting a single .o file. For
libstdc++-v3 this is only possible to a certain extent; the object
files in question contain template classes and template functions,
pre-instantiated, and splitting those up causes severe maintenance
object files are suddenly part of your executable. Historically the
best way around this was to only place a very few functions (often
only a single one) in each source/object file; then extracting a
single function is the same as extracting a single .o file. For
libstdc++-v3 this is only possible to a certain extent; the object
files in question contain template classes and template functions,
pre-instantiated, and splitting those up causes severe maintenance
headaches.
It's not a bug, and it's not really a problem. Nevertheless, some
It's not a bug, and it's not really a problem. Nevertheless, some
people don't like it, so here are two pseudo-solutions:
If the only functions from libstdc++.a which you need are language
support functions (those listed in [69]clause 18 of the standard,
e.g., new and delete), then try linking against libsupc++.a (usually
specifying -lsupc++ when calling g++ for the final link step will do
If the only functions from libstdc++.a which you need are language
support functions (those listed in [70]clause 18 of the standard,
e.g., new and delete), then try linking against libsupc++.a (usually
specifying -lsupc++ when calling g++ for the final link step will do
it). This library contains only those support routines, one per object
file. But if you are using anything from the rest of the library, such
as IOStreams or vectors, then you'll still need pieces from
as IOStreams or vectors, then you'll still need pieces from
libstdc++.a.
The second method is one we hope to incorporate into the library build
process. Some platforms can place each function and variable into its
own section in a .o file. The GNU linker can then perform garbage
collection on unused sections; this reduces the situation to only
copying needed functions into the executable, as before, but all
process. Some platforms can place each function and variable into its
own section in a .o file. The GNU linker can then perform garbage
collection on unused sections; this reduces the situation to only
copying needed functions into the executable, as before, but all
happens automatically.
Unfortunately the garbage collection in GNU ld is buggy; sections
(corresponding to functions and variables) which are used are
mistakenly removed, leading to horrible crashes when your executable
starts up. For the time being, this feature is not used when building
Unfortunately the garbage collection in GNU ld is buggy; sections
(corresponding to functions and variables) which are used are
mistakenly removed, leading to horrible crashes when your executable
starts up. For the time being, this feature is not used when building
the library.
_________________________________________________________________
......@@ -315,39 +316,39 @@
Probably not. Yet.
Because GCC advances so rapidly, development and testing of libstdc++
is being done almost entirely under that compiler. If you are curious
about whether other, lesser compilers (*grin*) support libstdc++, you
are more than welcome to try. Configuring and building the library
(see above) will still require certain tools, however. Also keep in
Because GCC advances so rapidly, development and testing of libstdc++
is being done almost entirely under that compiler. If you are curious
about whether other, lesser compilers (*grin*) support libstdc++, you
are more than welcome to try. Configuring and building the library
(see above) will still require certain tools, however. Also keep in
mind that building libstdc++ does not imply that your compiler will be
able to use all of the features found in the C++ Standard Library.
Since the goal of ISO Standardization is for all C++ implementations
to be able to share code, the final libstdc++ should, in theory, be
Since the goal of ISO Standardization is for all C++ implementations
to be able to share code, the final libstdc++ should, in theory, be
usable under any ISO-compliant compiler. It will still be targeted and
optimized for GCC/g++, however.
_________________________________________________________________
3.2 [removed]
This question has become moot and has been removed. The stub is here
This question has become moot and has been removed. The stub is here
to preserve numbering (and hence links/bookmarks).
_________________________________________________________________
3.3 [removed]
This question has become moot and has been removed. The stub is here
This question has become moot and has been removed. The stub is here
to preserve numbering (and hence links/bookmarks).
_________________________________________________________________
3.4 I can't use 'long long' on Solaris
By default we try to support the C99 long long type. This requires
By default we try to support the C99 long long type. This requires
that certain functions from your C library be present.
Up through release 3.0.2 the tests performed were too general, and
this feature was disabled when it did not need to be. The most
Up through release 3.0.2 the tests performed were too general, and
this feature was disabled when it did not need to be. The most
commonly reported platform affected was Solaris.
This has been fixed for 3.0.3 and onwards.
......@@ -355,72 +356,84 @@
3.5 _XOPEN_SOURCE / _GNU_SOURCE / etc is always defined
On Solaris, g++ (but not gcc) always defines the preprocessor macro
_XOPEN_SOURCE. On GNU/Linux, the same happens with _GNU_SOURCE. (This
is not an exhaustive list; other macros and other platforms are also
On Solaris, g++ (but not gcc) always defines the preprocessor macro
_XOPEN_SOURCE. On GNU/Linux, the same happens with _GNU_SOURCE. (This
is not an exhaustive list; other macros and other platforms are also
affected.)
These macros are typically used in C library headers, guarding new
versions of functions from their older versions. The C++ standard
library includes the C standard library, but it requires the C90
version, which for backwards-compatability reasons is often not the
These macros are typically used in C library headers, guarding new
versions of functions from their older versions. The C++ standard
library includes the C standard library, but it requires the C90
version, which for backwards-compatability reasons is often not the
default for many vendors.
More to the point, the C++ standard requires behavior which is only
available on certain platforms after certain symbols are defined.
Usually the issue involves I/O-related typedefs. In order to ensure
More to the point, the C++ standard requires behavior which is only
available on certain platforms after certain symbols are defined.
Usually the issue involves I/O-related typedefs. In order to ensure
correctness, the compiler simply predefines those symbols.
Note that it's not enough to #define them only when the library is
being built (during installation). Since we don't have an 'export'
keyword, much of the library exists as headers, which means that the
Note that it's not enough to #define them only when the library is
being built (during installation). Since we don't have an 'export'
keyword, much of the library exists as headers, which means that the
symbols must also be defined as your programs are parsed and compiled.
To see which symbols are defined, look for CPLUSPLUS_CPP_SPEC in the
gcc config headers for your target (and try changing them to see what
happens when building complicated code). You can also run "g++ -E -dM
- < /dev/null" to display a list of predefined macros for any
To see which symbols are defined, look for CPLUSPLUS_CPP_SPEC in the
gcc config headers for your target (and try changing them to see what
happens when building complicated code). You can also run "g++ -E -dM
- < /dev/null" to display a list of predefined macros for any
particular installation.
This has been discussed on the mailing lists [70]quite a bit.
This has been discussed on the mailing lists [71]quite a bit.
This method is something of a wart. We'd like to find a cleaner
This method is something of a wart. We'd like to find a cleaner
solution, but nobody yet has contributed the time.
_________________________________________________________________
3.6 OS X ctype.h is broken! How can I hack it?
This is a long-standing bug in the OS X support. Fortunately, the
patch is quite simple, and well-known. [71]Here's a link to the
This is a long-standing bug in the OS X support. Fortunately, the
patch is quite simple, and well-known. [72]Here's a link to the
solution.
_________________________________________________________________
Threading is broken on i386
Support for atomic integer operations is/was broken on i386 platforms.
The assembly code accidentally used opcodes that are only available on
the i486 and later. So if you configured GCC to target, for example,
i386-linux, but actually used the programs on an i686, then you would
encounter no problems. Only when actually running the code on a i386
will the problem appear.
This is fixed in 3.2.2.
_________________________________________________________________
4.0 Known Bugs and Non-Bugs
Note that this section can get rapdily outdated -- such is the nature
of an open-source project. For the latest information, join the
mailing list or look through recent archives. The RELEASE- NOTES and
Note that this section can get rapdily outdated -- such is the nature
of an open-source project. For the latest information, join the
mailing list or look through recent archives. The RELEASE- NOTES and
BUGS files are generally kept up-to-date.
For 3.0.1, the most common "bug" is an apparently missing "../" in
For 3.0.1, the most common "bug" is an apparently missing "../" in
include/Makefile, resulting in files like gthr.h and gthr-single.h not
being found. Please read [72]the configuration instructions for GCC,
being found. Please read [73]the configuration instructions for GCC,
specifically the part about configuring in a separate build directory,
and how strongly recommended it is. Building in the source directory
is fragile, is rarely tested, and tends to break, as in this case.
and how strongly recommended it is. Building in the source directory
is fragile, is rarely tested, and tends to break, as in this case.
This was fixed for 3.0.2.
For 3.1, the most common "bug" is a parse error when using <fstream>,
ending with a message, "bits/basic_file.h:52: parse error before `{'
token." Please read [73]the installation instructions for GCC,
specifically the part about not installing newer versions on top of
older versions. If you install 3.1 over a 3.0.x release, then the
wrong basic_file.h header will be found (its location changed between
For 3.1, the most common "bug" is a parse error when using <fstream>,
ending with a message, "bits/basic_file.h:52: parse error before `{'
token." Please read [74]the installation instructions for GCC,
specifically the part about not installing newer versions on top of
older versions. If you install 3.1 over a 3.0.x release, then the
wrong basic_file.h header will be found (its location changed between
releases).
Please do not report these as bugs. We know about them. Reporting this
-- or any other problem that's already been fixed -- hinders the
development of GCC, because we have to take time to respond to your
-- or any other problem that's already been fixed -- hinders the
development of GCC, because we have to take time to respond to your
report. Thank you.
4.1 What works already?
......@@ -476,51 +489,51 @@ New:
4.2 Bugs in gcc/g++ (not libstdc++-v3)
This is by no means meant to be complete nor exhaustive, but mentions
some problems that users may encounter when building or using
This is by no means meant to be complete nor exhaustive, but mentions
some problems that users may encounter when building or using
libstdc++. If you are experiencing one of these problems, you can find
more information on the libstdc++ and the GCC mailing lists.
Before reporting a bug, examine the [74]bugs database with the
category set to "libstdc++". The BUGS file in the source tree also
Before reporting a bug, examine the [75]bugs database with the
category set to "libstdc++". The BUGS file in the source tree also
tracks known serious problems.
* Debugging is problematic, due to bugs in line-number generation
* Debugging is problematic, due to bugs in line-number generation
(mostly fixed in the compiler) and gdb lagging behind the compiler
(lack of personnel). We recommend configuring the compiler using
--with-dwarf2 if the DWARF2 debugging format is not already the
default on your platform. Also, [75]changing your GDB settings can
(lack of personnel). We recommend configuring the compiler using
--with-dwarf2 if the DWARF2 debugging format is not already the
default on your platform. Also, [76]changing your GDB settings can
have a profound effect on your C++ debugging experiences. :-)
_________________________________________________________________
4.3 Bugs in the C++ language/lib specification
Yes, unfortunately, there are some. In a [76]message to the list,
Nathan Myers announced that he has started a list of problems in the
ISO C++ Standard itself, especially with regard to the chapters that
concern the library. The list itself is [77]posted on his website.
Developers who are having problems interpreting the Standard may wish
Yes, unfortunately, there are some. In a [77]message to the list,
Nathan Myers announced that he has started a list of problems in the
ISO C++ Standard itself, especially with regard to the chapters that
concern the library. The list itself is [78]posted on his website.
Developers who are having problems interpreting the Standard may wish
to consult his notes.
For those people who are not part of the ISO Library Group (i.e.,
nearly all of us needing to read this page in the first place :-), a
public list of the library defects is occasionally published [78]here.
Some of these have resulted in [79]code changes.
For those people who are not part of the ISO Library Group (i.e.,
nearly all of us needing to read this page in the first place :-), a
public list of the library defects is occasionally published [79]here.
Some of these have resulted in [80]code changes.
_________________________________________________________________
4.4 Things in libstdc++ that only look like bugs
There are things which are not bugs in the compiler (4.2) nor the
language specification (4.3), but aren't really bugs in libstdc++,
There are things which are not bugs in the compiler (4.2) nor the
language specification (4.3), but aren't really bugs in libstdc++,
either. Really! Please do not report these as bugs.
-Weffc++ The biggest of these is the quadzillions of warnings about
the library headers emitted when -Weffc++ is used. Making libstdc++
"-Weffc++-clean" is not a goal of the project, for a few reasons.
Mainly, that option tries to enforce object-oriented programming,
-Weffc++ The biggest of these is the quadzillions of warnings about
the library headers emitted when -Weffc++ is used. Making libstdc++
"-Weffc++-clean" is not a goal of the project, for a few reasons.
Mainly, that option tries to enforce object-oriented programming,
while the Standard Library isn't necessarily trying to be OO.
reopening a stream fails Did I just say that -Weffc++ was our biggest
false-bug report? I lied. (It used to be.) Today it seems to be
reopening a stream fails Did I just say that -Weffc++ was our biggest
false-bug report? I lied. (It used to be.) Today it seems to be
reports that after executing a sequence like
#include <fstream>
...
......@@ -531,43 +544,43 @@ New:
fs.close();
fs.open("a_new_file");
all operations on the re-opened fs will fail, or at least act very
strangely. Yes, they often will, especially if fs reached the EOF
all operations on the re-opened fs will fail, or at least act very
strangely. Yes, they often will, especially if fs reached the EOF
state on the previous file. The reason is that the state flags are not
cleared on a successful call to open(). The standard unfortunately did
not specify behavior in this case, and to everybody's great sorrow,
the [80]proposed LWG resolution (see DR #22) is to leave the flags
unchanged. You must insert a call to fs.clear() between the calls to
close() and open(), and then everything will work like we all expect
not specify behavior in this case, and to everybody's great sorrow,
the [81]proposed LWG resolution (see DR #22) is to leave the flags
unchanged. You must insert a call to fs.clear() between the calls to
close() and open(), and then everything will work like we all expect
it to work.
rel_ops Another is the rel_ops namespace and the template comparison
operator functions contained therein. If they become visible in the
same namespace as other comparison functions (e.g., 'using' them and
the <iterator> header), then you will suddenly be faced with huge
numbers of ambiguity errors. This was discussed on the -v3 list;
Nathan Myers [81]sums things up here. The collisions with
rel_ops Another is the rel_ops namespace and the template comparison
operator functions contained therein. If they become visible in the
same namespace as other comparison functions (e.g., 'using' them and
the <iterator> header), then you will suddenly be faced with huge
numbers of ambiguity errors. This was discussed on the -v3 list;
Nathan Myers [82]sums things up here. The collisions with
vector/string iterator types have been fixed for 3.1.
The g++-3 headers are not ours
If you have found an extremely broken header file which is causing
problems for you, look carefully before submitting a "high" priority
bug report (which you probably shouldn't do anyhow; see the last
paragraph of the page describing [82]the GCC bug database).
If you have found an extremely broken header file which is causing
problems for you, look carefully before submitting a "high" priority
bug report (which you probably shouldn't do anyhow; see the last
paragraph of the page describing [83]the GCC bug database).
If the headers are in ${prefix}/include/g++-3, or if the installed
If the headers are in ${prefix}/include/g++-3, or if the installed
library's name looks like libstdc++-2.10.a or libstdc++-libc6-2.10.so,
then you are using the old libstdc++-v2 library, which is nonstandard
and unmaintained. Do not report problems with -v2 to the -v3 mailing
then you are using the old libstdc++-v2 library, which is nonstandard
and unmaintained. Do not report problems with -v2 to the -v3 mailing
list.
Currently our header files are installed in ${prefix}/include/g++-v3
(see the 'v'?). This may change with the next release of GCC, as it
may be too confusing, but [83]the question has not yet been decided.
Currently our header files are installed in ${prefix}/include/g++-v3
(see the 'v'?). This may change with the next release of GCC, as it
may be too confusing, but [84]the question has not yet been decided.
glibc If you're on a GNU/Linux system and have just upgraded to glibc
2.2, but are still using gcc 2.95.2, then you should have read the
glibc If you're on a GNU/Linux system and have just upgraded to glibc
2.2, but are still using gcc 2.95.2, then you should have read the
glibc FAQ, specifically 2.34:
2.34. When compiling C++ programs, I get a compilation error in streambuf.h.
......@@ -577,23 +590,23 @@ type has changed in glibc 2.2. The patch is at
http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
Note that 2.95.x shipped with the [84]old v2 library which is no
longer maintained. Also note that gcc 2.95.3 fixes this problem, but
Note that 2.95.x shipped with the [85]old v2 library which is no
longer maintained. Also note that gcc 2.95.3 fixes this problem, but
requires a separate patch for libstdc++-v3.
concept checks If you see compilation errors containing messages about
fooConcept and a constraints member function, then most likely you
have violated one of the requirements for types used during
instantiation of template containers and functions. For example,
EqualityComparableConcept appears if your types must be comparable
with == and you have not provided this capability (a typo, or wrong
fooConcept and a constraints member function, then most likely you
have violated one of the requirements for types used during
instantiation of template containers and functions. For example,
EqualityComparableConcept appears if your types must be comparable
with == and you have not provided this capability (a typo, or wrong
visibility, or you just plain forgot, etc).
More information, including how to optionally enable/disable the
checks, is available [85]here.
More information, including how to optionally enable/disable the
checks, is available [86]here.
dlopen/dlsym If you are using the C++ library across
dynamically-loaded objects, make certain that you are passing the
dlopen/dlsym If you are using the C++ library across
dynamically-loaded objects, make certain that you are passing the
correct options when compiling and linking:
// compile the library components
g++ -fPIC -c a.cc
......@@ -610,18 +623,18 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
4.5 Aw, that's easy to fix!
If you have found a bug in the library and you think you have a
working fix, then send it in! The main GCC site has a page on
[86]submitting patches that covers the procedure, but for libstdc++
you should also send the patch to our mailing list in addition to the
GCC patches mailing list. The libstdc++ [87]contributors' page also
If you have found a bug in the library and you think you have a
working fix, then send it in! The main GCC site has a page on
[87]submitting patches that covers the procedure, but for libstdc++
you should also send the patch to our mailing list in addition to the
GCC patches mailing list. The libstdc++ [88]contributors' page also
talks about how to submit patches.
In addition to the description, the patch, and the ChangeLog entry, it
is a Good Thing if you can additionally create a small test program to
test for the presence of the bug that your patch fixes. Bugs have a
way of being reintroduced; if an old bug creeps back in, it will be
caught immediately by the [88]testsuite -- but only if such a test
test for the presence of the bug that your patch fixes. Bugs have a
way of being reintroduced; if an old bug creeps back in, it will be
caught immediately by the [89]testsuite -- but only if such a test
exists.
_________________________________________________________________
......@@ -629,61 +642,61 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
5.1 string::iterator is not char*; vector<T>::iterator is not T*
If you have code that depends on container<T> iterators being
If you have code that depends on container<T> iterators being
implemented as pointer-to-T, your code is broken.
While there are arguments for iterators to be implemented in that
manner, A) they aren't very good ones in the long term, and B) they
While there are arguments for iterators to be implemented in that
manner, A) they aren't very good ones in the long term, and B) they
were never guaranteed by the Standard anyway. The type-safety achieved
by making iterators a real class rather than a typedef for T*
by making iterators a real class rather than a typedef for T*
outweighs nearly all opposing arguments.
Code which does assume that a vector iterator i is a pointer can often
be fixed by changing i in certain expressions to &*i . Future
revisions of the Standard are expected to bless this usage for
be fixed by changing i in certain expressions to &*i . Future
revisions of the Standard are expected to bless this usage for
vector<> (but not for basic_string<>).
_________________________________________________________________
5.2 What's next after libstdc++-v3?
Hopefully, not much. The goal of libstdc++-v3 is to produce a
fully-compliant, fully-portable Standard Library. After that, we're
Hopefully, not much. The goal of libstdc++-v3 is to produce a
fully-compliant, fully-portable Standard Library. After that, we're
mostly done: there won't be any more compliance work to do. However:
1. The ISO Committee will meet periodically to review Defect Reports
in the C++ Standard. Undoubtedly some of these will result in
changes to the Standard, which will be reflected in patches to
libstdc++. Some of that is already happening, see 4.2. Some of
those changes are being predicted by the library maintainers, and
we add code to the library based on what the current proposed
resolution specifies. Those additions are listed in [89]the
1. The ISO Committee will meet periodically to review Defect Reports
in the C++ Standard. Undoubtedly some of these will result in
changes to the Standard, which will be reflected in patches to
libstdc++. Some of that is already happening, see 4.2. Some of
those changes are being predicted by the library maintainers, and
we add code to the library based on what the current proposed
resolution specifies. Those additions are listed in [90]the
extensions page.
2. Performance tuning. Lots of performance tuning. This too is
already underway for post-3.0 releases, starting with memory
expansion in container classes and buffer usage in synchronized
2. Performance tuning. Lots of performance tuning. This too is
already underway for post-3.0 releases, starting with memory
expansion in container classes and buffer usage in synchronized
stream objects.
3. An ABI for libstdc++ is being developed, so that multiple
binary-incompatible copies of the library can be replaced with a
3. An ABI for libstdc++ is being developed, so that multiple
binary-incompatible copies of the library can be replaced with a
single backwards-compatible library, like libgcc_s.so is.
4. The current libstdc++ contains extensions to the Library which
4. The current libstdc++ contains extensions to the Library which
must be explicitly requested by client code (for example, the hash
tables from SGI). Other extensions may be added to libstdc++-v3 if
they seem to be "standard" enough. (For example, the "long long"
type from C99.) Bugfixes and rewrites (to improve or fix thread
they seem to be "standard" enough. (For example, the "long long"
type from C99.) Bugfixes and rewrites (to improve or fix thread
safety, for instance) will of course be a continuing task.
[90]This question about the next libstdc++ prompted some brief but
interesting [91]speculation.
[91]This question about the next libstdc++ prompted some brief but
interesting [92]speculation.
_________________________________________________________________
5.3 What about the STL from SGI?
The [92]STL from SGI, version 3.3, was the most recent merge of the
STL codebase. The code in libstdc++ contains many fixes and changes,
and it is very likely that the SGI code is no longer under active
The [93]STL from SGI, version 3.3, was the most recent merge of the
STL codebase. The code in libstdc++ contains many fixes and changes,
and it is very likely that the SGI code is no longer under active
development. We expect that no future merges will take place.
In particular, string is not from SGI and makes no use of their "rope"
class (which is included as an optional extension), nor is valarray
class (which is included as an optional extension), nor is valarray
and some others. Classes like vector<> are, however.
The FAQ for SGI's STL (one jump off of their main page) is recommended
......@@ -692,34 +705,34 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
5.4 Extensions and Backward Compatibility
Headers in the ext and backward subdirectories should be referred to
Headers in the ext and backward subdirectories should be referred to
by their relative paths:
#include <ext/hash_map>
rather than using -I or other options. This is more portable and
forward-compatible. (The situation is the same as that of other
headers whose directories are not searched directly, e.g.,
rather than using -I or other options. This is more portable and
forward-compatible. (The situation is the same as that of other
headers whose directories are not searched directly, e.g.,
<sys/stat.h>, <X11/Xlib.h>.
Extensions to the library have [93]their own page.
Extensions to the library have [94]their own page.
_________________________________________________________________
5.5 [removed]
This question has become moot and has been removed. The stub is here
This question has become moot and has been removed. The stub is here
to preserve numbering (and hence links/bookmarks).
_________________________________________________________________
5.6 Is libstdc++-v3 thread-safe?
When the system's libc is itself thread-safe, a non-generic
implementation of atomicity.h exists for the architecture, and gcc
itself reports a thread model other than single; libstdc++-v3 strives
to be thread-safe. The user-code must guard against concurrent method
calls which may access any particular library object's state.
When the system's libc is itself thread-safe, a non-generic
implementation of atomicity.h exists for the architecture, and gcc
itself reports a thread model other than single; libstdc++-v3 strives
to be thread-safe. The user-code must guard against concurrent method
calls which may access any particular library object's state.
Typically, the application programmer may infer what object locks must
be held based on the objects referenced in a method call. Without
getting into great detail, here is an example which requires
be held based on the objects referenced in a method call. Without
getting into great detail, here is an example which requires
user-level locks:
library_class_a shared_object_a;
......@@ -733,8 +746,8 @@ a
// Multiple copies of thread_main() are started in independent threads.
Under the assumption that object_a and object_b are never exposed to
another thread, here is an example that should not require any
Under the assumption that object_a and object_b are never exposed to
another thread, here is an example that should not require any
user-level locks:
thread_main () {
library_class_a object_a;
......@@ -745,80 +758,80 @@ a
All library objects are safe to use in a multithreaded program as long
as each thread carefully locks out access by any other thread while it
uses any object visible to another thread. In general, this
requirement includes both read and write access to objects; unless
otherwise documented as safe, do not assume that two threads may
uses any object visible to another thread. In general, this
requirement includes both read and write access to objects; unless
otherwise documented as safe, do not assume that two threads may
access a shared standard library object at the same time.
See chapters [94]17 (library introduction), [95]23 (containers), and
[96]27 (I/O) for more information.
See chapters [95]17 (library introduction), [96]23 (containers), and
[97]27 (I/O) for more information.
_________________________________________________________________
5.7 How do I get a copy of the ISO C++ Standard?
Copies of the full ISO 14882 standard are available on line via the
ISO mirror site for committee members. Non-members, or those who have
not paid for the privilege of sitting on the committee and sustained
their two-meeting commitment for voting rights, may get a copy of the
Copies of the full ISO 14882 standard are available on line via the
ISO mirror site for committee members. Non-members, or those who have
not paid for the privilege of sitting on the committee and sustained
their two-meeting commitment for voting rights, may get a copy of the
standard from their respective national standards organization. In the
USA, this national standards organization is ANSI and their website is
right [97]here. (And if you've already registered with them, clicking
this link will take you to directly to the place where you can [98]buy
right [98]here. (And if you've already registered with them, clicking
this link will take you to directly to the place where you can [99]buy
the standard on-line.
Who is your country's member body? Visit the [99]ISO homepage and find
out!
Who is your country's member body? Visit the [100]ISO homepage and
find out!
_________________________________________________________________
5.8 What's an ABI and why is it so messy?
"ABI" stands for "Application Binary Interface." Conventionally, it
refers to a great mass of details about how arguments are arranged on
"ABI" stands for "Application Binary Interface." Conventionally, it
refers to a great mass of details about how arguments are arranged on
the call stack and/or in registers, and how various types are arranged
and padded in structs. A single CPU design may suffer multiple ABIs
designed by different development tool vendors who made different
choices, or even by the same vendor for different target applications
and padded in structs. A single CPU design may suffer multiple ABIs
designed by different development tool vendors who made different
choices, or even by the same vendor for different target applications
or compiler versions. In ideal circumstances the CPU designer presents
one ABI and all the OSes and compilers use it. In practice every ABI
one ABI and all the OSes and compilers use it. In practice every ABI
omits details that compiler implementers (consciously or accidentally)
must choose for themselves.
That ABI definition suffices for compilers to generate code so a
That ABI definition suffices for compilers to generate code so a
program can interact safely with an OS and its lowest-level libraries.
Users usually want an ABI to encompass more detail, allowing libraries
built with different compilers (or different releases of the same
compiler!) to be linked together. For C++, this includes many more
details than for C, and CPU designers (for good reasons elaborated
below) have not stepped up to publish C++ ABIs. The details include
virtual function implementation, struct inheritance layout, name
built with different compilers (or different releases of the same
compiler!) to be linked together. For C++, this includes many more
details than for C, and CPU designers (for good reasons elaborated
below) have not stepped up to publish C++ ABIs. The details include
virtual function implementation, struct inheritance layout, name
mangling, and exception handling. Such an ABI has been defined for GNU
C++, and is immediately useful for embedded work relying only on a
"free-standing implementation" that doesn't include (much of) the
C++, and is immediately useful for embedded work relying only on a
"free-standing implementation" that doesn't include (much of) the
standard library. It is a good basis for the work to come.
A useful C++ ABI must also incorporate many details of the standard
library implementation. For a C ABI, the layouts of a few structs
(such as FILE, stat, jmpbuf, and the like) and a few macros suffice.
For C++, the details include the complete set of names of functions
and types used, the offsets of class members and virtual functions,
and the actual definitions of all inlines. C++ exposes many more
library details to the caller than C does. It makes defining a
complete ABI a much bigger undertaking, and requires not just
documenting library implementation details, but carefully designing
those details so that future bug fixes and optimizations don't force
A useful C++ ABI must also incorporate many details of the standard
library implementation. For a C ABI, the layouts of a few structs
(such as FILE, stat, jmpbuf, and the like) and a few macros suffice.
For C++, the details include the complete set of names of functions
and types used, the offsets of class members and virtual functions,
and the actual definitions of all inlines. C++ exposes many more
library details to the caller than C does. It makes defining a
complete ABI a much bigger undertaking, and requires not just
documenting library implementation details, but carefully designing
those details so that future bug fixes and optimizations don't force
breaking the ABI.
There are ways to help isolate library implementation details from the
ABI, but they trade off against speed. Library details used in inner
loops (e.g., getchar) must be exposed and frozen for all time, but
many others may reasonably be kept hidden from user code, so they may
ABI, but they trade off against speed. Library details used in inner
loops (e.g., getchar) must be exposed and frozen for all time, but
many others may reasonably be kept hidden from user code, so they may
later be changed. Deciding which, and implementing the decisions, must
happen before you can reasonably document a candidate C++ ABI that
happen before you can reasonably document a candidate C++ ABI that
encompasses the standard library.
_________________________________________________________________
See [100]license.html for copying conditions. Comments and suggestions
are welcome, and may be sent to [101]the libstdc++ mailing list.
See [101]license.html for copying conditions. Comments and suggestions
are welcome, and may be sent to [102]the libstdc++ mailing list.
References
......@@ -848,78 +861,79 @@ References
24. ../faq/index.html#3_4
25. ../faq/index.html#3_5
26. ../faq/index.html#3_6
27. ../faq/index.html#4_0
28. ../faq/index.html#4_1
29. ../faq/index.html#4_2
30. ../faq/index.html#4_3
31. ../faq/index.html#4_4
32. ../faq/index.html#4_4_iostreamclear
33. ../faq/index.html#4_4_Weff
34. ../faq/index.html#4_4_rel_ops
35. ../faq/index.html#4_4_interface
36. ../faq/index.html#4_4_glibc
37. ../faq/index.html#4_4_checks
38. ../faq/index.html#4_4_dlsym
39. ../faq/index.html#4_5
40. ../faq/index.html#5_0
41. ../faq/index.html#5_1
42. ../faq/index.html#5_2
43. ../faq/index.html#5_3
44. ../faq/index.html#5_4
45. ../faq/index.html#5_5
46. ../faq/index.html#5_6
47. ../faq/index.html#5_7
48. ../faq/index.html#5_8
49. http://gcc.gnu.org/libstdc++/index.html#download
50. ../faq/index.html#1_4
51. ../faq/index.html#4_4_interface
52. ../17_intro/DESIGN
53. http://gcc.gnu.org/
54. http://gcc.gnu.org/gcc-3.0/buildstat.html
55. http://gcc.gnu.org/libstdc++/
56. http://gcc.gnu.org/libstdc++/index.html#download
57. http://gcc.gnu.org/libstdc++/
58. ../17_intro/contribute.html
59. http://www.boost.org/
60. http://gcc.gnu.org/fom_serv/cache/33.html
61. mailto:libstdc++@gcc.gnu.org
62. mailto:pme@gcc.gnu.org
63. mailto:gdr@gcc.gnu.org
64. ../17_intro/license.html
65. ../documentation.html
66. ../17_intro/RELEASE-NOTES
67. http://www.gnu.org/software/cvs/cvs.html
68. http://www.cvshome.org/
69. ../18_support/howto.html
70. http://gcc.gnu.org/cgi-bin/htsearch?method=and&format=builtin-long&sort=score&words=_XOPEN_SOURCE+Solaris
71. http://gcc.gnu.org/ml/gcc/2002-03/msg00817.html
72. http://gcc.gnu.org/install/configure.html
73. http://gcc.gnu.org/install/
74. http://gcc.gnu.org/bugs.html
75. http://gcc.gnu.org/ml/libstdc++/2002-02/msg00034.html
76. http://gcc.gnu.org/ml/libstdc++/1998/msg00006.html
77. http://www.cantrip.org/draft-bugs.txt
78. http://anubis.dkuug.dk/jtc1/sc22/wg21/
79. ../faq/index.html#5_2
80. ../ext/howto.html#5
81. http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html
82. http://gcc.gnu.org/gnatswrite.html
83. http://gcc.gnu.org/ml/gcc/2000-10/msg00732.html
84. ../faq/index.html#4_4_interface
85. ../19_diagnostics/howto.html#3
86. http://gcc.gnu.org/contribute.html
87. ../17_intro/contribute.html
88. ../faq/index.html#2_4
89. ../ext/howto.html#5
90. http://gcc.gnu.org/ml/libstdc++/1999/msg00080.html
91. http://gcc.gnu.org/ml/libstdc++/1999/msg00084.html
92. http://www.sgi.com/Technology/STL/
93. ../ext/howto.html
94. ../17_intro/howto.html#3
95. ../23_containers/howto.html#3
96. ../27_io/howto.html#9
97. http://www.ansi.org/
98. http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%2D1998
99. http://www.iso.ch/
100. ../17_intro/license.html
101. mailto:libstdc++@gcc.gnu.org
27. ../faq/index.html#3_7
28. ../faq/index.html#4_0
29. ../faq/index.html#4_1
30. ../faq/index.html#4_2
31. ../faq/index.html#4_3
32. ../faq/index.html#4_4
33. ../faq/index.html#4_4_iostreamclear
34. ../faq/index.html#4_4_Weff
35. ../faq/index.html#4_4_rel_ops
36. ../faq/index.html#4_4_interface
37. ../faq/index.html#4_4_glibc
38. ../faq/index.html#4_4_checks
39. ../faq/index.html#4_4_dlsym
40. ../faq/index.html#4_5
41. ../faq/index.html#5_0
42. ../faq/index.html#5_1
43. ../faq/index.html#5_2
44. ../faq/index.html#5_3
45. ../faq/index.html#5_4
46. ../faq/index.html#5_5
47. ../faq/index.html#5_6
48. ../faq/index.html#5_7
49. ../faq/index.html#5_8
50. http://gcc.gnu.org/libstdc++/index.html#download
51. ../faq/index.html#1_4
52. ../faq/index.html#4_4_interface
53. ../17_intro/DESIGN
54. http://gcc.gnu.org/
55. http://gcc.gnu.org/gcc-3.0/buildstat.html
56. http://gcc.gnu.org/libstdc++/
57. http://gcc.gnu.org/libstdc++/index.html#download
58. http://gcc.gnu.org/libstdc++/
59. ../17_intro/contribute.html
60. http://www.boost.org/
61. http://gcc.gnu.org/fom_serv/cache/33.html
62. mailto:libstdc++@gcc.gnu.org
63. mailto:pme@gcc.gnu.org
64. mailto:gdr@gcc.gnu.org
65. ../17_intro/license.html
66. ../documentation.html
67. ../17_intro/RELEASE-NOTES
68. http://www.gnu.org/software/cvs/cvs.html
69. http://www.cvshome.org/
70. ../18_support/howto.html
71. http://gcc.gnu.org/cgi-bin/htsearch?method=and&format=builtin-long&sort=score&words=_XOPEN_SOURCE+Solaris
72. http://gcc.gnu.org/ml/gcc/2002-03/msg00817.html
73. http://gcc.gnu.org/install/configure.html
74. http://gcc.gnu.org/install/
75. http://gcc.gnu.org/bugs.html
76. http://gcc.gnu.org/ml/libstdc++/2002-02/msg00034.html
77. http://gcc.gnu.org/ml/libstdc++/1998/msg00006.html
78. http://www.cantrip.org/draft-bugs.txt
79. http://anubis.dkuug.dk/jtc1/sc22/wg21/
80. ../faq/index.html#5_2
81. ../ext/howto.html#5
82. http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html
83. http://gcc.gnu.org/gnatswrite.html
84. http://gcc.gnu.org/ml/gcc/2000-10/msg00732.html
85. ../faq/index.html#4_4_interface
86. ../19_diagnostics/howto.html#3
87. http://gcc.gnu.org/contribute.html
88. ../17_intro/contribute.html
89. ../faq/index.html#2_4
90. ../ext/howto.html#5
91. http://gcc.gnu.org/ml/libstdc++/1999/msg00080.html
92. http://gcc.gnu.org/ml/libstdc++/1999/msg00084.html
93. http://www.sgi.com/Technology/STL/
94. ../ext/howto.html
95. ../17_intro/howto.html#3
96. ../23_containers/howto.html#3
97. ../27_io/howto.html#9
98. http://www.ansi.org/
99. http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%2D1998
100. http://www.iso.ch/
101. ../17_intro/license.html
102. mailto:libstdc++@gcc.gnu.org
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment