procyberian/gcc
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Improvements to the libstdc++ FAQ and manual

Browse source 
* doc/xml/faq.xml: Update several old entries. Improve
	cross-references.
	* doc/xml/manual/intro.xml: Add anchors to each DR.
	* doc/html/*: Regenerate.

From-SVN: r250125
This commit is contained in:
Jonathan Wakely 2017-07-11 12:11:33 +01:00 • committed by Jonathan Wakely
parent bee038f145
commit 6a28a7531b
6 changed files with 462 additions and 403 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
libstdc++-v3/ChangeLog
View file

@ -1,3 +1,10 @@
2017-07-11 Jonathan Wakely <jwakely@redhat.com>
* doc/xml/faq.xml: Update several old entries. Improve
cross-references.
* doc/xml/manual/intro.xml: Add anchors to each DR.
* doc/html/*: Regenerate.
2017-07-10 Jonathan Wakely <jwakely@redhat.com>
* testsuite/abi/pr42230.cc: Add header for std::free.

144
libstdc++-v3/doc/html/faq.html
View file

@ -76,7 +76,8 @@
</a></dt><dt>6.9. <a href="faq.html#faq.easy_to_fix">
Aw, that's easy to fix!
</a></dt></dl></dd><dt></dt><dd><dl><dt>7.1. <a href="faq.html#faq.iterator_as_pod">
string::iterator is not char*; vector&lt;T&gt;::iterator is not T*
string::iterator is not char*;
vector&lt;T&gt;::iterator is not T*
</a></dt><dt>7.2. <a href="faq.html#faq.what_is_next">
What's next after libstdc++?
</a></dt><dt>7.3. <a href="faq.html#faq.sgi_stl">
@ -133,10 +134,10 @@
<a class="link" href="https://gcc.gnu.org/buildstat.html" target="_top">portability</a>
that are the hallmarks of an open-source project are applied to libstdc++.
</p><p>
All of the standard classes and functions from C++98/C++03
All of the standard classes and functions from C++98/C++03, C++11 and C++14
(such as <code class="classname">string</code>,
<code class="classname">vector&lt;&gt;</code>, iostreams, algorithms etc.)
are freely available and atempt to be fully compliant.
are freely available and attempt to be fully compliant.
Work is ongoing to complete support for the current revision of the
ISO C++ Standard.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.who"></a><a id="q-who"></a><p><strong>1.3.</strong></p></td><td align="left" valign="top"><p>
@ -431,7 +432,7 @@
C++ compiler.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.solaris_long_long"></a><a id="q-solaris_long_long"></a><p><strong>4.2.</strong></p></td><td align="left" valign="top"><p>
No '<span class="type">long long</span>' type on Solaris?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-solaris_long_long"></a></td><td align="left" valign="top"><p>
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-solaris_long_long"></a></td><td align="left" valign="top"><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>This answer is old and probably no longer be relevant.</p></div><p>
By default we try to support the C99 <span class="type">long long</span> type.
This requires that certain functions from your C library be present.
</p><p>
@ -509,7 +510,7 @@
more recent the C library. (This is also documented in the main
GCC installation instructions.)
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.freebsd_wchar"></a><a id="q-freebsd_wchar"></a><p><strong>4.8.</strong></p></td><td align="left" valign="top"><p>
Can't use wchar_t/wstring on FreeBSD
Can't use <span class="type">wchar_t</span>/<code class="classname">wstring</code> on FreeBSD
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-freebsd_wchar"></a></td><td align="left" valign="top"><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>This answer is old and probably no longer be relevant.</p></div><p>
Older versions of FreeBSD's C library do not have sufficient
support for wide character functions, and as a result the
@ -552,7 +553,8 @@
place), a public list of the library defects is occasionally
published on <a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/" target="_top">the WG21
website</a>.
Many of these issues have resulted in code changes in libstdc++.
Many of these issues have resulted in
<a class="link" href="manual/bugs.html#manual.intro.status.bugs.iso" title="Standard Bugs">code changes in libstdc++</a>.
</p><p>
If you think you've discovered a new bug that is not listed,
please post a message describing your problem to the author of
@ -570,8 +572,8 @@
these lists with terms describing your issue.
</p><p>
Before reporting a bug, please examine the
<a class="link" href="http://gcc.gnu.org/bugs/" target="_top">bugs database</a> with the
category set to <span class="quote">“<span class="quote">g++</span>”</span>.
<a class="link" href="https://gcc.gnu.org/bugs/" target="_top">bugs database</a>, with the
component set to <span class="quote">“<span class="quote">c++</span>”</span>.
</p></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>6.1. <a href="faq.html#faq.stream_reopening_fails">
Reopening a stream fails
</a></dt><dt>6.2. <a href="faq.html#faq.wefcxx_verbose">
@ -594,8 +596,9 @@
Aw, that's easy to fix!
</a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.stream_reopening_fails"></a><a id="q-stream_reopening_fails"></a><p><strong>6.1.</strong></p></td><td align="left" valign="top"><p>
Reopening a stream fails
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-stream_reopening_fails"></a></td><td align="left" valign="top"><p>
One of the most-reported non-bug reports. Executing a sequence like:
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-stream_reopening_fails"></a></td><td align="left" valign="top"><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>This answer is old and probably no longer be relevant.</p></div><p>
Prior to GCC 4.0 this was one of the most-reported non-bug reports.
Executing a sequence like this would fail:
</p><pre class="programlisting">
#include &lt;fstream&gt;
...
@ -606,19 +609,20 @@
fs.close();
fs.open("a_new_file");
</pre><p>
All operations on the re-opened <code class="varname">fs</code> will fail, or at
least act very strangely. Yes, they often will, especially if
<code class="varname">fs</code> reached the EOF state on the previous file. The
reason is that the state flags are <span class="emphasis"><em>not</em></span> cleared
on a successful call to open(). The standard unfortunately did
not specify behavior in this case, and to everybody's great sorrow,
the <a class="link" href="manual/bugs.html" title="Bugs">proposed LWG resolution in
DR #22</a> is to leave the flags unchanged. You must insert a call
to <code class="function">fs.clear()</code> between the calls to close() and open(),
and then everything will work like we all expect it to work.
<span class="emphasis"><em>Update:</em></span> for GCC 4.0 we implemented the resolution
of <a class="link" href="manual/bugs.html" title="Bugs">DR #409</a> and open()
now calls <code class="function">clear()</code> on success!
All operations on the re-opened <code class="varname">fs</code> would fail, or at
least act very strangely, especially if <code class="varname">fs</code> reached the
EOF state on the previous file.
The original C++98 standard did not specify behavior in this case, and
the <a class="link" href="manual/bugs.html#manual.bugs.dr22">resolution of DR #22</a> was to
leave the state flags unchanged on a successful call to
<code class="function">open()</code>.
You had to insert a call to <code class="function">fs.clear()</code> between the
calls to <code class="function">close()</code> and <code class="function">open()</code>,
and then everything will work as expected.
<span class="emphasis"><em>Update:</em></span> For GCC 4.0 we implemented the resolution
of <a class="link" href="manual/bugs.html#manual.bugs.dr409">DR #409</a> and
<code class="function">open()</code>
now calls <code class="function">clear()</code> on success.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.wefcxx_verbose"></a><a id="q-wefcxx_verbose"></a><p><strong>6.2.</strong></p></td><td align="left" valign="top"><p>
-Weffc++ complains too much
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-wefcxx_verbose"></a></td><td align="left" valign="top"><p>
@ -626,7 +630,9 @@
libstdc++ <code class="option">-Weffc++</code>-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.
necessarily trying to be OO. The option also enforces outdated guidelines
from old editions of the books, and the advice isn't all relevant to
modern C++ (especially C++11 and later).
</p><p>
We do, however, try to have libstdc++ sources as clean as possible. If
you see some simple changes that pacify <code class="option">-Weffc++</code>
@ -637,15 +643,16 @@
Another problem is the <code class="literal">rel_ops</code> namespace and the template
comparison operator functions contained therein. If they become
visible in the same namespace as other comparison functions
(e.g., <span class="quote">“<span class="quote">using</span>”</span> them and the &lt;iterator&gt; header),
(e.g., <span class="quote">“<span class="quote">using</span>”</span> them and the
<code class="filename">&lt;iterator&gt;</code> header),
then you will suddenly be faced with huge numbers of ambiguity
errors. This was discussed on the -v3 list; Nathan Myers
errors. This was discussed on the mailing list; Nathan Myers
<a class="link" href="http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html" target="_top">sums
things up here</a>. The collisions with vector/string iterator
types have been fixed for 3.1.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.v2_headers"></a><a id="q-v2_headers"></a><p><strong>6.4.</strong></p></td><td align="left" valign="top"><p>
The g++-3 headers are <span class="emphasis"><em>not ours</em></span>
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-v2_headers"></a></td><td align="left" valign="top"><p>
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-v2_headers"></a></td><td align="left" valign="top"><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>This answer is old and probably no longer be relevant.</p></div><p>
If you are using headers in
<code class="filename">${prefix}/include/g++-3</code>, or if
the installed library's name looks like
@ -698,11 +705,12 @@
    <span class="command"><strong>g++ -fPIC -rdynamic -o foo ... -L. -lfoo -ldl</strong></span><br />
    </p></div></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.memory_leaks"></a><a id="q-memory_leaks"></a><p><strong>6.7.</strong></p></td><td align="left" valign="top"><p>
<span class="quote">“<span class="quote">Memory leaks</span>”</span> in containers
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-memory_leaks"></a></td><td align="left" valign="top"><p>
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-memory_leaks"></a></td><td align="left" valign="top"><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>This answer is old and probably no longer be relevant.</p></div><p>
A few people have reported that the standard containers appear
to leak memory when tested with memory checkers such as
<a class="link" href="http://valgrind.org/" target="_top"><span class="command"><strong>valgrind</strong></span></a>.
Under some configurations the library's allocators keep free memory in a
Under some (non-default) configurations the library's allocators keep
free memory in a
pool for later reuse, rather than returning it to the OS. Although
this memory is always reachable by the library and is never
lost, memory debugging tools can report it as a leak. If you
@ -710,7 +718,7 @@
<a class="link" href="manual/debug.html#debug.memory" title="Memory Leak Hunting">Tips for memory leak hunting</a>
first.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.list_size_on"></a><a id="q-list_size_on"></a><p><strong>6.8.</strong></p></td><td align="left" valign="top"><p>
list::size() is O(n)!
<code class="code">list::size()</code> is O(n)!
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-list_size_on"></a></td><td align="left" valign="top"><p>
See
the <a class="link" href="manual/containers.html" title="Chapter 9.  Containers">Containers</a>
@ -734,7 +742,8 @@
creeps back in, it will be caught immediately by the testsuite -
but only if such a test exists.
</p></td></tr><tr class="toc"><td align="left" valign="top" colspan="2"><dl><dt>7.1. <a href="faq.html#faq.iterator_as_pod">
string::iterator is not char*; vector&lt;T&gt;::iterator is not T*
string::iterator is not char*;
vector&lt;T&gt;::iterator is not T*
</a></dt><dt>7.2. <a href="faq.html#faq.what_is_next">
What's next after libstdc++?
</a></dt><dt>7.3. <a href="faq.html#faq.sgi_stl">
@ -749,7 +758,8 @@
</a></dt><dt>7.8. <a href="faq.html#faq.size_equals_capacity">
How do I make std::vector&lt;T&gt;::capacity() == std::vector&lt;T&gt;::size?
</a></dt></dl></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.iterator_as_pod"></a><a id="faq.iterator_as_pod_q"></a><p><strong>7.1.</strong></p></td><td align="left" valign="top"><p>
string::iterator is not char*; vector&lt;T&gt;::iterator is not T*
<code class="classname">string::iterator</code> is not <code class="code">char*</code>;
<code class="classname">vector&lt;T&gt;::iterator</code> is not <code class="code">T*</code>
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="faq.iterator_as_pod_a"></a></td><td align="left" valign="top"><p>
If you have code that depends on container&lt;T&gt; iterators
being implemented as pointer-to-T, your code is broken. It's
@ -762,38 +772,38 @@
than a typedef for <span class="type">T*</span> outweighs nearly all opposing
arguments.
</p><p>
Code which does assume that a vector iterator <code class="varname">i</code>
Code which does assume that a vector/string iterator <code class="varname">i</code>
is a pointer can often be fixed by changing <code class="varname">i</code> in
certain expressions to <code class="varname">&amp;*i</code>. Future revisions
of the Standard are expected to bless this usage for
vector&lt;&gt; (but not for basic_string&lt;&gt;).
certain expressions to <code class="varname">&amp;*i</code>.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.what_is_next"></a><a id="q-what_is_next"></a><p><strong>7.2.</strong></p></td><td align="left" valign="top"><p>
What's next after libstdc++?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-what_is_next"></a></td><td align="left" valign="top"><p>
Hopefully, not much. The goal of libstdc++ is to produce a
fully-compliant, fully-portable Standard Library. After that,
we're mostly done: there won't <span class="emphasis"><em>be</em></span> any
more compliance work to do.
</p><p>
There is an effort underway to add significant extensions to
the standard library specification. The latest version of
this effort is described in
<a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf" target="_top">
The C++ Library Technical Report 1</a>.
The goal of libstdc++ is to produce a
fully-compliant, fully-portable Standard Library.
While the C++ Standard continues to evolve the libstdc++ will
continue to track it.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.sgi_stl"></a><a id="q-sgi_stl"></a><p><strong>7.3.</strong></p></td><td align="left" valign="top"><p>
What about the STL from SGI?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-sgi_stl"></a></td><td align="left" valign="top"><p>
The <a class="link" href="http://www.sgi.com/tech/stl/" target="_top">STL from SGI</a>,
version 3.3, was the final merge of the STL codebase. The
code in libstdc++ contains many fixes and changes, and
the SGI code is no longer under active
development. We expect that no future merges will take place.
The STL (Standard Template Library) was the inspiration for large chunks
of the C++ Standard Library, but the terms are not interchangeable and
they don't mean the same thing. The C++ Standard Library includes lots of
things that didn't come from the STL, and some of them aren't even
templates, such as <code class="classname">std::locale</code> and
<code class="classname">std::thread</code>.
</p><p>
Libstdc++-v3 incorporates a lot of code from
<a class="link" href="http://www.sgi.com/tech/stl/" target="_top">the SGI STL</a>
(the final merge was from
<a class="link" href="http://www.sgi.com/tech/stl/whats_new.html" target="_top">release 3.3</a>).
The code in libstdc++ contains many fixes and changes compared to the
original SGI code.
</p><p>
In particular, <code class="classname">string</code> is not from SGI and makes no
use of their "rope" class (which is included as an
optional extension), nor is <code class="classname">valarray</code> and some others.
Classes like <code class="classname">vector&lt;&gt;</code> are, but have been
extensively modified.
use of their "rope" class (although that is included as an optional
extension), neither is <code class="classname">valarray</code> nor some others.
Classes like <code class="classname">vector&lt;&gt;</code> were from SGI, but have
been extensively modified.
</p><p>
More information on the evolution of libstdc++ can be found at the
<a class="link" href="manual/api.html" title="API Evolution and Deprecation History">API
@ -812,13 +822,17 @@
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-tr1_support"></a></td><td align="left" valign="top"><p>
Yes.
</p><p>
The C++ Standard Library Technical Report adds many new features to
the library. The latest version of this effort is described in
The C++ Standard Library
<a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf" target="_top">
Technical Report 1</a>.
Technical Report 1</a> added many new features to the library.
</p><p>
The implementation status of TR1 in libstdc++ can be tracked <a class="link" href="manual/status.html#status.iso.tr1" title="C++ TR1">on the TR1 status
page</a>.
The implementation status of TR1 in libstdc++ can be tracked
<a class="link" href="manual/status.html#status.iso.tr1" title="C++ TR1">on the TR1 status page</a>.
</p><p>
New code should probably not use TR1, because almost everything in it has
been added to the main C++ Standard Library (usually with significant
improvements).
The TR1 implementation in libstdc++ is no longer actively maintained.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.get_iso_cxx"></a><a id="q-get_iso_cxx"></a><p><strong>7.6.</strong></p></td><td align="left" valign="top"><p>How do I get a copy of the ISO C++ Standard?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-get_iso_cxx"></a></td><td align="left" valign="top"><p>
Please refer to the <a class="link" href="manual/appendix_contributing.html" title="Appendix A.  Contributing">Contributing</a>
@ -878,10 +892,14 @@
the decisions, must happen before you can reasonably document a
candidate C++ ABI that encompasses the standard library.
</p></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.size_equals_capacity"></a><a id="q-size_equals_capacity"></a><p><strong>7.8.</strong></p></td><td align="left" valign="top"><p>
How do I make std::vector&lt;T&gt;::capacity() == std::vector&lt;T&gt;::size?
How do I make <code class="code">std::vector&lt;T&gt;::capacity() == std::vector&lt;T&gt;::size</code>?
</p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-size_equals_capacity"></a></td><td align="left" valign="top"><p>
The standard idiom for deallocating a <code class="classname">vector&lt;T&gt;</code>'s
unused memory is to create a temporary copy of the vector and swap their
Since C++11 just call the <code class="function">shrink_to_fit()</code> member
function.
</p><p>
Before C++11, the standard idiom for deallocating a
<code class="classname">vector&lt;T&gt;</code>'s
unused memory was to create a temporary copy of the vector and swap their
contents, e.g. for <code class="classname">vector&lt;T&gt; v</code>
</p><div class="literallayout"><p><br />
     std::vector&lt;T&gt;(v).swap(v);<br />

282
libstdc++-v3/doc/html/manual/bugs.html
View file

@ -1,8 +1,8 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Bugs</title><meta name="generator" content="DocBook XSL-NS Stylesheets V1.78.1" /><meta name="keywords" content="ISO C++, library" /><meta name="keywords" content="ISO C++, runtime, library" /><link rel="home" href="../index.html" title="The GNU C++ Library" /><link rel="up" href="status.html" title="Chapter 1. Status" /><link rel="prev" href="license.html" title="License" /><link rel="next" href="setup.html" title="Chapter 2. Setup" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Bugs</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="license.html">Prev</a> </td><th width="60%" align="center">Chapter 1. Status</th><td width="20%" align="right"> <a accesskey="n" href="setup.html">Next</a></td></tr></table><hr /></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.intro.status.bugs"></a>Bugs</h2></div></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.status.bugs.impl"></a>Implementation Bugs</h3></div></div></div><p>
Information on known bugs, details on efforts to fix them, and
fixed bugs are all available as part of the <a class="link" href="http://gcc.gnu.org/bugs/" target="_top">GCC bug tracking system</a>,
with the category set to <code class="literal">libstdc++</code>.
fixed bugs are all available as part of the <a class="link" href="https://gcc.gnu.org/bugs/" target="_top">GCC bug tracking system</a>,
under the component <span class="quote">“<span class="quote">libstdc++</span>”</span>.
</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="manual.intro.status.bugs.iso"></a>Standard Bugs</h3></div></div></div><p>
Everybody's got issues. Even the C++ Standard Library.
</p><p>
@ -12,219 +12,221 @@
a consensus on proposed solutions, we often incorporate the solution.
</p><p>
Here are the issues which have resulted in code changes to the library.
The links are to the specific defect reports from a <span class="emphasis"><em>partial
copy</em></span> of the Issues List. You can read the full version online
The links are to the full version of the Issues List.
You can read the full version online
at the <a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/" target="_top">ISO C++
Committee homepage</a>.
</p><p>
If a DR is not listed here, we may simply not have gotten to
it yet; feel free to submit a patch. Search the include/bits
and src directories for appearances of
it yet; feel free to submit a patch. Search the
<code class="filename">include</code> and
<code class="filename">src</code>
directories for appearances of
<code class="constant">_GLIBCXX_RESOLVE_LIB_DEFECTS</code> for examples
of style. Note that we usually do not make changes to the
code until an issue has reached <a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR" target="_top">DR</a> status.
</p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#5" target="_top">5</a>:
</p><div class="variablelist"><dl class="variablelist"><dt><a id="manual.bugs.dr5"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#5" target="_top">5</a>:
<span class="emphasis"><em>string::compare specification questionable</em></span>
</span></dt><dd><p>This should be two overloaded functions rather than a single function.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17" target="_top">17</a>:
</p></dd><dt><a id="manual.bugs.dr17"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17" target="_top">17</a>:
<span class="emphasis"><em>Bad bool parsing</em></span>
</span></dt><dd><p>Apparently extracting Boolean values was messed up...
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#19" target="_top">19</a>:
</p></dd><dt><a id="manual.bugs.dr19"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#19" target="_top">19</a>:
<span class="emphasis"><em>"Noconv" definition too vague</em></span>
</span></dt><dd><p>If <code class="code">codecvt::do_in</code> returns <code class="code">noconv</code> there are
no changes to the values in <code class="code">[to, to_limit)</code>.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#22" target="_top">22</a>:
</p></dd><dt><a id="manual.bugs.dr22"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#22" target="_top">22</a>:
<span class="emphasis"><em>Member open vs flags</em></span>
</span></dt><dd><p>Re-opening a file stream does <span class="emphasis"><em>not</em></span> clear the state flags.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#23" target="_top">23</a>:
</p></dd><dt><a id="manual.bugs.dr23"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#23" target="_top">23</a>:
<span class="emphasis"><em>Num_get overflow result</em></span>
</span></dt><dd><p>Implement the proposed resolution.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#25" target="_top">25</a>:
</p></dd><dt><a id="manual.bugs.dr25"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#25" target="_top">25</a>:
<span class="emphasis"><em>String operator&lt;&lt; uses width() value wrong</em></span>
</span></dt><dd><p>Padding issues.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#48" target="_top">48</a>:
</p></dd><dt><a id="manual.bugs.dr48"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#48" target="_top">48</a>:
<span class="emphasis"><em>Use of non-existent exception constructor</em></span>
</span></dt><dd><p>An instance of <code class="code">ios_base::failure</code> is constructed instead.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49" target="_top">49</a>:
</p></dd><dt><a id="manual.bugs.dr49"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49" target="_top">49</a>:
<span class="emphasis"><em>Underspecification of ios_base::sync_with_stdio</em></span>
</span></dt><dd><p>The return type is the <span class="emphasis"><em>previous</em></span> state of synchronization.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#50" target="_top">50</a>:
</p></dd><dt><a id="manual.bugs.dr50"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#50" target="_top">50</a>:
<span class="emphasis"><em>Copy constructor and assignment operator of ios_base</em></span>
</span></dt><dd><p>These members functions are declared <code class="code">private</code> and are
thus inaccessible. Specifying the correct semantics of
"copying stream state" was deemed too complicated.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60" target="_top">60</a>:
</p></dd><dt><a id="manual.bugs.dr60"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60" target="_top">60</a>:
<span class="emphasis"><em>What is a formatted input function?</em></span>
</span></dt><dd><p>This DR made many widespread changes to <code class="code">basic_istream</code>
and <code class="code">basic_ostream</code> all of which have been implemented.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#63" target="_top">63</a>:
</p></dd><dt><a id="manual.bugs.dr63"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#63" target="_top">63</a>:
<span class="emphasis"><em>Exception-handling policy for unformatted output</em></span>
</span></dt><dd><p>Make the policy consistent with that of formatted input, unformatted
input, and formatted output.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#68" target="_top">68</a>:
</p></dd><dt><a id="manual.bugs.dr68"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#68" target="_top">68</a>:
<span class="emphasis"><em>Extractors for char* should store null at end</em></span>
</span></dt><dd><p>And they do now. An editing glitch in the last item in the list of
[27.6.1.2.3]/7.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#74" target="_top">74</a>:
</p></dd><dt><a id="manual.bugs.dr74"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#74" target="_top">74</a>:
<span class="emphasis"><em>Garbled text for codecvt::do_max_length</em></span>
</span></dt><dd><p>The text of the standard was gibberish. Typos gone rampant.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#75" target="_top">75</a>:
</p></dd><dt><a id="manual.bugs.dr75"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#75" target="_top">75</a>:
<span class="emphasis"><em>Contradiction in codecvt::length's argument types</em></span>
</span></dt><dd><p>Change the first parameter to <code class="code">stateT&amp;</code> and implement
the new effects paragraph.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83" target="_top">83</a>:
</p></dd><dt><a id="manual.bugs.dr83"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83" target="_top">83</a>:
<span class="emphasis"><em>string::npos vs. string::max_size()</em></span>
</span></dt><dd><p>Safety checks on the size of the string should test against
<code class="code">max_size()</code> rather than <code class="code">npos</code>.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#90" target="_top">90</a>:
</p></dd><dt><a id="manual.bugs.dr90"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#90" target="_top">90</a>:
<span class="emphasis"><em>Incorrect description of operator&gt;&gt; for strings</em></span>
</span></dt><dd><p>The effect contain <code class="code">isspace(c,getloc())</code> which must be
replaced by <code class="code">isspace(c,is.getloc())</code>.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91" target="_top">91</a>:
</p></dd><dt><a id="manual.bugs.dr91"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91" target="_top">91</a>:
<span class="emphasis"><em>Description of operator&gt;&gt; and getline() for string&lt;&gt;
might cause endless loop</em></span>
</span></dt><dd><p>They behave as a formatted input function and as an unformatted
input function, respectively (except that <code class="code">getline</code> is
not required to set <code class="code">gcount</code>).
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103" target="_top">103</a>:
</p></dd><dt><a id="manual.bugs.dr103"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103" target="_top">103</a>:
<span class="emphasis"><em>set::iterator is required to be modifiable, but this allows
modification of keys.</em></span>
</span></dt><dd><p>For associative containers where the value type is the same as
the key type, both <code class="code">iterator</code> and <code class="code">const_iterator
</code> are constant iterators.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109" target="_top">109</a>:
</p></dd><dt><a id="manual.bugs.dr109"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109" target="_top">109</a>:
<span class="emphasis"><em>Missing binders for non-const sequence elements</em></span>
</span></dt><dd><p>The <code class="code">binder1st</code> and <code class="code">binder2nd</code> didn't have an
<code class="code">operator()</code> taking a non-const parameter.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110" target="_top">110</a>:
</p></dd><dt><a id="manual.bugs.dr110"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110" target="_top">110</a>:
<span class="emphasis"><em>istreambuf_iterator::equal not const</em></span>
</span></dt><dd><p>This was not a const member function. Note that the DR says to
replace the function with a const one; we have instead provided an
overloaded version with identical contents.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#117" target="_top">117</a>:
</p></dd><dt><a id="manual.bugs.dr117"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#117" target="_top">117</a>:
<span class="emphasis"><em>basic_ostream uses nonexistent num_put member functions</em></span>
</span></dt><dd><p><code class="code">num_put::put()</code> was overloaded on the wrong types.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#118" target="_top">118</a>:
</p></dd><dt><a id="manual.bugs.dr118"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#118" target="_top">118</a>:
<span class="emphasis"><em>basic_istream uses nonexistent num_get member functions</em></span>
</span></dt><dd><p>Same as 117, but for <code class="code">num_get::get()</code>.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129" target="_top">129</a>:
</p></dd><dt><a id="manual.bugs.dr129"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129" target="_top">129</a>:
<span class="emphasis"><em>Need error indication from seekp() and seekg()</em></span>
</span></dt><dd><p>These functions set <code class="code">failbit</code> on error now.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130" target="_top">130</a>:
</p></dd><dt><a id="manual.bugs.dr130"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130" target="_top">130</a>:
<span class="emphasis"><em>Return type of container::erase(iterator) differs for associative containers</em></span>
</span></dt><dd><p>Make member <code class="code">erase</code> return iterator for <code class="code">set</code>, <code class="code">multiset</code>, <code class="code">map</code>, <code class="code">multimap</code>.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136" target="_top">136</a>:
</p></dd><dt><a id="manual.bugs.dr136"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136" target="_top">136</a>:
<span class="emphasis"><em>seekp, seekg setting wrong streams?</em></span>
</span></dt><dd><p><code class="code">seekp</code> should only set the output stream, and
<code class="code">seekg</code> should only set the input stream.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#167" target="_top">167</a>:
</p></dd><dt><a id="manual.bugs.dr167"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#167" target="_top">167</a>:
<span class="emphasis"><em>Improper use of traits_type::length()</em></span>
</span></dt><dd><p><code class="code">op&lt;&lt;</code> with a <code class="code">const char*</code> was
calculating an incorrect number of characters to write.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#169" target="_top">169</a>:
</p></dd><dt><a id="manual.bugs.dr169"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#169" target="_top">169</a>:
<span class="emphasis"><em>Bad efficiency of overflow() mandated</em></span>
</span></dt><dd><p>Grow efficiently the internal array object.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#171" target="_top">171</a>:
</p></dd><dt><a id="manual.bugs.dr171"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#171" target="_top">171</a>:
<span class="emphasis"><em>Strange seekpos() semantics due to joint position</em></span>
</span></dt><dd><p>Quite complex to summarize...
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#181" target="_top">181</a>:
</p></dd><dt><a id="manual.bugs.dr181"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#181" target="_top">181</a>:
<span class="emphasis"><em>make_pair() unintended behavior</em></span>
</span></dt><dd><p>This function used to take its arguments as reference-to-const, now
it copies them (pass by value).
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195" target="_top">195</a>:
</p></dd><dt><a id="manual.bugs.dr195"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195" target="_top">195</a>:
<span class="emphasis"><em>Should basic_istream::sentry's constructor ever set eofbit?</em></span>
</span></dt><dd><p>Yes, it can, specifically if EOF is reached while skipping whitespace.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211" target="_top">211</a>:
</p></dd><dt><a id="manual.bugs.dr211"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211" target="_top">211</a>:
<span class="emphasis"><em>operator&gt;&gt;(istream&amp;, string&amp;) doesn't set failbit</em></span>
</span></dt><dd><p>If nothing is extracted into the string, <code class="code">op&gt;&gt;</code> now
sets <code class="code">failbit</code> (which can cause an exception, etc., etc.).
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#214" target="_top">214</a>:
</p></dd><dt><a id="manual.bugs.dr214"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#214" target="_top">214</a>:
<span class="emphasis"><em>set::find() missing const overload</em></span>
</span></dt><dd><p>Both <code class="code">set</code> and <code class="code">multiset</code> were missing
overloaded find, lower_bound, upper_bound, and equal_range functions
for const instances.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#231" target="_top">231</a>:
</p></dd><dt><a id="manual.bugs.dr231"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#231" target="_top">231</a>:
<span class="emphasis"><em>Precision in iostream?</em></span>
</span></dt><dd><p>For conversion from a floating-point type, <code class="code">str.precision()</code>
is specified in the conversion specification.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233" target="_top">233</a>:
</p></dd><dt><a id="manual.bugs.dr233"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#233" target="_top">233</a>:
<span class="emphasis"><em>Insertion hints in associative containers</em></span>
</span></dt><dd><p>Implement N1780, first check before then check after, insert as close
to hint as possible.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235" target="_top">235</a>:
</p></dd><dt><a id="manual.bugs.dr235"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235" target="_top">235</a>:
<span class="emphasis"><em>No specification of default ctor for reverse_iterator</em></span>
</span></dt><dd><p>The declaration of <code class="code">reverse_iterator</code> lists a default constructor.
However, no specification is given what this constructor should do.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241" target="_top">241</a>:
</p></dd><dt><a id="manual.bugs.dr241"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241" target="_top">241</a>:
<span class="emphasis"><em>Does unique_copy() require CopyConstructible and Assignable?</em></span>
</span></dt><dd><p>Add a helper for forward_iterator/output_iterator, fix the existing
one for input_iterator/output_iterator to not rely on Assignability.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#243" target="_top">243</a>:
</p></dd><dt><a id="manual.bugs.dr243"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#243" target="_top">243</a>:
<span class="emphasis"><em>get and getline when sentry reports failure</em></span>
</span></dt><dd><p>Store a null character only if the character array has a non-zero size.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#251" target="_top">251</a>:
</p></dd><dt><a id="manual.bugs.dr251"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#251" target="_top">251</a>:
<span class="emphasis"><em>basic_stringbuf missing allocator_type</em></span>
</span></dt><dd><p>This nested typedef was originally not specified.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253" target="_top">253</a>:
</p></dd><dt><a id="manual.bugs.dr253"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253" target="_top">253</a>:
<span class="emphasis"><em>valarray helper functions are almost entirely useless</em></span>
</span></dt><dd><p>Make the copy constructor and copy-assignment operator declarations
public in gslice_array, indirect_array, mask_array, slice_array; provide
definitions.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265" target="_top">265</a>:
</p></dd><dt><a id="manual.bugs.dr265"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265" target="_top">265</a>:
<span class="emphasis"><em>std::pair::pair() effects overly restrictive</em></span>
</span></dt><dd><p>The default ctor would build its members from copies of temporaries;
now it simply uses their respective default ctors.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#266" target="_top">266</a>:
</p></dd><dt><a id="manual.bugs.dr266"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#266" target="_top">266</a>:
<span class="emphasis"><em>bad_exception::~bad_exception() missing Effects clause</em></span>
</span></dt><dd><p>The <code class="code">bad_</code>* classes no longer have destructors (they
are trivial), since no description of them was ever given.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271" target="_top">271</a>:
</p></dd><dt><a id="manual.bugs.dr271"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271" target="_top">271</a>:
<span class="emphasis"><em>basic_iostream missing typedefs</em></span>
</span></dt><dd><p>The typedefs it inherits from its base classes can't be used, since
(for example) <code class="code">basic_iostream&lt;T&gt;::traits_type</code> is ambiguous.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#275" target="_top">275</a>:
</p></dd><dt><a id="manual.bugs.dr275"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#275" target="_top">275</a>:
<span class="emphasis"><em>Wrong type in num_get::get() overloads</em></span>
</span></dt><dd><p>Similar to 118.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280" target="_top">280</a>:
</p></dd><dt><a id="manual.bugs.dr280"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280" target="_top">280</a>:
<span class="emphasis"><em>Comparison of reverse_iterator to const reverse_iterator</em></span>
</span></dt><dd><p>Add global functions with two template parameters.
(NB: not added for now a templated assignment operator)
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#292" target="_top">292</a>:
</p></dd><dt><a id="manual.bugs.dr292"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#292" target="_top">292</a>:
<span class="emphasis"><em>Effects of a.copyfmt (a)</em></span>
</span></dt><dd><p>If <code class="code">(this == &amp;rhs)</code> do nothing.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#300" target="_top">300</a>:
</p></dd><dt><a id="manual.bugs.dr300"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#300" target="_top">300</a>:
<span class="emphasis"><em>List::merge() specification incomplete</em></span>
</span></dt><dd><p>If <code class="code">(this == &amp;x)</code> do nothing.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303" target="_top">303</a>:
</p></dd><dt><a id="manual.bugs.dr303"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303" target="_top">303</a>:
<span class="emphasis"><em>Bitset input operator underspecified</em></span>
</span></dt><dd><p>Basically, compare the input character to
<code class="code">is.widen(0)</code> and <code class="code">is.widen(1)</code>.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#305" target="_top">305</a>:
</p></dd><dt><a id="manual.bugs.dr305"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#305" target="_top">305</a>:
<span class="emphasis"><em>Default behavior of codecvt&lt;wchar_t, char,
mbstate_t&gt;::length()</em></span>
</span></dt><dd><p>Do not specify what <code class="code">codecvt&lt;wchar_t, char,
mbstate_t&gt;::do_length</code> must return.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#328" target="_top">328</a>:
</p></dd><dt><a id="manual.bugs.dr328"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#328" target="_top">328</a>:
<span class="emphasis"><em>Bad sprintf format modifier in
money_put&lt;&gt;::do_put()</em></span>
</span></dt><dd><p>Change the format string to "%.0Lf".
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#365" target="_top">365</a>:
</p></dd><dt><a id="manual.bugs.dr365"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#365" target="_top">365</a>:
<span class="emphasis"><em>Lack of const-qualification in clause 27</em></span>
</span></dt><dd><p>Add const overloads of <code class="code">is_open</code>.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387" target="_top">387</a>:
</p></dd><dt><a id="manual.bugs.dr387"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387" target="_top">387</a>:
<span class="emphasis"><em>std::complex over-encapsulated</em></span>
</span></dt><dd><p>Add the <code class="code">real(T)</code> and <code class="code">imag(T)</code>
members; in C++11 mode, also adjust the existing
<code class="code">real()</code> and <code class="code">imag()</code> members and
free functions.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389" target="_top">389</a>:
</p></dd><dt><a id="manual.bugs.dr389"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389" target="_top">389</a>:
<span class="emphasis"><em>Const overload of valarray::operator[] returns
by value</em></span>
</span></dt><dd><p>Change it to return a <code class="code">const T&amp;</code>.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#396" target="_top">396</a>:
</p></dd><dt><a id="manual.bugs.dr396"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#396" target="_top">396</a>:
<span class="emphasis"><em>what are characters zero and one</em></span>
</span></dt><dd><p>Implement the proposed resolution.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402" target="_top">402</a>:
</p></dd><dt><a id="manual.bugs.dr402"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402" target="_top">402</a>:
<span class="emphasis"><em>Wrong new expression in [some_]allocator::construct</em></span>
</span></dt><dd><p>Replace "new" with "::new".
</p></dd><dt><span class="term"><a class="link" href="../ext/lwg-closed.html#408" target="_top">408</a>:
@ -232,39 +234,39 @@
Is vector&lt;reverse_iterator&lt;char*&gt; &gt; forbidden?
</em></span>
</span></dt><dd><p>Tweak the debug-mode checks in _Safe_iterator.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#409" target="_top">409</a>:
</p></dd><dt><a id="manual.bugs.dr409"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#409" target="_top">409</a>:
<span class="emphasis"><em>Closing an fstream should clear the error state</em></span>
</span></dt><dd><p>Have <code class="code">open</code> clear the error flags.
</p></dd><dt><span class="term"><a class="link" href="../ext/lwg-closed.html#431" target="_top">431</a>:
<span class="emphasis"><em>Swapping containers with unequal allocators</em></span>
</span></dt><dd><p>Implement Option 3, as per N1599.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#432" target="_top">432</a>:
</p></dd><dt><a id="manual.bugs.dr432"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#432" target="_top">432</a>:
<span class="emphasis"><em>stringbuf::overflow() makes only one write position
available</em></span>
</span></dt><dd><p>Implement the resolution, beyond DR 169.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#434" target="_top">434</a>:
</p></dd><dt><a id="manual.bugs.dr434"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#434" target="_top">434</a>:
<span class="emphasis"><em>bitset::to_string() hard to use</em></span>
</span></dt><dd><p>Add three overloads, taking fewer template arguments.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#438" target="_top">438</a>:
</p></dd><dt><a id="manual.bugs.dr438"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#438" target="_top">438</a>:
<span class="emphasis"><em>Ambiguity in the "do the right thing" clause</em></span>
</span></dt><dd><p>Implement the resolution, basically cast less.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#445" target="_top">445</a>:
</p></dd><dt><a id="manual.bugs.dr445"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#445" target="_top">445</a>:
<span class="emphasis"><em>iterator_traits::reference unspecified for some iterator categories</em></span>
</span></dt><dd><p>Change <code class="code">istreambuf_iterator::reference</code> in C++11 mode.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#453" target="_top">453</a>:
</p></dd><dt><a id="manual.bugs.dr453"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#453" target="_top">453</a>:
<span class="emphasis"><em>basic_stringbuf::seekoff need not always fail for an empty stream</em></span>
</span></dt><dd><p>Don't fail if the next pointer is null and newoff is zero.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#455" target="_top">455</a>:
</p></dd><dt><a id="manual.bugs.dr455"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#455" target="_top">455</a>:
<span class="emphasis"><em>cerr::tie() and wcerr::tie() are overspecified</em></span>
</span></dt><dd><p>Initialize cerr tied to cout and wcerr tied to wcout.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464" target="_top">464</a>:
</p></dd><dt><a id="manual.bugs.dr464"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464" target="_top">464</a>:
<span class="emphasis"><em>Suggestion for new member functions in standard containers</em></span>
</span></dt><dd><p>Add <code class="code">data()</code> to <code class="code">std::vector</code> and
<code class="code">at(const key_type&amp;)</code> to <code class="code">std::map</code>.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#467" target="_top">467</a>:
</p></dd><dt><a id="manual.bugs.dr467"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#467" target="_top">467</a>:
<span class="emphasis"><em>char_traits::lt(), compare(), and memcmp()</em></span>
</span></dt><dd><p>Change <code class="code">lt</code>.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508" target="_top">508</a>:
</p></dd><dt><a id="manual.bugs.dr508"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508" target="_top">508</a>:
<span class="emphasis"><em>Bad parameters for ranlux64_base_01</em></span>
</span></dt><dd><p>Fix the parameters.
</p></dd><dt><span class="term"><a class="link" href="../ext/lwg-closed.html#512" target="_top">512</a>:
@ -274,246 +276,246 @@
<span class="emphasis"><em>Is it undefined if a function in the standard changes in
parameters?</em></span>
</span></dt><dd><p>Use &amp;value.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538" target="_top">538</a>:
</p></dd><dt><a id="manual.bugs.dr538"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538" target="_top">538</a>:
<span class="emphasis"><em>241 again: Does unique_copy() require CopyConstructible
and Assignable?</em></span>
</span></dt><dd><p>In case of input_iterator/output_iterator rely on Assignability of
input_iterator' value_type.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#539" target="_top">539</a>:
</p></dd><dt><a id="manual.bugs.dr539"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#539" target="_top">539</a>:
<span class="emphasis"><em>partial_sum and adjacent_difference should mention
requirements</em></span>
</span></dt><dd><p>We were almost doing the right thing, just use std::move
in adjacent_difference.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541" target="_top">541</a>:
</p></dd><dt><a id="manual.bugs.dr541"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541" target="_top">541</a>:
<span class="emphasis"><em>shared_ptr template assignment and void</em></span>
</span></dt><dd><p>Add an auto_ptr&lt;void&gt; specialization.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543" target="_top">543</a>:
</p></dd><dt><a id="manual.bugs.dr543"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#543" target="_top">543</a>:
<span class="emphasis"><em>valarray slice default constructor</em></span>
</span></dt><dd><p>Follow the straightforward proposed resolution.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550" target="_top">550</a>:
</p></dd><dt><a id="manual.bugs.dr550"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#550" target="_top">550</a>:
<span class="emphasis"><em>What should the return type of pow(float,int) be?</em></span>
</span></dt><dd><p>In C++11 mode, remove the pow(float,int), etc., signatures.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586" target="_top">586</a>:
</p></dd><dt><a id="manual.bugs.dr586"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#586" target="_top">586</a>:
<span class="emphasis"><em>string inserter not a formatted function</em></span>
</span></dt><dd><p>Change it to be a formatted output function (i.e. catch exceptions).
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596" target="_top">596</a>:
</p></dd><dt><a id="manual.bugs.dr596"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#596" target="_top">596</a>:
<span class="emphasis"><em>27.8.1.3 Table 112 omits "a+" and "a+b" modes</em></span>
</span></dt><dd><p>Add the missing modes to fopen_mode.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#630" target="_top">630</a>:
</p></dd><dt><a id="manual.bugs.dr630"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#630" target="_top">630</a>:
<span class="emphasis"><em>arrays of valarray</em></span>
</span></dt><dd><p>Implement the simple resolution.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660" target="_top">660</a>:
</p></dd><dt><a id="manual.bugs.dr660"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#660" target="_top">660</a>:
<span class="emphasis"><em>Missing bitwise operations</em></span>
</span></dt><dd><p>Add the missing operations.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#691" target="_top">691</a>:
</p></dd><dt><a id="manual.bugs.dr691"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#691" target="_top">691</a>:
<span class="emphasis"><em>const_local_iterator cbegin, cend missing from TR1</em></span>
</span></dt><dd><p>In C++11 mode add cbegin(size_type) and cend(size_type)
to the unordered containers.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693" target="_top">693</a>:
</p></dd><dt><a id="manual.bugs.dr693"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#693" target="_top">693</a>:
<span class="emphasis"><em>std::bitset::all() missing</em></span>
</span></dt><dd><p>Add it, consistently with the discussion.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695" target="_top">695</a>:
</p></dd><dt><a id="manual.bugs.dr695"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#695" target="_top">695</a>:
<span class="emphasis"><em>ctype&lt;char&gt;::classic_table() not accessible</em></span>
</span></dt><dd><p>Make the member functions table and classic_table public.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#696" target="_top">696</a>:
</p></dd><dt><a id="manual.bugs.dr696"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#696" target="_top">696</a>:
<span class="emphasis"><em>istream::operator&gt;&gt;(int&amp;) broken</em></span>
</span></dt><dd><p>Implement the straightforward resolution.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761" target="_top">761</a>:
</p></dd><dt><a id="manual.bugs.dr761"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#761" target="_top">761</a>:
<span class="emphasis"><em>unordered_map needs an at() member function</em></span>
</span></dt><dd><p>In C++11 mode, add at() and at() const.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775" target="_top">775</a>:
</p></dd><dt><a id="manual.bugs.dr775"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#775" target="_top">775</a>:
<span class="emphasis"><em>Tuple indexing should be unsigned?</em></span>
</span></dt><dd><p>Implement the int -&gt; size_t replacements.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776" target="_top">776</a>:
</p></dd><dt><a id="manual.bugs.dr776"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#776" target="_top">776</a>:
<span class="emphasis"><em>Undescribed assign function of std::array</em></span>
</span></dt><dd><p>In C++11 mode, remove assign, add fill.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781" target="_top">781</a>:
</p></dd><dt><a id="manual.bugs.dr781"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#781" target="_top">781</a>:
<span class="emphasis"><em>std::complex should add missing C99 functions</em></span>
</span></dt><dd><p>In C++11 mode, add std::proj.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809" target="_top">809</a>:
</p></dd><dt><a id="manual.bugs.dr809"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#809" target="_top">809</a>:
<span class="emphasis"><em>std::swap should be overloaded for array types</em></span>
</span></dt><dd><p>Add the overload.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853" target="_top">853</a>:
</p></dd><dt><a id="manual.bugs.dr853"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#853" target="_top">853</a>:
<span class="emphasis"><em>to_string needs updating with zero and one</em></span>
</span></dt><dd><p>Update / add the signatures.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#865" target="_top">865</a>:
</p></dd><dt><a id="manual.bugs.dr865"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#865" target="_top">865</a>:
<span class="emphasis"><em>More algorithms that throw away information</em></span>
</span></dt><dd><p>The traditional HP / SGI return type and value is blessed
by the resolution of the DR.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1339" target="_top">1339</a>:
</p></dd><dt><a id="manual.bugs.dr1339"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1339" target="_top">1339</a>:
<span class="emphasis"><em>uninitialized_fill_n should return the end of its range</em></span>
</span></dt><dd><p>Return the end of the filled range.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2021" target="_top">2021</a>:
</p></dd><dt><a id="manual.bugs.dr2021"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2021" target="_top">2021</a>:
<span class="emphasis"><em>Further incorrect uses of <code class="code">result_of</code></em></span>
</span></dt><dd><p>Correctly decay types in signature of <code class="code">std::async</code>.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2049" target="_top">2049</a>:
</p></dd><dt><a id="manual.bugs.dr2049"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2049" target="_top">2049</a>:
<span class="emphasis"><em><code class="code">is_destructible</code> underspecified</em></span>
</span></dt><dd><p>Handle non-object types.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2056" target="_top">2056</a>:
</p></dd><dt><a id="manual.bugs.dr2056"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2056" target="_top">2056</a>:
<span class="emphasis"><em>future_errc enums start with value 0 (invalid value for broken_promise)</em></span>
</span></dt><dd><p>Reorder enumerators.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2059" target="_top">2059</a>:
</p></dd><dt><a id="manual.bugs.dr2059"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2059" target="_top">2059</a>:
<span class="emphasis"><em>C++0x ambiguity problem with map::erase</em></span>
</span></dt><dd><p>Add additional overloads.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2062" target="_top">2062</a>:
</p></dd><dt><a id="manual.bugs.dr2062"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2062" target="_top">2062</a>:
<span class="emphasis"><em>2062. Effect contradictions w/o no-throw guarantee of <code class="code">std::function</code> swaps</em></span>
</span></dt><dd><p>Add <code class="code">noexcept</code> to swap functions.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2063" target="_top">2063</a>:
</p></dd><dt><a id="manual.bugs.dr2063"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2063" target="_top">2063</a>:
<span class="emphasis"><em>Contradictory requirements for string move assignment</em></span>
</span></dt><dd><p>Respect propagation trait for move assignment.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2064" target="_top">2064</a>:
</p></dd><dt><a id="manual.bugs.dr2064"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2064" target="_top">2064</a>:
<span class="emphasis"><em>More noexcept issues in basic_string</em></span>
</span></dt><dd><p>Add noexcept to the comparison operators.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2067" target="_top">2067</a>:
</p></dd><dt><a id="manual.bugs.dr2067"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2067" target="_top">2067</a>:
<span class="emphasis"><em>packaged_task should have deleted copy c'tor with const parameter</em></span>
</span></dt><dd><p>Fix signatures.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2101" target="_top">2101</a>:
</p></dd><dt><a id="manual.bugs.dr2101"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2101" target="_top">2101</a>:
<span class="emphasis"><em>Some transformation types can produce impossible types</em></span>
</span></dt><dd><p>Use the referenceable type concept.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2106" target="_top">2106</a>:
</p></dd><dt><a id="manual.bugs.dr2106"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2106" target="_top">2106</a>:
<span class="emphasis"><em>move_iterator wrapping iterators returning prvalues</em></span>
</span></dt><dd><p>Change the <code class="code">reference</code> type.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2108" target="_top">2108</a>:
</p></dd><dt><a id="manual.bugs.dr2108"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2108" target="_top">2108</a>:
<span class="emphasis"><em>No way to identify allocator types that always compare equal</em></span>
</span></dt><dd><p>Define and use <code class="code">is_always_equal</code> even for C++11.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2118" target="_top">2118</a>:
</p></dd><dt><a id="manual.bugs.dr2118"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2118" target="_top">2118</a>:
<span class="emphasis"><em><code class="code">unique_ptr</code> for array does not support cv qualification conversion of actual argument</em></span>
</span></dt><dd><p>Adjust constraints to allow safe conversions.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2127" target="_top">2127</a>:
</p></dd><dt><a id="manual.bugs.dr2127"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2127" target="_top">2127</a>:
<span class="emphasis"><em>Move-construction with <code class="code">raw_storage_iterator</code></em></span>
</span></dt><dd><p>Add assignment operator taking an rvalue.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2132" target="_top">2132</a>:
</p></dd><dt><a id="manual.bugs.dr2132"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2132" target="_top">2132</a>:
<span class="emphasis"><em><code class="code">std::function</code> ambiguity</em></span>
</span></dt><dd><p>Constrain the constructor to only accept callable types.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2141" target="_top">2141</a>:
</p></dd><dt><a id="manual.bugs.dr2141"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2141" target="_top">2141</a>:
<span class="emphasis"><em><code class="code">common_type</code> trait produces reference types</em></span>
</span></dt><dd><p>Use <code class="code">decay</code> for the result type.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2144" target="_top">2144</a>:
</p></dd><dt><a id="manual.bugs.dr2144"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2144" target="_top">2144</a>:
<span class="emphasis"><em>Missing <code class="code">noexcept</code> specification in <code class="code">type_index</code></em></span>
</span></dt><dd><p>Add <code class="code">noexcept</code>
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2145" target="_top">2145</a>:
</p></dd><dt><a id="manual.bugs.dr2145"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2145" target="_top">2145</a>:
<span class="emphasis"><em><code class="code">error_category</code> default constructor</em></span>
</span></dt><dd><p>Declare a public constexpr constructor.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2162" target="_top">2162</a>:
</p></dd><dt><a id="manual.bugs.dr2162"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2162" target="_top">2162</a>:
<span class="emphasis"><em><code class="code">allocator_traits::max_size</code> missing <code class="code">noexcept</code></em></span>
</span></dt><dd><p>Add <code class="code">noexcept</code>.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2187" target="_top">2187</a>:
</p></dd><dt><a id="manual.bugs.dr2187"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2187" target="_top">2187</a>:
<span class="emphasis"><em><code class="code">vector&lt;bool&gt;</code> is missing <code class="code">emplace</code> and <code class="code">emplace_back</code> member functions</em></span>
</span></dt><dd><p>Add <code class="code">emplace</code> and <code class="code">emplace_back</code> member functions.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2192" target="_top">2192</a>:
</p></dd><dt><a id="manual.bugs.dr2192"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2192" target="_top">2192</a>:
<span class="emphasis"><em>Validity and return type of <code class="code">std::abs(0u)</code> is unclear</em></span>
</span></dt><dd><p>Move all declarations to a common header and remove the
generic <code class="code">abs</code> which accepted unsigned arguments.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2196" target="_top">2196</a>:
</p></dd><dt><a id="manual.bugs.dr2196"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2196" target="_top">2196</a>:
<span class="emphasis"><em>Specification of <code class="code">is_*[copy/move]_[constructible/assignable]</code> unclear for non-referencable types</em></span>
</span></dt><dd><p>Use the referenceable type concept.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2212" target="_top">2212</a>:
</p></dd><dt><a id="manual.bugs.dr2212"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2212" target="_top">2212</a>:
<span class="emphasis"><em><code class="code">tuple_size</code> for <code class="code">const pair</code> request <code class="code">&lt;tuple&gt;</code> header</em></span>
</span></dt><dd><p>The <code class="code">tuple_size</code> and <code class="code">tuple_element</code>
partial specializations are defined in <code class="code">&lt;utility&gt;</code> which
is included by <code class="code">&lt;array&gt;</code>.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2296" target="_top">2296</a>:
</p></dd><dt><a id="manual.bugs.dr2296"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2296" target="_top">2296</a>:
<span class="emphasis"><em><code class="code">std::addressof</code> should be constexpr</em></span>
</span></dt><dd><p>Use <code class="code">__builtin_addressof</code> and add
<code class="code">constexpr</code> to <code class="code">addressof</code> for C++17 and later.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2313" target="_top">2313</a>:
</p></dd><dt><a id="manual.bugs.dr2313"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2313" target="_top">2313</a>:
<span class="emphasis"><em><code class="code">tuple_size</code> should always derive from <code class="code">integral_constant&lt;size_t, N&gt;</code></em></span>
</span></dt><dd><p>Update definitions of the partial specializations for const and volatile types.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2328" target="_top">2328</a>:
</p></dd><dt><a id="manual.bugs.dr2328"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2328" target="_top">2328</a>:
<span class="emphasis"><em>Rvalue stream extraction should use perfect forwarding</em></span>
</span></dt><dd><p>Use perfect forwarding for right operand.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2329" target="_top">2329</a>:
</p></dd><dt><a id="manual.bugs.dr2329"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2329" target="_top">2329</a>:
<span class="emphasis"><em><code class="code">regex_match()/regex_search()</code> with <code class="code">match_results</code> should forbid temporary strings</em></span>
</span></dt><dd><p>Add deleted overloads for rvalue strings.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2332" target="_top">2332</a>:
</p></dd><dt><a id="manual.bugs.dr2332"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2332" target="_top">2332</a>:
<span class="emphasis"><em><code class="code">regex_iterator/regex_token_iterator</code> should forbid temporary regexes</em></span>
</span></dt><dd><p>Add deleted constructors.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2399" target="_top">2399</a>:
</p></dd><dt><a id="manual.bugs.dr2399"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2399" target="_top">2399</a>:
<span class="emphasis"><em><code class="code">shared_ptr</code>'s constructor from <code class="code">unique_ptr</code> should be constrained</em></span>
</span></dt><dd><p>Constrain the constructor to require convertibility.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2400" target="_top">2400</a>:
</p></dd><dt><a id="manual.bugs.dr2400"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2400" target="_top">2400</a>:
<span class="emphasis"><em><code class="code">shared_ptr</code>'s <code class="code">get_deleter()</code> should use <code class="code">addressof()</code></em></span>
</span></dt><dd><p>Use <code class="code">addressof</code>.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2401" target="_top">2401</a>:
</p></dd><dt><a id="manual.bugs.dr2401"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2401" target="_top">2401</a>:
<span class="emphasis"><em><code class="code">std::function</code> needs more <code class="code">noexcept</code></em></span>
</span></dt><dd><p>Add <code class="code">noexcept</code> to the assignment and comparisons.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2407" target="_top">2407</a>:
</p></dd><dt><a id="manual.bugs.dr2407"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2407" target="_top">2407</a>:
<span class="emphasis"><em><code class="code">packaged_task(allocator_arg_t, const Allocator&amp;, F&amp;&amp;)</code>
should neither be constrained nor <code class="code">explicit</code>
</em></span>
</span></dt><dd><p>Remove <code class="code">explicit</code> from the constructor.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2415" target="_top">2415</a>:
</p></dd><dt><a id="manual.bugs.dr2415"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2415" target="_top">2415</a>:
<span class="emphasis"><em>Inconsistency between <code class="code">unique_ptr</code> and <code class="code">shared_ptr</code></em></span>
</span></dt><dd><p>Create empty an <code class="code">shared_ptr</code> from an empty
<code class="code">unique_ptr</code>.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2418" target="_top">2418</a>:
</p></dd><dt><a id="manual.bugs.dr2418"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2418" target="_top">2418</a>:
<span class="emphasis"><em><code class="code">apply</code> does not work with member pointers</em></span>
</span></dt><dd><p>Use <code class="code">mem_fn</code> for member pointers.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2440" target="_top">2440</a>:
</p></dd><dt><a id="manual.bugs.dr2440"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2440" target="_top">2440</a>:
<span class="emphasis"><em><code class="code">seed_seq::size()</code> should be <code class="code">noexcept</code></em></span>
</span></dt><dd><p>Add <code class="code">noexcept</code>.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2441" target="_top">2441</a>:
</p></dd><dt><a id="manual.bugs.dr2441"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2441" target="_top">2441</a>:
<span class="emphasis"><em>Exact-width atomic typedefs should be provided</em></span>
</span></dt><dd><p>Define the typedefs.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2442" target="_top">2442</a>:
</p></dd><dt><a id="manual.bugs.dr2442"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2442" target="_top">2442</a>:
<span class="emphasis"><em><code class="code">call_once()</code> shouldn't <code class="code">DECAY_COPY()</code></em></span>
</span></dt><dd><p>Remove indirection through call wrapper that made copies
of arguments and forward arguments straight to <code class="code">std::invoke</code>.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2454" target="_top">2454</a>:
</p></dd><dt><a id="manual.bugs.dr2454"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2454" target="_top">2454</a>:
<span class="emphasis"><em>Add <code class="code">raw_storage_iterator::base()</code> member
</em></span>
</span></dt><dd><p>Add the <code class="code">base()</code> member function.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2455" target="_top">2455</a>:
</p></dd><dt><a id="manual.bugs.dr2455"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2455" target="_top">2455</a>:
<span class="emphasis"><em>Allocator default construction should be allowed to throw
</em></span>
</span></dt><dd><p>Make <code class="code">noexcept</code> specifications conditional.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2458" target="_top">2458</a>:
</p></dd><dt><a id="manual.bugs.dr2458"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2458" target="_top">2458</a>:
<span class="emphasis"><em>N3778 and new library deallocation signatures
</em></span>
</span></dt><dd><p>Remove unused overloads.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2459" target="_top">2459</a>:
</p></dd><dt><a id="manual.bugs.dr2459"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2459" target="_top">2459</a>:
<span class="emphasis"><em><code class="code">std::polar</code> should require a non-negative rho
</em></span>
</span></dt><dd><p>Add debug mode assertion.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2466" target="_top">2466</a>:
</p></dd><dt><a id="manual.bugs.dr2466"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2466" target="_top">2466</a>:
<span class="emphasis"><em><code class="code">allocator_traits::max_size()</code> default behavior is incorrect
</em></span>
</span></dt><dd><p>Divide by the object type.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2484" target="_top">2484</a>:
</p></dd><dt><a id="manual.bugs.dr2484"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2484" target="_top">2484</a>:
<span class="emphasis"><em><code class="code">rethrow_if_nested()</code> is doubly unimplementable
</em></span>
</span></dt><dd><p>Avoid using <code class="code">dynamic_cast</code> when it would be
ill-formed.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2583" target="_top">2583</a>:
</p></dd><dt><a id="manual.bugs.dr2583"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2583" target="_top">2583</a>:
<span class="emphasis"><em>There is no way to supply an allocator for <code class="code">basic_string(str, pos)</code>
</em></span>
</span></dt><dd><p>Add new constructor
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2684" target="_top">2684</a>:
</p></dd><dt><a id="manual.bugs.dr2684"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2684" target="_top">2684</a>:
<span class="emphasis"><em><code class="code">priority_queue</code> lacking comparator typedef
</em></span>
</span></dt><dd><p>Define the <code class="code">value_compare</code> typedef.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2770" target="_top">2770</a>:
</p></dd><dt><a id="manual.bugs.dr2770"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2770" target="_top">2770</a>:
<span class="emphasis"><em><code class="code">tuple_size&lt;const T&gt;</code> specialization is not
SFINAE compatible and breaks decomposition declarations
</em></span>
</span></dt><dd><p>Safely detect <code class="code">tuple_size&lt;T&gt;::value</code> and
only use it if valid.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2781" target="_top">2781</a>:
</p></dd><dt><a id="manual.bugs.dr2781"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2781" target="_top">2781</a>:
<span class="emphasis"><em>Contradictory requirements for <code class="code">std::function</code>
and <code class="code">std::reference_wrapper</code>
</em></span>
</span></dt><dd><p>Remove special handling for <code class="code">reference_wrapper</code>
arguments and store them directly as the target object.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2802" target="_top">2802</a>:
</p></dd><dt><a id="manual.bugs.dr2802"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2802" target="_top">2802</a>:
<span class="emphasis"><em>Add noexcept to several <code class="code">shared_ptr</code> related
functions
</em></span>
</span></dt><dd><p>Add noexcept.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2873" target="_top">2873</a>:
</p></dd><dt><a id="manual.bugs.dr2873"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2873" target="_top">2873</a>:
<span class="emphasis"><em><code class="code">shared_ptr</code> constructor requirements for a deleter
</em></span>
</span></dt><dd><p>Use rvalues for deleters.
</p></dd><dt><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2942" target="_top">2942</a>:
</p></dd><dt><a id="manual.bugs.dr2942"></a><span class="term"><a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2942" target="_top">2942</a>:
<span class="emphasis"><em>LWG 2873's resolution missed
<code class="code">weak_ptr::owner_before</code>
</em></span>

4
libstdc++-v3/doc/html/manual/test.html
View file

@ -327,13 +327,13 @@ cat 27_io/objects/char/3_xin.in | a.out</pre></dd><dt><span class="term"><code c
For example, to run the tests with
<code class="option">-O1 -D_GLIBCXX_ASSERTIONS</code>
you could use:
</p><pre class="programlisting"> make RUNTESTFLAGS=--target_board=unix/-O1/-D_GLIBCXX_ASSERTIONS</pre><p>
</p><pre class="programlisting"> make check RUNTESTFLAGS=--target_board=unix/-O1/-D_GLIBCXX_ASSERTIONS</pre><p>
</p><p>
The <code class="option">--target_board</code> option can also be used to run the
tests multiple times in different variations. For example, to run the
entire testsuite three times using <code class="option">-O3</code> but with
different <code class="option">-std</code> options:
</p><pre class="programlisting"> make 'RUNTESTFLAGS=--target_board=unix/-O3\"{-std=gnu++98,-std=gnu++11,-std=gnu++14}\"'</pre><p>
</p><pre class="programlisting"> make check 'RUNTESTFLAGS=--target_board=unix/-O3\"{-std=gnu++98,-std=gnu++11,-std=gnu++14}\"'</pre><p>
N.B. that set of variations could also be written as
<code class="literal">unix/-O3\"{-std=gnu++98,-std=gnu++11,}\"</code> so that
the third variation would use the default for <code class="option">-std</code>

146
libstdc++-v3/doc/xml/faq.xml
View file

@ -66,10 +66,10 @@
that are the hallmarks of an open-source project are applied to libstdc++.
</para>
<para>
All of the standard classes and functions from C++98/C++03
All of the standard classes and functions from C++98/C++03, C++11 and C++14
(such as <classname>string</classname>,
<classname>vector&lt;&gt;</classname>, iostreams, algorithms etc.)
are freely available and atempt to be fully compliant.
are freely available and attempt to be fully compliant.
Work is ongoing to complete support for the current revision of the
ISO C++ Standard.
</para>
@ -539,6 +539,9 @@
</para>
</question>
<answer xml:id="a-solaris_long_long">
<note>
<para>This answer is old and probably no longer be relevant.</para>
</note>
<para>
By default we try to support the C99 <type>long long</type> type.
This requires that certain functions from your C library be present.
@ -692,7 +695,7 @@
<qandaentry xml:id="faq.freebsd_wchar">
<question xml:id="q-freebsd_wchar">
<para>
Can't use wchar_t/wstring on FreeBSD
Can't use <type>wchar_t</type>/<classname>wstring</classname> on FreeBSD
</para>
</question>
<answer xml:id="a-freebsd_wchar">
@ -764,7 +767,8 @@
published on <link xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/">the WG21
website</link>.
Many of these issues have resulted in code changes in libstdc++.
Many of these issues have resulted in
<link linkend="manual.intro.status.bugs.iso">code changes in libstdc++</link>.
</para>
<para>
If you think you've discovered a new bug that is not listed,
@ -794,8 +798,8 @@
</para>
<para>
Before reporting a bug, please examine the
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/bugs/">bugs database</link> with the
category set to <quote>g++</quote>.
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="https://gcc.gnu.org/bugs/">bugs database</link>, with the
component set to <quote>c++</quote>.
</para>
</answer>
</qandaentry>
@ -813,8 +817,12 @@
</para>
</question>
<answer xml:id="a-stream_reopening_fails">
<note>
<para>This answer is old and probably no longer be relevant.</para>
</note>
<para>
One of the most-reported non-bug reports. Executing a sequence like:
Prior to GCC 4.0 this was one of the most-reported non-bug reports.
Executing a sequence like this would fail:
</para>
<programlisting>
@ -829,19 +837,20 @@
</programlisting>
<para>
All operations on the re-opened <varname>fs</varname> will fail, or at
least act very strangely. Yes, they often will, especially if
<varname>fs</varname> reached the EOF state on the previous file. The
reason is that the state flags are <emphasis>not</emphasis> cleared
on a successful call to open(). The standard unfortunately did
not specify behavior in this case, and to everybody's great sorrow,
the <link linkend="manual.intro.status.bugs">proposed LWG resolution in
DR #22</link> is to leave the flags unchanged. You must insert a call
to <function>fs.clear()</function> between the calls to close() and open(),
and then everything will work like we all expect it to work.
<emphasis>Update:</emphasis> for GCC 4.0 we implemented the resolution
of <link linkend="manual.intro.status.bugs">DR #409</link> and open()
now calls <function>clear()</function> on success!
All operations on the re-opened <varname>fs</varname> would fail, or at
least act very strangely, especially if <varname>fs</varname> reached the
EOF state on the previous file.
The original C++98 standard did not specify behavior in this case, and
the <link linkend="manual.bugs.dr22">resolution of DR #22</link> was to
leave the state flags unchanged on a successful call to
<function>open()</function>.
You had to insert a call to <function>fs.clear()</function> between the
calls to <function>close()</function> and <function>open()</function>,
and then everything will work as expected.
<emphasis>Update:</emphasis> For GCC 4.0 we implemented the resolution
of <link linkend="manual.bugs.dr409">DR #409</link> and
<function>open()</function>
now calls <function>clear()</function> on success.
</para>
</answer>
</qandaentry>
@ -858,7 +867,9 @@
libstdc++ <option>-Weffc++</option>-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.
necessarily trying to be OO. The option also enforces outdated guidelines
from old editions of the books, and the advice isn't all relevant to
modern C++ (especially C++11 and later).
</para>
<para>
We do, however, try to have libstdc++ sources as clean as possible. If
@ -879,9 +890,10 @@
Another problem is the <literal>rel_ops</literal> namespace and the template
comparison operator functions contained therein. If they become
visible in the same namespace as other comparison functions
(e.g., <quote>using</quote> them and the &lt;iterator&gt; header),
(e.g., <quote>using</quote> them and the
<filename class="headerfile">&lt;iterator&gt;</filename> header),
then you will suddenly be faced with huge numbers of ambiguity
errors. This was discussed on the -v3 list; Nathan Myers
errors. This was discussed on the mailing list; Nathan Myers
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html">sums
things up here</link>. The collisions with vector/string iterator
types have been fixed for 3.1.
@ -896,6 +908,9 @@
</para>
</question>
<answer xml:id="a-v2_headers">
<note>
<para>This answer is old and probably no longer be relevant.</para>
</note>
<para>
If you are using headers in
<filename class="directory">${prefix}/include/g++-3</filename>, or if
@ -981,11 +996,15 @@
</para>
</question>
<answer xml:id="a-memory_leaks">
<note>
<para>This answer is old and probably no longer be relevant.</para>
</note>
<para>
A few people have reported that the standard containers appear
to leak memory when tested with memory checkers such as
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://valgrind.org/"><command>valgrind</command></link>.
Under some configurations the library's allocators keep free memory in a
Under some (non-default) configurations the library's allocators keep
free memory in a
pool for later reuse, rather than returning it to the OS. Although
this memory is always reachable by the library and is never
lost, memory debugging tools can report it as a leak. If you
@ -999,7 +1018,7 @@
<qandaentry xml:id="faq.list_size_on">
<question xml:id="q-list_size_on">
<para>
list::size() is O(n)!
<code>list::size()</code> is O(n)!
</para>
</question>
<answer xml:id="a-list_size_on">
@ -1049,7 +1068,8 @@
<qandaentry xml:id="faq.iterator_as_pod">
<question xml:id="faq.iterator_as_pod_q">
<para>
string::iterator is not char*; vector&lt;T&gt;::iterator is not T*
<classname>string::iterator</classname> is not <code>char*</code>;
<classname>vector&lt;T&gt;::iterator</classname> is not <code>T*</code>
</para>
</question>
<answer xml:id="faq.iterator_as_pod_a">
@ -1067,11 +1087,9 @@
arguments.
</para>
<para>
Code which does assume that a vector iterator <varname>i</varname>
Code which does assume that a vector/string iterator <varname>i</varname>
is a pointer can often be fixed by changing <varname>i</varname> in
certain expressions to <varname>&amp;*i</varname>. Future revisions
of the Standard are expected to bless this usage for
vector&lt;&gt; (but not for basic_string&lt;&gt;).
certain expressions to <varname>&amp;*i</varname>.
</para>
</answer>
</qandaentry>
@ -1084,17 +1102,10 @@
</question>
<answer xml:id="a-what_is_next">
<para>
Hopefully, not much. The goal of libstdc++ is to produce a
fully-compliant, fully-portable Standard Library. After that,
we're mostly done: there won't <emphasis>be</emphasis> any
more compliance work to do.
</para>
<para>
There is an effort underway to add significant extensions to
the standard library specification. The latest version of
this effort is described in
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">
The C++ Library Technical Report 1</link>.
The goal of libstdc++ is to produce a
fully-compliant, fully-portable Standard Library.
While the C++ Standard continues to evolve the libstdc++ will
continue to track it.
</para>
</answer>
</qandaentry>
@ -1107,18 +1118,27 @@
</question>
<answer xml:id="a-sgi_stl">
<para>
The <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.sgi.com/tech/stl/">STL from SGI</link>,
version 3.3, was the final merge of the STL codebase. The
code in libstdc++ contains many fixes and changes, and
the SGI code is no longer under active
development. We expect that no future merges will take place.
The STL (Standard Template Library) was the inspiration for large chunks
of the C++ Standard Library, but the terms are not interchangeable and
they don't mean the same thing. The C++ Standard Library includes lots of
things that didn't come from the STL, and some of them aren't even
templates, such as <classname>std::locale</classname> and
<classname>std::thread</classname>.
</para>
<para>
Libstdc++-v3 incorporates a lot of code from
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.sgi.com/tech/stl/">the SGI STL</link>
(the final merge was from
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.sgi.com/tech/stl/whats_new.html">release 3.3</link>).
The code in libstdc++ contains many fixes and changes compared to the
original SGI code.
</para>
<para>
In particular, <classname>string</classname> is not from SGI and makes no
use of their "rope" class (which is included as an
optional extension), nor is <classname>valarray</classname> and some others.
Classes like <classname>vector&lt;&gt;</classname> are, but have been
extensively modified.
use of their "rope" class (although that is included as an optional
extension), neither is <classname>valarray</classname> nor some others.
Classes like <classname>vector&lt;&gt;</classname> were from SGI, but have
been extensively modified.
</para>
<para>
More information on the evolution of libstdc++ can be found at the
@ -1158,14 +1178,19 @@
Yes.
</para>
<para>
The C++ Standard Library Technical Report adds many new features to
the library. The latest version of this effort is described in
The C++ Standard Library
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf">
Technical Report 1</link>.
Technical Report 1</link> added many new features to the library.
</para>
<para>
The implementation status of TR1 in libstdc++ can be tracked <link linkend="status.iso.tr1">on the TR1 status
page</link>.
The implementation status of TR1 in libstdc++ can be tracked
<link linkend="status.iso.tr1">on the TR1 status page</link>.
</para>
<para>
New code should probably not use TR1, because almost everything in it has
been added to the main C++ Standard Library (usually with significant
improvements).
The TR1 implementation in libstdc++ is no longer actively maintained.
</para>
</answer>
</qandaentry>
@ -1252,13 +1277,18 @@
<qandaentry xml:id="faq.size_equals_capacity">
<question xml:id="q-size_equals_capacity">
<para>
How do I make std::vector&lt;T&gt;::capacity() == std::vector&lt;T&gt;::size?
How do I make <code>std::vector&lt;T&gt;::capacity() == std::vector&lt;T&gt;::size</code>?
</para>
</question>
<answer xml:id="a-size_equals_capacity">
<para>
The standard idiom for deallocating a <classname>vector&lt;T&gt;</classname>'s
unused memory is to create a temporary copy of the vector and swap their
Since C++11 just call the <function>shrink_to_fit()</function> member
function.
</para>
<para>
Before C++11, the standard idiom for deallocating a
<classname>vector&lt;T&gt;</classname>'s
unused memory was to create a temporary copy of the vector and swap their
contents, e.g. for <classname>vector&lt;T&gt; v</classname>
</para>
<literallayout class="normal">

282
libstdc++-v3/doc/xml/manual/intro.xml
View file

File diff suppressed because it is too large Load diff