Skip to content

R
riscv-gcc-1
Commit 7d31a1f4 by Paolo Carlini Committed by Paolo Carlini
Options

lwg-active.html, [...]: Import Revision 37. 

2005-06-29  Paolo Carlini  <pcarlini@suse.de>

	* docs/html/ext/lwg-active.html, lwg-defects.html: Import Revision 37.
	* docs/html/ext/howto.html: Adjust.

From-SVN: r101418
parent c7b80291
Showing with 1003 additions and 55 deletions
libstdc++-v3/ChangeLog
2005-06-29 Paolo Carlini <pcarlini@suse.de>
* docs/html/ext/lwg-active.html, lwg-defects.html: Import Revision 37.
* docs/html/ext/howto.html: Adjust.
2005-06-29 Paolo Carlini <pcarlini@suse.de>
PR libstdc++/22131
* include/bits/locale_facets.tcc (num_get<>::_M_extract_int,
num_get<>::_M_extract_float, money_get<>::_M_extract):
......
libstdc++-v3/docs/html/ext/howto.html
......@@ -503,19 +503,19 @@
<dd>Replace &quot;new&quot; with &quot;::new&quot;.
</dd>
<dt><a href="lwg-active.html#409">409</a>:
<dt><a href="lwg-defects.html#409">409</a>:
<em>Closing an fstream should clear the error state</em>
</dt>
<dd>Have <code>open</code> clear the error flags.
</dd>
<dt><a href="lwg-active.html#434">434</a>:
<dt><a href="lwg-defects.html#434">434</a>:
<em>bitset::to_string() hard to use</em>
</dt>
<dd>Add three overloads, taking fewer template arguments.
</dd>
<dt><a href="lwg-active.html#453">453</a>:
<dt><a href="lwg-defects.html#453">453</a>:
<em>basic_stringbuf::seekoff need not always fail for an empty stream</em>
</dt>
<dd>Don't fail if the next pointer is null and newoff is zero.
......
libstdc++-v3/docs/html/ext/lwg-active.html
This source diff could not be displayed because it is too large. You can view the blob instead.
libstdc++-v3/docs/html/ext/lwg-defects.html
......@@ -5,11 +5,11 @@
<table>
<tbody><tr>
<td align="left">Doc. no.</td>
<td align="left">N1763=05-0023</td>
<td align="left">N1831=05-0091</td>
</tr>
<tr>
<td align="left">Date:</td>
<td align="left">2005-03-04</td>
<td align="left">2005-06-24</td>
</tr>
<tr>
<td align="left">Project:</td>
......@@ -17,10 +17,10 @@
</tr>
<tr>
<td align="left">Reply to:</td>
<td align="left">Matt Austern &lt;austern@google.com&gt;</td>
<td align="left">Howard Hinnant &lt;howard.hinnant@gmail.com&gt;</td>
</tr>
</tbody></table>
<h1>C++ Standard Library Defect Report List (Revision 35)</h1>
<h1>C++ Standard Library Defect Report List (Revision R37)</h1>
<p>Reference ISO/IEC IS 14882:1998(E)</p>
<p>Also see:</p>
<ul>
......@@ -42,19 +42,28 @@
document.</p>
<h2>Revision History</h2>
<ul>
<li>R37:
2005-06 mid-term mailing.
Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>.
</li>
<li>R36:
2005-04 post-Lillehammer mailing. All issues in "ready" status except
for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#454">454</a> were moved to "DR" status, and all issues
previously in "DR" status were moved to "WP".
</li>
<li>R35:
2005-03 pre-Lillehammer mailing.
</li>
<li>R34:
2005-01 mid-term mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#488">488</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#494">494</a>.
2005-01 mid-term mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#488">488</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#494">494</a>.
</li>
<li>R33:
2004-11 post-Redmond mailing. Reflections actions taken in Redmond.
2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
</li>
<li>R32:
2004-09 pre-Redmond mailing: reflects new proposed resolutions and
new issues received after the 2004-07 mailing. Added
new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#479">479</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#481">481</a>.
new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#479">479</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#481">481</a>.
</li>
<li>R31:
2004-07 mid-term mailing: reflects new proposed resolutions and
......@@ -64,10 +73,10 @@ new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#
<li>R30:
Post-Sydney mailing: reflects decisions made at the Sydney meeting.
Voted all "Ready" issues from R29 into the working paper.
Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#462">462</a>.
Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#462">462</a>.
</li>
<li>R29:
Pre-Sydney mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#457">457</a>.
Pre-Sydney mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>.
</li>
<li>R28:
Post-Kona mailing: reflects decisions made at the Kona meeting.
......@@ -96,7 +105,7 @@ Pre-Santa Cruz mailing. Added new issues <a href="http://www.open-std.org/jtc1/
Moved issues in the TC to TC status.
</li>
<li>R22:
Post-Curaao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#362">362</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#366">366</a>.
Post-Curaao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#362">362</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#366">366</a>.
</li>
<li>R21:
Pre-Curaao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#361">361</a>.
......@@ -222,7 +231,7 @@ post-Dublin mailing. Updated to reflect LWG and full committee actions
in Dublin. (99-0016/N1193, 21 Apr 99)
</li>
<li>R7:
pre-Dublin updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#130">130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#131">131</a>,
pre-Dublin updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#131">131</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#132">132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#133">133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#135">135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a> (31 Mar 99)
......@@ -618,7 +627,7 @@ list maintainer's note: the IS is the same.]</p>
<p>See 99-0040/N1216, October 22, 1999, by Stephen D. Clamage for the analysis
supporting to the proposed resolution.</p>
<hr>
<a name="11"><h3>11.&nbsp;Bitset minor problems</h3></a><p><b>Section:</b>&nbsp;23.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;22 Jan 1998</p>
<a name="11"></a><h3><a name="11">11.&nbsp;Bitset minor problems</a></h3><p><b>Section:</b>&nbsp;23.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;22 Jan 1998</p>
<p>(1) bitset&lt;&gt;::operator[] is mentioned in the class synopsis (23.3.5), but it is
not documented in 23.3.5.2. </p>
......@@ -671,7 +680,7 @@ it's undefined. </p>
<p>In 27.6.1.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>, replace "eos" with
"charT()"</p>
<hr>
<a name="14"><h3>14.&nbsp;Locale::combine should be const</h3></a><p><b>Section:</b>&nbsp;22.1.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.members"> [lib.locale.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
<a name="14"></a><h3><a name="14">14.&nbsp;Locale::combine should be const</a></h3><p><b>Section:</b>&nbsp;22.1.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.members"> [lib.locale.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
<p>locale::combine is the only member function of locale (other than constructors and
destructor) that is not const. There is no reason for it not to be const, and good reasons
why it should have been const. Furthermore, leaving it non-const conflicts with 22.1.1
......@@ -880,7 +889,7 @@ and do_out". </p>
"do_convert" to "do_in or do_out". Also, in 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a>, change "do_convert()" to "do_in
or do_out". </p>
<hr>
<a name="25"><h3>25.&nbsp;String operator&lt;&lt; uses width() value wrong</h3></a><p><b>Section:</b>&nbsp;21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
<a name="25"></a><h3><a name="25">25.&nbsp;String operator&lt;&lt; uses width() value wrong</a></h3><p><b>Section:</b>&nbsp;21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
<p>In the description of operator&lt;&lt; applied to strings, the standard says that uses
the smaller of os.width() and str.size(), to pad "as described in stage 3"
elsewhere; but this is inconsistent, as this allows no possibility of space for padding. </p>
......@@ -1200,7 +1209,7 @@ initialization/identification system depends...", or (at the
editor's option) replace it with a place-holder to keep the paragraph
numbering the same. </p>
<hr>
<a name="41"></a><h3><a name="41">41.&nbsp;Ios_base needs clear(), exceptions()</a></h3><p><b>Section:</b>&nbsp;27.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
<a name="41"><h3>41.&nbsp;Ios_base needs clear(), exceptions()</h3></a><p><b>Section:</b>&nbsp;27.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
<p>The description of ios_base::iword() and pword() in 27.4.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>, say that if they fail, they "set badbit,
which may throw an exception". However, ios_base offers no
interface to set or to test badbit; those interfaces are defined in
......@@ -1662,8 +1671,7 @@ character c by</p>
<p>for any sequences of characters; and the effect of pushing
back a character c by</p>
<pre>
ungetc(c, f);
<pre> ungetc(c, f);
</pre>
<p>is the same as the effect of</p>
......@@ -2360,7 +2368,7 @@ item from:</p>
extracted.
</blockquote>
<hr>
<a name="69"><h3>69.&nbsp;Must elements of a vector be contiguous?</h3></a><p><b>Section:</b>&nbsp;23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;29 Jul 1998</p>
<a name="69"></a><h3><a name="69">69.&nbsp;Must elements of a vector be contiguous?</a></h3><p><b>Section:</b>&nbsp;23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;29 Jul 1998</p>
<p>The issue is this: Must the elements of a vector be in contiguous memory?</p>
<p>(Please note that this is entirely separate from the question of
......@@ -2604,7 +2612,7 @@ return value.]</i></p>
<p>to:</p>
<pre> template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = 0); </pre>
<hr>
<a name="80"></a><h3><a name="80">80.&nbsp;Global Operators of complex declared twice</a></h3><p><b>Section:</b>&nbsp;26.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, 26.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex"> [lib.complex]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
<a name="80"><h3>80.&nbsp;Global Operators of complex declared twice</h3></a><p><b>Section:</b>&nbsp;26.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>, 26.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex"> [lib.complex]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
<p>Both 26.2.1 and 26.2.2 contain declarations of global operators for
class complex. This redundancy should be removed.</p>
<p><b>Proposed resolution:</b></p>
......@@ -2861,7 +2869,7 @@ for <tt>*r++</tt> from <tt>T</tt> to "convertible to T".
of input iterators, we can't impose any requirements in the Input
Iterator requirements table that forward iterators don't satisfy.</p>
<hr>
<a name="103"><h3>103.&nbsp;set::iterator is required to be modifiable, but this allows modification of keys</h3></a><p><b>Section:</b>&nbsp;23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
<a name="103"></a><h3><a name="103">103.&nbsp;set::iterator is required to be modifiable, but this allows modification of keys</a></h3><p><b>Section:</b>&nbsp;23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
<p>Set::iterator is described as implementation-defined with a
reference to the container requirement; the container requirement says
that const_iterator is an iterator pointing to const T and iterator an
......@@ -3132,7 +3140,7 @@ replace:</p>
<pre>bool equal(const istreambuf_iterator&amp; b) const;</pre>
</blockquote>
<hr>
<a name="112"></a><h3><a name="112">112.&nbsp;Minor typo in <tt>ostreambuf_iterator</tt> constructor</a></h3><p><b>Section:</b>&nbsp;24.5.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.ostreambuf.iter.cons"> [lib.ostreambuf.iter.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;20 Oct 1998</p>
<a name="112"><h3>112.&nbsp;Minor typo in <tt>ostreambuf_iterator</tt> constructor</h3></a><p><b>Section:</b>&nbsp;24.5.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.ostreambuf.iter.cons"> [lib.ostreambuf.iter.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;20 Oct 1998</p>
<p>The <b>requires</b> clause for <tt>ostreambuf_iterator</tt>'s
constructor from an <tt>ostream_type</tt> (24.5.4.1, paragraph 1)
reads "<i>s</i> is not null". However, <i>s</i> is a
......@@ -3150,7 +3158,7 @@ reading:</p>
<p><b>Requires</b>: <tt>s.rdbuf()</tt> is not null.</p>
</blockquote>
<hr>
<a name="114"><h3>114.&nbsp;Placement forms example in error twice</h3></a><p><b>Section:</b>&nbsp;18.4.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.placement"> [lib.new.delete.placement]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;28 Oct 1998</p>
<a name="114"></a><h3><a name="114">114.&nbsp;Placement forms example in error twice</a></h3><p><b>Section:</b>&nbsp;18.4.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.placement"> [lib.new.delete.placement]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;28 Oct 1998</p>
<p>Section 18.4.1.3 contains the following example: </p>
<pre>[Example: This can be useful for constructing an object at a known address:
......@@ -3359,7 +3367,7 @@ operator&gt;&gt;(int&amp; val);</pre>
<p><i>[Post-Tokyo: PJP provided the above wording.]</i></p>
<hr>
<a name="119"></a><h3><a name="119">119.&nbsp;Should virtual functions be allowed to strengthen the exception specification?</a></h3><p><b>Section:</b>&nbsp;17.4.4.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
<a name="119"><h3>119.&nbsp;Should virtual functions be allowed to strengthen the exception specification?</h3></a><p><b>Section:</b>&nbsp;17.4.4.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
<p>Section 17.4.4.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a> states: </p>
<p>"An implementation may strengthen the exception-specification
......@@ -3754,6 +3762,65 @@ stream state in case of failure.</p>
<p><b>Rationale:</b></p>
<p>Setting failbit is the usual error reporting mechanism for streams</p>
<hr>
<a name="130"><h3>130.&nbsp;Return type of container::erase(iterator) differs for associative containers</h3></a><p><b>Section:</b>&nbsp;23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;2 Mar 1999</p>
<p>Table 67 (23.1.1) says that container::erase(iterator) returns an
iterator. Table 69 (23.1.2) says that in addition to this requirement,
associative containers also say that container::erase(iterator)
returns void. That's not an addition; it's a change to the
requirements, which has the effect of making associative containers
fail to meet the requirements for containers.</p>
<p><b>Proposed resolution:</b></p>
<p>
In 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, in Table 69 Associative container
requirements, change the return type of <tt>a.erase(q)</tt> from
<tt>void</tt> to <tt>iterator</tt>. Change the
assertion/not/pre/post-condition from "erases the element pointed to
by <tt>q</tt>" to "erases the element pointed to by <tt>q</tt>.
Returns an iterator pointing to the element immediately following q
prior to the element being erased. If no such element exists, a.end()
is returned."
</p>
<p>
In 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, in Table 69 Associative container
requirements, change the return type of <tt>a.erase(q1, q2)</tt>
from <tt>void</tt> to <tt>iterator</tt>. Change the
assertion/not/pre/post-condition from "erases the elements in the
range <tt>[q1, q2)</tt>" to "erases the elements in the range <tt>[q1,
q2)</tt>. Returns q2."
</p>
<p>
In 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a>, in the <tt>map</tt> class synopsis; and
in 23.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.multimap"> [lib.multimap]</a>, in the <tt>multimap</tt> class synopsis; and
in 23.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.set"> [lib.set]</a>, in the <tt>set</tt> class synopsis; and
in 23.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.multiset"> [lib.multiset]</a>, in the <tt>multiset</tt> class synopsis:
change the signature of the first <tt>erase</tt> overload to
</p>
<pre> iterator erase(iterator position);
</pre>
<p>and change the signature of the third <tt>erase</tt> overload to</p>
<pre> iterator erase(iterator first, iterator last);
</pre>
<p><i>[Pre-Kona: reopened at the request of Howard Hinnant]</i></p>
<p><i>[Post-Kona: the LWG agrees the return type should be
<tt>iterator</tt>, not <tt>void</tt>. (Alex Stepanov agrees too.)
Matt provided wording.]</i></p>
<p><i>[
Sydney: the proposed wording went in the right direction, but it
wasn't good enough. We want to return an iterator from the range form
of erase as well as the single-iterator form. Also, the wording is
slightly different from the wording we have for sequences; there's no
good reason for having a difference. Matt provided new wording,
which we will review at the next meeting.
]</i></p>
<hr>
<a name="132"><h3>132.&nbsp;list::resize description uses random access iterators</h3></a><p><b>Section:</b>&nbsp;23.2.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.capacity"> [lib.list.capacity]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;6 Mar 1999</p>
<p>The description reads:</p>
......@@ -4084,7 +4151,7 @@ follows an "all-or-none" rule.</p>
<p>For inserters, the LWG believes there is no defect; the standard is correct
as written.</p>
<hr>
<a name="147"><h3>147.&nbsp;Library Intro refers to global functions that aren't global</h3></a><p><b>Section:</b>&nbsp;17.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.global.functions"> [lib.global.functions]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Lois Goldthwaite&nbsp; <b>Date:</b>&nbsp;4 Jun 1999</p>
<a name="147"></a><h3><a name="147">147.&nbsp;Library Intro refers to global functions that aren't global</a></h3><p><b>Section:</b>&nbsp;17.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.global.functions"> [lib.global.functions]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Lois Goldthwaite&nbsp; <b>Date:</b>&nbsp;4 Jun 1999</p>
<p>The library had many global functions until 17.4.1.1 [lib.contents]
paragraph 2 was added: </p>
......@@ -4338,8 +4405,8 @@ be fixed to use <tt>sbumpc()</tt> instead.</p>
"supplied" with the words "extracted from the
stream".</p>
<hr>
<a name="160"><h3>160.&nbsp;Typo: Use of non-existing function <tt>exception()</tt>
</h3></a><p><b>Section:</b>&nbsp;27.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream"> [lib.istream]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Khl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
<a name="160"></a><h3><a name="160">160.&nbsp;Typo: Use of non-existing function <tt>exception()</tt>
</a></h3><p><b>Section:</b>&nbsp;27.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream"> [lib.istream]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Khl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
<p>The paragraph 4 refers to the function <tt>exception()</tt> which
is not defined. Probably, the referred function is
<tt>basic_ios&lt;&gt;::exceptions()</tt>.</p>
......@@ -4500,7 +4567,7 @@ traits class for some arbitrary charT type, and we somehow have to
deal with a const char*. There's nothing better to do but fall back
to char_traits&lt;char&gt;</p>
<hr>
<a name="168"><h3>168.&nbsp;Typo: formatted vs. unformatted</h3></a><p><b>Section:</b>&nbsp;27.6.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Khl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
<a name="168"></a><h3><a name="168">168.&nbsp;Typo: formatted vs. unformatted</a></h3><p><b>Section:</b>&nbsp;27.6.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Khl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
<p>The first paragraph begins with a descriptions what has to be done
in <i>formatted</i> output functions. Probably this is a typo and the
paragraph really want to describe unformatted output functions...</p>
......@@ -5829,7 +5896,7 @@ change.
or change the return to distance(b,a). The LWG preferred the
former for consistency.</p>
<hr>
<a name="211"><h3>211.&nbsp;operator&gt;&gt;(istream&amp;, string&amp;) doesn't set failbit</h3></a><p><b>Section:</b>&nbsp;21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Scott Snyder&nbsp; <b>Date:</b>&nbsp;4 Feb 2000</p>
<a name="211"></a><h3><a name="211">211.&nbsp;operator&gt;&gt;(istream&amp;, string&amp;) doesn't set failbit</a></h3><p><b>Section:</b>&nbsp;21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Scott Snyder&nbsp; <b>Date:</b>&nbsp;4 Feb 2000</p>
<p>The description of the stream extraction operator for std::string (section
21.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in
the case that the operator fails to extract any characters from the input
......@@ -5940,7 +6007,7 @@ declared above.</pre>
return 0;
}</pre>
<hr>
<a name="220"></a><h3><a name="220">220.&nbsp;~ios_base() usage valid?</a></h3><p><b>Section:</b>&nbsp;27.4.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.cons"> [lib.ios.base.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Jonathan Schilling, Howard Hinnant&nbsp; <b>Date:</b>&nbsp;13 Mar 2000</p>
<a name="220"><h3>220.&nbsp;~ios_base() usage valid?</h3></a><p><b>Section:</b>&nbsp;27.4.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.cons"> [lib.ios.base.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Jonathan Schilling, Howard Hinnant&nbsp; <b>Date:</b>&nbsp;13 Mar 2000</p>
<p>The pre-conditions for the ios_base destructor are described in 27.4.2.7
paragraph 2:</p>
<blockquote>
......@@ -7248,10 +7315,10 @@ iterators into *this, not into x.
<p>The original proposed resolution said that iterators and references
would remain "valid". The new proposed resolution clarifies what that
means. Note that this only applies to the case of equal allocators.
From 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> paragraph 4, the behavior of list when
&gt;From 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a> paragraph 4, the behavior of list when
allocators compare nonequal is outside the scope of the standard.</p>
<hr>
<a name="251"></a><h3><a name="251">251.&nbsp;basic_stringbuf missing allocator_type</a></h3><p><b>Section:</b>&nbsp;27.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf"> [lib.stringbuf]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jul 2000</p>
<a name="251"><h3>251.&nbsp;basic_stringbuf missing allocator_type</h3></a><p><b>Section:</b>&nbsp;27.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf"> [lib.stringbuf]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jul 2000</p>
<p>The synopsis for the template class <tt>basic_stringbuf</tt>
doesn't list a typedef for the template parameter
<tt>Allocator</tt>. This makes it impossible to determine the type of
......@@ -7493,8 +7560,8 @@ In section 21.3.4, paragraph 1, change
<i>pos</i>)</tt>".
</p>
<hr>
<a name="260"></a><h3><a name="260">260.&nbsp;Inconsistent return type of <tt>istream_iterator::operator++(int)</tt>
</a></h3><p><b>Section:</b>&nbsp;24.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istream.iterator.ops"> [lib.istream.iterator.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;27 Aug 2000</p>
<a name="260"><h3>260.&nbsp;Inconsistent return type of <tt>istream_iterator::operator++(int)</tt>
</h3></a><p><b>Section:</b>&nbsp;24.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istream.iterator.ops"> [lib.istream.iterator.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;27 Aug 2000</p>
<p>The synopsis of istream_iterator::operator++(int) in 24.5.1 shows
it as returning the iterator by value. 24.5.1.2, p5 shows the same
operator as returning the iterator by reference. That's incorrect
......@@ -8955,7 +9022,7 @@ list" is excessively vague.]</i></p>
<p><i>[Post-Curaao: Robert Klarer provided new wording.]</i></p>
<hr>
<a name="301"><h3>301.&nbsp;basic_string template ctor effects clause omits allocator argument</h3></a><p><b>Section:</b>&nbsp;21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;27 Jan 2001</p>
<a name="301"></a><h3><a name="301">301.&nbsp;basic_string template ctor effects clause omits allocator argument</a></h3><p><b>Section:</b>&nbsp;21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;27 Jan 2001</p>
<p>
The effects clause for the basic_string template ctor in 21.3.1, p15
leaves out the third argument of type Allocator. I believe this to be
......@@ -9506,7 +9573,7 @@ Table 82. However, &lt;cstdio&gt; is mentioned several times within
section 27.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a>, including 27.8.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.c.files"> [lib.c.files]</a>.]</i></p>
<hr>
<a name="310"></a><h3><a name="310">310.&nbsp;Is errno a macro?</a></h3><p><b>Section:</b>&nbsp;17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a>, 19.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-diagnostics.html#lib.errno"> [lib.errno]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;21 Mar 2001</p>
<a name="310"><h3>310.&nbsp;Is errno a macro?</h3></a><p><b>Section:</b>&nbsp;17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a>, 19.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-diagnostics.html#lib.errno"> [lib.errno]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;21 Mar 2001</p>
<p>
Exactly how should errno be declared in a conforming C++ header?
</p>
......@@ -10449,7 +10516,7 @@ parameter name conveys real normative meaning.
<hr>
<a name="338"><h3>338.&nbsp; is whitespace allowed between `-' and a digit?</h3></a><p><b>Section:</b>&nbsp;22.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.categories"> [lib.locale.categories]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;17 Sep 2001</p>
<p>
From Stage 2 processing in 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>, p8 and 9 (the
&gt;From Stage 2 processing in 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>, p8 and 9 (the
original text or the text corrected by the proposed resolution of
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#221">221</a>) it seems clear that no whitespace is allowed
within a number, but 22.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.numpunct"> [lib.locale.numpunct]</a>, p2, which gives the
......@@ -10506,7 +10573,7 @@ for it to differ gratuitously from the very specific description of
numeric processing in 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>. The proposed
resolution removes all mention of "whitespace" from that format.</p>
<hr>
<a name="339"></a><h3><a name="339">339.&nbsp;definition of bitmask type restricted to clause 27</a></h3><p><b>Section:</b>&nbsp;22.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a>, 17.3.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;17 September 2001</p>
<a name="339"><h3>339.&nbsp;definition of bitmask type restricted to clause 27</h3></a><p><b>Section:</b>&nbsp;22.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a>, 17.3.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;17 September 2001</p>
<p>
The ctype_category::mask type is declared to be an enum in 22.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a> with p1 then stating that it is a bitmask type, most
likely referring to the definition of bitmask type in 17.3.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a>, p1. However, the said definition only applies to
......@@ -10564,8 +10631,8 @@ following (note, in particluar, the cross-reference to 17.3.2.1.2 in
consistent with the rest of the standard.]</i></p>
<hr>
<a name="340"></a><h3><a name="340">340.&nbsp;interpretation of <tt>has_facet&lt;Facet&gt;(loc)</tt>
</a></h3><p><b>Section:</b>&nbsp;22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2001</p>
<a name="340"><h3>340.&nbsp;interpretation of <tt>has_facet&lt;Facet&gt;(loc)</tt>
</h3></a><p><b>Section:</b>&nbsp;22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2001</p>
<p>
It's unclear whether 22.1.1.1.1, p3 says that
<tt>has_facet&lt;Facet&gt;(loc)</tt> returns true for any <tt>Facet</tt>
......@@ -11489,6 +11556,57 @@ Change the guarantee to "postcondition: r is dereferenceable."
<p><b>Rationale:</b></p>
<p>Fixes an obvious typo</p>
<hr>
<a name="386"><h3>386.&nbsp;Reverse iterator's operator[] has impossible return type</h3></a><p><b>Section:</b>&nbsp;24.4.1.3.11 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.opindex"> [lib.reverse.iter.opindex]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;23 Oct 2002</p>
<p>In 24.4.1.3.11 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.opindex"> [lib.reverse.iter.opindex]</a>, <tt>reverse_iterator&lt;&gt;::operator[]</tt>
is specified as having a return type of <tt>reverse_iterator::reference</tt>,
which is the same as <tt>iterator_traits&lt;Iterator&gt;::reference</tt>.
(Where <tt>Iterator</tt> is the underlying iterator type.)</p>
<p>The trouble is that <tt>Iterator</tt>'s own operator[] doesn't
necessarily have a return type
of <tt>iterator_traits&lt;Iterator&gt;::reference</tt>. Its
return type is merely required to be convertible
to <tt>Iterator</tt>'s value type. The return type specified for
reverse_iterator's operator[] would thus appear to be impossible.</p>
<p>With the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a>, the type of
<tt>a[n]</tt> will continue to be required (for random access
iterators) to be convertible to the value type, and also <tt>a[n] =
t</tt> will be a valid expression. Implementations of
<tt>reverse_iterator</tt> will likely need to return a proxy from
<tt>operator[]</tt> to meet these requirements. As mentioned in the
comment from Dave Abrahams, the simplest way to specify that
<tt>reverse_iterator</tt> meet this requirement to just mandate
it and leave the return type of <tt>operator[]</tt> unspecified.</p>
<p><b>Proposed resolution:</b></p>
<p>In 24.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.requirements"> [lib.reverse.iter.requirements]</a> change:</p>
<blockquote>
<pre>reference operator[](difference_type n) const;
</pre>
</blockquote>
<p>to:</p>
<blockquote>
<pre><b><i>unspecified</i></b> operator[](difference_type n) const; // see <font color="red">lib.random.access.iterators</font>
</pre>
</blockquote>
<p><i>[
Comments from Dave Abrahams: IMO we should resolve 386 by just saying
that the return type of reverse_iterator's operator[] is
unspecified, allowing the random access iterator requirements to
impose an appropriate return type. If we accept 299's proposed
resolution (and I think we should), the return type will be
readable and writable, which is about as good as we can do.
]</i></p>
<hr>
<a name="389"><h3>389.&nbsp;Const overload of valarray::operator[] returns by value</h3></a><p><b>Section:</b>&nbsp;26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Gabriel Dos Reis&nbsp; <b>Date:</b>&nbsp;8 Nov 2002</p>
<p>Consider the following program:</p>
<pre> #include &lt;iostream&gt;
......@@ -11772,7 +11890,7 @@ Providing this functionality would be difficult in some cases, and is
believed to be of limited value.
</p>
<hr>
<a name="405"><h3>405.&nbsp;qsort and POD</h3></a><p><b>Section:</b>&nbsp;25.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.c.library"> [lib.alg.c.library]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;08 Apr 2003</p>
<a name="405"><h3>405.&nbsp;qsort and POD</h3></a><p><b>Section:</b>&nbsp;25.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.c.library"> [lib.alg.c.library]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;08 Apr 2003</p>
<p>
Section 25.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.c.library"> [lib.alg.c.library]</a> describes bsearch and qsort, from the C
standard library. Paragraph 4 does not list any restrictions on qsort,
......@@ -11791,6 +11909,29 @@ type."
<p><i>[Something along these lines is clearly necessary. Matt
provided wording.]</i></p>
<hr>
<a name="406"><h3>406.&nbsp;vector::insert(s) exception safety</h3></a><p><b>Section:</b>&nbsp;23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;27 Apr 2003</p>
<p>
There is a possible defect in the standard: the standard text was
never intended to prevent arbitrary ForwardIterators, whose operations
may throw exceptions, from being passed, and it also wasn't intended
to require a temporary buffer in the case where ForwardIterators were
passed (and I think most implementations don't use one). As is, the
standard appears to impose requirements that aren't met by any
existing implementation.
</p>
<p><b>Proposed resolution:</b></p>
<p>Replace 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a> paragraph 1 with:</p>
<blockquote>
1- Notes: Causes reallocation if the new size is greater than the
old capacity. If no reallocation happens, all the iterators and
references before the insertion point remain valid. If an exception
is thrown other than by the copy constructor or assignment operator
of T or by any InputIterator operation there are no effects.
</blockquote>
<p><i>[We probably need to say something similar for deque.]</i></p>
<hr>
<a name="407"><h3>407.&nbsp;Can singular iterators be destroyed?</h3></a><p><b>Section:</b>&nbsp;24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;3 June 2003</p>
<p>
Clause 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>, paragraph 5, says that the only expression
......@@ -11807,7 +11948,82 @@ destroying an iterator that holds a singular value, or the assignment
of a non-singular value to an iterator that holds a singular value."
</p>
<hr>
<a name="410"><h3>410.&nbsp;Missing semantics for stack and queue comparison operators</h3></a><p><b>Section:</b>&nbsp;23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.queue"> [lib.queue]</a>, 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Hans Bos&nbsp; <b>Date:</b>&nbsp;7 Jun 2003</p>
<a name="409"><h3>409.&nbsp;Closing an fstream should clear error state</h3></a><p><b>Section:</b>&nbsp;27.8.1.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a>, 27.8.1.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ofstream.members"> [lib.ofstream.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;3 June 2003</p>
<p>
A strict reading of 27.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstreams"> [lib.fstreams]</a> shows that opening or
closing a basic_[io]fstream does not affect the error bits. This
means, for example, that if you read through a file up to EOF, and
then close the stream and reopen it at the beginning of the file,
the EOF bit in the stream's error state is still set. This is
counterintuitive.
</p>
<p>
The LWG considered this issue once before, as issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#22">22</a>,
and put in a footnote to clarify that the strict reading was indeed
correct. We did that because we believed the standard was
unambiguous and consistent, and that we should not make architectural
changes in a TC. Now that we're working on a new revision of the
language, those considerations no longer apply.
</p>
<p><b>Proposed resolution:</b></p>
<p>Change 27.8.1.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a>, para. 3 from:</p>
<blockquote>
Calls rdbuf()-&gt;open(s,mode|in). If that function returns a null
pointer, calls setstate(failbit) (which may throw ios_base::failure
[Footnote: (lib.iostate.flags)].
</blockquote>
<p>to:</p>
<blockquote>Calls rdbuf()-&gt;open(s,mode|in). If that function returns
a null pointer, calls setstate(failbit) (which may throw
ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
</blockquote>
<p>Change 27.8.1.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ofstream.members"> [lib.ofstream.members]</a>, para. 3 from:</p>
<blockquote>Calls rdbuf()-&gt;open(s,mode|out). If that function
returns a null pointer, calls setstate(failbit) (which may throw
ios_base::failure [Footnote: (lib.iostate.flags)).
</blockquote>
<p>to:</p>
<blockquote>Calls rdbuf()-&gt;open(s,mode|out). If that function
returns a null pointer, calls setstate(failbit) (which may throw
ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
</blockquote>
<p>Change 27.8.1.13 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstream.members"> [lib.fstream.members]</a>, para. 3 from:</p>
<blockquote>Calls rdbuf()-&gt;open(s,mode), If that function returns a
null pointer, calls setstate(failbit), (which may throw
ios_base::failure). (lib.iostate.flags) )
</blockquote>
<p>to:</p>
<blockquote>Calls rdbuf()-&gt;open(s,mode), If that function returns a
null pointer, calls setstate(failbit), (which may throw
ios_base::failure). (lib.iostate.flags) ), else calls clear().
</blockquote>
<p><i>[Kona: the LWG agrees this is a good idea. Post-Kona: Bill
provided wording. He suggests having open, not close, clear the error
flags.]</i></p>
<p><i>[Post-Sydney: Howard provided a new proposed resolution. The
old one didn't make sense because it proposed to fix this at the
level of basic_filebuf, which doesn't have access to the stream's
error state. Howard's proposed resolution fixes this at the level
of the three fstream class template instead.]</i></p>
<hr>
<a name="410"></a><h3><a name="410">410.&nbsp;Missing semantics for stack and queue comparison operators</a></h3><p><b>Section:</b>&nbsp;23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.queue"> [lib.queue]</a>, 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Hans Bos&nbsp; <b>Date:</b>&nbsp;7 Jun 2003</p>
<p>
Sections 23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.queue"> [lib.queue]</a> and 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a> list
comparison operators (==, !=, &lt;, &lt;=, &gt;, =&gt;) for queue and
......@@ -11892,7 +12108,7 @@ set_intersection(), not union() and intersection().
<p><b>Proposed resolution:</b></p>
<p>Change that sentence to use the correct names.</p>
<hr>
<a name="412"><h3>412.&nbsp;Typo in 27.4.4.3</h3></a><p><b>Section:</b>&nbsp;27.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostate.flags"> [lib.iostate.flags]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;10 Jul 2003</p>
<a name="412"></a><h3><a name="412">412.&nbsp;Typo in 27.4.4.3</a></h3><p><b>Section:</b>&nbsp;27.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostate.flags"> [lib.iostate.flags]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;10 Jul 2003</p>
<p>
The Effects clause in 27.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostate.flags"> [lib.iostate.flags]</a> paragraph 5 says that the
function only throws if the respective bits are already set prior to
......@@ -11914,6 +12130,51 @@ exceptions()) == 0" with "If ((state | (rdbuf() ? goodbit : badbit))
latter, of course. Post-Kona: Martin provided wording.]</i></p>
<hr>
<a name="413"><h3>413.&nbsp;Proposed resolution to LDR#64 still wrong</h3></a><p><b>Section:</b>&nbsp;27.6.1.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Bo Persson&nbsp; <b>Date:</b>&nbsp;13 Jul 2003</p>
<p>
The second sentence of the proposed resolution says:
</p>
<p>
"If it inserted no characters because it caught an exception thrown
while extracting characters from sb and ..."
</p>
<p>
However, we are not extracting from sb, but extracting from the
basic_istream (*this) and inserting into sb. I can't really tell if
"extracting" or "sb" is a typo.
</p>
<p><i>[
Sydney: Definitely a real issue. We are, indeed, extracting characters
from an istream and not from sb. The problem was there in the FDIS and
wasn't fixed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a>. Probably what was intended was
to have *this instead of sb. We're talking about the exception flag
state of a basic_istream object, and there's only one basic_istream
object in this discussion, so that would be a consistent
interpretation. (But we need to be careful: the exception policy of
this member function must be consistent with that of other
extractors.) PJP will provide wording.
]</i></p>
<p><b>Proposed resolution:</b></p>
<p>Change the sentence from:</p>
<blockquote>
If it inserted no characters because it caught an exception thrown
while extracting characters from sb and failbit is on in exceptions(),
then the caught exception is rethrown.
</blockquote>
<p>to:</p>
<blockquote>
If it inserted no characters because it caught an exception thrown
while extracting characters from *this and failbit is on in exceptions(),
then the caught exception is rethrown.
</blockquote>
<hr>
<a name="414"><h3>414.&nbsp;Which iterators are invalidated by v.erase()?</h3></a><p><b>Section:</b>&nbsp;23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;19 Aug 2003</p>
<p>
Consider the following code fragment:
......@@ -11975,7 +12236,7 @@ erase".
and references in parallel, and it would seem counterintuitive to
say that a reference to an erased value remains valid.</p>
<hr>
<a name="415"><h3>415.&nbsp;behavior of std::ws</h3></a><p><b>Section:</b>&nbsp;27.6.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.manip"> [lib.istream.manip]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
<a name="415"><h3>415.&nbsp;behavior of std::ws</h3></a><p><b>Section:</b>&nbsp;27.6.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.manip"> [lib.istream.manip]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
<p>
According to 27.6.1.4, the ws() manipulator is not required to construct
the sentry object. The manipulator is also not a member function so the
......@@ -12023,7 +12284,7 @@ allowed to just declare it without providing a full definition?
already says. We don't want to make anything implementation defined,
because that imposes new requirements in implementations.</p>
<hr>
<a name="425"><h3>425.&nbsp;return value of std::get_temporary_buffer</h3></a><p><b>Section:</b>&nbsp;20.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.temporary.buffer"> [lib.temporary.buffer]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
<a name="425"><h3>425.&nbsp;return value of std::get_temporary_buffer</h3></a><p><b>Section:</b>&nbsp;20.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.temporary.buffer"> [lib.temporary.buffer]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
<p>
The standard is not clear about the requirements on the value returned from
a call to get_temporary_buffer(0). In particular, it fails to specify whether
......@@ -12038,7 +12299,7 @@ values if no storage can be obtained" to "...or a pair of 0 values if
no storage can be obtained or if <i>n</i> &lt;= 0."</p>
<p><i>[Kona: Matt provided wording]</i></p>
<hr>
<a name="426"><h3>426.&nbsp;search_n(), fill_n(), and generate_n() with negative n</h3></a><p><b>Section:</b>&nbsp;25.1.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.search"> [lib.alg.search]</a>, 25.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.fill"> [lib.alg.fill]</a>, 25.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.generate"> [lib.alg.generate]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
<a name="426"><h3>426.&nbsp;search_n(), fill_n(), and generate_n() with negative n</h3></a><p><b>Section:</b>&nbsp;25.1.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.search"> [lib.alg.search]</a>, 25.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.fill"> [lib.alg.fill]</a>, 25.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.generate"> [lib.alg.generate]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
<p>
The complexity requirements for these function templates are incorrect
(or don't even make sense) for negative n:</p>
......@@ -12129,7 +12390,7 @@ which is most likely not the intent.
option, on the grounds that duplicating text always risks the
possibility that it might be duplicated incorrectly.</p>
<hr>
<a name="432"><h3>432.&nbsp;stringbuf::overflow() makes only one write position available</h3></a><p><b>Section:</b>&nbsp;27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Christian W Brock&nbsp; <b>Date:</b>&nbsp;24 Sep 2003</p>
<a name="432"><h3>432.&nbsp;stringbuf::overflow() makes only one write position available</h3></a><p><b>Section:</b>&nbsp;27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Christian W Brock&nbsp; <b>Date:</b>&nbsp;24 Sep 2003</p>
<p>27.7.1.3 par 8 says:</p>
<blockquote>
Notes: The function can make a write position available only if
......@@ -12400,7 +12661,47 @@ longer allowable since [pbase(), epptr()) may now contain
uninitialized characters. Positioning is only allowable over the
initialized range.</p>
<hr>
<a name="435"><h3>435.&nbsp;bug in DR 25</h3></a><p><b>Section:</b>&nbsp;21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;15 Oct 2003</p>
<a name="434"><h3>434.&nbsp;bitset::to_string() hard to use</h3></a><p><b>Section:</b>&nbsp;23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;15 Oct 2003</p>
<p>
It has been pointed out a number of times that the bitset to_string() member
function template is tedious to use since callers must explicitly specify the
entire template argument list (3 arguments). At least two implementations
provide a number of overloads of this template to make it easier to use.
</p>
<p><b>Proposed resolution:</b></p>
<p>In order to allow callers to specify no template arguments at all, just the
first one (charT), or the first 2 (charT and traits), in addition to all
three template arguments, add the following three overloads to both the
interface (declarations only) of the class template bitset as well as to
section 23.3.5.2, immediately after p34, the Returns clause of the existing
to_string() member function template:</p>
<pre> template &lt;class charT, class traits&gt;
basic_string&lt;charT, traits, allocator&lt;charT&gt; &gt;
to_string () const;
-34.1- Returns: to_string&lt;charT, traits, allocator&lt;charT&gt; &gt;().
template &lt;class charT&gt;
basic_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;
to_string () const;
-34.2- Returns: to_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;().
basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;
to_string () const;
-34.3- Returns: to_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;().
</pre>
<p><i>[Kona: the LWG agrees that this is an improvement over the
status quo. Dietmar thought about an alternative using a proxy
object but now believes that the proposed resolution above is the
right choice.
]</i></p>
<hr>
<a name="435"><h3>435.&nbsp;bug in DR 25</h3></a><p><b>Section:</b>&nbsp;21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;15 Oct 2003</p>
<p>
It has been pointed out that the proposed resolution in DR 25 may not be
......@@ -12473,7 +12774,330 @@ template parameter.</p>
text.]</i></p>
<hr>
<a name="441"><h3>441.&nbsp;Is fpos::state const?</h3></a><p><b>Section:</b>&nbsp;27.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos"> [lib.fpos]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Vincent Leloup&nbsp; <b>Date:</b>&nbsp;17 Nov 2003</p>
<a name="438"></a><h3><a name="438">438.&nbsp;Ambiguity in the "do the right thing" clause</a></h3><p><b>Section:</b>&nbsp;23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;20 Oct 2003</p>
<p>Section 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>, paragraphs 9-11, fixed up the problem
noticed with statements like:</p>
<pre>vector&lt;int&gt; v(10, 1);
</pre>
<p>The intent of the above statement was to construct with:</p>
<pre>vector(size_type, const value_type&amp;);
</pre>
<p>but early implementations failed to compile as they bound to:</p>
<pre>template &lt;class InputIterator&gt;
vector(InputIterator f, InputIterator l);
</pre>
<p>instead.</p>
<p>Paragraphs 9-11 say that if InputIterator is an integral type, then the
member template constructor will have the same effect as:</p>
<pre>vector&lt;static_cast&lt;size_type&gt;(f), static_cast&lt;value_type&gt;(l));
</pre>
<p>(and similarly for the other member template functions of sequences).</p>
<p>There is also a note that describes one implementation technique:</p>
<blockquote>
One way that sequence implementors can satisfy this requirement is to
specialize the member template for every integral type.
</blockquote>
<p>This might look something like:</p>
<blockquote>
<pre>template &lt;class T&gt;
struct vector
{
typedef unsigned size_type;
explicit vector(size_type) {}
vector(size_type, const T&amp;) {}
template &lt;class I&gt;
vector(I, I);
// ...
};
template &lt;class T&gt;
template &lt;class I&gt;
vector&lt;T&gt;::vector(I, I) { ... }
template &lt;&gt;
template &lt;&gt;
vector&lt;int&gt;::vector(int, int) { ... }
template &lt;&gt;
template &lt;&gt;
vector&lt;int&gt;::vector(unsigned, unsigned) { ... }
// ...
</pre>
</blockquote>
<p>Label this solution 'A'.</p>
<p>The standard also says:</p>
<blockquote>
Less cumbersome implementation techniques also exist.
</blockquote>
<p>
A popular technique is to not specialize as above, but instead catch
every call with the member template, detect the type of InputIterator,
and then redirect to the correct logic. Something like:
</p>
<blockquote>
<pre>template &lt;class T&gt;
template &lt;class I&gt;
vector&lt;T&gt;::vector(I f, I l)
{
choose_init(f, l, int2type&lt;is_integral&lt;I&gt;::value&gt;());
}
template &lt;class T&gt;
template &lt;class I&gt;
vector&lt;T&gt;::choose_init(I f, I l, int2type&lt;false&gt;)
{
// construct with iterators
}
template &lt;class T&gt;
template &lt;class I&gt;
vector&lt;T&gt;::choose_init(I f, I l, int2type&lt;true&gt;)
{
size_type sz = static_cast&lt;size_type&gt;(f);
value_type v = static_cast&lt;value_type&gt;(l);
// construct with sz,v
}
</pre>
</blockquote>
<p>Label this solution 'B'.</p>
<p>Both of these solutions solve the case the standard specifically
mentions:</p>
<pre>vector&lt;int&gt; v(10, 1); // ok, vector size 10, initialized to 1
</pre>
<p>
However, (and here is the problem), the two solutions have different
behavior in some cases where the value_type of the sequence is not an
integral type. For example consider:
</p>
<blockquote><pre> pair&lt;char, char&gt; p('a', 'b');
vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt; d('a', 'b');
</pre></blockquote>
<p>
The second line of this snippet is likely an error. Solution A catches
the error and refuses to compile. The reason is that there is no
specialization of the member template constructor that looks like:
</p>
<pre>template &lt;&gt;
template &lt;&gt;
vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;::vector(char, char) { ... }
</pre>
<p>
So the expression binds to the unspecialized member template
constructor, and then fails (compile time) because char is not an
InputIterator.
</p>
<p>
Solution B compiles the above example though. 'a' is casted to an
unsigned integral type and used to size the outer vector. 'b' is
static casted to the inner vector using it's explicit constructor:
</p>
<pre>explicit vector(size_type n);
</pre>
<p>
and so you end up with a static_cast&lt;size_type&gt;('a') by
static_cast&lt;size_type&gt;('b') matrix.
</p>
<p>
It is certainly possible that this is what the coder intended. But the
explicit qualifier on the inner vector has been thwarted at any rate.
</p>
<p>
The standard is not clear whether the expression:
</p>
<pre> vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt; d('a', 'b');
</pre>
<p>
(and similar expressions) are:
</p>
<ol>
<li> undefined behavior.</li>
<li> illegal and must be rejected.</li>
<li> legal and must be accepted.</li>
</ol>
<p>My preference is listed in the order presented.</p>
<p>There are still other techniques for implementing the requirements of
paragraphs 9-11, namely the "restricted template technique" (e.g.
enable_if). This technique is the most compact and easy way of coding
the requirements, and has the behavior of #2 (rejects the above
expression).
</p>
<p>
Choosing 1 would allow all implementation techniques I'm aware of.
Choosing 2 would allow only solution 'A' and the enable_if technique.
Choosing 3 would allow only solution 'B'.
</p>
<p>
Possible wording for a future standard if we wanted to actively reject
the expression above would be to change "static_cast" in paragraphs
9-11 to "implicit_cast" where that is defined by:
</p>
<blockquote>
<pre>template &lt;class T, class U&gt;
inline
T implicit_cast(const U&amp; u)
{
return u;
}
</pre>
</blockquote>
<p><b>Proposed resolution:</b></p>
Replace 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> paragraphs 9 - 11 with:
<p>For every sequence defined in this clause and in clause lib.strings:</p>
<ul>
<li>
<p>If the constructor</p>
<pre> template &lt;class InputIterator&gt;
X(InputIterator f, InputIterator l,
const allocator_type&amp; a = allocator_type())
</pre>
<p>is called with a type InputIterator that does not qualify as
an input iterator, then the constructor will behave as if the
overloaded constructor:</p>
<pre> X(size_type, const value_type&amp; = value_type(),
const allocator_type&amp; = allocator_type())
</pre>
<p>were called instead, with the arguments static_cast&lt;size_type&gt;(f), l and a, respectively.</p>
</li>
<li>
<p>If the member functions of the forms:</p>
<pre> template &lt;class InputIterator&gt; // such as insert()
rt fx1(iterator p, InputIterator f, InputIterator l);
template &lt;class InputIterator&gt; // such as append(), assign()
rt fx2(InputIterator f, InputIterator l);
template &lt;class InputIterator&gt; // such as replace()
rt fx3(iterator i1, iterator i2, InputIterator f, InputIterator l);
</pre>
<p>are called with a type InputIterator that does not qualify as
an input iterator, then these functions will behave as if the
overloaded member functions:</p>
<pre> rt fx1(iterator, size_type, const value_type&amp;);
rt fx2(size_type, const value_type&amp;);
rt fx3(iterator, iterator, size_type, const value_type&amp;);
</pre>
<p>were called instead, with the same arguments.</p>
</li>
</ul>
<p>In the previous paragraph the alternative binding will fail if f
is not implicitly convertible to X::size_type or if l is not implicitly
convertible to X::value_type.</p>
<p>
The extent to which an implementation determines that a type cannot be
an input iterator is unspecified, except that as a minimum integral
types shall not qualify as input iterators.
</p>
<p><i>[
Kona: agreed that the current standard requires <tt>v('a', 'b')</tt>
to be accepted, and also agreed that this is surprising behavior. The
LWG considered several options, including something like
implicit_cast, which doesn't appear to be quite what we want. We
considered Howards three options: allow acceptance or rejection,
require rejection as a compile time error, and require acceptance. By
straw poll (1-6-1), we chose to require a compile time error.
Post-Kona: Howard provided wording.
]</i></p>
<p><i>[
Sydney: The LWG agreed with this general direction, but there was some
discomfort with the wording in the original proposed resolution.
Howard submitted new wording, and we will review this again in
Redmond.
]</i></p>
<p><i>[Redmond: one very small change in wording: the first argument
is cast to size_t. This fixes the problem of something like
<tt>vector&lt;vector&lt;int&gt; &gt;(5, 5)</tt>, where int is not
implicitly convertible to the value type.]</i></p>
<p><b>Rationale:</b></p>
<p>The proposed resolution fixes:</p>
<pre> vector&lt;int&gt; v(10, 1);
</pre>
<p>
since as integral types 10 and 1 must be disqualified as input
iterators and therefore the (size,value) constructor is called (as
if).</p>
<p>The proposed resolution breaks:</p>
<pre> vector&lt;vector&lt;T&gt; &gt; v(10, 1);
</pre>
<p>
because the integral type 1 is not *implicitly* convertible to
vector&lt;T&gt;. The wording above requires a diagnostic.</p>
<p>
The proposed resolution leaves the behavior of the following code
unspecified.
</p>
<pre> struct A
{
operator int () const {return 10;}
};
struct B
{
B(A) {}
};
vector&lt;B&gt; v(A(), A());
</pre>
<p>
The implementation may or may not detect that A is not an input
iterator and employee the (size,value) constructor. Note though that
in the above example if the B(A) constructor is qualified explicit,
then the implementation must reject the constructor as A is no longer
implicitly convertible to B.
</p>
<hr>
<a name="441"><h3>441.&nbsp;Is fpos::state const?</h3></a><p><b>Section:</b>&nbsp;27.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos"> [lib.fpos]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Vincent Leloup&nbsp; <b>Date:</b>&nbsp;17 Nov 2003</p>
<p>
In section 27.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos.members"> [lib.fpos.members]</a> fpos&lt;stateT&gt;::state() is declared
non const, but in section 27.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos"> [lib.fpos]</a> it is declared const.
......@@ -12484,7 +13108,7 @@ In section 27.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-ios
<tt>fpos&lt;stateT&gt;::state()</tt> to const.
</p>
<hr>
<a name="442"><h3>442.&nbsp;sentry::operator bool() inconsistent signature</h3></a><p><b>Section:</b>&nbsp;27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Vincent Leloup&nbsp; <b>Date:</b>&nbsp;18 Nov 2003</p>
<a name="442"><h3>442.&nbsp;sentry::operator bool() inconsistent signature</h3></a><p><b>Section:</b>&nbsp;27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Vincent Leloup&nbsp; <b>Date:</b>&nbsp;18 Nov 2003</p>
<p>
In section 27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a> paragraph 4, in description part
basic_ostream&lt;charT, traits&gt;::sentry::operator bool() is declared
......@@ -12497,7 +13121,7 @@ In section 27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-ios
of <tt>sentry::operator bool()</tt> to const.
</p>
<hr>
<a name="443"><h3>443.&nbsp;filebuf::close() inconsistent use of EOF</h3></a><p><b>Section:</b>&nbsp;27.8.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.members"> [lib.filebuf.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Vincent Leloup&nbsp; <b>Date:</b>&nbsp;20 Nov 2003</p>
<a name="443"><h3>443.&nbsp;filebuf::close() inconsistent use of EOF</h3></a><p><b>Section:</b>&nbsp;27.8.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.members"> [lib.filebuf.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Vincent Leloup&nbsp; <b>Date:</b>&nbsp;20 Nov 2003</p>
<p>
In section 27.8.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.members"> [lib.filebuf.members]</a> par6, in effects description of
basic_filebuf&lt;charT, traits&gt;::close(), overflow(EOF) is used twice;
......@@ -12508,7 +13132,204 @@ should be overflow(traits::eof()).
Change overflow(EOF) to overflow(traits::eof()).
</p>
<hr>
<a name="448"><h3>448.&nbsp;Random Access Iterators over abstract classes</h3></a><p><b>Section:</b>&nbsp;24.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;7 Jan 2004</p>
<a name="444"><h3>444.&nbsp;Bad use of casts in fstream</h3></a><p><b>Section:</b>&nbsp;27.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstreams"> [lib.fstreams]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Vincent Leloup&nbsp; <b>Date:</b>&nbsp;20 Nov 2003</p>
<p>
27.8.1.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a> p1, 27.8.1.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ofstream.members"> [lib.ofstream.members]</a> p1, 27.8.1.13 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstream.members"> [lib.fstream.members]</a> p1 seems have same problem as exposed in LWG issue
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a>.
</p>
<p><b>Proposed resolution:</b></p>
<p><i>[Sydney: Genuine defect. 27.8.1.13 needs a cast to cast away
constness. The other two places are stylistic: we could change the
C-style casts to const_cast. Post-Sydney: Howard provided wording.
]</i></p>
<p>Change 27.8.1.7/1 from:</p>
<blockquote>
Returns: (basic_filebuf&lt;charT,traits&gt;*)&amp;sb.
</blockquote>
<p>to:</p>
<blockquote>
Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
</blockquote>
<p>Change 27.8.1.10/1 from:</p>
<blockquote>
Returns: (basic_filebuf&lt;charT,traits&gt;*)&amp;sb.
</blockquote>
<p>to:</p>
<blockquote>
Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
</blockquote>
<p>Change 27.8.1.13/1 from:</p>
<blockquote>
Returns: &amp;sb.
</blockquote>
<p>to:</p>
<blockquote>
Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
</blockquote>
<hr>
<a name="445"><h3>445.&nbsp;iterator_traits::reference unspecified for some iterator categories</h3></a><p><b>Section:</b>&nbsp;24.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.traits"> [lib.iterator.traits]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;9 Dec 2003</p>
<p>
The standard places no restrictions at all on the reference type
of input, output, or forward iterators (for forward iterators it
only specifies that *x must be value_type&amp; and doesn't mention
the reference type). Bidirectional iterators' reference type is
restricted only by implication, since the base iterator's
reference type is used as the return type of reverse_iterator's
operator*, which must be T&amp; in order to be a conforming forward
iterator.
</p>
<p>
Here's what I think we ought to be able to expect from an input
or forward iterator's reference type R, where a is an iterator
and V is its value_type
</p>
<ul>
<li>
*a is convertible to R
</li>
<li>
R is convertible to V
</li>
<li>
static_cast&lt;V&gt;(static_cast&lt;R&gt;(*a)) is equivalent to
static_cast&lt;V&gt;(*a)
</li>
</ul>
<p>A mutable forward iterator ought to satisfy, for x of type V:</p>
<li>
{ R r = *a; r = x; } is equivalent to *a = x;
</li>
<p>
I think these requirements capture existing container iterators
(including vector&lt;bool&gt;'s), but render istream_iterator invalid;
its reference type would have to be changed to a constant
reference.
</p>
<p>
(Jeremy Siek) During the discussion in Sydney, it was felt that a
simpler long term solution for this was needed. The solution proposed
was to require <tt>reference</tt> to be the same type as <tt>*a</tt>
and <tt>pointer</tt> to be the same type as <tt>a-&gt;</tt>. Most
iterators in the Standard Library already meet this requirement. Some
iterators are output iterators, and do not need to meet the
requirement, and others are only specified through the general
iterator requirements (which will change with this resolution). The
sole case where there is an explicit definition of the reference type
that will need to change is <tt>istreambuf_iterator</tt> which returns
<tt>charT</tt> from <tt>operator*</tt> but has a reference type of
<tt>charT&amp;</tt>. We propose changing the reference type of
<tt>istreambuf_iterator</tt> to <tt>charT</tt>.
</p>
<p>The other option for resolving the issue with <tt>pointer</tt>,
mentioned in the note below, is to remove <tt>pointer</tt>
altogether. I prefer placing requirements on <tt>pointer</tt> to
removing it for two reasons. First, <tt>pointer</tt> will become
useful for implementing iterator adaptors and in particular,
<tt>reverse_iterator</tt> will become more well defined. Second,
removing <tt>pointer</tt> is a rather drastic and publicly-visible
action to take.</p>
<p>The proposed resolution technically enlarges the requirements for
iterators, which means there are existing iterators (such as
<tt>istreambuf_iterator</tt>, and potentially some programmer-defined
iterators) that will no longer meet the requirements. Will this break
existing code? The scenario in which it would is if an algorithm
implementation (say in the Standard Library) is changed to rely on
<tt>iterator_traits::reference</tt>, and then is used with one of the
iterators that do not have an appropriately defined
<tt>iterator_traits::reference</tt>.
</p>
<p>The proposed resolution makes one other subtle change. Previously,
it was required that output iterators have a <tt>difference_type</tt>
and <tt>value_type</tt> of <tt>void</tt>, which means that a forward
iterator could not be an output iterator. This is clearly a mistake,
so I've changed the wording to say that those types may be
<tt>void</tt>.
</p>
<p><b>Proposed resolution:</b></p>
<p>In 24.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.traits"> [lib.iterator.traits]</a>, after:</p>
<blockquote>
be defined as the iterator's difference type, value type and iterator
category, respectively.
</blockquote>
<p>add</p>
<blockquote>
In addition, the types
<pre>iterator_traits&lt;Iterator&gt;::reference
iterator_traits&lt;Iterator&gt;::pointer
</pre>
must be defined as the iterator's reference and pointer types, that
is, the same type as the type of <tt>*a</tt> and <tt>a-&gt;</tt>,
respectively.
</blockquote>
<p>In 24.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.traits"> [lib.iterator.traits]</a>, change:</p>
<blockquote>
In the case of an output iterator, the types
<pre>iterator_traits&lt;Iterator&gt;::difference_type
iterator_traits&lt;Iterator&gt;::value_type
</pre>
are both defined as <tt>void</tt>.
</blockquote>
<p>to:</p>
<blockquote>
In the case of an output iterator, the types
<pre>iterator_traits&lt;Iterator&gt;::difference_type
iterator_traits&lt;Iterator&gt;::value_type
iterator_traits&lt;Iterator&gt;::reference
iterator_traits&lt;Iterator&gt;::pointer
</pre>
may be defined as <tt>void</tt>.
</blockquote>
<p>In 24.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator"> [lib.istreambuf.iterator]</a>, change:</p>
<blockquote>
<pre>typename traits::off_type, charT*, charT&amp;&gt;
</pre>
</blockquote>
<p>to:</p>
<blockquote>
<pre>typename traits::off_type, charT*, charT&gt;
</pre>
</blockquote>
<p><i>[
Redmond: there was concern in Sydney that this might not be the only place
where things were underspecified and needed to be changed. Jeremy
reviewed iterators in the standard and confirmed that nothing else
needed to be changed.
]</i></p>
<hr>
<a name="448"><h3>448.&nbsp;Random Access Iterators over abstract classes</h3></a><p><b>Section:</b>&nbsp;24.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;7 Jan 2004</p>
<p>
Table 76, the random access iterator requirement table, says that the
return type of a[n] must be "convertible to T". When an iterator's
......@@ -12520,7 +13341,7 @@ Surely this isn't an intended restriction?
Change the return type to "convertible to T const&amp;".
</p>
<hr>
<a name="449"><h3>449.&nbsp;Library Issue 306 Goes Too Far</h3></a><p><b>Section:</b>&nbsp;18.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.types"> [lib.support.types]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Pete Becker&nbsp; <b>Date:</b>&nbsp;15 Jan 2004</p>
<a name="449"><h3>449.&nbsp;Library Issue 306 Goes Too Far</h3></a><p><b>Section:</b>&nbsp;18.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.types"> [lib.support.types]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Pete Becker&nbsp; <b>Date:</b>&nbsp;15 Jan 2004</p>
<p>Original text:</p>
<blockquote>
The macro offsetof accepts a restricted set of type arguments in this
......@@ -12549,5 +13370,126 @@ the results are undefined. The result of applying the offsetof macro
to a field that is a static data member or a function member is
undefined."
</blockquote>
<hr>
<a name="453"><h3>453.&nbsp;basic_stringbuf::seekoff need not always fail for an empty stream</h3></a><p><b>Section:</b>&nbsp;27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Bill Plauger&nbsp; <b>Date:</b>&nbsp;30 Jan 2004</p>
<pre> pos_type basic_stringbuf::seekoff(off_type, ios_base::seekdir,
ios_base::openmode);
</pre>
<p>
is obliged to fail if nothing has been inserted into the stream. This
is unnecessary and undesirable. It should be permissible to seek to
an effective offset of zero.</p>
<p><i>[
Sydney: Agreed that this is an annoying problem: seeking to zero should be
legal. Bill will provide wording.
]</i></p>
<p><b>Proposed resolution:</b></p>
<p>Change the sentence from:</p>
<blockquote>
For a sequence to be positioned, if its next pointer (either
gptr() or pptr()) is a null pointer, the positioning operation
fails.
</blockquote>
<p>to:</p>
<blockquote>
For a sequence to be positioned, if its next pointer (either
gptr() or pptr()) is a null pointer and the new offset newoff
is nonzero, the positioning operation fails.
</blockquote>
<hr>
<a name="455"><h3>455.&nbsp;cerr::tie() and wcerr::tie() are overspecified</h3></a><p><b>Section:</b>&nbsp;27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Bill Plauger&nbsp; <b>Date:</b>&nbsp;30 Jan 2004</p>
<p>
Both cerr::tie() and wcerr::tie() are obliged to be null at program
startup. This is overspecification and overkill. It is both traditional
and useful to tie cerr to cout, to ensure that standard output is drained
whenever an error message is written. This behavior should at least be
permitted if not required. Same for wcerr::tie().
</p>
<p><b>Proposed resolution:</b></p>
<p>Add to the description of cerr:</p>
<blockquote>
After the object cerr is initialized, cerr.tie() returns &amp;cout.
Its state is otherwise the same as required for basic_ios&lt;char&gt;::init
(lib.basic.ios.cons).
</blockquote>
<p>Add to the description of wcerr:</p>
<blockquote>
After the object wcerr is initialized, wcerr.tie() returns &amp;wcout.
Its state is otherwise the same as required for basic_ios&lt;wchar_t&gt;::init
(lib.basic.ios.cons).
</blockquote>
<p><i>[Sydney: straw poll (3-1): we should <i>require</i>, not just
permit, cout and cerr to be tied on startup. Pre-Redmond: Bill will
provide wording.]</i></p>
<hr>
<a name="457"><h3>457.&nbsp;bitset constructor: incorrect number of initialized bits</h3></a><p><b>Section:</b>&nbsp;23.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Dag Henriksson&nbsp; <b>Date:</b>&nbsp;30 Jan 2004</p>
<p>
The constructor from unsigned long says it initializes "the first M
bit positions to the corresponding bit values in val. M is the smaller
of N and the value CHAR_BIT * sizeof(unsigned long)."
</p>
<p>
Object-representation vs. value-representation strikes again. CHAR_BIT *
sizeof (unsigned long) does not give us the number of bits an unsigned long
uses to hold the value. Thus, the first M bit position above is not
guaranteed to have any corresponding bit values in val.
</p>
<p><b>Proposed resolution:</b></p>
<p>In 23.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</a> paragraph 2, change "M is the smaller of
N and the value CHAR_BIT * sizeof (unsigned long). (249)" to
"<tt>M</tt> is the smaller of <tt>N</tt> and the number of bits in
the value representation (section 3.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/basic.html#basic.types"> [basic.types]</a>) of <tt>unsigned
long</tt>."
</p>
<hr>
<a name="460"><h3>460.&nbsp;Default modes missing from basic_fstream member specifications</h3></a><p><b>Section:</b>&nbsp;27.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstreams"> [lib.fstreams]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Ben Hutchings&nbsp; <b>Date:</b>&nbsp;1 Apr 2004</p>
<p>
The second parameters of the non-default constructor and of the open
member function for basic_fstream, named "mode", are optional
according to the class declaration in 27.8.1.11 [lib.fstream]. The
specifications of these members in 27.8.1.12 [lib.fstream.cons] and
27.8.1.13 lib.fstream.members] disagree with this, though the
constructor declaration has the "explicit" function-specifier implying
that it is intended to be callable with one argument.
</p>
<p><b>Proposed resolution:</b></p>
<p>In 27.8.1.12 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstream.cons"> [lib.fstream.cons]</a>, change</p>
<pre> explicit basic_fstream(const char* s, ios_base::openmode mode);
</pre>
<p>to</p>
<pre> explicit basic_fstream(const char* s,
ios_base::openmode mode = ios_base::in|ios_base::out);
</pre>
<p>In 27.8.1.13 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstream.members"> [lib.fstream.members]</a>, change</p>
<pre> void open(const char*s, ios_base::openmode mode);
</pre>
<p>to</p>
void open(const char*s,
ios_base::openmode mode = ios_base::in|ios_base::out);
<hr>
<a name="469"><h3>469.&nbsp;vector&lt;bool&gt; ill-formed relational operators</h3></a><p><b>Section:</b>&nbsp;23.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.bool"> [lib.vector.bool]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jun 2004</p>
<p>
The overloads of relational operators for vector&lt;bool&gt; specified
in [lib.vector.bool] are redundant (they are semantically identical
to those provided for the vector primary template) and may even be
diagnosed as ill-formed (refer to Daveed Vandevoorde's explanation
in c++std-lib-13647).
</p>
<p><b>Proposed resolution:</b></p>
<p>
Remove all overloads of overloads of relational operators for
vector&lt;bool&gt; from [lib.vector.bool].
</p>
<p>----- End of document -----</p>
</body></html>
\ No newline at end of file
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment