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
This commit is contained in:
Paolo Carlini
Paolo Carlini
parent
6868dfa02b
commit
e4b600fb23
@ -1,3 +1,8 @@
|
||||
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>
|
||||
|
||||
PR libstdc++/24450
|
||||
|
||||
@ -453,7 +453,7 @@
|
||||
<dd>Similar to 118.
|
||||
</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>
|
||||
</dt>
|
||||
<dd>Add global functions with two template parameters.
|
||||
@ -528,7 +528,7 @@
|
||||
<dd>Don't fail if the next pointer is null and newoff is zero.
|
||||
</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>
|
||||
</dt>
|
||||
<dd>Add <code>data()</code> to <code>std::vector</code> and
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -5,11 +5,11 @@
|
||||
<table>
|
||||
<tbody><tr>
|
||||
<td align="left">Doc. no.</td>
|
||||
<td align="left">N1831=05-0091</td>
|
||||
<td align="left">N1909=05-0169</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td align="left">Date:</td>
|
||||
<td align="left">2005-06-24</td>
|
||||
<td align="left">2005-10-23</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td align="left">Project:</td>
|
||||
@ -20,7 +20,7 @@
|
||||
<td align="left">Howard Hinnant <howard.hinnant@gmail.com></td>
|
||||
</tr>
|
||||
</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>Also see:</p>
|
||||
<ul>
|
||||
@ -42,6 +42,21 @@
|
||||
document.</p>
|
||||
<h2>Revision History</h2>
|
||||
<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:
|
||||
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>.
|
||||
@ -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
|
||||
supporting to the proposed resolution.</p>
|
||||
<hr>
|
||||
<a name="11"></a><h3><a name="11">11. Bitset minor problems</a></h3><p><b>Section:</b> 23.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 22 Jan 1998</p>
|
||||
<a name="11"><h3>11. Bitset minor problems</h3></a><p><b>Section:</b> 23.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 22 Jan 1998</p>
|
||||
<p>(1) bitset<>::operator[] is mentioned in the class synopsis (23.3.5), but it is
|
||||
not documented in 23.3.5.2. </p>
|
||||
|
||||
@ -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
|
||||
"charT()"</p>
|
||||
<hr>
|
||||
<a name="14"></a><h3><a name="14">14. Locale::combine should be const</a></h3><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
||||
<a name="14"><h3>14. Locale::combine should be const</h3></a><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
||||
<p>locale::combine is the only member function of locale (other than constructors and
|
||||
destructor) that is not const. There is no reason for it not to be const, and good reasons
|
||||
why it should have been const. Furthermore, leaving it non-const conflicts with 22.1.1
|
||||
@ -879,7 +894,7 @@ one case. The resolution of this issue clarifies what the LWG
|
||||
believes to have been the original intent.</p>
|
||||
|
||||
<hr>
|
||||
<a name="24"><h3>24. "do_convert" doesn't exist</h3></a><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
||||
<a name="24"></a><h3><a name="24">24. "do_convert" doesn't exist</a></h3><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
||||
<p>The description of codecvt<>::do_out and do_in mentions a
|
||||
symbol "do_convert" which is not defined in the
|
||||
standard. This is a leftover from an edit, and should be "do_in
|
||||
@ -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
|
||||
or do_out". </p>
|
||||
<hr>
|
||||
<a name="25"></a><h3><a name="25">25. String operator<< uses width() value wrong</a></h3><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
||||
<a name="25"><h3>25. String operator<< uses width() value wrong</h3></a><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
||||
<p>In the description of operator<< applied to strings, the standard says that uses
|
||||
the smaller of os.width() and str.size(), to pad "as described in stage 3"
|
||||
elsewhere; but this is inconsistent, as this allows no possibility of space for padding. </p>
|
||||
@ -2368,7 +2383,7 @@ item from:</p>
|
||||
extracted.
|
||||
</blockquote>
|
||||
<hr>
|
||||
<a name="69"></a><h3><a name="69">69. Must elements of a vector be contiguous?</a></h3><p><b>Section:</b> 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 29 Jul 1998</p>
|
||||
<a name="69"><h3>69. Must elements of a vector be contiguous?</h3></a><p><b>Section:</b> 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 29 Jul 1998</p>
|
||||
<p>The issue is this: Must the elements of a vector be in contiguous memory?</p>
|
||||
|
||||
<p>(Please note that this is entirely separate from the question of
|
||||
@ -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
|
||||
functions do get characters from a streambuf.</p>
|
||||
<hr>
|
||||
<a name="92"><h3>92. Incomplete Algorithm Requirements</h3></a><p><b>Section:</b> 25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
|
||||
<a name="92"></a><h3><a name="92">92. Incomplete Algorithm Requirements</a></h3><p><b>Section:</b> 25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
|
||||
<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
|
||||
surprising/buggy behavior. Consider the following example: </p>
|
||||
@ -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
|
||||
Iterator requirements table that forward iterators don't satisfy.</p>
|
||||
<hr>
|
||||
<a name="103"></a><h3><a name="103">103. set::iterator is required to be modifiable, but this allows modification of keys</a></h3><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p>
|
||||
<a name="103"><h3>103. set::iterator is required to be modifiable, but this allows modification of keys</h3></a><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p>
|
||||
<p>Set::iterator is described as implementation-defined with a
|
||||
reference to the container requirement; the container requirement says
|
||||
that const_iterator is an iterator pointing to const T and iterator an
|
||||
@ -3158,7 +3173,7 @@ reading:</p>
|
||||
<p><b>Requires</b>: <tt>s.rdbuf()</tt> is not null.</p>
|
||||
</blockquote>
|
||||
<hr>
|
||||
<a name="114"></a><h3><a name="114">114. Placement forms example in error twice</a></h3><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 28 Oct 1998</p>
|
||||
<a name="114"><h3>114. Placement forms example in error twice</h3></a><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 28 Oct 1998</p>
|
||||
<p>Section 18.4.1.3 contains the following example: </p>
|
||||
|
||||
<pre>[Example: This can be useful for constructing an object at a known address:
|
||||
@ -3647,7 +3662,7 @@ to return a const char* not a const charT*. </p>
|
||||
<tt>do_scan_not()</tt> to return a <tt> const
|
||||
charT*</tt>. </p>
|
||||
<hr>
|
||||
<a name="125"><h3>125. valarray<T>::operator!() return type is inconsistent</h3></a><p><b>Section:</b> 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
|
||||
<a name="125"></a><h3><a name="125">125. valarray<T>::operator!() return type is inconsistent</a></h3><p><b>Section:</b> 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
|
||||
<p>In Section 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.valarray"> [lib.template.valarray]</a> valarray<T>::operator!() is
|
||||
declared to return a valarray<T>, but in Section 26.3.2.5 <a href="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<bool>. The
|
||||
latter appears to be correct. </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
|
||||
as written.</p>
|
||||
<hr>
|
||||
<a name="147"></a><h3><a name="147">147. Library Intro refers to global functions that aren't global</a></h3><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Lois Goldthwaite <b>Date:</b> 4 Jun 1999</p>
|
||||
<a name="147"><h3>147. Library Intro refers to global functions that aren't global</h3></a><p><b>Section:</b> 17.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.global.functions"> [lib.global.functions]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Lois Goldthwaite <b>Date:</b> 4 Jun 1999</p>
|
||||
<p>The library had many global functions until 17.4.1.1 [lib.contents]
|
||||
paragraph 2 was added: </p>
|
||||
|
||||
@ -4405,8 +4420,8 @@ be fixed to use <tt>sbumpc()</tt> instead.</p>
|
||||
"supplied" with the words "extracted from the
|
||||
stream".</p>
|
||||
<hr>
|
||||
<a name="160"></a><h3><a name="160">160. Typo: Use of non-existing function <tt>exception()</tt>
|
||||
</a></h3><p><b>Section:</b> 27.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream"> [lib.istream]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
||||
<a name="160"><h3>160. Typo: Use of non-existing function <tt>exception()</tt>
|
||||
</h3></a><p><b>Section:</b> 27.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream"> [lib.istream]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
||||
<p>The paragraph 4 refers to the function <tt>exception()</tt> which
|
||||
is not defined. Probably, the referred function is
|
||||
<tt>basic_ios<>::exceptions()</tt>.</p>
|
||||
@ -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
|
||||
to char_traits<char></p>
|
||||
<hr>
|
||||
<a name="168"></a><h3><a name="168">168. Typo: formatted vs. unformatted</a></h3><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
||||
<a name="168"><h3>168. Typo: formatted vs. unformatted</h3></a><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
|
||||
<p>The first paragraph begins with a descriptions what has to be done
|
||||
in <i>formatted</i> output functions. Probably this is a typo and the
|
||||
paragraph really want to describe unformatted output functions...</p>
|
||||
@ -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
|
||||
<tt>X::reverse_iterator</tt> and <tt>X::const_reverse_iterator</tt>
|
||||
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>
|
||||
<hr>
|
||||
<a name="181"><h3>181. make_pair() unintended behavior</h3></a><p><b>Section:</b> 20.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.pairs"> [lib.pairs]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 3 Aug 1999</p>
|
||||
@ -5896,7 +5911,7 @@ change.
|
||||
or change the return to distance(b,a). The LWG preferred the
|
||||
former for consistency.</p>
|
||||
<hr>
|
||||
<a name="211"></a><h3><a name="211">211. operator>>(istream&, string&) doesn't set failbit</a></h3><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Scott Snyder <b>Date:</b> 4 Feb 2000</p>
|
||||
<a name="211"><h3>211. operator>>(istream&, string&) doesn't set failbit</h3></a><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Scott Snyder <b>Date:</b> 4 Feb 2000</p>
|
||||
<p>The description of the stream extraction operator for std::string (section
|
||||
21.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in
|
||||
the case that the operator fails to extract any characters from the input
|
||||
@ -8406,6 +8421,73 @@ the wording. Dave provided new wording.]</i></p>
|
||||
element into the middle of a vector is correctly said to invalidate
|
||||
all iterators pointing into the vector. That doesn't necessarily
|
||||
mean they all become singular.</p>
|
||||
<hr>
|
||||
<a name="280"><h3>280. Comparison of reverse_iterator to const reverse_iterator</h3></a><p><b>Section:</b> 24.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iterators"> [lib.reverse.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Steve Cleary <b>Date:</b> 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 < class U >
|
||||
reverse_iterator < Iterator >& operator=(const reverse_iterator< U >& u);
|
||||
|
||||
B) Make all global functions (except the operator+) have
|
||||
two template parameters instead of one, that is, for
|
||||
operator ==, !=, <, >, <=, >=, - replace:
|
||||
|
||||
template < class Iterator >
|
||||
typename reverse_iterator< Iterator >::difference_type operator-(
|
||||
const reverse_iterator< Iterator >& x,
|
||||
const reverse_iterator< Iterator >& y);
|
||||
|
||||
with:
|
||||
|
||||
template < class Iterator1, class Iterator2 >
|
||||
typename reverse_iterator < Iterator1 >::difference_type operator-(
|
||||
const reverse_iterator < Iterator1 > & x,
|
||||
const reverse_iterator < Iterator2 > & 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. std::min() and max() requirements overly restrictive</h3></a><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 02 Dec 2000</p>
|
||||
<p>The requirements in 25.3.7, p1 and 4 call for T to satisfy the
|
||||
@ -9022,7 +9104,7 @@ list" is excessively vague.]</i></p>
|
||||
<p><i>[Post-Curaçao: Robert Klarer provided new wording.]</i></p>
|
||||
|
||||
<hr>
|
||||
<a name="301"></a><h3><a name="301">301. basic_string template ctor effects clause omits allocator argument</a></h3><p><b>Section:</b> 21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 27 Jan 2001</p>
|
||||
<a name="301"><h3>301. basic_string template ctor effects clause omits allocator argument</h3></a><p><b>Section:</b> 21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 27 Jan 2001</p>
|
||||
<p>
|
||||
The effects clause for the basic_string template ctor in 21.3.1, p15
|
||||
leaves out the third argument of type Allocator. I believe this to be
|
||||
@ -10998,7 +11080,7 @@ key greater than k, or a.end() if such an element is not found.
|
||||
<p><i>[Curaçao: LWG reviewed PR.]</i></p>
|
||||
|
||||
<hr>
|
||||
<a name="355"><h3>355. Operational semantics for a.back()</h3></a><p><b>Section:</b> 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Yaroslav Mironov <b>Date:</b> 23 Jan 2002</p>
|
||||
<a name="355"></a><h3><a name="355">355. Operational semantics for a.back()</a></h3><p><b>Section:</b> 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Yaroslav Mironov <b>Date:</b> 23 Jan 2002</p>
|
||||
|
||||
<p>Table 68 "Optional Sequence Operations" in 23.1.1/12
|
||||
specifies operational semantics for "a.back()" as
|
||||
@ -11067,8 +11149,8 @@ LWG would like a new issue opened.]</i></p>
|
||||
"*tmp" to "return *tmp;"]</i></p>
|
||||
|
||||
<hr>
|
||||
<a name="358"><h3>358. interpreting <tt>thousands_sep</tt> after a <tt>decimal_point</tt>
|
||||
</h3></a><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 12 Mar 2002</p>
|
||||
<a name="358"></a><h3><a name="358">358. interpreting <tt>thousands_sep</tt> after a <tt>decimal_point</tt>
|
||||
</a></h3><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 12 Mar 2002</p>
|
||||
<p>
|
||||
I don't think <tt>thousands_sep</tt> is being treated correctly after
|
||||
decimal_point has been seen. Since grouping applies only to the
|
||||
@ -11350,7 +11432,7 @@ with the following signature:</p>
|
||||
<p><b>Rationale:</b></p>
|
||||
<p>Fixes an obvious typo.</p>
|
||||
<hr>
|
||||
<a name="373"><h3>373. Are basic_istream and basic_ostream to use (exceptions()&badbit) != 0 ?</h3></a><p><b>Section:</b> 27.6.1.2.1 <a href="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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Keith Baker <b>Date:</b> 23 Jul 2002</p>
|
||||
<a name="373"></a><h3><a name="373">373. Are basic_istream and basic_ostream to use (exceptions()&badbit) != 0 ?</a></h3><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Keith Baker <b>Date:</b> 23 Jul 2002</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>
|
||||
@ -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>Fixes an obvious typo.</p>
|
||||
<hr>
|
||||
<a name="375"><h3>375. basic_ios should be ios_base in 27.7.1.3</h3></a><p><b>Section:</b> 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 14 Aug 2002</p>
|
||||
<a name="375"></a><h3><a name="375">375. basic_ios should be ios_base in 27.7.1.3</a></h3><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 14 Aug 2002</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
|
||||
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
|
||||
elements was needed to terminate a sequence given the value of state."
|
||||
</p>
|
||||
<hr>
|
||||
<a name="381"><h3>381. detection of invalid mbstate_t in codecvt</h3></a><p><b>Section:</b> 22.2.1.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.virtuals"> [lib.locale.codecvt.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 6 Sep 2002</p>
|
||||
<a name="381"></a><h3><a name="381">381. detection of invalid mbstate_t in codecvt</a></h3><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 6 Sep 2002</p>
|
||||
<p>
|
||||
All but one codecvt member functions that take a state_type argument
|
||||
list as one of their preconditions that the state_type argument have
|
||||
@ -12023,7 +12105,7 @@ flags.]</i></p>
|
||||
of the three fstream class template instead.]</i></p>
|
||||
|
||||
<hr>
|
||||
<a name="410"></a><h3><a name="410">410. Missing semantics for stack and queue comparison operators</a></h3><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Hans Bos <b>Date:</b> 7 Jun 2003</p>
|
||||
<a name="410"><h3>410. Missing semantics for stack and queue comparison operators</h3></a><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Hans Bos <b>Date:</b> 7 Jun 2003</p>
|
||||
<p>
|
||||
Sections 23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.queue"> [lib.queue]</a> and 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a> list
|
||||
comparison operators (==, !=, <, <=, >, =>) for queue and
|
||||
@ -12108,7 +12190,7 @@ set_intersection(), not union() and intersection().
|
||||
<p><b>Proposed resolution:</b></p>
|
||||
<p>Change that sentence to use the correct names.</p>
|
||||
<hr>
|
||||
<a name="412"></a><h3><a name="412">412. Typo in 27.4.4.3</a></h3><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 10 Jul 2003</p>
|
||||
<a name="412"><h3>412. Typo in 27.4.4.3</h3></a><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 10 Jul 2003</p>
|
||||
<p>
|
||||
The Effects clause in 27.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostate.flags"> [lib.iostate.flags]</a> paragraph 5 says that the
|
||||
function only throws if the respective bits are already set prior to
|
||||
@ -12774,7 +12856,7 @@ template parameter.</p>
|
||||
text.]</i></p>
|
||||
|
||||
<hr>
|
||||
<a name="438"></a><h3><a name="438">438. Ambiguity in the "do the right thing" clause</a></h3><p><b>Section:</b> 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 20 Oct 2003</p>
|
||||
<a name="438"><h3>438. Ambiguity in the "do the right thing" clause</h3></a><p><b>Section:</b> 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 20 Oct 2003</p>
|
||||
|
||||
<p>Section 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>, paragraphs 9-11, fixed up the problem
|
||||
noticed with statements like:</p>
|
||||
@ -13476,6 +13558,294 @@ that it is intended to be callable with one argument.
|
||||
void open(const char*s,
|
||||
ios_base::openmode mode = ios_base::in|ios_base::out);
|
||||
<hr>
|
||||
<a name="461"><h3>461. time_get hard or impossible to implement</h3></a><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 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& str,
|
||||
ios_base::iostate& 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<>::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& str,
|
||||
ios_base::iostate& 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<>::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& str,
|
||||
ios_base::iostate& 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<>::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. Suggestion for new member functions in standard containers</h3></a><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Thorsten Ottosen <b>Date:</b> 12 May 2004</p>
|
||||
|
||||
<p>To add slightly more convenience to vector<T> and map<Key,T> we should consider to add</p>
|
||||
<ol>
|
||||
<li> add vector<T>::data() member (const and non-const version)
|
||||
semantics: if( empty() ) return 0; else return buffer_;</li>
|
||||
<li> add map<Key,T>::at( const Key& 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<T,sz> 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() == &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& at(const key_type& x);
|
||||
const T& at(const key_type& 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& at(const key_type& x);
|
||||
const T& at(const key_type& 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. Contents of <ciso646></h3></a><p><b>Section:</b> 17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 3 Jun 2004</p>
|
||||
<p>C header <iso646.h> 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 <cname> C++ header contents are the same
|
||||
as the C header <name.h>. In particular, table 12 lists
|
||||
<ciso646> as a C++ header.</p>
|
||||
|
||||
<p>I don't find any other mention of <ciso646>, or any mention of
|
||||
<iso646.h>, in clauses 17 thorough 27. That implies that the
|
||||
contents of <ciso646> are the same as C header <iso646.h>.</p>
|
||||
|
||||
<p>Annex C (informative, not normative) in [diff.header.iso646.h] C.2.2.2
|
||||
"Header <iso646.h>" says that the alternative tokens are not
|
||||
defined as macros in <ciso646>, but does not mention the contents
|
||||
of <iso646.h>.</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 <iso646.h>
|
||||
or <ciso646> has no effect. </p>
|
||||
</blockquote>
|
||||
|
||||
<p><i>[post-Redmond: Steve provided wording.]</i></p>
|
||||
|
||||
<hr>
|
||||
<a name="467"><h3>467. char_traits::lt(), compare(), and memcmp()</h3></a><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 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<char>::lt()
|
||||
to yield the same result as operator<(char, char).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Most, if not all, implementations of char_traits<char>::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 < 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 < 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. unexpected consequences of ios_base::operator void*()</h3></a><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 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 <cassert>
|
||||
#include <iostream>
|
||||
|
||||
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<charT, traits>::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. vector<bool> ill-formed relational operators</h3></a><p><b>Section:</b> 23.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.bool"> [lib.vector.bool]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 28 Jun 2004</p>
|
||||
|
||||
<p>
|
||||
@ -13491,5 +13861,30 @@ in c++std-lib-13647).
|
||||
Remove all overloads of overloads of relational operators for
|
||||
vector<bool> from [lib.vector.bool].
|
||||
</p>
|
||||
<hr>
|
||||
<a name="474"><h3>474. confusing Footnote 297</h3></a><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 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<char>), 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. Illegal use of "T" in vector<bool></h3></a><p><b>Section:</b> 23.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.bool"> [lib.vector.bool]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> richard@ex-parrot.com <b>Date:</b> 10 Feb 2005</p>
|
||||
<p>
|
||||
In the synopsis of the std::vector<bool> 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& 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>
|
||||
</body></html>
|
||||
Loading…
Reference in New Issue
Block a user