Skip to content

R
riscv-gcc-1
Commit e4b600fb by Paolo Carlini Committed by Paolo Carlini
Options

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

2005-10-25  Paolo Carlini  <pcarlini@suse.de>

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

From-SVN: r105884
parent 6868dfa0
Showing with 1425 additions and 448 deletions
libstdc++-v3/ChangeLog
2005-10-25 Paolo Carlini <pcarlini@suse.de>
* docs/html/ext/lwg-active.html, lwg-defects.html: Import Revision 39.
* docs/html/ext/howto.html: Adjust.
2005-10-21 Paolo Carlini <pcarlini@suse.de> 2005-10-21 Paolo Carlini <pcarlini@suse.de>
PR libstdc++/24450 PR libstdc++/24450
......
libstdc++-v3/docs/html/ext/howto.html
...@@ -453,7 +453,7 @@ ...@@ -453,7 +453,7 @@
<dd>Similar to 118. <dd>Similar to 118.
</dd> </dd>
<dt><a href="lwg-active.html#280">280</a>: <dt><a href="lwg-defects.html#280">280</a>:
<em>Comparison of reverse_iterator to const reverse_iterator</em> <em>Comparison of reverse_iterator to const reverse_iterator</em>
</dt> </dt>
<dd>Add global functions with two template parameters. <dd>Add global functions with two template parameters.
...@@ -528,7 +528,7 @@ ...@@ -528,7 +528,7 @@
<dd>Don't fail if the next pointer is null and newoff is zero. <dd>Don't fail if the next pointer is null and newoff is zero.
</dd> </dd>
<dt><a href="lwg-active.html#464">464</a>: <dt><a href="lwg-defects.html#464">464</a>:
<em>Suggestion for new member functions in standard containers</em> <em>Suggestion for new member functions in standard containers</em>
</dt> </dt>
<dd>Add <code>data()</code> to <code>std::vector</code> and <dd>Add <code>data()</code> to <code>std::vector</code> and
......
libstdc++-v3/docs/html/ext/lwg-active.html
...@@ -5,11 +5,11 @@ ...@@ -5,11 +5,11 @@
<table> <table>
<tbody><tr> <tbody><tr>
<td align="left">Doc. no.</td> <td align="left">Doc. no.</td>
<td align="left">N1830=05-0090</td> <td align="left">N1908=05-0168</td>
</tr> </tr>
<tr> <tr>
<td align="left">Date:</td> <td align="left">Date:</td>
<td align="left">2005-06-24</td> <td align="left">2005-10-23</td>
</tr> </tr>
<tr> <tr>
<td align="left">Project:</td> <td align="left">Project:</td>
...@@ -20,7 +20,7 @@ ...@@ -20,7 +20,7 @@
<td align="left">Howard Hinnant &lt;howard.hinnant@gmail.com&gt;</td> <td align="left">Howard Hinnant &lt;howard.hinnant@gmail.com&gt;</td>
</tr> </tr>
</tbody></table> </tbody></table>
<h1>C++ Standard Library Active Issues List (Revision R37)</h1> <h1>C++ Standard Library Active Issues List (Revision R39)</h1>
<p>Reference ISO/IEC IS 14882:1998(E)</p> <p>Reference ISO/IEC IS 14882:1998(E)</p>
<p>Also see:</p> <p>Also see:</p>
<ul> <ul>
...@@ -88,6 +88,21 @@ ...@@ -88,6 +88,21 @@
directory as the issues list files. </p> directory as the issues list files. </p>
<h2>Revision History</h2> <h2>Revision History</h2>
<ul> <ul>
<li>R39:
2005-10-14 post-Mont Tremblant mailing.
Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#526">526</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#528">528</a>.
Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461">461</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464">464</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#465">465</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#467">467</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#474">474</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#496">496</a> from Ready to WP as per the vote from Mont Tremblant.
Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a>, <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#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#497">497</a> from Review to Ready.
Moved 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#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#514">514</a> from New to Open.
Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#519">519</a> from New to Ready.
Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a> from New to Review.
</li>
<li>R38:
2005-07-03 pre-Mont Tremblant mailing.
Merged open TR1 issues in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#504">504</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>.
Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>
</li>
<li>R37: <li>R37:
2005-06 mid-term mailing. 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>. 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>.
...@@ -679,7 +694,7 @@ feedback from Lillehammer with more information regarding performance. ...@@ -679,7 +694,7 @@ feedback from Lillehammer with more information regarding performance.
]</i></p> ]</i></p>
<hr> <hr>
<a name="247"><h3>247.&nbsp;<tt>vector</tt>, <tt>deque::insert</tt> complexity</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#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Lisa Lippincott&nbsp; <b>Date:</b>&nbsp;06 June 2000</p> <a name="247"><h3>247.&nbsp;<tt>vector</tt>, <tt>deque::insert</tt> complexity</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#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Lisa Lippincott&nbsp; <b>Date:</b>&nbsp;06 June 2000</p>
<p>Paragraph 2 of 23.2.4.3 [lib.vector.modifiers] describes the complexity <p>Paragraph 2 of 23.2.4.3 [lib.vector.modifiers] describes the complexity
of <tt>vector::insert</tt>:</p> of <tt>vector::insert</tt>:</p>
...@@ -953,73 +968,6 @@ the second line from the bottom in table 32 already implies the ...@@ -953,73 +968,6 @@ the second line from the bottom in table 32 already implies the
desired property. This issue should be considered in light of desired property. This issue should be considered in light of
other issues related to allocator instances.]</i></p> other issues related to allocator instances.]</i></p>
<hr> <hr>
<a name="280"><h3>280.&nbsp;Comparison of reverse_iterator to const reverse_iterator</h3></a><p><b>Section:</b>&nbsp;24.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iterators"> [lib.reverse.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Cleary&nbsp; <b>Date:</b>&nbsp;27 Nov 2000</p>
<p>
This came from an email from Steve Cleary to Fergus in reference to
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>. The library working group briefly discussed
this in Toronto and believed it should be a separate issue. There was
also some reservations about whether this was a worthwhile problem to
fix.
</p>
<p>
Steve said: "Fixing reverse_iterator. std::reverse_iterator can
(and should) be changed to preserve these additional
requirements." He also said in email that it can be done without
breaking user's code: "If you take a look at my suggested
solution, reverse_iterator doesn't have to take two parameters; there
is no danger of breaking existing code, except someone taking the
address of one of the reverse_iterator global operator functions, and
I have to doubt if anyone has ever done that. . . <i>But</i>, just in
case they have, you can leave the old global functions in as well --
they won't interfere with the two-template-argument functions. With
that, I don't see how <i>any</i> user code could break."
</p>
<p><b>Proposed resolution:</b></p>
<p>
<b>Section:</b> 24.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iterator"> [lib.reverse.iterator]</a>
add/change the following declarations:</p>
<pre> A) Add a templated assignment operator, after the same manner
as the templated copy constructor, i.e.:
template &lt; class U &gt;
reverse_iterator &lt; Iterator &gt;&amp; operator=(const reverse_iterator&lt; U &gt;&amp; u);
B) Make all global functions (except the operator+) have
two template parameters instead of one, that is, for
operator ==, !=, &lt;, &gt;, &lt;=, &gt;=, - replace:
template &lt; class Iterator &gt;
typename reverse_iterator&lt; Iterator &gt;::difference_type operator-(
const reverse_iterator&lt; Iterator &gt;&amp; x,
const reverse_iterator&lt; Iterator &gt;&amp; y);
with:
template &lt; class Iterator1, class Iterator2 &gt;
typename reverse_iterator &lt; Iterator1 &gt;::difference_type operator-(
const reverse_iterator &lt; Iterator1 &gt; &amp; x,
const reverse_iterator &lt; Iterator2 &gt; &amp; y);
</pre>
<p>
Also make the addition/changes for these signatures in
24.4.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.ops"> [lib.reverse.iter.ops]</a>.
</p>
<p><i>[
Copenhagen: The LWG is concerned that the proposed resolution
introduces new overloads. Experience shows that introducing
overloads is always risky, and that it would be inappropriate to
make this change without implementation experience. It may be
desirable to provide this feature in a different way.
]</i></p>
<p><i>[
Lillehammer: We now have implementation experience, and agree that
this solution is safe and correct.
]</i></p>
<hr>
<a name="290"><h3>290.&nbsp;Requirements to for_each and its function object</h3></a><p><b>Section:</b>&nbsp;25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;03 Jan 2001</p> <a name="290"><h3>290.&nbsp;Requirements to for_each and its function object</h3></a><p><b>Section:</b>&nbsp;25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;03 Jan 2001</p>
<p>The specification of the for_each algorithm does not have a <p>The specification of the for_each algorithm does not have a
"Requires" section, which means that there are no "Requires" section, which means that there are no
...@@ -1053,7 +1001,7 @@ algorithm does not say so. ...@@ -1053,7 +1001,7 @@ algorithm does not say so.
iterators unless otherwise specified. Bill will provide wording.]</i></p> iterators unless otherwise specified. Bill will provide wording.]</i></p>
<hr> <hr>
<a name="294"><h3>294.&nbsp;User defined macros and standard headers</h3></a><p><b>Section:</b>&nbsp;17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze&nbsp; <b>Date:</b>&nbsp;11 Jan 2001</p> <a name="294"><h3>294.&nbsp;User defined macros and standard headers</h3></a><p><b>Section:</b>&nbsp;17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze&nbsp; <b>Date:</b>&nbsp;11 Jan 2001</p>
<p>Paragraph 2 of 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a> reads: "A <p>Paragraph 2 of 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a> reads: "A
translation unit that includes a header shall not contain any macros translation unit that includes a header shall not contain any macros
that define names declared in that header." As I read this, it that define names declared in that header." As I read this, it
...@@ -1204,7 +1152,7 @@ with a return type of convertible to <tt>T</tt> and operational semantics of ...@@ -1204,7 +1152,7 @@ with a return type of convertible to <tt>T</tt> and operational semantics of
iterator redesign]</i></p> iterator redesign]</i></p>
<hr> <hr>
<a name="342"><h3>342.&nbsp;seek and eofbit</h3></a><p><b>Section:</b>&nbsp;27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;09 Oct 2001</p> <a name="342"><h3>342.&nbsp;seek and eofbit</h3></a><p><b>Section:</b>&nbsp;27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;09 Oct 2001</p>
<p>I think we have a defect.</p> <p>I think we have a defect.</p>
<p>According to lwg issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a> which is now a dr, the <p>According to lwg issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a> which is now a dr, the
...@@ -1291,7 +1239,7 @@ In case of failure, the function calls <tt>setstate(failbit)</tt> ...@@ -1291,7 +1239,7 @@ In case of failure, the function calls <tt>setstate(failbit)</tt>
or <tt>badbit</tt> is set, so using <tt>!fail()</tt>, rather or <tt>badbit</tt> is set, so using <tt>!fail()</tt>, rather
than <tt>good()</tt>, satisfies this goal.</p> than <tt>good()</tt>, satisfies this goal.</p>
<hr> <hr>
<a name="362"><h3>362.&nbsp;bind1st/bind2nd type safety</h3></a><p><b>Section:</b>&nbsp;20.3.6.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.bind.1st"> [lib.bind.1st]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Demkin&nbsp; <b>Date:</b>&nbsp;26 Apr 2002</p> <a name="362"><h3>362.&nbsp;bind1st/bind2nd type safety</h3></a><p><b>Section:</b>&nbsp;20.3.6.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.bind.1st"> [lib.bind.1st]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Demkin&nbsp; <b>Date:</b>&nbsp;26 Apr 2002</p>
<p> <p>
The definition of bind1st() (20.3.6.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.bind.1st"> [lib.bind.1st]</a>) can result in The definition of bind1st() (20.3.6.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.bind.1st"> [lib.bind.1st]</a>) can result in
the construction of an unsafe binding between incompatible pointer the construction of an unsafe binding between incompatible pointer
...@@ -1339,7 +1287,7 @@ as a reinterpret_cast, thus masking the error. ...@@ -1339,7 +1287,7 @@ as a reinterpret_cast, thus masking the error.
<p>There is no point in fixing bind1st and bind2nd. tr1::bind is a <p>There is no point in fixing bind1st and bind2nd. tr1::bind is a
superior solution. It solves this problem and others.</p> superior solution. It solves this problem and others.</p>
<hr> <hr>
<a name="369"><h3>369.&nbsp;io stream objects and static ctors</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#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Ruslan Abdikeev&nbsp; <b>Date:</b>&nbsp;8 Jul 2002</p> <a name="369"><h3>369.&nbsp;io stream objects and static ctors</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#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Ruslan Abdikeev&nbsp; <b>Date:</b>&nbsp;8 Jul 2002</p>
<p> <p>
Is it safe to use standard iostream objects from constructors of Is it safe to use standard iostream objects from constructors of
static objects? Are standard iostream objects constructed and are static objects? Are standard iostream objects constructed and are
...@@ -1407,15 +1355,18 @@ mention of an _instance_ of ios_base::Init in Standard. ...@@ -1407,15 +1355,18 @@ mention of an _instance_ of ios_base::Init in Standard.
<p>Add to 27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>, p2, immediately before the last sentence <p>Add to 27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>, p2, immediately before the last sentence
of the paragraph, the following two sentences:</p> of the paragraph, the following two sentences:</p>
<blockquote> <blockquote>
If a translation unit includes &lt;iostream&gt;, or explicitly If a translation unit includes &lt;iostream&gt;, or explicitly
constructs an ios_base::Init object, dynamic initialization of objects constructs an ios_base::Init object, these stream objects shall
later in that translation unit may assume that these stream objects be constructed before dynamic initialization of non-local
have been constructed and destructors may assume that these stream objects defined later in that translation unit, and these stream
objects have not yet been destroyed. objects shall be destroyed after the destruction of dynamically
initialized non-local objects defined later in that translation unit.
</blockquote> </blockquote>
<p><i>[Lillehammer: Matt provided wording.]</i></p> <p><i>[Lillehammer: Matt provided wording.]</i></p>
<p><i>[Mont Tremblant: Matt provided revised wording.]</i></p>
<p><b>Rationale:</b></p> <p><b>Rationale:</b></p>
<p> <p>
The original proposed resolution unconditionally required The original proposed resolution unconditionally required
...@@ -1432,7 +1383,7 @@ object.</p> ...@@ -1432,7 +1383,7 @@ object.</p>
The new proposed resolution gives users guidance on what they need to The new proposed resolution gives users guidance on what they need to
do to ensure that stream objects are constructed during startup.</p> do to ensure that stream objects are constructed during startup.</p>
<hr> <hr>
<a name="371"><h3>371.&nbsp;Stability of multiset and multimap member functions</h3></a><p><b>Section:</b>&nbsp;23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Frank Compagner&nbsp; <b>Date:</b>&nbsp;20 Jul 2002</p> <a name="371"><h3>371.&nbsp;Stability of multiset and multimap member functions</h3></a><p><b>Section:</b>&nbsp;23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Frank Compagner&nbsp; <b>Date:</b>&nbsp;20 Jul 2002</p>
<p> <p>
The requirements for multiset and multimap containers (23.1 The requirements for multiset and multimap containers (23.1
[lib.containers.requirements], 23.1.2 [lib.associative.reqmnts], [lib.containers.requirements], 23.1.2 [lib.associative.reqmnts],
...@@ -1489,7 +1440,7 @@ erase_if() member function that much greater. ...@@ -1489,7 +1440,7 @@ erase_if() member function that much greater.
<p><b>Proposed resolution:</b></p> <p><b>Proposed resolution:</b></p>
<p>Add the following to the end of 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> paragraph 4: <p>Add the following to the end of 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> paragraph 4:
"For <tt>set</tt> and <tt>map</tt>, <tt>insert</tt>and <tt>erase</tt> "For <tt>multiset</tt> and <tt>multimap</tt>, <tt>insert</tt>and <tt>erase</tt>
are <i>stable</i>: they preserve the relative ordering of equivalent are <i>stable</i>: they preserve the relative ordering of equivalent
elements.</p> elements.</p>
...@@ -1498,14 +1449,17 @@ erase_if() member function that much greater. ...@@ -1498,14 +1449,17 @@ erase_if() member function that much greater.
multimap and multiset. N1780 also addresses this issue and suggests multimap and multiset. N1780 also addresses this issue and suggests
wording.]</i></p> wording.]</i></p>
<p><i>[Mont Tremblant: Changed set and map to multiset and multimap.]</i></p>
<p><b>Rationale:</b></p> <p><b>Rationale:</b></p>
<p>The LWG agrees that this guarantee is necessary for common user <p>The LWG agrees that this guarantee is necessary for common user
idioms to work, and that all existing implementations provide this idioms to work, and that all existing implementations provide this
property. Note that this resolution guarantees stability for property. Note that this resolution guarantees stability for
multimap and multiset, not for all associative containers in multimap and multiset, not for all associative containers in
general.</p> general.</p>
<hr> <hr>
<a name="376"><h3>376.&nbsp;basic_streambuf semantics</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#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;14 Aug 2002</p> <a name="376"><h3>376.&nbsp;basic_streambuf semantics</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#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;14 Aug 2002</p>
<p> <p>
In Section 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>, Table 90, the implication is that In Section 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>, Table 90, the implication is that
the four conditions should be mutually exclusive, but they are not. the four conditions should be mutually exclusive, but they are not.
...@@ -1653,7 +1607,7 @@ partial can only occur if (from_next != from_end)? ...@@ -1653,7 +1607,7 @@ partial can only occur if (from_next != from_end)?
we need to make sure Martin and Howard agree.]</i></p> we need to make sure Martin and Howard agree.]</i></p>
<hr> <hr>
<a name="384"><h3>384.&nbsp;equal_range has unimplementable runtime complexity</h3></a><p><b>Section:</b>&nbsp;25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Hans Bos&nbsp; <b>Date:</b>&nbsp;18 Oct 2002</p> <a name="384"><h3>384.&nbsp;equal_range has unimplementable runtime complexity</h3></a><p><b>Section:</b>&nbsp;25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Hans Bos&nbsp; <b>Date:</b>&nbsp;18 Oct 2002</p>
<p> <p>
Section 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a> Section 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a>
states that at most 2 * log(last - first) + 1 states that at most 2 * log(last - first) + 1
...@@ -1952,7 +1906,7 @@ functions should be changed as proposed below. ...@@ -1952,7 +1906,7 @@ functions should be changed as proposed below.
<p><b>Rationale:</b></p> <p><b>Rationale:</b></p>
<hr> <hr>
<a name="396"></a><h3><a name="396">396.&nbsp;what are characters zero and one</a></h3><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#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;5 Jan 2003</p> <a name="396"><h3>396.&nbsp;what are characters zero and one</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#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;5 Jan 2003</p>
<p> <p>
23.3.5.1, p6 [lib.bitset.cons] talks about a generic character 23.3.5.1, p6 [lib.bitset.cons] talks about a generic character
having the value of 0 or 1 but there is no definition of what having the value of 0 or 1 but there is no definition of what
...@@ -3147,7 +3101,7 @@ operational semantics for this column to: ...@@ -3147,7 +3101,7 @@ operational semantics for this column to:
</code> </code>
<hr> <hr>
<a name="459"><h3>459.&nbsp;Requirement for widening in stage 2 is overspecification</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;16 Mar 2004</p> <a name="459"></a><h3><a name="459">459.&nbsp;Requirement for widening in stage 2 is overspecification</a></h3><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;16 Mar 2004</p>
<p>When parsing strings of wide-character digits, the standard <p>When parsing strings of wide-character digits, the standard
requires the library to widen narrow-character "atoms" and compare requires the library to widen narrow-character "atoms" and compare
the widened atoms against the characters that are being parsed. the widened atoms against the characters that are being parsed.
...@@ -3224,95 +3178,6 @@ technique to perform the comparison:</p> ...@@ -3224,95 +3178,6 @@ technique to perform the comparison:</p>
if it the source and destination types are the same</li> if it the source and destination types are the same</li>
</ol> </ol>
<hr> <hr>
<a name="461"><h3>461.&nbsp;time_get hard or impossible to implement</h3></a><p><b>Section:</b>&nbsp;22.2.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.get.virtuals"> [lib.locale.time.get.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Bill Plauger&nbsp; <b>Date:</b>&nbsp;23 Mar 2004</p>
<p>
Template time_get currently contains difficult, if not impossible,
requirements for do_date_order, do_get_time, and do_get_date. All require
the implementation to scan a field generated by the %x or %X conversion
specifier in strftime. Yes, do_date_order can always return no_order, but
that doesn't help the other functions. The problem is that %x can be
nearly anything, and it can vary widely with locales. It's horribly
onerous to have to parse "third sunday after Michaelmas in the year of
our Lord two thousand and three," but that's what we currently ask of
do_get_date. More practically, it leads some people to think that if
%x produces 10.2.04, we should know to look for dots as separators. Still
not easy.
</p>
<p>
Note that this is the <i>opposite</i> effect from the intent stated in the
footnote earlier in this subclause:
</p>
<blockquote>
"In other words, user confirmation is required for reliable parsing of
user-entered dates and times, but machine-generated formats can be
parsed reliably. This allows parsers to be aggressive about interpreting
user variations on standard formats."
</blockquote>
<p>
We should give both implementers and users an easier and more reliable
alternative: provide a (short) list of alternative delimiters and say
what the default date order is for no_order. For backward compatibility,
and maximum latitude, we can permit an implementation to parse whatever
%x or %X generates, but we shouldn't require it.
</p>
<p><b>Proposed resolution:</b></p>
<p><b>In the description:</b></p>
<pre>iter_type do_get_time(iter_type s, iter_type end, ios_base&amp; str,
ios_base::iostate&amp; err, tm* t) const;
</pre>
<p>
2 Effects: Reads characters starting at suntil it has extracted those
struct tm members, and remaining format characters, used by
time_put&lt;&gt;::put to produce the format specified by 'X', or until it
encounters an error or end of sequence.
</p>
<p><b>change:</b> 'X'</p>
<p><b>to:</b> "%H:%M:%S"</p>
<p>Change</p>
<pre>iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
ios_base::iostate&amp; err, tm* t) const;
4 Effects: Reads characters starting at s until it has extracted those
struct tm members, and remaining format characters, used by
time_put&lt;&gt;::put to produce the format specified by 'x', or until it
encounters an error.
</pre>
<p>to</p>
iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
ios_base::iostate&amp; err, tm* t) const;
4 Effects: Reads characters starting at s until it has extracted those
struct tm members, and remaining format characters, used by
time_put&lt;&gt;::put to produce one of the following formats, or until it
encounters an error. The format depends on the value returned by
date_order() as follows:
date_order() format
no_order "%m/%d/%y"
dmy "%d/%m/%y"
mdy "%m/%d/%y"
ymd "%y/%m/%d"
ydm "%y/%d/%m"
An implementation may also accept additional implementation-defined formats.
<pre></pre>
<p><i>[Redmond: agreed that this is a real problem. The solution is
probably to match C99's parsing rules. Bill provided wording.
]</i></p>
<hr>
<a name="462"><h3>462.&nbsp;Destroying objects with static storage duration</h3></a><p><b>Section:</b>&nbsp;3.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/basic.html#basic.start.term"> [basic.start.term]</a>, 18.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.start.term"> [lib.support.start.term]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Bill Plauger&nbsp; <b>Date:</b>&nbsp;23 Mar 2004</p> <a name="462"><h3>462.&nbsp;Destroying objects with static storage duration</h3></a><p><b>Section:</b>&nbsp;3.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/basic.html#basic.start.term"> [basic.start.term]</a>, 18.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.start.term"> [lib.support.start.term]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Bill Plauger&nbsp; <b>Date:</b>&nbsp;23 Mar 2004</p>
<p> <p>
3.6.3 Termination spells out in detail the interleaving of static 3.6.3 Termination spells out in detail the interleaving of static
...@@ -3601,107 +3466,6 @@ from r-value derived to base). ...@@ -3601,107 +3466,6 @@ from r-value derived to base).
want to fix auto_ptr for C++-0x, or remove it and replace it with want to fix auto_ptr for C++-0x, or remove it and replace it with
move_ptr and unique_ptr.]</i></p> move_ptr and unique_ptr.]</i></p>
<hr> <hr>
<a name="464"><h3>464.&nbsp;Suggestion for new member functions in standard containers</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>, 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Thorsten Ottosen&nbsp; <b>Date:</b>&nbsp;12 May 2004</p>
<p>To add slightly more convenience to vector&lt;T&gt; and map&lt;Key,T&gt; we should consider to add</p>
<ol>
<li> add vector&lt;T&gt;::data() member (const and non-const version)
semantics: if( empty() ) return 0; else return buffer_;</li>
<li> add map&lt;Key,T&gt;::at( const Key&amp; k ) member (const and non-const version)
<i>semantics</i>: iterator i = find( k ); if( i != end() ) return *i; else throw range_error();</li>
</ol>
<p>Rationale:</p>
<ul>
<li>To obtain a pointer to the vector's buffer, one must use either
operator[]() (which can give undefined behavior for empty vectors) or
at() (which will then throw if the vector is empty). </li>
<li>tr1::array&lt;T,sz&gt; already has a data() member</li>
<li>e cannot use operator[]() when T is not DefaultDonstructible</li>
<li>Neither when the map is const.</li>
<li>when we want to make sure we don't add an element accidently</li>
<li>when it should be considered an error if a key is not in the map</li>
</ul>
<p><b>Proposed resolution:</b></p>
<p>In 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>, add the following to the <tt>vector</tt>
synopsis after "element access" and before "modifiers":</p>
<pre> // <i>[lib.vector.data] data access</i>
pointer data();
const_pointer data() const;
</pre>
<p>Add a new subsection of 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>:</p>
<blockquote>
<p>23.2.4.x <tt>vector</tt> data access</p>
<pre> pointer data();
const_pointer data() const;
</pre>
<p><b>Returns:</b> A pointer such that [data(), data() + size()) is a valid
range. For a non-empty vector, data() == &amp;front().</p>
<p><b>Complexity:</b> Constant time.</p>
<p><b>Throws:</b> Nothing.</p>
</blockquote>
<p>In 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a>, add the following to the <tt>map</tt>
synopsis immediately after the line for operator[]:</p>
<pre> T&amp; at(const key_type&amp; x);
const T&amp; at(const key_type&amp; x) const;
</pre>
<p>Add the following to 23.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map.access"> [lib.map.access]</a>:</p>
<blockquote>
<pre> T&amp; at(const key_type&amp; x);
const T&amp; at(const key_type&amp; x) const;
</pre>
<p><b>Returns:</b> A reference to the element whose key is equivalent
to x, if such an element is present in the map.</p>
<p><b>Throws:</b> <tt>out_of_range</tt> if no such element is present.</p>
</blockquote>
<p><b>Rationale:</b></p>
<p>Neither of these additions provides any new functionality but the
LWG agreed that they are convenient, especially for novices. The
exception type chosen for <tt>at</tt>, <tt>std::out_of_range</tt>,
was chosen to match <tt>vector::at</tt>.</p>
<hr>
<a name="465"><h3>465.&nbsp;Contents of &lt;ciso646&gt;</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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;3 Jun 2004</p>
<p>C header &lt;iso646.h&gt; defines macros for some operators, such as
not_eq for !=.</p>
<p>Section 17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a> "Headers" says that except as noted in
clauses 18 through 27, the &lt;cname&gt; C++ header contents are the same
as the C header &lt;name.h&gt;. In particular, table 12 lists
&lt;ciso646&gt; as a C++ header.</p>
<p>I don't find any other mention of &lt;ciso646&gt;, or any mention of
&lt;iso646.h&gt;, in clauses 17 thorough 27. That implies that the
contents of &lt;ciso646&gt; are the same as C header &lt;iso646.h&gt;.</p>
<p>Annex C (informative, not normative) in [diff.header.iso646.h] C.2.2.2
"Header &lt;iso646.h&gt;" says that the alternative tokens are not
defined as macros in &lt;ciso646&gt;, but does not mention the contents
of &lt;iso646.h&gt;.</p>
<p>I don't find any normative text to support C.2.2.2.</p>
<p><b>Proposed resolution:</b></p>
<p>Add to section 17.4.1.2 Headers [lib.headers] a new paragraph after
paragraph 6 (the one about functions must be functions):</p>
<blockquote>
<p>Identifiers that are keywords or operators in C++ shall not be defined
as macros in C++ standard library headers.
[Footnote:In particular, including the standard header &lt;iso646.h&gt;
or &lt;ciso646&gt; has no effect. </p>
</blockquote>
<p><i>[post-Redmond: Steve provided wording.]</i></p>
<hr>
<a name="466"><h3>466.&nbsp;basic_string ctor should prevent null pointer error</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#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Daniel Frey&nbsp; <b>Date:</b>&nbsp;10 Jun 2004</p> <a name="466"><h3>466.&nbsp;basic_string ctor should prevent null pointer error</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#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Daniel Frey&nbsp; <b>Date:</b>&nbsp;10 Jun 2004</p>
<p> <p>
Today, my colleagues and me wasted a lot of time. After some time, I Today, my colleagues and me wasted a lot of time. After some time, I
...@@ -3731,104 +3495,6 @@ ambiguate any other legal ctors.</p> ...@@ -3731,104 +3495,6 @@ ambiguate any other legal ctors.</p>
value is a null pointer), at run time, or both.]</i></p> value is a null pointer), at run time, or both.]</i></p>
<hr> <hr>
<a name="467"><h3>467.&nbsp;char_traits::lt(), compare(), and memcmp()</h3></a><p><b>Section:</b>&nbsp;21.1.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits.specializations.char"> [lib.char.traits.specializations.char]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jun 2004</p>
<p>
Table 37 describes the requirements on Traits::compare() in terms of
those on Traits::lt(). 21.1.3.1, p6 requires char_traits&lt;char&gt;::lt()
to yield the same result as operator&lt;(char, char).
</p>
<p>
Most, if not all, implementations of char_traits&lt;char&gt;::compare()
call memcmp() for efficiency. However, the C standard requires both
memcmp() and strcmp() to interpret characters under comparison as
unsigned, regardless of the signedness of char. As a result, all
these char_traits implementations fail to meet the requirement
imposed by Table 37 on compare() when char is signed.
</p>
<p>Read email thread starting with c++std-lib-13499 for more. </p>
<p><b>Proposed resolution:</b></p>
<p>Change 21.1.3.1, p6 from</p>
<blockquote>
The two-argument members assign, eq, and lt are defined identically
to the built-in operators =, ==, and &lt; respectively.
</blockquote>
<p>to</p>
<blockquote>
The two-argument member assign is defined identically to
the built-in operator =. The two
argument members eq and lt are defined identically to
the built-in operators == and &lt; for type unsigned char.
</blockquote>
<p><i>[Redmond: The LWG agreed with this general direction, but we
also need to change <tt>eq</tt> to be consistent with this change.
Post-Redmond: Martin provided wording.]</i></p>
<hr>
<a name="468"><h3>468.&nbsp;unexpected consequences of ios_base::operator void*()</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#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jun 2004</p>
<p>The program below is required to compile but when run it typically
produces unexpected results due to the user-defined conversion from
std::cout or any object derived from basic_ios to void*.
</p>
<pre> #include &lt;cassert&gt;
#include &lt;iostream&gt;
int main ()
{
assert (std::cin.tie () == std::cout);
// calls std::cout.ios::operator void*()
}
</pre>
<p><b>Proposed resolution:</b></p>
<p>
Replace std::basic_ios&lt;charT, traits&gt;::operator void*() with another
conversion operator to some unspecified type that is guaranteed not
to be convertible to any other type except for bool (a pointer-to-member
might be one such suitable type). In addition, make it clear that the
pointer type need not be a pointer to a complete type and when non-null,
the value need not be valid.
</p>
<p>Specifically, change in [lib.ios] the signature of</p>
<pre> operator void*() const;
</pre>
<p>to</p>
<pre> operator unspecified-bool-type() const;
</pre>
<p>and change [lib.iostate.flags], p1 from</p>
<pre> operator void*() const;
</pre>
<p>to</p>
<pre>operator unspecified-bool-type() const;
-1- Returns: if fail() then a value that will evaluate false in a
boolean context; otherwise a value that will evaluate true in a
boolean context. The value type returned shall not be
convertible to int.
-2- [Note: This conversion can be used in contexts where a bool
is expected (e.g., an if condition); however, implicit
conversions (e.g., to int) that can occur with bool are not
allowed, eliminating some sources of user error. One possible
implementation choice for this type is pointer-to-member. - end
note]
</pre>
<p><i>[Redmond: 5-4 straw poll in favor of doing this.]</i></p>
<p><i>[Lillehammer: Doug provided revised wording for
"unspecified-bool-type".]</i></p>
<hr>
<a name="470"><h3>470.&nbsp;accessing containers from their elements' special functions</h3></a><p><b>Section:</b>&nbsp;23 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.containers"> [lib.containers]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jun 2004</p> <a name="470"><h3>470.&nbsp;accessing containers from their elements' special functions</h3></a><p><b>Section:</b>&nbsp;23 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.containers"> [lib.containers]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jun 2004</p>
<p> <p>
...@@ -3975,20 +3641,7 @@ facet's virtuals may never call each other. We might want to do that ...@@ -3975,20 +3641,7 @@ facet's virtuals may never call each other. We might want to do that
in clause 27 too, for that matter. A review is necessary. Bill will in clause 27 too, for that matter. A review is necessary. Bill will
provide wording.</p> provide wording.</p>
<hr> <hr>
<a name="474"><h3>474.&nbsp;confusing Footnote 297</h3></a><p><b>Section:</b>&nbsp;27.6.2.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;1 Jul 2004</p> <a name="475"><h3>475.&nbsp;May the function object passed to for_each modify the elements of the iterated sequence?</h3></a><p><b>Section:</b>&nbsp;25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Stephan T. Lavavej, Jaakko Jarvi&nbsp; <b>Date:</b>&nbsp;9 Jul 2004</p>
<p>
I think Footnote 297 is confused. The paragraph it applies to seems
quite clear in that widen() is only called if the object is not a char
stream (i.e., not basic_ostream&lt;char&gt;), so it's irrelevant what the
value of widen(c) is otherwise.
</p>
<p><b>Proposed resolution:</b></p>
<p>
I propose to strike the Footnote.
</p>
<hr>
<a name="475"><h3>475.&nbsp;May the function object passed to for_each modify the elements of the iterated sequence?</h3></a><p><b>Section:</b>&nbsp;25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Stephan T. Lavavej, Jaakko Jarvi&nbsp; <b>Date:</b>&nbsp;9 Jul 2004</p>
<p> <p>
It is not clear whether the function object passed to for_each is allowed to It is not clear whether the function object passed to for_each is allowed to
modify the elements of the sequence being iterated over. modify the elements of the sequence being iterated over.
...@@ -4059,7 +3712,7 @@ passed to it. ...@@ -4059,7 +3712,7 @@ passed to it.
for_each is in a secion entitled "nonmutating algorithms", and the for_each is in a secion entitled "nonmutating algorithms", and the
title may be confusing. A nonnormative note should clarify that.</p> title may be confusing. A nonnormative note should clarify that.</p>
<hr> <hr>
<a name="478"><h3>478.&nbsp;Should forward iterator requirements table have a line for r-&gt;m?</h3></a><p><b>Section:</b>&nbsp;24.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.forward.iterators"> [lib.forward.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;11 Jul 2004</p> <a name="478"><h3>478.&nbsp;Should forward iterator requirements table have a line for r-&gt;m?</h3></a><p><b>Section:</b>&nbsp;24.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.forward.iterators"> [lib.forward.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;11 Jul 2004</p>
<p> <p>
The Forward Iterator requirements table contains the following: The Forward Iterator requirements table contains the following:
</p> </p>
...@@ -4108,6 +3761,10 @@ table. Change</p> ...@@ -4108,6 +3761,10 @@ table. Change</p>
<p>in paragraph 11 of [lib.iterator.requirements].</p> <p>in paragraph 11 of [lib.iterator.requirements].</p>
<p><b>Rationale:</b></p>
<p>
This is a defect because it constrains an lvalue to returning a modifiable lvalue.
</p>
<hr> <hr>
<a name="479"><h3>479.&nbsp;Container requirements and placement new</h3></a><p><b>Section:</b>&nbsp;23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Herb Sutter&nbsp; <b>Date:</b>&nbsp;1 Aug 2004</p> <a name="479"><h3>479.&nbsp;Container requirements and placement new</h3></a><p><b>Section:</b>&nbsp;23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Herb Sutter&nbsp; <b>Date:</b>&nbsp;1 Aug 2004</p>
<p>Nothing in the standard appears to make this program ill-formed:</p> <p>Nothing in the standard appears to make this program ill-formed:</p>
...@@ -4127,7 +3784,7 @@ table. Change</p> ...@@ -4127,7 +3784,7 @@ table. Change</p>
to require containers to support types that define their own special to require containers to support types that define their own special
versions of <tt>operator new</tt>.</p> versions of <tt>operator new</tt>.</p>
<notes> <p><i>[
Lillehammer: A container will definitely never use this overridden Lillehammer: A container will definitely never use this overridden
operator new, but whether it will fail to compile is unclear from the operator new, but whether it will fail to compile is unclear from the
standard. Are containers supposed to use qualified or unqualified standard. Are containers supposed to use qualified or unqualified
...@@ -4137,7 +3794,7 @@ Allocator::construct(). If containers don't use it, the details of how ...@@ -4137,7 +3794,7 @@ Allocator::construct(). If containers don't use it, the details of how
containers use placement new are unspecified. That is the real bug, containers use placement new are unspecified. That is the real bug,
but it needs to be fixed as part of the allocator overhaul. Weak but it needs to be fixed as part of the allocator overhaul. Weak
support that the eventual solution should make this code well formed. support that the eventual solution should make this code well formed.
</notes> ]</i></p>
<p><b>Proposed resolution:</b></p> <p><b>Proposed resolution:</b></p>
<hr> <hr>
...@@ -4479,7 +4136,7 @@ not quite broad enough, because there are some arithmetic expressions ...@@ -4479,7 +4136,7 @@ not quite broad enough, because there are some arithmetic expressions
it doesn't cover. Bill will provide wording.]</i></p> it doesn't cover. Bill will provide wording.]</i></p>
<hr> <hr>
<a name="495"><h3>495.&nbsp;Clause 22 template parameter requirements</h3></a><p><b>Section:</b>&nbsp;22 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.localization"> [lib.localization]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;10 Jan 2005</p> <a name="495"><h3>495.&nbsp;Clause 22 template parameter requirements</h3></a><p><b>Section:</b>&nbsp;22 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.localization"> [lib.localization]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;10 Jan 2005</p>
<p>It appears that there are no requirements specified for many of the <p>It appears that there are no requirements specified for many of the
template parameters in clause 22. It looks like this issue has never template parameters in clause 22. It looks like this issue has never
come up, except perhaps for Facet.</p> come up, except perhaps for Facet.</p>
...@@ -4542,19 +4199,7 @@ requirements of charT (described in 21 <a href="http://www.open-std.org/jtc1/sc2 ...@@ -4542,19 +4199,7 @@ requirements of charT (described in 21 <a href="http://www.open-std.org/jtc1/sc2
for. The only issue is what to do about stateT. This wording is for. The only issue is what to do about stateT. This wording is
thin, but probably adequate.</p> thin, but probably adequate.</p>
<hr> <hr>
<a name="496"><h3>496.&nbsp;Illegal use of "T" in vector&lt;bool&gt;</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#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;richard@ex-parrot.com&nbsp; <b>Date:</b>&nbsp;10 Feb 2005</p> <a name="497"><h3>497.&nbsp;meaning of numeric_limits::traps for floating point types</h3></a><p><b>Section:</b>&nbsp;18.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.numeric.limits.members"> [lib.numeric.limits.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;2 Mar 2005</p>
<p>
In the synopsis of the std::vector&lt;bool&gt; specialisation in 23.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.bool"> [lib.vector.bool]</a>,
the non-template assign() function has the signature</p>
<pre> void assign( size_type n, const T&amp; t );
</pre>
<p>The type, T, is not defined in this context.</p>
<p><b>Proposed resolution:</b></p>
<p>Replace "T" with "value_type".</p>
<hr>
<a name="497"><h3>497.&nbsp;meaning of numeric_limits::traps for floating point types</h3></a><p><b>Section:</b>&nbsp;18.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.numeric.limits.members"> [lib.numeric.limits.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;2 Mar 2005</p>
<p>18.2.1.2, p59 says this much about the traps member of numeric_limits:</p> <p>18.2.1.2, p59 says this much about the traps member of numeric_limits:</p>
...@@ -4603,7 +4248,7 @@ at runtime. ...@@ -4603,7 +4248,7 @@ at runtime.
proposed resolution is at least consistent and slightly better than proposed resolution is at least consistent and slightly better than
nothing.</p> nothing.</p>
<hr> <hr>
<a name="498"><h3>498.&nbsp;Requirements for partition() and stable_partition() too strong</h3></a><p><b>Section:</b>&nbsp;25.2.12 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.partitions"> [lib.alg.partitions]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Sean Parent, Joe Gottman&nbsp; <b>Date:</b>&nbsp;4 May 2005</p> <a name="498"><h3>498.&nbsp;Requirements for partition() and stable_partition() too strong</h3></a><p><b>Section:</b>&nbsp;25.2.12 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.partitions"> [lib.alg.partitions]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Sean Parent, Joe Gottman&nbsp; <b>Date:</b>&nbsp;4 May 2005</p>
<p> <p>
Problem: Problem:
The iterator requirements for partition() and stable_partition() [25.2.12] The iterator requirements for partition() and stable_partition() [25.2.12]
...@@ -4643,6 +4288,21 @@ swaps are done; otherwise at most (last - first) swaps are done. Exactly ...@@ -4643,6 +4288,21 @@ swaps are done; otherwise at most (last - first) swaps are done. Exactly
(last - first) applications of the predicate are done. (last - first) applications of the predicate are done.
</p></blockquote> </p></blockquote>
<p><b>Rationale:</b></p>
Partition is a "foundation" algorithm useful in many contexts (like sorting
as just one example) - my motivation for extending it to include forward
iterators is slist - without this extension you can't partition an slist
(without writing your own partition). Holes like this in the standard
library weaken the argument for generic programming (ideally I'd be able
to provide a library that would refine std::partition() to other concepts
without fear of conflicting with other libraries doing the same - but
that is a digression). I consider the fact that partition isn't defined
to work for ForwardIterator a minor embarrassment.
<p><i>[Mont Tremblant: Moved to Open, request motivation and use cases
by next meeting. Sean provided further rationale by post-meeting
mailing.]</i></p>
<hr> <hr>
<a name="499"><h3>499.&nbsp;Std. doesn't seem to require stable_sort() to be stable!</h3></a><p><b>Section:</b>&nbsp;25.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.stable.sort"> [lib.stable.sort]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Prateek Karandikar&nbsp; <b>Date:</b>&nbsp;12 Apr 2005</p> <a name="499"><h3>499.&nbsp;Std. doesn't seem to require stable_sort() to be stable!</h3></a><p><b>Section:</b>&nbsp;25.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.stable.sort"> [lib.stable.sort]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Prateek Karandikar&nbsp; <b>Date:</b>&nbsp;12 Apr 2005</p>
<blockquote> <blockquote>
...@@ -4701,19 +4361,6 @@ in the informative paragraph? Or am I missing something obvious? ...@@ -4701,19 +4361,6 @@ in the informative paragraph? Or am I missing something obvious?
<p> <p>
</p> </p>
<hr> <hr>
<a name="500"><h3>500.&nbsp;do_length cannot be implemented correctly</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Krzysztof elechowski&nbsp; <b>Date:</b>&nbsp;24 May 2005</p>
<ol>
<li>codecvt::do_length is of type int;</li>
<li>it is assumed to be sort-of returning from_next - from of type ptrdiff_t;</li>
<li>ptrdiff_t cannot be cast to an int without data loss.</li>
</ol>
<p>
Contradiction.
</p>
<p><b>Proposed resolution:</b></p>
<p>
</p>
<hr>
<a name="501"><h3>501.&nbsp;Proposal: strengthen guarantees of lib.comparisons</h3></a><p><b>Section:</b>&nbsp;20.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.comparisons"> [lib.comparisons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Me &lt;anti_spam_email2003@yahoo.com&gt;&nbsp; <b>Date:</b>&nbsp;7 Jun 2005</p> <a name="501"><h3>501.&nbsp;Proposal: strengthen guarantees of lib.comparisons</h3></a><p><b>Section:</b>&nbsp;20.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.comparisons"> [lib.comparisons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Me &lt;anti_spam_email2003@yahoo.com&gt;&nbsp; <b>Date:</b>&nbsp;7 Jun 2005</p>
<blockquote> <blockquote>
"For templates greater, less, greater_equal, and less_equal, "For templates greater, less, greater_equal, and less_equal,
...@@ -4888,5 +4535,933 @@ facet, but several also need to use a codecvt facet and we don't say so. ...@@ -4888,5 +4535,933 @@ facet, but several also need to use a codecvt facet and we don't say so.
<p><b>Proposed resolution:</b></p> <p><b>Proposed resolution:</b></p>
<p> <p>
</p> </p>
<hr>
<a name="504"><h3>504.&nbsp;Integer types in pseudo-random number engine requirements</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.req"> [tr.rand.req]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
<p>
In [tr.rand.req], Paragraph 2 states that "... s is a value of integral type,
g is an ... object returning values of unsigned integral type ..."
</p>
<p><b>Proposed resolution:</b></p>
<p>
In 5.1.1 [tr.rand.req], Paragraph 2 replace
</p>
<blockquote>
... s is a value of integral type, g is an lvalue of a type other than X that
defines a zero-argument function object returning values of <del>unsigned integral</del> type
<ins><tt>unsigned long int</tt></ins>,
...
</blockquote>
<p>
In 5.1.1 [tr.rand.seq], Table 16, replace in the line for X(s)
</p>
<blockquote>
creates an engine with the initial internal state
determined by <ins><tt>static_cast&lt;unsigned long&gt;(</tt></ins><tt><i>s</i></tt><ins><tt>)</tt></ins>
</blockquote>
<p><i>[
Mont Tremblant: Both s and g should be unsigned long.
This should refer to the constructor signatures. Jens provided wording post Mont Tremblant.
]</i></p>
<p><b>Rationale:</b></p>
<p>
Jens: Just requiring X(unsigned long) still makes it possible
for an evil library writer to also supply a X(int) that does something
unexpected. The wording above requires that X(s) always performs
as if X(unsigned long) would have been called. I believe that is
sufficient and implements our intentions from Mont Tremblant. I
see no additional use in actually requiring a X(unsigned long)
signature. u.seed(s) is covered by its reference to X(s), same
arguments.
</p>
<hr>
<a name="505"><h3>505.&nbsp;Result_type in random distribution requirements</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.req"> [tr.rand.req]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
<p>
Table 17: Random distribution requirements
</p>
<p>
Row 1 requires that each random distribution provide a nested type "input_type";
this type denotes the type of the values that the distribution consumes.
</p>
<p>
Inspection of all distributions in [tr.rand.dist] reveals that each distribution
provides a second typedef ("result_type") that denotes the type of the values the
distribution produces when called.
</p>
<p><b>Proposed resolution:</b></p>
<p>
It seems to me that this is also a requirement
for all distributions and should therefore be indicated as such via a new second
row to this table 17:
</p>
<table border="1" cellpadding="5">
<tbody><tr>
<td>X::result_type</td>
<td>T</td>
<td>---</td>
<td>compile-time</td>
</tr>
</tbody></table>
<hr>
<a name="506"><h3>506.&nbsp;Requirements of Distribution parameter for variate_generator</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.var"> [tr.rand.var]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
<p>
Paragraph 3 requires that template argument U (which corresponds to template
parameter Engine) satisfy all uniform random number generator requirements.
However, there is no analogous requirement regarding the template argument
that corresponds to template parameter Distribution. We believe there should
be, and that it should require that this template argument satisfy all random
distribution requirements.
</p>
<p><b>Proposed resolution:</b></p>
<p>
Consequence 1: Remove the precondition clauses [tr.rand.var]/16 and /18.
</p>
<p>
Consequence 2: Add max() and min() functions to those distributions that
do not already have them.
</p>
<p><i>[
Mont Tremblant: Jens reccommends NAD, min/max not needed everywhere.
Marc supports having min and max to satisfy generic programming interface.
]</i></p>
<hr>
<a name="507"><h3>507.&nbsp;Missing requirement for variate_generator::operator()</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.var"> [tr.rand.var]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
<p>
Paragraph 11 of [tr.rand.var] equires that the member template
</p>
<blockquote><pre>template&lt;class T&gt; result_type operator() (T value);
</pre></blockquote>
<p>
return
</p>
<blockquote><pre>distribution()(e, value)
</pre></blockquote>
<p>
However, not all distributions have an operator() with a corresponding signature.
</p>
<p><b>Proposed resolution:</b></p>
<p>
We therefore recommend that we insert the following precondition before paragraph 11:
</p>
<blockquote>
Precondition: <tt>distribution().operator()(e,value)</tt> is well-formed.
</blockquote>
<hr>
<a name="508"><h3>508.&nbsp;Bad parameters for ranlux64_base_01</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.predef"> [tr.rand.predef]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
<p>
The fifth of these engines with predefined parameters, ranlux64_base_01,
appears to have an unintentional error for which there is a simple correction.
The two pre-defined subtract_with_carry_01 engines are given as:
</p>
<blockquote><pre>typedef subtract_with_carry_01&lt;float, 24, 10, 24&gt; ranlux_base_01;
typedef subtract_with_carry_01&lt;double, 48, 10, 24&gt; ranlux64_base_01;
</pre></blockquote>
<p>
We demonstrate below that ranlux64_base_01 fails to meet the intent of the
random number generation proposal, but that the simple correction to
</p>
<blockquote><pre>typedef subtract_with_carry_01&lt;double, 48, 5, 12&gt; ranlux64_base_01;
</pre></blockquote>
<p>
does meet the intent of defining well-known good parameterizations.
</p>
<p>
The ranlux64_base_01 engine as presented fails to meet the intent for
predefined engines, stated in proposal N1398 (section E):
</p>
<blockquote><p>
In order to make good random numbers available to a large number of library
users, this proposal not only defines generic random-number engines, but also
provides a number of predefined well-known good parameterizations for those.
</p></blockquote>
<p>
The predefined ranlux_base_01 engine has been proven [1,2,3] to have a very
long period and so meets this criterion. This property makes it suitable for
use in the excellent discard_block engines defined subsequently. The proof
of long period relies on the fact (proven in [1]) that 2**(w*r) - 2**(w*s)
+ 1 is prime (w, r, and s are template parameters to subtract_with_carry_01,
as defined in [tr.rand.eng.sub1]).
</p>
<p>
The ranlux64_base_01 engine as presented in [tr.rand.predef] uses w=48, r=24, s=10.
For these numbers, the combination 2**(w*r)-2**(w*s)+1 is non-prime (though
explicit factorization would be a challenge). In consequence, while it is
certainly possible for some seeding states that this engine would have a very
long period, it is not at all well-known that this is the case. The intent
in the N1398 proposal involved the base of the ranlux64 engine, which finds heavy
use in the physics community. This is isomorphic to the predefined ranlux_base_01,
but exploits the ability of double variables to hold (at least) 48 bits of mantissa,
to deliver 48 random bits at a time rather than 24.
</p>
<p><b>Proposed resolution:</b></p>
<p>
To achieve this intended behavior, the correct template parameteriztion would be:
</p>
<blockquote><pre>typedef subtract_with_carry_01&lt;double, 48, 5, 12&gt; ranlux64_base_01;
</pre></blockquote>
<p>
The sequence of mantissa bits delivered by this is isomorphic (treating each
double as having the bits of two floats) to that delivered by ranlux_base_01.
</p>
<p>
<b>References:</b>
</p>
<ol>
<li>F. James, Comput. Phys. Commun. 60(1990) 329</li>
<li>G. Marsaglia and A. Zaman, Ann. Appl. Prob 1(1991) 462</li>
<li>M. Luscher, Comput. Phys. Commun. 79(1994) 100-110</li>
</ol>
<hr>
<a name="509"><h3>509.&nbsp;Uniform_int template parameters</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.dist.iunif"> [tr.rand.dist.iunif]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
<p>
In [tr.rand.dist.iunif] the uniform_int distribution currently has a single
template parameter, IntType, used as the input_type and as the result_type
of the distribution. We believe there is no reason to conflate these types
in this way.
</p>
<p><b>Proposed resolution:</b></p>
<p>
We recommend that there be a second template parameter to
reflect the distributions input_type, and that the existing first template
parameter continue to reflect (solely) the result_type:
</p>
<blockquote><pre>template&lt; class IntType = int, UIntType = unsigned int &gt;
class uniform_int
{
public:
// types
typedef UIntType input_type;
typedef IntType result_type;
</pre></blockquote>
<hr>
<a name="510"><h3>510.&nbsp;Input_type for bernoulli_distribution</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.7.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.dist.bern"> [tr.rand.dist.bern]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
<p>
In [tr.rand.dist.bern] the distribution currently requires;
</p>
<blockquote><pre>typedef int input_type;
</pre></blockquote>
<p><b>Proposed resolution:</b></p>
<p>
We believe this is an unfortunate choice, and recommend instead:
</p>
<blockquote><pre>typedef unsigned int input_type;
</pre></blockquote>
<hr>
<a name="511"><h3>511.&nbsp;Input_type for binomial_distribution</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.7.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.dist.bin"> [tr.rand.dist.bin]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
<p>
Unlike all other distributions in TR1, this binomial_distribution has an
implementation-defined input_type. We believe this is an unfortunate choice,
because it hinders users from writing portable code. It also hinders the
writing of compliance tests. We recommend instead:
</p>
<blockquote><pre>typedef RealType input_type;
</pre></blockquote>
<p>
While this choice is somewhat arbitrary (as it was for some of the other
distributions), we make this particular choice because (unlike all other
distributions) otherwise this template would not publish its RealType
argument and so users could not write generic code that accessed this
second template parameter. In this respect, the choice is consistent with
the other distributions in TR1.
</p>
<p>
We have two reasons for recommending that a real type be specified instead.
One reason is based specifically on characteristics of binomial distribution
implementations, while the other is based on mathematical characteristics of
probability distribution functions in general.
</p>
<p>
Implementations of binomial distributions commonly use Stirling approximations
for values in certain ranges. It is far more natural to use real values to
represent these approximations than it would be to use integral values to do
so. In other ranges, implementations reply on the Bernoulli distribution to
obtain values. While TR1s bernoulli_distribution::input_type is specified as
int, we believe this would be better specified as double.
</p>
<p>
This brings us to our main point: The notion of a random distribution rests
on the notion of a cumulative distribution function, which in turn mathematically
depends on a continuous dependent variable. Indeed, such a distribution function
would be meaningless if it depended on discrete values such as integersand this
remains true even if the distribution function were to take discrete steps.
</p>
<p>
Although this note is specifically about binomial_distribution::input_type,
we intend to recommend that all of the random distributions input_types be
specified as a real type (either a RealType template parameter, or double,
as appropriate).
</p>
<p>
Of the nine distributions in TR1, four already have this characteristic
(uniform_real, exponential_distribution, normal_distribution, and
gamma_distribution). We have already argued the case for the binomial the
remaining four distributions.
</p>
<p>
In the case of uniform_int, we believe that the calculations to produce an
integer result in a specified range from an integer in a different specified
range is best done using real arithmetic. This is because it involves a
product, one of whose terms is the ratio of the extents of the two ranges.
Without real arithmetic, the results become less uniform: some numbers become
more (or less) probable that they should be. This is, of course, undesireable
behavior in a uniform distribution.
</p>
<p>
Finally, we believe that in the case of the bernoulli_distribution (briefly
mentioned earlier), as well as the cases of the geometric_distribution and the
poisson_distribution, it would be far more natural to have a real input_type.
This is because the most natural computation involves the random number
delivered and the distributions parameter p (in the case of bernoulli_distribution,
for example, the computation is a comparison against p), and p is already specified
in each case as having some real type.
</p>
<p><b>Proposed resolution:</b></p>
<blockquote><pre>typedef RealType input_type;
</pre></blockquote>
<hr>
<a name="512"></a><h3><a name="512">512.&nbsp;Seeding subtract_with_carry_01 from a single unsigned long</a></h3><p><b>Section:</b>&nbsp;TR1 5.1.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.eng.sub1"> [tr.rand.eng.sub1]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
<p>
Paragraph 8 specifies the algorithm by which a subtract_with_carry_01 engine
is to be seeded given a single unsigned long. This algorithm is seriously
flawed in the case where the engine parameter w (also known as word_size)
exceeds 31 [bits]. The key part of the paragraph reads:
</p>
<blockquote>
sets x(-r) ... x(-1) to (lcg(1)*2**(-w)) mod 1
</blockquote>
<p>
and so forth.
</p>
<p>
Since the specified linear congruential engine, lcg, delivers numbers with
a maximum of 2147483563 (just a shade under 31 bits), then when w is, for
example, 48, each of the x(i) will be less than 2**-17. The consequence
is that roughly the first 400 numbers delivered will be conspicuously
close to either zero or one.
</p>
<p>
Unfortunately, this is not an innocuous flaw: One of the predefined engines
in [tr.rand.predef], namely ranlux64_base_01, has w = 48 and would exhibit
this poor behavior, while the original N1378 proposal states that these
pre-defined engines are intended to be of "known good properties."
</p>
<p><b>Proposed resolution:</b></p>
<p>
In 5.1.4.4 [tr.rand.eng.sub1], replace the "effects" clause for
void seed(unsigned long value = 19780503) by
</p>
<blockquote>
<i>Effects:</i> If <tt>value == 0</tt>, sets value to <tt>19780503</tt>. In any
case, <del>with a linear congruential generator <tt>lcg</tt>(i) having parameters
<tt><i>m<sub>lcg</sub></i> = 2147483563</tt>, <tt><i>a<sub>lcg</sub></i> = 40014</tt>,
<tt><i>c<sub>lcg</sub></i> = 0</tt>, and <tt><i>lcg</i>(0) = value</tt>,</del>
sets <ins>carry<tt>(-1)</tt> and</ins> <tt>x(-r) &#8230; x(-1)</tt>
<ins>as if executing</ins>
<blockquote><pre><ins>
linear_congruential&lt;unsigned long, 40014, 0, 2147483563&gt; lcg(value);
seed(lcg);
</ins></pre></blockquote>
<del>to <tt>(<i>lcg</i>(1) 2<sup>-<i>w</i></sup>) mod 1
&#8230; (<i>lcg</i>(<i>r</i>) 2<sup>-<i>w</i></sup>) mod 1</tt>,
respectively. If <tt><i>x</i>(-1) == 0</tt>, sets carry<tt>(-1) = 2<sup>-<i>w</i></sup></tt>,
else sets carry<tt>(-1) = 0</tt>.</del>
</blockquote>
<p><i>[
Jens provided revised wording post Mont Tremblant.
]</i></p>
<p><b>Rationale:</b></p>
<p>
Jens: I'm using an explicit type here, because fixing the
prose would probably not qualify for the (with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#504">504</a> even
stricter) requirements we have for seed(Gen&amp;).
</p>
<hr>
<a name="513"><h3>513.&nbsp;Size of state for subtract_with_carry_01</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.eng.sub1"> [tr.rand.eng.sub1]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
<p>
Paragraph 3 begins:
</p>
<blockquote>
The size of the state is r.
</blockquote>
<p>
However, this is not quite consistent with the remainder of the paragraph
which specifies a total of nr+1 items in the textual representation of
the state. We recommend the sentence be corrected to match:
</p>
<blockquote>
The size of the state is nr+1.
</blockquote>
<p>
To give meaning to the coefficient n, it may be also desirable to move
ns definition from later in the paragraph. Either of the following
seem reasonable formulations:
</p>
<blockquote>
With n=..., the size of the state is nr+1.
</blockquote>
<blockquote>
The size of the state is nr+1, where n=... .
</blockquote>
<p>
</p>
<p><b>Proposed resolution:</b></p>
<p><i>[
Jens: I plead for "NAD" on the grounds that "size of state" is only
used as an argument for big-O complexity notation, thus
constant factors and additions don't count.
]</i></p>
<hr>
<a name="514"><h3>514.&nbsp;Size of state for subtract_with_carry</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.eng.sub"> [tr.rand.eng.sub]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
<p>
Paragraph 2 begins:
</p>
<blockquote>
The size of the state is r.
</blockquote>
<p>
However, the next sentence specifies a total of r+1 items in the textual
representation of the state, r specific xs as well as a specific carry.
This makes a total of r+1 items that constitute the size of the state,
rather than r.
</p>
<p><b>Proposed resolution:</b></p>
<p>
We recommend the sentence be corrected to match:
</p>
<blockquote>
The size of the state is r+1.
</blockquote>
<p><i>[
Jens: I plead for "NAD" on the grounds that "size of state" is only
used as an argument for big-O complexity notation, thus
constant factors and additions don't count.
]</i></p>
<hr>
<a name="515"><h3>515.&nbsp;Random number engine traits</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.synopsis"> [tr.rand.synopsis]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
<p>
To accompany the concept of a pseudo-random number engine as defined in Table 17,
we propose and recommend an adjunct template, engine_traits, to be declared in
[tr.rand.synopsis] as:
</p>
<blockquote><pre>template&lt; class PSRE &gt;
class engine_traits;
</pre></blockquote>
<p>
This templates primary purpose would be as an aid to generic programming involving
pseudo-random number engines. Given only the facilities described in tr1, it would
be very difficult to produce any algorithms involving the notion of a generic engine.
The intent of this proposal is to provide, via engine_traits&lt;&gt;, sufficient
descriptive information to allow an algorithm to employ a pseudo-random number engine
without regard to its exact type, i.e., as a template parameter.
</p>
<p>
For example, today it is not possible to write an efficient generic function that
requires any specific number of random bits. More specifically, consider a
cryptographic application that internally needs 256 bits of randomness per call:
</p>
<blockquote><pre>template&lt; class Eng, class InIter, class OutIter &gt;
void crypto( Eng&amp; e, InIter in, OutIter out );
</pre></blockquote>
<p>
Without knowning the number of bits of randomness produced per call to a provided
engine, the algorithm has no means of determining how many times to call the engine.
</p>
<p>
In a new section [tr.rand.eng.traits], we proposed to define the engine_traits
template as:
</p>
<blockquote><pre>template&lt; class PSRE &gt;
class engine_traits
{
static std::size_t bits_of_randomness = 0u;
static std::string name() { return "unknown_engine"; }
// TODO: other traits here
};
</pre></blockquote>
<p>
Further, each engine described in [tr.rand.engine] would be accompanied by a
complete specialization of this new engine_traits template.
</p>
<p><b>Proposed resolution:</b></p>
<p>
</p>
<hr>
<a name="516"><h3>516.&nbsp;Seeding subtract_with_carry_01 using a generator</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.eng.sub1"> [tr.rand.eng.sub1]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
<p>
Paragraph 6 says:
</p>
<blockquote>
... obtained by successive invocations of g, ...
</blockquote>
<p>
We recommend instead:
</p>
<blockquote>
... obtained by taking successive invocations of g mod 2**32, ...
</blockquote>
<p>
as the context seems to require only 32-bit quantities be used here.
</p>
<p><b>Proposed resolution:</b></p>
<p>
</p>
<hr>
<a name="517"><h3>517.&nbsp;Should include name in external representation</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.req"> [tr.rand.req]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
<p>
The last two rows of Table 16 deal with the i/o requirements of an engine,
specifying that the textual representation of an engines state,
appropriately formatted, constitute the engines external representation.
</p>
<p>
This seems adequate when an engines type is known. However, it seems
inadequate in the context of generic code, where it becomes useful and
perhaps even necessary to determine an engines type via input.
</p>
<p>
</p>
<p><b>Proposed resolution:</b></p>
<p>
We therefore recommend that, in each of these two rows of Table 16, the
text "textual representation" be expanded so as to read "engine name
followed by the textual representation."
</p>
<hr>
<a name="518"><h3>518.&nbsp;Are insert and erase stable for unordered_multiset and unordered_multimap?</h3></a><p><b>Section:</b>&nbsp;TR1 6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.hash"> [tr.hash]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
<p>
Issue 371 deals with stability of multiset/multimap under insert and erase
(i.e. do they preserve the relative order in ranges of equal elements).
The same issue applies to unordered_multiset and unordered_multimap.
</p>
<p><b>Proposed resolution:</b></p>
<p>
</p>
<hr>
<a name="519"><h3>519.&nbsp;Data() undocumented</h3></a><p><b>Section:</b>&nbsp;TR1 6.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.array.array"> [tr.array.array]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a>&nbsp; <b>Submitter:</b>&nbsp;Pete Becker&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
<p>
<tt>array&lt;&gt;::data()</tt> is present in the class synopsis, but not documented.
</p>
<p><b>Proposed resolution:</b></p>
<p>
Add a new section, after 6.2.2.3:
</p>
<blockquote><pre>T* data()
const T* data() const;
</pre></blockquote>
<p>
<b>Returns:</b> <tt>elems</tt>.
</p>
<p>
Change 6.2.2.4/2 to:
</p>
<blockquote>
In the case where <tt>N == 0</tt>, <tt>begin() == end()</tt>. The return value
of <tt>data()</tt> is unspecified.
</blockquote>
<hr>
<a name="520"><h3>520.&nbsp;Result_of and pointers to data members</h3></a><p><b>Section:</b>&nbsp;TR1 3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.func.bind"> [tr.func.bind]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Pete Becker&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
<p>
In the original proposal for binders, the return type of bind() when
called with a pointer to member data as it's callable object was
defined to be mem_fn(ptr); when Peter Dimov and I unified the
descriptions of the TR1 function objects we hoisted the descriptions
of return types into the INVOKE pseudo-function and into result_of.
Unfortunately, we left pointer to member data out of result_of, so
bind doesn't have any specified behavior when called with a pointer
to member data.
</p>
<p><b>Proposed resolution:</b></p>
<p><i>[
Pete and Peter will provide wording.
]</i></p>
<hr>
<a name="521"><h3>521.&nbsp;Garbled requirements for argument_type in reference_wrapper</h3></a><p><b>Section:</b>&nbsp;TR1 2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.refwrp.refwrp"> [tr.util.refwrp.refwrp]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Pete Becker&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
<p>
2.1.2/3, second bullet item currently says that reference_wrapper&lt;T&gt; is
derived from unary_function&lt;T, R&gt; if T is:
</p>
<blockquote>
a pointer to member function type with cv-qualifier cv and no arguments;
the type T1 is cv T* and R is the return type of the pointer to member function;
</blockquote>
<p>
The type of T1 can't be cv T*, 'cause that's a pointer to a pointer to member
function. It should be a pointer to the class that T is a pointer to member of.
Like this:
</p>
<blockquote>
a pointer to a member function R T0::f() cv (where cv represents the member
function's cv-qualifiers); the type T1 is cv T0*
</blockquote>
<p>
Similarly, bullet item 2 in 2.1.2/4 should be:
</p>
<blockquote>
a pointer to a member function R T0::f(T2) cv (where cv represents the member
function's cv-qualifiers); the type T1 is cv T0*
</blockquote>
<p><b>Proposed resolution:</b></p>
<hr>
<a name="522"></a><h3><a name="522">522.&nbsp;Tuple doesn't define swap</a></h3><p><b>Section:</b>&nbsp;TR1 6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.tuple"> [tr.tuple]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Koenig&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
<p>
Tuple doesn't define swap(). It should.
</p>
<p><b>Proposed resolution:</b></p>
<hr>
<a name="523"><h3>523.&nbsp;regex case-insensitive character ranges are unimplementable as specified</h3></a><p><b>Section:</b>&nbsp;TR1 7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.re"> [tr.re]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Eric Niebler&nbsp; <b>Date:</b>&nbsp;1 Jul 2005</p>
<p>
A problem with TR1 regex is currently being discussed on the Boost
developers list. It involves the handling of case-insensitive matching
of character ranges such as [Z-a]. The proper behavior (according to the
ECMAScript standard) is unimplementable given the current specification
of the TR1 regex_traits&lt;&gt; class template. John Maddock, the author of
the TR1 regex proposal, agrees there is a problem. The full discussion
can be found at http://lists.boost.org/boost/2005/06/28850.php (first
message copied below). We don't have any recommendations as yet.
</p>
<p>
-- Begin original message --
</p>
<p>
The situation of interest is described in the ECMAScript specification
(ECMA-262), section 15.10.2.15:
</p>
<p>
"Even if the pattern ignores case, the case of the two ends of a range
is significant in determining which characters belong to the range.
Thus, for example, the pattern /[E-F]/i matches only the letters E, F,
e, and f, while the pattern /[E-f]/i matches all upper and lower-case
ASCII letters as well as the symbols [, \, ], ^, _, and `."
</p>
<p>
A more interesting case is what should happen when doing a
case-insentitive match on a range such as [Z-a]. It should match z, Z,
a, A and the symbols [, \, ], ^, _, and `. This is not what happens with
Boost.Regex (it throws an exception from the regex constructor).
</p>
<p>
The tough pill to swallow is that, given the specification in TR1, I
don't think there is any effective way to handle this situation.
According to the spec, case-insensitivity is handled with
regex_traits&lt;&gt;::translate_nocase(CharT) -- two characters are equivalent
if they compare equal after both are sent through the translate_nocase
function. But I don't see any way of using this translation function to
make character ranges case-insensitive. Consider the difficulty of
detecting whether "z" is in the range [Z-a]. Applying the transformation
to "z" has no effect (it is essentially std::tolower). And we're not
allowed to apply the transformation to the ends of the range, because as
ECMA-262 says, "the case of the two ends of a range is significant."
</p>
<p>
So AFAICT, TR1 regex is just broken, as is Boost.Regex. One possible fix
is to redefine translate_nocase to return a string_type containing all
the characters that should compare equal to the specified character. But
this function is hard to implement for Unicode, and it doesn't play nice
with the existing ctype facet. What a mess!
</p>
<p>
-- End original message --
</p>
<p><i>[
John Maddock adds:
]</i></p>
<p>
One small correction, I have since found that ICU's regex package does
implement this correctly, using a similar mechanism to the current
TR1.Regex.
</p>
<p>
Given an expression [c1-c2] that is compiled as case insensitive it:
</p>
<p>
Enumerates every character in the range c1 to c2 and converts it to it's
case folded equivalent. That case folded character is then used a key to a
table of equivalence classes, and each member of the class is added to the
list of possible matches supported by the character-class. This second step
isn't possible with our current traits class design, but isn't necessary if
the input text is also converted to a case-folded equivalent on the fly.
</p>
<p>
ICU applies similar brute force mechanisms to character classes such as
[[:lower:]] and [[:word:]], however these are at least cached, so the impact
is less noticeable in this case.
</p>
<p>
Quick and dirty performance comparisons show that expressions such as
"[X-\\x{fff0}]+" are indeed very slow to compile with ICU (about 200 times
slower than a "normal" expression). For an application that uses a lot of
regexes this could have a noticeable performance impact. ICU also has an
advantage in that it knows the range of valid characters codes: code points
outside that range are assumed not to require enumeration, as they can not
be part of any equivalence class. I presume that if we want the TR1.Regex
to work with arbitrarily large character sets enumeration really does become
impractical.
</p>
<p>
Finally note that Unicode has:
</p>
<p>
Three cases (upper, lower and title).
One to many, and many to one case transformations.
Character that have context sensitive case translations - for example an
uppercase sigma has two different lowercase forms - the form chosen depends
on context(is it end of a word or not), a caseless match for an upper case
sigma should match either of the lower case forms, which is why case folding
is often approximated by tolower(toupper(c)).
</p>
<p>
Probably we need some way to enumerate character equivalence classes,
including digraphs (either as a result or an input), and some way to tell
whether the next character pair is a valid digraph in the current locale.
</p>
<p>
Hoping this doesn't make this even more complex that it was already,
</p>
<p><b>Proposed resolution:</b></p>
<hr>
<a name="524"><h3>524.&nbsp;regex named character classes and case-insensitivity don't mix</h3></a><p><b>Section:</b>&nbsp;TR1 7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.re"> [tr.re]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Eric Niebler&nbsp; <b>Date:</b>&nbsp;1 Jul 2005</p>
<p>
This defect is also being discussed on the Boost developers list. The
full discussion can be found here:
http://lists.boost.org/boost/2005/07/29546.php
</p>
<p>
-- Begin original message --
</p>
<p>
Also, I may have found another issue, closely related to the one under
discussion. It regards case-insensitive matching of named character
classes. The regex_traits&lt;&gt; provides two functions for working with
named char classes: lookup_classname and isctype. To match a char class
such as [[:alpha:]], you pass "alpha" to lookup_classname and get a
bitmask. Later, you pass a char and the bitmask to isctype and get a
bool yes/no answer.
</p>
<p>
But how does case-insensitivity work in this scenario? Suppose we're
doing a case-insensitive match on [[:lower:]]. It should behave as if it
were [[:lower:][:upper:]], right? But there doesn't seem to be enough
smarts in the regex_traits interface to do this.
</p>
<p>
Imagine I write a traits class which recognizes [[:fubar:]], and the
"fubar" char class happens to be case-sensitive. How is the regex engine
to know that? And how should it do a case-insensitive match of a
character against the [[:fubar:]] char class? John, can you confirm this
is a legitimate problem?
</p>
<p>
I see two options:
</p>
<p>
1) Add a bool icase parameter to lookup_classname. Then,
lookup_classname( "upper", true ) will know to return lower|upper
instead of just upper.
</p>
<p>
2) Add a isctype_nocase function
</p>
<p>
I prefer (1) because the extra computation happens at the time the
pattern is compiled rather than when it is executed.
</p>
<p>
-- End original message --
</p>
<p>
For what it's worth, John has also expressed his preference for option
(1) above.
</p>
<p><b>Proposed resolution:</b></p>
<hr>
<a name="525"><h3>525.&nbsp;type traits definitions not clear</h3></a><p><b>Section:</b>&nbsp;TR1 4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.meta.unary"> [tr.meta.unary]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Robert Klarer&nbsp; <b>Date:</b>&nbsp;11 Jul 2005</p>
<p>
It is not completely clear how the primary type traits deal with
cv-qualified types. And several of the secondary type traits
seem to be lacking a definition.
</p>
<p><b>Proposed resolution:</b></p>
<hr>
<a name="526"></a><h3><a name="526">526.&nbsp;Is it undefined if a function in the standard changes in parameters?</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#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Chris Jefferson&nbsp; <b>Date:</b>&nbsp;14 Sep 2005</p>
<p>
Problem: There are a number of places in the C++ standard library where
it is possible to write what appear to be sensible ways of calling
functions, but which can cause problems in some (or all)
implementations, as they cause the values given to the function to be
changed in a way not specified in standard (and therefore not coded to
correctly work). These fall into two similar categories.
</p>
<p>
1) Parameters taken by const reference can be changed during execution
of the function
</p>
<p>
Examples:
</p>
<p>
Given std::vector&lt;int&gt; v:
</p>
<p>
v.insert(v.begin(), v[2]);
</p>
<p>
v[2] can be changed by moving elements of vector
</p>
<p>
Given std::list&lt;int&gt; l:
</p>
<p>
l.remove(*l.begin());
</p>
<p>
Will delete the first element, and then continue trying to access it.
This is particularily vicious, as it will appear to work in almost all
cases.
</p>
<p>
2) A range is given which changes during the execution of the function:
Similarly,
</p>
<p>
v.insert(v.begin(), v.begin()+4, v.begin()+6);
</p>
<p>
This kind of problem has been partly covered in some cases. For example
std::copy(first, last, result) states that result cannot be in the range
[first, last). However, does this cover the case where result is a
reverse_iterator built from some iterator in the range [first, last)?
Also, std::copy would still break if result was reverse_iterator(last +
1), yet this is not forbidden by the standard
</p>
<p>
Solution:
</p>
<p>
One option would be to try to more carefully limit the requirements of
each function. There are many functions which would have to be checked.
However as has been shown in the std::copy case, this may be difficult.
A simpler, more global option would be to somewhere insert text similar to:
</p>
<p>
If the execution of any function would change either any values passed
by reference or any value in any range passed to a function in a way not
defined in the definition of that function, the result is undefined.
</p>
<p>
Such code would have to at least cover chapters 23 and 25 (the sections
I read through carefully). I can see no harm on applying it to much of
the rest of the standard.
</p>
<p>
Some existing parts of the standard could be improved to fit with this,
for example the requires for 25.2.1 (Copy) could be adjusted to:
</p>
<p>
Requires: For each non-negative integer n &lt; (last - first), assigning to
*(result + n) must not alter any value in the range [first + n, last).
</p>
<p>
However, this may add excessive complication.
</p>
<p>
One other benefit of clearly introducing this text is that it would
allow a number of small optimisations, such as caching values passed
by const reference.
</p>
<p><b>Proposed resolution:</b></p>
<p>
</p>
<hr>
<a name="527"><h3>527.&nbsp;tr1::bind has lost its Throws clause</h3></a><p><b>Section:</b>&nbsp;TR1 3.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.func.bind.bind"> [tr.func.bind.bind]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Peter Dimov&nbsp; <b>Date:</b>&nbsp;01 Oct 2005</p>
<p>
The original bind proposal gives the guarantee that tr1::bind(f, t1,
..., tN) does not throw when the copy constructors of f, t1, ..., tN
don't.
</p>
<p>
This guarantee is not present in the final version of TR1.
</p>
<p>
I'm pretty certain that we never removed it on purpose. Editorial omission? :-)
</p>
<p><b>Proposed resolution:</b></p>
<p>
</p>
<hr>
<a name="528"><h3>528.&nbsp;TR1: issue 6.19 vs 6.3.4.3/2 (and 6.3.4.5/2)</h3></a><p><b>Section:</b>&nbsp;TR1 6.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.unord.unord"> [tr.unord.unord]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a>&nbsp; <b>Submitter:</b>&nbsp;Paolo Carlini&nbsp; <b>Date:</b>&nbsp;12 Oct 2005</p>
<p>
while implementing the resolution of issue 6.19 I'm noticing the
following: according to 6.3.4.3/2 (and 6.3.4.5/2), for unordered_set and
unordered_multiset:
</p>
<blockquote>
"The iterator and const_iterator types are both const types. It is
unspecified whether they are the same type"
</blockquote>
<p>
Now, according to the resolution of 6.19, we have overloads of insert
with hint and erase (single and range) both for iterator and
const_iterator, which, AFAICS, can be meaningful at the same time *only*
if iterator and const_iterator *are* in fact different types.
</p>
<p>
Then, iterator and const_iterator are *required* to be different types?
Or that is an unintended consequence? Maybe the overloads for plain
iterators should be added only to unordered_map and unordered_multimap?
Or, of course, I'm missing something?
</p>
<p><b>Proposed resolution:</b></p>
<p>
Add to 6.3.4.3p2 (and 6.3.4.5p2):
</p>
<p>
2 ... The iterator and const_iterator types are both <del>const</del>
<ins>constant</ins> iterator types.
It is unspecified whether they are the same type. <ins>If they are the
same type, those signatures that become otherwise indistinguishable
collapse into a single signature.</ins>
</p>
<p>----- End of document -----</p> <p>----- End of document -----</p>
</body></html> </body></html>
\ No newline at end of file
libstdc++-v3/docs/html/ext/lwg-defects.html
...@@ -5,11 +5,11 @@ ...@@ -5,11 +5,11 @@
<table> <table>
<tbody><tr> <tbody><tr>
<td align="left">Doc. no.</td> <td align="left">Doc. no.</td>
<td align="left">N1831=05-0091</td> <td align="left">N1909=05-0169</td>
</tr> </tr>
<tr> <tr>
<td align="left">Date:</td> <td align="left">Date:</td>
<td align="left">2005-06-24</td> <td align="left">2005-10-23</td>
</tr> </tr>
<tr> <tr>
<td align="left">Project:</td> <td align="left">Project:</td>
...@@ -20,7 +20,7 @@ ...@@ -20,7 +20,7 @@
<td align="left">Howard Hinnant &lt;howard.hinnant@gmail.com&gt;</td> <td align="left">Howard Hinnant &lt;howard.hinnant@gmail.com&gt;</td>
</tr> </tr>
</tbody></table> </tbody></table>
<h1>C++ Standard Library Defect Report List (Revision R37)</h1> <h1>C++ Standard Library Defect Report List (Revision R39)</h1>
<p>Reference ISO/IEC IS 14882:1998(E)</p> <p>Reference ISO/IEC IS 14882:1998(E)</p>
<p>Also see:</p> <p>Also see:</p>
<ul> <ul>
...@@ -42,6 +42,21 @@ ...@@ -42,6 +42,21 @@
document.</p> document.</p>
<h2>Revision History</h2> <h2>Revision History</h2>
<ul> <ul>
<li>R39:
2005-10-14 post-Mont Tremblant mailing.
Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#526">526</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#528">528</a>.
Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461">461</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464">464</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#465">465</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#467">467</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#474">474</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#496">496</a> from Ready to WP as per the vote from Mont Tremblant.
Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a>, <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#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#497">497</a> from Review to Ready.
Moved 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#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#514">514</a> from New to Open.
Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#519">519</a> from New to Ready.
Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a> from New to Review.
</li>
<li>R38:
2005-07-03 pre-Mont Tremblant mailing.
Merged open TR1 issues in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#504">504</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>.
Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>
</li>
<li>R37: <li>R37:
2005-06 mid-term mailing. 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>. 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>.
...@@ -627,7 +642,7 @@ list maintainer's note: the IS is the same.]</p> ...@@ -627,7 +642,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 <p>See 99-0040/N1216, October 22, 1999, by Stephen D. Clamage for the analysis
supporting to the proposed resolution.</p> supporting to the proposed resolution.</p>
<hr> <hr>
<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> <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>
<p>(1) bitset&lt;&gt;::operator[] is mentioned in the class synopsis (23.3.5), but it is <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> not documented in 23.3.5.2. </p>
...@@ -680,7 +695,7 @@ it's undefined. </p> ...@@ -680,7 +695,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 <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> "charT()"</p>
<hr> <hr>
<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> <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>
<p>locale::combine is the only member function of locale (other than constructors and <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 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 why it should have been const. Furthermore, leaving it non-const conflicts with 22.1.1
...@@ -879,7 +894,7 @@ one case. The resolution of this issue clarifies what the LWG ...@@ -879,7 +894,7 @@ one case. The resolution of this issue clarifies what the LWG
believes to have been the original intent.</p> believes to have been the original intent.</p>
<hr> <hr>
<a name="24"><h3>24.&nbsp;"do_convert" doesn't exist</h3></a><p><b>Section:</b>&nbsp;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>&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="24"></a><h3><a name="24">24.&nbsp;"do_convert" doesn't exist</a></h3><p><b>Section:</b>&nbsp;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>&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 codecvt&lt;&gt;::do_out and do_in mentions a <p>The description of codecvt&lt;&gt;::do_out and do_in mentions a
symbol "do_convert" which is not defined in the symbol "do_convert" which is not defined in the
standard. This is a leftover from an edit, and should be "do_in standard. This is a leftover from an edit, and should be "do_in
...@@ -889,7 +904,7 @@ and do_out". </p> ...@@ -889,7 +904,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 "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> or do_out". </p>
<hr> <hr>
<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> <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>
<p>In the description of operator&lt;&lt; applied to strings, the standard says that uses <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" 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> elsewhere; but this is inconsistent, as this allows no possibility of space for padding. </p>
...@@ -2368,7 +2383,7 @@ item from:</p> ...@@ -2368,7 +2383,7 @@ item from:</p>
extracted. extracted.
</blockquote> </blockquote>
<hr> <hr>
<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> <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>
<p>The issue is this: Must the elements of a vector be in contiguous memory?</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 <p>(Please note that this is entirely separate from the question of
...@@ -2737,7 +2752,7 @@ returning eof or by throwing an exception; there are no other ...@@ -2737,7 +2752,7 @@ returning eof or by throwing an exception; there are no other
possibilities. The proposed resolution makes it clear that these two possibilities. The proposed resolution makes it clear that these two
functions do get characters from a streambuf.</p> functions do get characters from a streambuf.</p>
<hr> <hr>
<a name="92"><h3>92.&nbsp;Incomplete Algorithm Requirements</h3></a><p><b>Section:</b>&nbsp;25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</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;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p> <a name="92"></a><h3><a name="92">92.&nbsp;Incomplete Algorithm Requirements</a></h3><p><b>Section:</b>&nbsp;25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</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;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
<p>The standard does not state, how often a function object is copied, <p>The standard does not state, how often a function object is copied,
called, or the order of calls inside an algorithm. This may lead to called, or the order of calls inside an algorithm. This may lead to
surprising/buggy behavior. Consider the following example: </p> surprising/buggy behavior. Consider the following example: </p>
...@@ -2869,7 +2884,7 @@ for <tt>*r++</tt> from <tt>T</tt> to "convertible to T". ...@@ -2869,7 +2884,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 of input iterators, we can't impose any requirements in the Input
Iterator requirements table that forward iterators don't satisfy.</p> Iterator requirements table that forward iterators don't satisfy.</p>
<hr> <hr>
<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> <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>
<p>Set::iterator is described as implementation-defined with a <p>Set::iterator is described as implementation-defined with a
reference to the container requirement; the container requirement says reference to the container requirement; the container requirement says
that const_iterator is an iterator pointing to const T and iterator an that const_iterator is an iterator pointing to const T and iterator an
...@@ -3158,7 +3173,7 @@ reading:</p> ...@@ -3158,7 +3173,7 @@ reading:</p>
<p><b>Requires</b>: <tt>s.rdbuf()</tt> is not null.</p> <p><b>Requires</b>: <tt>s.rdbuf()</tt> is not null.</p>
</blockquote> </blockquote>
<hr> <hr>
<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> <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>
<p>Section 18.4.1.3 contains the following example: </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: <pre>[Example: This can be useful for constructing an object at a known address:
...@@ -3647,7 +3662,7 @@ to return a const char* not a const charT*. </p> ...@@ -3647,7 +3662,7 @@ to return a const char* not a const charT*. </p>
<tt>do_scan_not()</tt> to return a <tt> const <tt>do_scan_not()</tt> to return a <tt> const
charT*</tt>. </p> charT*</tt>. </p>
<hr> <hr>
<a name="125"><h3>125.&nbsp;valarray&lt;T&gt;::operator!() return type is inconsistent</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#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p> <a name="125"></a><h3><a name="125">125.&nbsp;valarray&lt;T&gt;::operator!() return type is inconsistent</a></h3><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#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
<p>In Section 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> valarray&lt;T&gt;::operator!() is <p>In Section 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> valarray&lt;T&gt;::operator!() is
declared to return a valarray&lt;T&gt;, but in Section 26.3.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.unary"> [lib.valarray.unary]</a> it is declared to return a valarray&lt;bool&gt;. The declared to return a valarray&lt;T&gt;, but in Section 26.3.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.unary"> [lib.valarray.unary]</a> it is declared to return a valarray&lt;bool&gt;. The
latter appears to be correct. </p> latter appears to be correct. </p>
...@@ -4151,7 +4166,7 @@ follows an "all-or-none" rule.</p> ...@@ -4151,7 +4166,7 @@ follows an "all-or-none" rule.</p>
<p>For inserters, the LWG believes there is no defect; the standard is correct <p>For inserters, the LWG believes there is no defect; the standard is correct
as written.</p> as written.</p>
<hr> <hr>
<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> <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>
<p>The library had many global functions until 17.4.1.1 [lib.contents] <p>The library had many global functions until 17.4.1.1 [lib.contents]
paragraph 2 was added: </p> paragraph 2 was added: </p>
...@@ -4405,8 +4420,8 @@ be fixed to use <tt>sbumpc()</tt> instead.</p> ...@@ -4405,8 +4420,8 @@ be fixed to use <tt>sbumpc()</tt> instead.</p>
"supplied" with the words "extracted from the "supplied" with the words "extracted from the
stream".</p> stream".</p>
<hr> <hr>
<a name="160"></a><h3><a name="160">160.&nbsp;Typo: Use of non-existing function <tt>exception()</tt> <a name="160"><h3>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> </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>
<p>The paragraph 4 refers to the function <tt>exception()</tt> which <p>The paragraph 4 refers to the function <tt>exception()</tt> which
is not defined. Probably, the referred function is is not defined. Probably, the referred function is
<tt>basic_ios&lt;&gt;::exceptions()</tt>.</p> <tt>basic_ios&lt;&gt;::exceptions()</tt>.</p>
...@@ -4567,7 +4582,7 @@ traits class for some arbitrary charT type, and we somehow have to ...@@ -4567,7 +4582,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 deal with a const char*. There's nothing better to do but fall back
to char_traits&lt;char&gt;</p> to char_traits&lt;char&gt;</p>
<hr> <hr>
<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> <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>
<p>The first paragraph begins with a descriptions what has to be done <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 in <i>formatted</i> output functions. Probably this is a typo and the
paragraph really want to describe unformatted output functions...</p> paragraph really want to describe unformatted output functions...</p>
...@@ -4858,7 +4873,7 @@ the nested types <tt>X::iterator</tt> and <tt>X::const_iterator</tt>, ...@@ -4858,7 +4873,7 @@ the nested types <tt>X::iterator</tt> and <tt>X::const_iterator</tt>,
where <tt>X</tt> is a container. There is no requirement that where <tt>X</tt> is a container. There is no requirement that
<tt>X::reverse_iterator</tt> and <tt>X::const_reverse_iterator</tt> <tt>X::reverse_iterator</tt> and <tt>X::const_reverse_iterator</tt>
can be mixed. If mixing them is considered important, that's a can be mixed. If mixing them is considered important, that's a
separate issue. (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#280">280</a>.) separate issue. (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>.)
</p> </p>
<hr> <hr>
<a name="181"><h3>181.&nbsp;make_pair() unintended behavior</h3></a><p><b>Section:</b>&nbsp;20.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.pairs"> [lib.pairs]</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;3 Aug 1999</p> <a name="181"><h3>181.&nbsp;make_pair() unintended behavior</h3></a><p><b>Section:</b>&nbsp;20.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.pairs"> [lib.pairs]</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;3 Aug 1999</p>
...@@ -5896,7 +5911,7 @@ change. ...@@ -5896,7 +5911,7 @@ change.
or change the return to distance(b,a). The LWG preferred the or change the return to distance(b,a). The LWG preferred the
former for consistency.</p> former for consistency.</p>
<hr> <hr>
<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> <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>
<p>The description of the stream extraction operator for std::string (section <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 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 the case that the operator fails to extract any characters from the input
...@@ -8407,6 +8422,73 @@ the wording. Dave provided new wording.]</i></p> ...@@ -8407,6 +8422,73 @@ the wording. Dave provided new wording.]</i></p>
all iterators pointing into the vector. That doesn't necessarily all iterators pointing into the vector. That doesn't necessarily
mean they all become singular.</p> mean they all become singular.</p>
<hr> <hr>
<a name="280"><h3>280.&nbsp;Comparison of reverse_iterator to const reverse_iterator</h3></a><p><b>Section:</b>&nbsp;24.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iterators"> [lib.reverse.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;Steve Cleary&nbsp; <b>Date:</b>&nbsp;27 Nov 2000</p>
<p>
This came from an email from Steve Cleary to Fergus in reference to
issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>. The library working group briefly discussed
this in Toronto and believed it should be a separate issue. There was
also some reservations about whether this was a worthwhile problem to
fix.
</p>
<p>
Steve said: "Fixing reverse_iterator. std::reverse_iterator can
(and should) be changed to preserve these additional
requirements." He also said in email that it can be done without
breaking user's code: "If you take a look at my suggested
solution, reverse_iterator doesn't have to take two parameters; there
is no danger of breaking existing code, except someone taking the
address of one of the reverse_iterator global operator functions, and
I have to doubt if anyone has ever done that. . . <i>But</i>, just in
case they have, you can leave the old global functions in as well --
they won't interfere with the two-template-argument functions. With
that, I don't see how <i>any</i> user code could break."
</p>
<p><b>Proposed resolution:</b></p>
<p>
<b>Section:</b> 24.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iterator"> [lib.reverse.iterator]</a>
add/change the following declarations:</p>
<pre> A) Add a templated assignment operator, after the same manner
as the templated copy constructor, i.e.:
template &lt; class U &gt;
reverse_iterator &lt; Iterator &gt;&amp; operator=(const reverse_iterator&lt; U &gt;&amp; u);
B) Make all global functions (except the operator+) have
two template parameters instead of one, that is, for
operator ==, !=, &lt;, &gt;, &lt;=, &gt;=, - replace:
template &lt; class Iterator &gt;
typename reverse_iterator&lt; Iterator &gt;::difference_type operator-(
const reverse_iterator&lt; Iterator &gt;&amp; x,
const reverse_iterator&lt; Iterator &gt;&amp; y);
with:
template &lt; class Iterator1, class Iterator2 &gt;
typename reverse_iterator &lt; Iterator1 &gt;::difference_type operator-(
const reverse_iterator &lt; Iterator1 &gt; &amp; x,
const reverse_iterator &lt; Iterator2 &gt; &amp; y);
</pre>
<p>
Also make the addition/changes for these signatures in
24.4.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.ops"> [lib.reverse.iter.ops]</a>.
</p>
<p><i>[
Copenhagen: The LWG is concerned that the proposed resolution
introduces new overloads. Experience shows that introducing
overloads is always risky, and that it would be inappropriate to
make this change without implementation experience. It may be
desirable to provide this feature in a different way.
]</i></p>
<p><i>[
Lillehammer: We now have implementation experience, and agree that
this solution is safe and correct.
]</i></p>
<hr>
<a name="281"><h3>281.&nbsp;std::min() and max() requirements overly restrictive</h3></a><p><b>Section:</b>&nbsp;25.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.min.max"> [lib.alg.min.max]</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;02 Dec 2000</p> <a name="281"><h3>281.&nbsp;std::min() and max() requirements overly restrictive</h3></a><p><b>Section:</b>&nbsp;25.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.min.max"> [lib.alg.min.max]</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;02 Dec 2000</p>
<p>The requirements in 25.3.7, p1 and 4 call for T to satisfy the <p>The requirements in 25.3.7, p1 and 4 call for T to satisfy the
requirements of <tt>LessThanComparable</tt> (20.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>) requirements of <tt>LessThanComparable</tt> (20.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>)
...@@ -9022,7 +9104,7 @@ list" is excessively vague.]</i></p> ...@@ -9022,7 +9104,7 @@ list" is excessively vague.]</i></p>
<p><i>[Post-Curaao: Robert Klarer provided new wording.]</i></p> <p><i>[Post-Curaao: Robert Klarer provided new wording.]</i></p>
<hr> <hr>
<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> <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>
<p> <p>
The effects clause for the basic_string template ctor in 21.3.1, p15 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 leaves out the third argument of type Allocator. I believe this to be
...@@ -10998,7 +11080,7 @@ key greater than k, or a.end() if such an element is not found. ...@@ -10998,7 +11080,7 @@ key greater than k, or a.end() if such an element is not found.
<p><i>[Curaao: LWG reviewed PR.]</i></p> <p><i>[Curaao: LWG reviewed PR.]</i></p>
<hr> <hr>
<a name="355"><h3>355.&nbsp;Operational semantics for a.back()</h3></a><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#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Yaroslav Mironov&nbsp; <b>Date:</b>&nbsp;23 Jan 2002</p> <a name="355"></a><h3><a name="355">355.&nbsp;Operational semantics for a.back()</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#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Yaroslav Mironov&nbsp; <b>Date:</b>&nbsp;23 Jan 2002</p>
<p>Table 68 "Optional Sequence Operations" in 23.1.1/12 <p>Table 68 "Optional Sequence Operations" in 23.1.1/12
specifies operational semantics for "a.back()" as specifies operational semantics for "a.back()" as
...@@ -11067,8 +11149,8 @@ LWG would like a new issue opened.]</i></p> ...@@ -11067,8 +11149,8 @@ LWG would like a new issue opened.]</i></p>
"*tmp" to "return *tmp;"]</i></p> "*tmp" to "return *tmp;"]</i></p>
<hr> <hr>
<a name="358"><h3>358.&nbsp;interpreting <tt>thousands_sep</tt> after a <tt>decimal_point</tt> <a name="358"></a><h3><a name="358">358.&nbsp;interpreting <tt>thousands_sep</tt> after a <tt>decimal_point</tt>
</h3></a><p><b>Section:</b>&nbsp;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>&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;12 Mar 2002</p> </a></h3><p><b>Section:</b>&nbsp;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>&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;12 Mar 2002</p>
<p> <p>
I don't think <tt>thousands_sep</tt> is being treated correctly after I don't think <tt>thousands_sep</tt> is being treated correctly after
decimal_point has been seen. Since grouping applies only to the decimal_point has been seen. Since grouping applies only to the
...@@ -11350,7 +11432,7 @@ with the following signature:</p> ...@@ -11350,7 +11432,7 @@ with the following signature:</p>
<p><b>Rationale:</b></p> <p><b>Rationale:</b></p>
<p>Fixes an obvious typo.</p> <p>Fixes an obvious typo.</p>
<hr> <hr>
<a name="373"><h3>373.&nbsp;Are basic_istream and basic_ostream to use (exceptions()&amp;badbit) != 0 ?</h3></a><p><b>Section:</b>&nbsp;27.6.1.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a>, 27.6.2.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.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;Keith Baker&nbsp; <b>Date:</b>&nbsp;23 Jul 2002</p> <a name="373"></a><h3><a name="373">373.&nbsp;Are basic_istream and basic_ostream to use (exceptions()&amp;badbit) != 0 ?</a></h3><p><b>Section:</b>&nbsp;27.6.1.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a>, 27.6.2.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.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;Keith Baker&nbsp; <b>Date:</b>&nbsp;23 Jul 2002</p>
<p> <p>
In 27.6.1.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a> and 27.6.2.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a> In 27.6.1.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a> and 27.6.2.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a>
...@@ -11367,7 +11449,7 @@ In 27.6.1.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams ...@@ -11367,7 +11449,7 @@ In 27.6.1.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams
<p><b>Rationale:</b></p> <p><b>Rationale:</b></p>
<p>Fixes an obvious typo.</p> <p>Fixes an obvious typo.</p>
<hr> <hr>
<a name="375"><h3>375.&nbsp;basic_ios should be ios_base in 27.7.1.3</h3></a><p><b>Section:</b>&nbsp;27.7.1.3 <a href="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;Ray Lischner&nbsp; <b>Date:</b>&nbsp;14 Aug 2002</p> <a name="375"></a><h3><a name="375">375.&nbsp;basic_ios should be ios_base in 27.7.1.3</a></h3><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;Ray Lischner&nbsp; <b>Date:</b>&nbsp;14 Aug 2002</p>
<p> <p>
In Section 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>: Table 90, Table 91, and paragraph In Section 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>: Table 90, Table 91, and paragraph
14 all contain references to "basic_ios::" which should be 14 all contain references to "basic_ios::" which should be
...@@ -11449,7 +11531,7 @@ heading Meaning, to "space for more than (to_limit - to) destination ...@@ -11449,7 +11531,7 @@ heading Meaning, to "space for more than (to_limit - to) destination
elements was needed to terminate a sequence given the value of state." elements was needed to terminate a sequence given the value of state."
</p> </p>
<hr> <hr>
<a name="381"><h3>381.&nbsp;detection of invalid mbstate_t in codecvt</h3></a><p><b>Section:</b>&nbsp;22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.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;Martin Sebor&nbsp; <b>Date:</b>&nbsp;6 Sep 2002</p> <a name="381"></a><h3><a name="381">381.&nbsp;detection of invalid mbstate_t in codecvt</a></h3><p><b>Section:</b>&nbsp;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>&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;6 Sep 2002</p>
<p> <p>
All but one codecvt member functions that take a state_type argument All but one codecvt member functions that take a state_type argument
list as one of their preconditions that the state_type argument have list as one of their preconditions that the state_type argument have
...@@ -12023,7 +12105,7 @@ flags.]</i></p> ...@@ -12023,7 +12105,7 @@ flags.]</i></p>
of the three fstream class template instead.]</i></p> of the three fstream class template instead.]</i></p>
<hr> <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> <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#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Hans Bos&nbsp; <b>Date:</b>&nbsp;7 Jun 2003</p>
<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 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 comparison operators (==, !=, &lt;, &lt;=, &gt;, =&gt;) for queue and
...@@ -12108,7 +12190,7 @@ set_intersection(), not union() and intersection(). ...@@ -12108,7 +12190,7 @@ set_intersection(), not union() and intersection().
<p><b>Proposed resolution:</b></p> <p><b>Proposed resolution:</b></p>
<p>Change that sentence to use the correct names.</p> <p>Change that sentence to use the correct names.</p>
<hr> <hr>
<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> <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#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;10 Jul 2003</p>
<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 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 function only throws if the respective bits are already set prior to
...@@ -12774,7 +12856,7 @@ template parameter.</p> ...@@ -12774,7 +12856,7 @@ template parameter.</p>
text.]</i></p> text.]</i></p>
<hr> <hr>
<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> <a name="438"><h3>438.&nbsp;Ambiguity in the "do the right thing" clause</h3></a><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 <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> noticed with statements like:</p>
...@@ -13476,6 +13558,294 @@ that it is intended to be callable with one argument. ...@@ -13476,6 +13558,294 @@ that it is intended to be callable with one argument.
void open(const char*s, void open(const char*s,
ios_base::openmode mode = ios_base::in|ios_base::out); ios_base::openmode mode = ios_base::in|ios_base::out);
<hr> <hr>
<a name="461"><h3>461.&nbsp;time_get hard or impossible to implement</h3></a><p><b>Section:</b>&nbsp;22.2.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.get.virtuals"> [lib.locale.time.get.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;Bill Plauger&nbsp; <b>Date:</b>&nbsp;23 Mar 2004</p>
<p>
Template time_get currently contains difficult, if not impossible,
requirements for do_date_order, do_get_time, and do_get_date. All require
the implementation to scan a field generated by the %x or %X conversion
specifier in strftime. Yes, do_date_order can always return no_order, but
that doesn't help the other functions. The problem is that %x can be
nearly anything, and it can vary widely with locales. It's horribly
onerous to have to parse "third sunday after Michaelmas in the year of
our Lord two thousand and three," but that's what we currently ask of
do_get_date. More practically, it leads some people to think that if
%x produces 10.2.04, we should know to look for dots as separators. Still
not easy.
</p>
<p>
Note that this is the <i>opposite</i> effect from the intent stated in the
footnote earlier in this subclause:
</p>
<blockquote>
"In other words, user confirmation is required for reliable parsing of
user-entered dates and times, but machine-generated formats can be
parsed reliably. This allows parsers to be aggressive about interpreting
user variations on standard formats."
</blockquote>
<p>
We should give both implementers and users an easier and more reliable
alternative: provide a (short) list of alternative delimiters and say
what the default date order is for no_order. For backward compatibility,
and maximum latitude, we can permit an implementation to parse whatever
%x or %X generates, but we shouldn't require it.
</p>
<p><b>Proposed resolution:</b></p>
<p><b>In the description:</b></p>
<pre>iter_type do_get_time(iter_type s, iter_type end, ios_base&amp; str,
ios_base::iostate&amp; err, tm* t) const;
</pre>
<p>
2 Effects: Reads characters starting at suntil it has extracted those
struct tm members, and remaining format characters, used by
time_put&lt;&gt;::put to produce the format specified by 'X', or until it
encounters an error or end of sequence.
</p>
<p><b>change:</b> 'X'</p>
<p><b>to:</b> "%H:%M:%S"</p>
<p>Change</p>
<pre>iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
ios_base::iostate&amp; err, tm* t) const;
4 Effects: Reads characters starting at s until it has extracted those
struct tm members, and remaining format characters, used by
time_put&lt;&gt;::put to produce the format specified by 'x', or until it
encounters an error.
</pre>
<p>to</p>
iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
ios_base::iostate&amp; err, tm* t) const;
4 Effects: Reads characters starting at s until it has extracted those
struct tm members, and remaining format characters, used by
time_put&lt;&gt;::put to produce one of the following formats, or until it
encounters an error. The format depends on the value returned by
date_order() as follows:
date_order() format
no_order "%m/%d/%y"
dmy "%d/%m/%y"
mdy "%m/%d/%y"
ymd "%y/%m/%d"
ydm "%y/%d/%m"
An implementation may also accept additional implementation-defined formats.
<pre></pre>
<p><i>[Redmond: agreed that this is a real problem. The solution is
probably to match C99's parsing rules. Bill provided wording.
]</i></p>
<hr>
<a name="464"><h3>464.&nbsp;Suggestion for new member functions in standard containers</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>, 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</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;Thorsten Ottosen&nbsp; <b>Date:</b>&nbsp;12 May 2004</p>
<p>To add slightly more convenience to vector&lt;T&gt; and map&lt;Key,T&gt; we should consider to add</p>
<ol>
<li> add vector&lt;T&gt;::data() member (const and non-const version)
semantics: if( empty() ) return 0; else return buffer_;</li>
<li> add map&lt;Key,T&gt;::at( const Key&amp; k ) member (const and non-const version)
<i>semantics</i>: iterator i = find( k ); if( i != end() ) return *i; else throw range_error();</li>
</ol>
<p>Rationale:</p>
<ul>
<li>To obtain a pointer to the vector's buffer, one must use either
operator[]() (which can give undefined behavior for empty vectors) or
at() (which will then throw if the vector is empty). </li>
<li>tr1::array&lt;T,sz&gt; already has a data() member</li>
<li>e cannot use operator[]() when T is not DefaultDonstructible</li>
<li>Neither when the map is const.</li>
<li>when we want to make sure we don't add an element accidently</li>
<li>when it should be considered an error if a key is not in the map</li>
</ul>
<p><b>Proposed resolution:</b></p>
<p>In 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>, add the following to the <tt>vector</tt>
synopsis after "element access" and before "modifiers":</p>
<pre> // <i>[lib.vector.data] data access</i>
pointer data();
const_pointer data() const;
</pre>
<p>Add a new subsection of 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>:</p>
<blockquote>
<p>23.2.4.x <tt>vector</tt> data access</p>
<pre> pointer data();
const_pointer data() const;
</pre>
<p><b>Returns:</b> A pointer such that [data(), data() + size()) is a valid
range. For a non-empty vector, data() == &amp;front().</p>
<p><b>Complexity:</b> Constant time.</p>
<p><b>Throws:</b> Nothing.</p>
</blockquote>
<p>In 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a>, add the following to the <tt>map</tt>
synopsis immediately after the line for operator[]:</p>
<pre> T&amp; at(const key_type&amp; x);
const T&amp; at(const key_type&amp; x) const;
</pre>
<p>Add the following to 23.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map.access"> [lib.map.access]</a>:</p>
<blockquote>
<pre> T&amp; at(const key_type&amp; x);
const T&amp; at(const key_type&amp; x) const;
</pre>
<p><b>Returns:</b> A reference to the element whose key is equivalent
to x, if such an element is present in the map.</p>
<p><b>Throws:</b> <tt>out_of_range</tt> if no such element is present.</p>
</blockquote>
<p><b>Rationale:</b></p>
<p>Neither of these additions provides any new functionality but the
LWG agreed that they are convenient, especially for novices. The
exception type chosen for <tt>at</tt>, <tt>std::out_of_range</tt>,
was chosen to match <tt>vector::at</tt>.</p>
<hr>
<a name="465"><h3>465.&nbsp;Contents of &lt;ciso646&gt;</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>&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;3 Jun 2004</p>
<p>C header &lt;iso646.h&gt; defines macros for some operators, such as
not_eq for !=.</p>
<p>Section 17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a> "Headers" says that except as noted in
clauses 18 through 27, the &lt;cname&gt; C++ header contents are the same
as the C header &lt;name.h&gt;. In particular, table 12 lists
&lt;ciso646&gt; as a C++ header.</p>
<p>I don't find any other mention of &lt;ciso646&gt;, or any mention of
&lt;iso646.h&gt;, in clauses 17 thorough 27. That implies that the
contents of &lt;ciso646&gt; are the same as C header &lt;iso646.h&gt;.</p>
<p>Annex C (informative, not normative) in [diff.header.iso646.h] C.2.2.2
"Header &lt;iso646.h&gt;" says that the alternative tokens are not
defined as macros in &lt;ciso646&gt;, but does not mention the contents
of &lt;iso646.h&gt;.</p>
<p>I don't find any normative text to support C.2.2.2.</p>
<p><b>Proposed resolution:</b></p>
<p>Add to section 17.4.1.2 Headers [lib.headers] a new paragraph after
paragraph 6 (the one about functions must be functions):</p>
<blockquote>
<p>Identifiers that are keywords or operators in C++ shall not be defined
as macros in C++ standard library headers.
[Footnote:In particular, including the standard header &lt;iso646.h&gt;
or &lt;ciso646&gt; has no effect. </p>
</blockquote>
<p><i>[post-Redmond: Steve provided wording.]</i></p>
<hr>
<a name="467"><h3>467.&nbsp;char_traits::lt(), compare(), and memcmp()</h3></a><p><b>Section:</b>&nbsp;21.1.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits.specializations.char"> [lib.char.traits.specializations.char]</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 Jun 2004</p>
<p>
Table 37 describes the requirements on Traits::compare() in terms of
those on Traits::lt(). 21.1.3.1, p6 requires char_traits&lt;char&gt;::lt()
to yield the same result as operator&lt;(char, char).
</p>
<p>
Most, if not all, implementations of char_traits&lt;char&gt;::compare()
call memcmp() for efficiency. However, the C standard requires both
memcmp() and strcmp() to interpret characters under comparison as
unsigned, regardless of the signedness of char. As a result, all
these char_traits implementations fail to meet the requirement
imposed by Table 37 on compare() when char is signed.
</p>
<p>Read email thread starting with c++std-lib-13499 for more. </p>
<p><b>Proposed resolution:</b></p>
<p>Change 21.1.3.1, p6 from</p>
<blockquote>
The two-argument members assign, eq, and lt are defined identically
to the built-in operators =, ==, and &lt; respectively.
</blockquote>
<p>to</p>
<blockquote>
The two-argument member assign is defined identically to
the built-in operator =. The two
argument members eq and lt are defined identically to
the built-in operators == and &lt; for type unsigned char.
</blockquote>
<p><i>[Redmond: The LWG agreed with this general direction, but we
also need to change <tt>eq</tt> to be consistent with this change.
Post-Redmond: Martin provided wording.]</i></p>
<hr>
<a name="468"><h3>468.&nbsp;unexpected consequences of ios_base::operator void*()</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#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jun 2004</p>
<p>The program below is required to compile but when run it typically
produces unexpected results due to the user-defined conversion from
std::cout or any object derived from basic_ios to void*.
</p>
<pre> #include &lt;cassert&gt;
#include &lt;iostream&gt;
int main ()
{
assert (std::cin.tie () == std::cout);
// calls std::cout.ios::operator void*()
}
</pre>
<p><b>Proposed resolution:</b></p>
<p>
Replace std::basic_ios&lt;charT, traits&gt;::operator void*() with another
conversion operator to some unspecified type that is guaranteed not
to be convertible to any other type except for bool (a pointer-to-member
might be one such suitable type). In addition, make it clear that the
pointer type need not be a pointer to a complete type and when non-null,
the value need not be valid.
</p>
<p>Specifically, change in [lib.ios] the signature of</p>
<pre> operator void*() const;
</pre>
<p>to</p>
<pre> operator unspecified-bool-type() const;
</pre>
<p>and change [lib.iostate.flags], p1 from</p>
<pre> operator void*() const;
</pre>
<p>to</p>
<pre>operator unspecified-bool-type() const;
-1- Returns: if fail() then a value that will evaluate false in a
boolean context; otherwise a value that will evaluate true in a
boolean context. The value type returned shall not be
convertible to int.
-2- [Note: This conversion can be used in contexts where a bool
is expected (e.g., an if condition); however, implicit
conversions (e.g., to int) that can occur with bool are not
allowed, eliminating some sources of user error. One possible
implementation choice for this type is pointer-to-member. - end
note]
</pre>
<p><i>[Redmond: 5-4 straw poll in favor of doing this.]</i></p>
<p><i>[Lillehammer: Doug provided revised wording for
"unspecified-bool-type".]</i></p>
<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> <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> <p>
...@@ -13491,5 +13861,30 @@ in c++std-lib-13647). ...@@ -13491,5 +13861,30 @@ in c++std-lib-13647).
Remove all overloads of overloads of relational operators for Remove all overloads of overloads of relational operators for
vector&lt;bool&gt; from [lib.vector.bool]. vector&lt;bool&gt; from [lib.vector.bool].
</p> </p>
<hr>
<a name="474"><h3>474.&nbsp;confusing Footnote 297</h3></a><p><b>Section:</b>&nbsp;27.6.2.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</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;1 Jul 2004</p>
<p>
I think Footnote 297 is confused. The paragraph it applies to seems
quite clear in that widen() is only called if the object is not a char
stream (i.e., not basic_ostream&lt;char&gt;), so it's irrelevant what the
value of widen(c) is otherwise.
</p>
<p><b>Proposed resolution:</b></p>
<p>
I propose to strike the Footnote.
</p>
<hr>
<a name="496"><h3>496.&nbsp;Illegal use of "T" in vector&lt;bool&gt;</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#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;richard@ex-parrot.com&nbsp; <b>Date:</b>&nbsp;10 Feb 2005</p>
<p>
In the synopsis of the std::vector&lt;bool&gt; specialisation in 23.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.bool"> [lib.vector.bool]</a>,
the non-template assign() function has the signature</p>
<pre> void assign( size_type n, const T&amp; t );
</pre>
<p>The type, T, is not defined in this context.</p>
<p><b>Proposed resolution:</b></p>
<p>Replace "T" with "value_type".</p>
<p>----- End of document -----</p> <p>----- End of document -----</p>
</body></html> </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