diff options
Diffstat (limited to 'libstdc++-v3/docs/html/ext/lwg-defects.html')
| -rw-r--r-- | libstdc++-v3/docs/html/ext/lwg-defects.html | 451 |
1 files changed, 423 insertions, 28 deletions
diff --git a/libstdc++-v3/docs/html/ext/lwg-defects.html b/libstdc++-v3/docs/html/ext/lwg-defects.html index f7ff410c01d..380c85e70e6 100644 --- a/libstdc++-v3/docs/html/ext/lwg-defects.html +++ b/libstdc++-v3/docs/html/ext/lwg-defects.html @@ -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 @@ -8407,6 +8422,73 @@ the wording. Dave provided new wording.]</i></p> 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 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> <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>
\ No newline at end of file |