diff options
| author | Paolo Carlini <pcarlini@suse.de> | 2006-04-23 11:44:40 +0000 |
|---|---|---|
| committer | Paolo Carlini <paolo@gcc.gnu.org> | 2006-04-23 11:44:40 +0000 |
| commit | db03587b6c2a9b2f3b8c5c9da7e40000f752c621 (patch) | |
| tree | b338f6ea489444e20c8052defb76f96111ca1de6 /libstdc++-v3 | |
| parent | 1464eeb8be87335d2ed335437d029fa6d436b997 (diff) | |
| download | gcc-db03587b6c2a9b2f3b8c5c9da7e40000f752c621.zip gcc-db03587b6c2a9b2f3b8c5c9da7e40000f752c621.tar.gz gcc-db03587b6c2a9b2f3b8c5c9da7e40000f752c621.tar.bz2 | |
lwg-active.html, [...]: Import Revision 42.
2006-04-23 Paolo Carlini <pcarlini@suse.de>
* docs/html/ext/lwg-active.html, lwg-defects.html: Import Revision 42.
From-SVN: r113193
Diffstat (limited to 'libstdc++-v3')
| -rw-r--r-- | libstdc++-v3/ChangeLog | 4 | ||||
| -rw-r--r-- | libstdc++-v3/docs/html/ext/lwg-active.html | 1610 | ||||
| -rw-r--r-- | libstdc++-v3/docs/html/ext/lwg-defects.html | 846 |
3 files changed, 1282 insertions, 1178 deletions
diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog index 08e6c3b..a9ed643 100644 --- a/libstdc++-v3/ChangeLog +++ b/libstdc++-v3/ChangeLog @@ -1,3 +1,7 @@ +2006-04-23 Paolo Carlini <pcarlini@suse.de> + + * docs/html/ext/lwg-active.html, lwg-defects.html: Import Revision 42. + 2006-04-19 Paolo Carlini <pcarlini@suse.de> PR libstdc++/26424 diff --git a/libstdc++-v3/docs/html/ext/lwg-active.html b/libstdc++-v3/docs/html/ext/lwg-active.html index bd2346f..3e279f4 100644 --- a/libstdc++-v3/docs/html/ext/lwg-active.html +++ b/libstdc++-v3/docs/html/ext/lwg-active.html @@ -8,11 +8,11 @@ del {background-color:#FFFFA0}</style></head> <table> <tbody><tr> <td align="left">Doc. no.</td> -<td align="left">N1949=06-0019</td> +<td align="left">N2000=06-0070</td> </tr> <tr> <td align="left">Date:</td> -<td align="left">2006-02-24</td> +<td align="left">2006-04-21</td> </tr> <tr> <td align="left">Project:</td> @@ -23,7 +23,7 @@ del {background-color:#FFFFA0}</style></head> <td align="left">Howard Hinnant <howard.hinnant@gmail.com></td> </tr> </tbody></table> -<h1>C++ Standard Library Active Issues List (Revision R41)</h1> +<h1>C++ Standard Library Active Issues List (Revision R42)</h1> <p>Reference ISO/IEC IS 14882:1998(E)</p> <p>Also see:</p> <ul> @@ -91,6 +91,15 @@ del {background-color:#FFFFA0}</style></head> directory as the issues list files. </p> <h2>Revision History</h2> <ul> +<li>R42: +2006-04-21 post-Berlin mailing. +Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#572">572</a>. +Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#501">501</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#517">517</a> to NAD. +Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#548">548</a> to Open. +Moved issue <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#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#549">549</a> to Ready. +Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> to WP. +Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#534">534</a> to Review. +</li> <li>R41: 2006-02-24 pre-Berlin mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#536">536</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#566">566</a>. @@ -105,9 +114,9 @@ Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active 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 issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a> from New to Open. +Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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> @@ -142,7 +151,7 @@ new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html# <li>R31: 2004-07 mid-term mailing: reflects new proposed resolutions and new issues received after the post-Sydney mailing. Added -new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#478">478</a>. +new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>. </li> <li>R30: Post-Sydney mailing: reflects decisions made at the Sydney meeting. @@ -179,7 +188,7 @@ Pre-Santa Cruz mailing. Added new issues <a href="http://www.open-std.org/jtc1/ Moved issues in the TC to TC status. </li> <li>R22: -Post-Curaçao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#362">362</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#366">366</a>. +Post-Curaçao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#366">366</a>. </li> <li>R21: Pre-Curaçao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#361">361</a>. @@ -377,6 +386,12 @@ format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64 <b>Proposed Resolution</b> is now available for review on an issue for which the LWG previously reached informal consensus.</p> + <p><b><a name="Tentatively Ready">Tentatively Ready</a></b> - The issue has + been reviewed online, but not in a meeting, and some support has been formed + for the proposed resolution. Tentatively Ready issues may be moved to Ready + and forwarded to full committee within the same meeting. Unlike Ready issues + they will be reviewed in subcommittee prior to forwarding to full committee.</p> + <p><b><a name="Ready">Ready</a></b> - The LWG has reached consensus that the issue is a defect in the Standard, the <b>Proposed Resolution</b> is correct, and the issue is ready to forward to the @@ -707,69 +722,6 @@ feedback from Lillehammer with more information regarding performance. ]</i></p> <hr> -<a name="247"><h3>247. <tt>vector</tt>, <tt>deque::insert</tt> complexity</h3></a><p><b>Section:</b> 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Lisa Lippincott <b>Date:</b> 06 June 2000</p> -<p>Paragraph 2 of 23.2.4.3 [lib.vector.modifiers] describes the complexity -of <tt>vector::insert</tt>:</p> - - <blockquote> - Complexity: If first and last are forward iterators, bidirectional - iterators, or random access iterators, the complexity is linear in - the number of elements in the range [first, last) plus the distance - to the end of the vector. If they are input iterators, the complexity - is proportional to the number of elements in the range [first, last) - times the distance to the end of the vector. - </blockquote> - -<p>First, this fails to address the non-iterator forms of -<tt>insert</tt>.</p> - -<p>Second, the complexity for input iterators misses an edge case -- -it requires that an arbitrary number of elements can be added at -the end of a <tt>vector</tt> in constant time.</p> - -<p>I looked to see if <tt>deque</tt> had a similar problem, and was -surprised to find that <tt>deque</tt> places no requirement on the -complexity of inserting multiple elements (23.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.modifiers"> [lib.deque.modifiers]</a>, -paragraph 3):</p> - - <blockquote> - Complexity: In the worst case, inserting a single element into a - deque takes time linear in the minimum of the distance from the - insertion point to the beginning of the deque and the distance - from the insertion point to the end of the deque. Inserting a - single element either at the beginning or end of a deque always - takes constant time and causes a single call to the copy constructor - of T. - </blockquote> -<p><b>Proposed resolution:</b></p> - -<p>Change Paragraph 2 of 23.2.4.3 [lib.vector.modifiers] to</p> - <blockquote> - Complexity: The complexity is linear in the number of elements - inserted plus the distance to the end of the vector. - </blockquote> - - <p><i>[For input iterators, one may achieve this complexity by first - inserting at the end of the <tt>vector</tt>, and then using - <tt>rotate</tt>.]</i></p> - -<p>Change 23.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.modifiers"> [lib.deque.modifiers]</a>, paragraph 3, to:</p> - - <blockquote> - Complexity: The complexity is linear in the number of elements - inserted plus the shorter of the distances to the beginning and - end of the deque. Inserting a single element at either the - beginning or the end of a deque causes a single call to the copy - constructor of T. - </blockquote> - -<p><b>Rationale:</b></p> -<p>This is a real defect, and proposed resolution fixes it: some - complexities aren't specified that should be. This proposed - resolution does constrain deque implementations (it rules out the - most naive possible implementations), but the LWG doesn't see a - reason to permit that implementation.</p> -<hr> <a name="254"><h3>254. Exception types in clause 19 are constructed from <tt>std::string</tt> </h3></a><p><b>Section:</b> 19.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-diagnostics.html#lib.std.exceptions"> [lib.std.exceptions]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 01 Aug 2000</p> <p> @@ -981,7 +933,7 @@ the second line from the bottom in table 32 already implies the desired property. This issue should be considered in light of other issues related to allocator instances.]</i></p> <hr> -<a name="290"><h3>290. Requirements to for_each and its function object</h3></a><p><b>Section:</b> 25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 03 Jan 2001</p> +<a name="290"></a><h3><a name="290">290. Requirements to for_each and its function object</a></h3><p><b>Section:</b> 25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 03 Jan 2001</p> <p>The specification of the for_each algorithm does not have a "Requires" section, which means that there are no restrictions imposed on the function object whatsoever. In essence it @@ -1014,54 +966,6 @@ algorithm does not say so. iterators unless otherwise specified. Bill will provide wording.]</i></p> <hr> -<a name="294"><h3>294. User defined macros and standard headers</h3></a><p><b>Section:</b> 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> James Kanze <b>Date:</b> 11 Jan 2001</p> -<p>Paragraph 2 of 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a> reads: "A -translation unit that includes a header shall not contain any macros -that define names declared in that header." As I read this, it -would mean that the following program is legal:</p> - -<pre> #define npos 3.14 - #include <sstream> -</pre> - -<p>since npos is not defined in <sstream>. It is, however, defined -in <string>, and it is hard to imagine an implementation in -which <sstream> didn't include <string>.</p> - -<p>I think that this phrase was probably formulated before it was -decided that a standard header may freely include other standard -headers. The phrase would be perfectly appropriate for C, for -example. In light of 17.4.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.headers"> [lib.res.on.headers]</a> paragraph 1, however, -it isn't stringent enough.</p> -<p><b>Proposed resolution:</b></p> -<p>For 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a>, replace the current wording, which reads:</p> -<blockquote> - <p>Each name defined as a macro in a header is reserved to the - implementation for any use if the translation unit includes - the header.168)</p> - - <p>A translation unit that includes a header shall not contain any - macros that define names declared or defined in that header. Nor shall - such a translation unit define macros for names lexically - identical to keywords.</p> - - <p>168) It is not permissible to remove a library macro definition by - using the #undef directive.</p> -</blockquote> - -<p>with the wording:</p> - -<blockquote> - <p>A translation unit that includes a standard library header shall not - #define or #undef names declared in any standard library header.</p> - - <p>A translation unit shall not #define or #undef names lexically - identical to keywords.</p> -</blockquote> - -<p><i>[Lillehammer: Beman provided new wording]</i></p> - -<hr> <a name="299"><h3>299. Incorrect return types for iterator dereference</h3></a><p><b>Section:</b> 24.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.bidirectional.iterators"> [lib.bidirectional.iterators]</a>, 24.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> John Potter <b>Date:</b> 22 Jan 2001</p> <p> In section 24.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.bidirectional.iterators"> [lib.bidirectional.iterators]</a>, @@ -1165,7 +1069,7 @@ with a return type of convertible to <tt>T</tt> and operational semantics of iterator redesign]</i></p> <hr> -<a name="309"></a><h3><a name="309">309. Does sentry catch exceptions?</a></h3><p><b>Section:</b> 27.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.format"> [lib.iostream.format]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 19 Mar 2001</p> +<a name="309"><h3>309. Does sentry catch exceptions?</h3></a><p><b>Section:</b> 27.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.format"> [lib.iostream.format]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 19 Mar 2001</p> <p> The descriptions of the constructors of basic_istream<>::sentry (27.6.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a>) and basic_ostream<>::sentry @@ -1507,262 +1411,6 @@ In case of failure, the function calls <tt>setstate(failbit)</tt> or <tt>badbit</tt> is set, so using <tt>!fail()</tt>, rather than <tt>good()</tt>, satisfies this goal.</p> <hr> -<a name="362"><h3>362. bind1st/bind2nd type safety</h3></a><p><b>Section:</b> 20.3.6.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.bind.1st"> [lib.bind.1st]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Andrew Demkin <b>Date:</b> 26 Apr 2002</p> -<p> -The definition of bind1st() (20.3.6.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.bind.1st"> [lib.bind.1st]</a>) can result in -the construction of an unsafe binding between incompatible pointer -types. For example, given a function whose first parameter type is -'pointer to T', it's possible without error to bind an argument of -type 'pointer to U' when U does not derive from T: -</p> -<pre> foo(T*, int); - - struct T {}; - struct U {}; - - U u; - - int* p; - int* q; - - for_each(p, q, bind1st(ptr_fun(foo), &u)); // unsafe binding -</pre> - -<p> -The definition of bind1st() includes a functional-style conversion to -map its argument to the expected argument type of the bound function -(see below): -</p> -<pre> typename Operation::first_argument_type(x) -</pre> - -<p> -A functional-style conversion (5.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/expr.html#expr.type.conv"> [expr.type.conv]</a>) is defined to be -semantically equivalent to an explicit cast expression (5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/expr.html#expr.cast"> [expr.cast]</a>), which may (according to 5.4, paragraph 5) be interpreted -as a reinterpret_cast, thus masking the error. -</p> - -<p>The problem and proposed change also apply to 20.3.6.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.bind.2nd"> [lib.bind.2nd]</a>.</p> -<p><b>Proposed resolution:</b></p> -<p>Add this sentence to the end of 20.3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.binders"> [lib.binders]</a>/1: - "Binders <tt>bind1st</tt> and <tt>bind2nd</tt> are deprecated in - favor of <tt>std::tr1::bind</tt>."</p> - -<p>(Notes to editor: (1) when and if tr1::bind is incorporated into - the standard, "std::tr1::bind" should be changed to "std::bind". (2) - 20.3.6 should probably be moved to Annex D.</p> -<p><b>Rationale:</b></p> -<p>There is no point in fixing bind1st and bind2nd. tr1::bind is a - superior solution. It solves this problem and others.</p> -<hr> -<a name="369"><h3>369. io stream objects and static ctors</h3></a><p><b>Section:</b> 27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Ruslan Abdikeev <b>Date:</b> 8 Jul 2002</p> -<p> -Is it safe to use standard iostream objects from constructors of -static objects? Are standard iostream objects constructed and are -their associations established at that time? -</p> - -<p>Surpisingly enough, Standard does NOT require that.</p> - -<p> -27.3/2 [lib.iostream.objects] guarantees that standard iostream -objects are constructed and their associations are established before -the body of main() begins execution. It also refers to ios_base::Init -class as the panacea for constructors of static objects. -</p> - -<p> -However, there's nothing in 27.3 [lib.iostream.objects], -in 27.4.2 [lib.ios.base], and in 27.4.2.1.6 [lib.ios::Init], -that would require implementations to allow access to standard -iostream objects from constructors of static objects. -</p> - -<p>Details:</p> - -<p>Core text refers to some magic object ios_base::Init, which will -be discussed below:</p> - -<blockquote> - "The [standard iostream] objects are constructed, and their - associations are established at some time prior to or during - first time an object of class basic_ios<charT,traits>::Init - is constructed, and in any case before the body of main - begins execution." (27.3/2 [lib.iostream.objects]) -</blockquote> - -<p> -The first <i>non-normative</i> footnote encourages implementations -to initialize standard iostream objects earlier than required. -</p> - -<p>However, the second <i>non-normative</i> footnote makes an explicit -and unsupported claim:</p> - -<blockquote> - "Constructors and destructors for static objects can access these - [standard iostream] objects to read input from stdin or write output - to stdout or stderr." (27.3/2 footnote 265 [lib.iostream.objects]) -</blockquote> - -<p> -The only bit of magic is related to that ios_base::Init class. AFAIK, -the rationale behind ios_base::Init was to bring an instance of this -class to each translation unit which #included <iostream> or -related header. Such an inclusion would support the claim of footnote -quoted above, because in order to use some standard iostream object it -is necessary to #include <iostream>. -</p> - -<p> -However, while Standard explicitly describes ios_base::Init as -an appropriate class for doing the trick, I failed to found a -mention of an _instance_ of ios_base::Init in Standard. -</p> -<p><b>Proposed resolution:</b></p> - -<p>Add to 27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>, p2, immediately before the last sentence -of the paragraph, the following two sentences:</p> - -<blockquote> -If a translation unit includes <iostream>, or explicitly -constructs an ios_base::Init object, these stream objects shall -be constructed before dynamic initialization of non-local -objects defined later in that translation unit, and these stream -objects shall be destroyed after the destruction of dynamically -initialized non-local objects defined later in that translation unit. -</blockquote> - -<p><i>[Lillehammer: Matt provided wording.]</i></p> -<p><i>[Mont Tremblant: Matt provided revised wording.]</i></p> -<p><b>Rationale:</b></p> -<p> -The original proposed resolution unconditionally required -implementations to define an ios_base::Init object of some -implementation-defined name in the header <iostream>. That's an -overspecification. First, defining the object may be unnecessary -and even detrimental to performance if an implementation can -guarantee that the 8 standard iostream objects will be initialized -before any other user-defined object in a program. Second, there -is no need to require implementations to document the name of the -object.</p> - -<p> -The new proposed resolution gives users guidance on what they need to -do to ensure that stream objects are constructed during startup.</p> -<hr> -<a name="371"><h3>371. Stability of multiset and multimap member functions</h3></a><p><b>Section:</b> 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Frank Compagner <b>Date:</b> 20 Jul 2002</p> -<p> -The requirements for multiset and multimap containers (23.1 -[lib.containers.requirements], 23.1.2 [lib.associative.reqmnts], -23.3.2 [lib.multimap] and 23.3.4 [lib.multiset]) make no mention of -the stability of the required (mutating) member functions. It appears -the standard allows these functions to reorder equivalent elements of -the container at will, yet the pervasive red-black tree implementation -appears to provide stable behaviour. -</p> - -<p>This is of most concern when considering the behaviour of erase(). -A stability requirement would guarantee the correct working of the -following 'idiom' that removes elements based on a certain predicate -function. -</p> - -<pre> multimap<int, int> m; - multimap<int, int>::iterator i = m.begin(); - while (i != m.end()) { - if (pred(i)) - m.erase (i++); - else - ++i; - } -</pre> - -<p> -Although clause 23.1.2/8 guarantees that i remains a valid iterator -througout this loop, absence of the stability requirement could -potentially result in elements being skipped. This would make -this code incorrect, and, furthermore, means that there is no way -of erasing these elements without iterating first over the entire -container, and second over the elements to be erased. This would -be unfortunate, and have a negative impact on both performance and -code simplicity. -</p> - -<p> -If the stability requirement is intended, it should be made explicit -(probably through an extra paragraph in clause 23.1.2). -</p> -<p> -If it turns out stability cannot be guaranteed, i'd argue that a -remark or footnote is called for (also somewhere in clause 23.1.2) to -warn against relying on stable behaviour (as demonstrated by the code -above). If most implementations will display stable behaviour, any -problems emerging on an implementation without stable behaviour will -be hard to track down by users. This would also make the need for an -erase_if() member function that much greater. -</p> - -<p>This issue is somewhat related to LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>.</p> - -<p><b>Proposed resolution:</b></p> - -<p>Add the following to the end of 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> paragraph 4: -"For <tt>multiset</tt> and <tt>multimap</tt>, <tt>insert</tt>and <tt>erase</tt> - are <i>stable</i>: they preserve the relative ordering of equivalent - elements.</p> - -<p><i>[Lillehammer: Matt provided wording]</i></p> -<p><i>[Joe Gottman points out that the provided wording does not address -multimap and multiset. N1780 also addresses this issue and suggests -wording.]</i></p> - -<p><i>[Mont Tremblant: Changed set and map to multiset and multimap.]</i></p> - -<p><b>Rationale:</b></p> -<p>The LWG agrees that this guarantee is necessary for common user - idioms to work, and that all existing implementations provide this - property. Note that this resolution guarantees stability for - multimap and multiset, not for all associative containers in - general.</p> - -<hr> -<a name="376"><h3>376. basic_streambuf semantics</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#Ready">Ready</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, the implication is that -the four conditions should be mutually exclusive, but they are not. -The first two cases, as written, are subcases of the third.</p> - -<p> -As written, it is unclear what should be the result if cases 1 and 2 -are both true, but case 3 is false. -</p> - -<p><b>Proposed resolution:</b></p> - -<p>Rewrite these conditions as:</p> -<blockquote> -<p> - (which & (ios_base::in|ios_base::out)) == ios_base::in -</p> - -<p> - (which & (ios_base::in|ios_base::out)) == ios_base::out -</p> - -<p> - (which & (ios_base::in|ios_base::out)) == -(ios_base::in|ios_base::out) - and way == either ios_base::beg or ios_base::end -</p> - -<p>Otherwise</p> -</blockquote> - -<p><b>Rationale:</b></p> -<p>It's clear what we wanted to say, we just failed to say it. This - fixes it.</p> -<hr> <a name="382"><h3>382. codecvt do_in/out result</h3></a><p><b>Section:</b> 22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 30 Aug 2002</p> <p> It seems that the descriptions of codecvt do_in() and do_out() leave @@ -1875,64 +1523,6 @@ partial can only occur if (from_next != from_end)? we need to make sure Martin and Howard agree.]</i></p> <hr> -<a name="384"><h3>384. equal_range has unimplementable runtime complexity</h3></a><p><b>Section:</b> 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Hans Bos <b>Date:</b> 18 Oct 2002</p> -<p> -Section 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a> -states that at most 2 * log(last - first) + 1 -comparisons are allowed for equal_range. -</p> - -<p>It is not possible to implement equal_range with these constraints.</p> - -<p>In a range of one element as in:</p> -<pre> int x = 1; - equal_range(&x, &x + 1, 1) -</pre> - -<p>it is easy to see that at least 2 comparison operations are needed.</p> - -<p>For this case at most 2 * log(1) + 1 = 1 comparison is allowed.</p> - -<p>I have checked a few libraries and they all use the same (nonconforming) -algorithm for equal_range that has a complexity of</p> -<pre> 2* log(distance(first, last)) + 2. -</pre> -<p>I guess this is the algorithm that the standard assumes for equal_range.</p> - -<p> -It is easy to see that 2 * log(distance) + 2 comparisons are enough -since equal range can be implemented with lower_bound and upper_bound -(both log(distance) + 1). -</p> - -<p> -I think it is better to require something like 2log(distance) + O(1) (or -even logarithmic as multiset::equal_range). -Then an implementation has more room to optimize for certain cases (e.g. -have log(distance) characteristics when at most match is found in the range -but 2log(distance) + 4 for the worst case). -</p> - -<p><b>Proposed resolution:</b></p> -<p>In 25.3.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.lower.bound"> [lib.lower.bound]</a>/4, change <tt>log(last - first) + 1</tt> -to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p> - -<p>In 25.3.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.upper.bound"> [lib.upper.bound]</a>/4, change <tt>log(last - first) + 1</tt> -to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p> - -<p>In 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a>/4, change <tt>2*log(last - first) + 1</tt> -to <tt>2*log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p> - -<p><i>[Matt provided wording]</i></p> -<p><b>Rationale:</b></p> -<p>The LWG considered just saying <i>O</i>(log n) for all three, but -Ê decided that threw away too much valuable information.Ê The fact -Ê that lower_bound is twice as fast as equal_range is important. -Ê However, it's better to allow an arbitrary additive constant than to -Ê specify an exact count.Ê An exact count would have to -Ê involve <tt>floor</tt> or <tt>ceil</tt>.Ê It would be too easy to -Ê get this wrong, and don't provide any substantial value for users.</p> -<hr> <a name="385"><h3>385. Does call by value imply the CopyConstructible requirement?</h3></a><p><b>Section:</b> 17 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.library"> [lib.library]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 23 Oct 2002</p> <p> Many function templates have parameters that are passed by value; @@ -2257,7 +1847,7 @@ is <i>zero</i>. Otherwise, the element has the value 1.</p> fixed the analogous problem with the extractor in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a>.</p> <hr> -<a name="397"></a><h3><a name="397">397. ostream::sentry dtor throws exceptions</a></h3><p><b>Section:</b> 27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 5 Jan 2003</p> +<a name="397"><h3>397. ostream::sentry dtor throws exceptions</h3></a><p><b>Section:</b> 27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 5 Jan 2003</p> <p> 17.4.4.8, p3 prohibits library dtors from throwing exceptions. </p> @@ -2971,7 +2561,7 @@ library class templates. We need to consult with CWG to make sure we use the right wording.]</i></p> <hr> -<a name="423"><h3>423. effects of negative streamsize in iostreams</h3></a><p><b>Section:</b> 27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p> +<a name="423"></a><h3><a name="423">423. effects of negative streamsize in iostreams</a></h3><p><b>Section:</b> 27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p> <p> A third party test suite tries to exercise istream::ignore(N) with @@ -3916,131 +3506,6 @@ facet's virtuals may never call each other. We might want to do that in clause 27 too, for that matter. A review is necessary. Bill will provide wording.</p> <hr> -<a name="475"><h3>475. May the function object passed to for_each modify the elements of the iterated sequence?</h3></a><p><b>Section:</b> 25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Stephan T. Lavavej, Jaakko Jarvi <b>Date:</b> 9 Jul 2004</p> -<p> -It is not clear whether the function object passed to for_each is allowed to -modify the elements of the sequence being iterated over. -</p> - -<p> -for_each is classified without explanation in [lib.alg.nonmodifying], "25.1 -Non-modifying sequence operations". 'Non-modifying sequence operation' is -never defined. -</p> - -<p> -25(5) says: "If an algorithm's Effects section says that a value pointed to -by any iterator passed as an argument is modified, then that algorithm has -an additional type requirement: The type of that argument shall satisfy the -requirements of a mutable iterator (24.1)." -</p> - -<p>for_each's Effects section does not mention whether arguments can be -modified:</p> - -<blockquote> - "Effects: Applies f to the result of dereferencing every iterator in the - range [first, last), starting from first and proceeding to last - 1." -</blockquote> - -<p> -Every other algorithm in [lib.alg.nonmodifying] is "really" non-modifying in -the sense that neither the algorithms themselves nor the function objects -passed to the algorithms may modify the sequences or elements in any way. -This DR affects only for_each. -</p> - -<p> -We suspect that for_each's classification in "non-modifying sequence -operations" means that the algorithm itself does not inherently modify the -sequence or the elements in the sequence, but that the function object -passed to it may modify the elements it operates on. -</p> - -<p> -The original STL document by Stepanov and Lee explicitly prohibited the -function object from modifying its argument. -The "obvious" implementation of for_each found in several standard library -implementations, however, does not impose this restriction. -As a result, we suspect that the use of for_each with function objects that modify -their arguments is wide-spread. -If the restriction was reinstated, all such code would become non-conforming. -Further, none of the other algorithms in the Standard -could serve the purpose of for_each (transform does not guarantee the order in -which its function object is called). -</p> - -<p> -We suggest that the standard be clarified to explicitly allow the function object -passed to for_each modify its argument.</p> - -<p><b>Proposed resolution:</b></p> -<p>Add a nonnormative note to the Effects in 25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a>: If -the type of 'first' satisfies the requirements of a mutable iterator, -'f' may apply nonconstant functions through the dereferenced iterators -passed to it. -</p> - -<p><b>Rationale:</b></p> -<p>The LWG believes that nothing in the standard prohibits function - objects that modify the sequence elements. The problem is that - for_each is in a secion entitled "nonmutating algorithms", and the - title may be confusing. A nonnormative note should clarify that.</p> -<hr> -<a name="478"><h3>478. Should forward iterator requirements table have a line for r->m?</h3></a><p><b>Section:</b> 24.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.forward.iterators"> [lib.forward.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 11 Jul 2004</p> -<p> -The Forward Iterator requirements table contains the following: -</p> -<pre> expression return type operational precondition - semantics - ========== ================== =========== ========================== - a->m U& if X is mutable, (*a).m pre: (*a).m is well-defined. - otherwise const U& - - r->m U& (*r).m pre: (*r).m is well-defined. -</pre> - -<p>The second line may be unnecessary. Paragraph 11 of - [lib.iterator.requirements] says: -</p> - -<blockquote> - In the following sections, a and b denote values of type const X, n - denotes a value of the difference type Distance, u, tmp, and m - denote identifiers, r denotes a value of X&, t denotes a value of - value type T, o denotes a value of some type that is writable to - the output iterator. -</blockquote> - -<p> -Because operators can be overloaded on an iterator's const-ness, the -current requirements allow iterators to make many of the operations -specified using the identifiers a and b invalid for non-const -iterators.</p> - -<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#477">477</a></p> -<p><b>Proposed resolution:</b></p> - -<p>Remove the "r->m" line from the Forward Iterator requirements -table. Change</p> -<blockquote> - "const X" -</blockquote> - -<p> to </p> - -<blockquote> - "X or const X" -</blockquote> - -<p>in paragraph 11 of [lib.iterator.requirements].</p> - - -<p><b>Rationale:</b></p> -<p> -This is a defect because it constrains an lvalue to returning a modifiable lvalue. -</p> -<hr> <a name="479"><h3>479. Container requirements and placement new</h3></a><p><b>Section:</b> 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Herb Sutter <b>Date:</b> 1 Aug 2004</p> <p>Nothing in the standard appears to make this program ill-formed:</p> @@ -4411,118 +3876,6 @@ not quite broad enough, because there are some arithmetic expressions it doesn't cover. Bill will provide wording.]</i></p> <hr> -<a name="495"><h3>495. Clause 22 template parameter requirements</h3></a><p><b>Section:</b> 22 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.localization"> [lib.localization]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 10 Jan 2005</p> -<p>It appears that there are no requirements specified for many of the -template parameters in clause 22. It looks like this issue has never -come up, except perhaps for Facet.</p> - -<p>Clause 22 isn't even listed in 17.3.2.1 [lib.type.descriptions], -either, which is the wording that allows requirements on template -parameters to be identified by name.</p> - -<p>So one issue is that 17.3.2.1 [lib.type.descriptions] Should be -changed to cover clause 22. A better change, which will cover us in -the future, would be to say that it applies to all the library -clauses. Then if a template gets added to any library clause we are -covered.</p> - -<p>charT, InputIterator, and other names with requirements defined -elsewhere are fine, assuming the 17.3.2.1 [lib.type.descriptions] fix. -But there are a few template arguments names which I don't think have -requirements given elsewhere:</p> - -<ul> -<li>internT and externT. The fix is to add wording saying that internT -and externT must meet the same requirements as template arguments -named charT.</li> - -<li>stateT. I'm not sure about this one. There already is some wording, -but it seems a bit vague.</li> - -<li>Intl. [lib.locale.moneypunct.byname] The fix for this one is to -rename "Intl" to "International". The name is important because other -text identifies the requirements for the name International but not -for Intl.</li> -</ul> -<p><b>Proposed resolution:</b></p> -<p>Change 17.3.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.type.descriptions"> [lib.type.descriptions]</a>, paragraph 1, from:</p> -<blockquote> -The Requirements subclauses may describe names that are used to -specify constraints on template arguments.153) These names are used in -clauses 20, 23, 25, and 26 to describe the types that may be supplied -as arguments by a C++ program when instantiating template components -from the library. -</blockquote> -<p>to:</p> -<blockquote> -The Requirements subclauses may describe names that are used to -specify constraints on template arguments.153) These names are used in -library clauses to describe the types that may be supplied as -arguments by a C++ program when instantiating template components from -the library. -</blockquote> - -<p>In the front matter of class 22, locales, add:</p> -<blockquote> -Template parameter types internT and externT shall meet the -requirements of charT (described in 21 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.strings"> [lib.strings]</a>). -</blockquote> -<p><b>Rationale:</b></p> -<p> - Again, a blanket clause isn't blanket enough. Also, we've got a - couple of names that we don't have blanket requirement statements - for. The only issue is what to do about stateT. This wording is - thin, but probably adequate.</p> -<hr> -<a name="497"><h3>497. meaning of numeric_limits::traps for floating point types</h3></a><p><b>Section:</b> 18.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.numeric.limits.members"> [lib.numeric.limits.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2 Mar 2005</p> - -<p>18.2.1.2, p59 says this much about the traps member of numeric_limits:</p> - -<blockquote> -<p>static const bool traps;<br> --59- true if trapping is implemented for the type.204) -<br> -Footnote 204: Required by LIA-1. -</p> -</blockquote> - -<p>It's not clear what is meant by "is implemented" here.</p> - -<p> -In the context of floating point numbers it seems reasonable to expect -to be able to use traps to determine whether a program can "safely" use -infinity(), quiet_NaN(), etc., in arithmetic expressions, that is -without causing a trap (i.e., on UNIX without having to worry about -getting a signal). When traps is true, I would expect any of the -operations in section 7 of IEEE 754 to cause a trap (and my program -to get a SIGFPE). So, for example, on Alpha, I would expect traps -to be true by default (unless I compiled my program with the -ieee -option), false by default on most other popular architectures, -including IA64, MIPS, PA-RISC, PPC, SPARC, and x86 which require -traps to be explicitly enabled by the program. -</p> - -<p> -Another possible interpretation of p59 is that traps should be true -on any implementation that supports traps regardless of whether they -are enabled by default or not. I don't think such an interpretation -makes the traps member very useful, even though that is how traps is -implemented on several platforms. It is also the only way to implement -traps on platforms that allow programs to enable and disable trapping -at runtime. -</p> -<p><b>Proposed resolution:</b></p> -<p>Change p59 to read:</p> -<blockquote>True if, at program startup, there exists a value of the type that - would cause an arithmetic operation using that value to trap.</blockquote> -<p><b>Rationale:</b></p> -<p> - Real issue, since trapping can be turned on and off. Unclear what a - static query can say about a dynamic issue. The real advice we should - give users is to use cfenv for these sorts of queries. But this new - proposed resolution is at least consistent and slightly better than - nothing.</p> -<hr> <a name="498"><h3>498. Requirements for partition() and stable_partition() too strong</h3></a><p><b>Section:</b> 25.2.12 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.partitions"> [lib.alg.partitions]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Sean Parent, Joe Gottman <b>Date:</b> 4 May 2005</p> <p> Problem: @@ -4579,117 +3932,7 @@ by next meeting. Sean provided further rationale by post-meeting mailing.]</i></p> <hr> -<a name="499"><h3>499. Std. doesn't seem to require stable_sort() to be stable!</h3></a><p><b>Section:</b> 25.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.stable.sort"> [lib.stable.sort]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Prateek Karandikar <b>Date:</b> 12 Apr 2005</p> -<blockquote> -<p> -17.3.1.1 Summary</p> - -<p> -1 The Summary provides a synopsis of the category, and introduces the -first-level subclauses. Each subclause also provides a summary, listing -the headers specified in the subclause and the library entities -provided in each header. -</p> -<p> -2 Paragraphs labelled "Note(s):" or "Example(s):" are informative, -other paragraphs are normative. -</p> -</blockquote> - -<p>So this means that a "Notes" paragraph wouldn't be normative. </p> - -<blockquote> -<p> -25.3.1.2 stable_sort -</p> -<pre>template<class RandomAccessIterator> -void stable_sort(RandomAccessIterat or first, RandomAccessIterator last); - -template<class RandomAccessIterator, class Compare> -void stable_sort(RandomAccessIterat or first, RandomAccessIterator last, Compare comp); -</pre> -<p> -1 Effects: Sorts the elements in the range [first, last). -</p> -<p> -2 Complexity: It does at most N(log N)^2 (where N == last - first) -comparisons; if enough extra memory is available, it is N log N. -</p> -<p> -3 Notes: Stable: the relative order of the equivalent elements is -preserved. -</p> -</blockquote> - -<p> -The Notes para is informative, and nowhere else is stability mentioned above. -</p> - -<p> -Also, I just searched for the word "stable" in my copy of the Standard. -and the phrase "Notes: Stable: the relative order of the elements..." -is repeated several times in the Standard library clauses for -describing various functions. How is it that stability is talked about -in the informative paragraph? Or am I missing something obvious? -</p> -<p><b>Proposed resolution:</b></p> -<p> -</p> -<hr> -<a name="501"><h3>501. Proposal: strengthen guarantees of lib.comparisons</h3></a><p><b>Section:</b> 20.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.comparisons"> [lib.comparisons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Me <anti_spam_email2003@yahoo.com> <b>Date:</b> 7 Jun 2005</p> -<blockquote> -"For templates greater, less, greater_equal, and less_equal, -the specializations for any pointer type yield a total order, even if -the built-in operators <, >, <=, >= do not." -</blockquote> - -<p> -The standard should do much better than guarantee that these provide a -total order, it should guarantee that it can be used to test if memory -overlaps, i.e. write a portable memmove. You can imagine a platform -where the built-in operators use a uint32_t comparison (this tests for -overlap on this platform) but the less<T*> functor is allowed to be -defined to use a int32_t comparison. On this platform, if you use -std::less with the intent of making a portable memmove, comparison on -an array that straddles the 0x7FFFFFFF/0x8000000 boundary can give -incorrect results. -</p> -<p><b>Proposed resolution:</b></p> -<p> -Add a footnote to 20.3.3/8 saying: -</p> - -<blockquote> -Given a p1 and p2 such that p1 points to N objects of type T and p2 -points to M objects of type T. If [p1,p1+N) does not overlap [p2,p2+M), -less returns the same value when comparing all pointers in [p1,p1+N) to -all pointers in [p2,p2+M). Otherwise, there is a value Q and a value R -such that less returns the same value when comparing all pointers in -[p1,p1+Q) to all pointers in [p2,p2+R) and an opposite value when -comparing all pointers in [p1+Q,p1+N) to all pointers in [p2+R,p2+M). -For the sake of completeness, the null pointer value (4.10) for T is -considered to be an array of 1 object that doesn't overlap with any -non-null pointer to T. less_equal, greater, greater_equal, equal_to, -and not_equal_to give the expected results based on the total ordering -semantics of less. For T of void, treat it as having similar semantics -as T of char i.e. less<cv T*>(a, b) gives the same results as less<cv -void*>(a, b) which gives the same results as less<cv char*>((cv -char*)(cv void*)a, (cv char*)(cv void*)b). -</blockquote> - -<p> -I'm also thinking there should be a footnote to 20.3.3/1 saying that if -A and B are similar types (4.4/4), comp<A>(a,b) returns the same value -as comp<B>(a,b) (where comp is less, less_equal, etc.). But this might -be problematic if there is some really funky operator overloading going -on that does different things based on cv (that should be undefined -behavior if somebody does that though). This at least should be -guaranteed for all POD types (especially pointers) that use the -built-in comparison operators. -</p> - -<hr> -<a name="502"><h3>502. Proposition: Clarification of the interaction between a facet and an iterator</h3></a><p><b>Section:</b> 22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Christopher Conrade Zseleghovski <b>Date:</b> 7 Jun 2005</p> +<a name="502"><h3>502. Proposition: Clarification of the interaction between a facet and an iterator</h3></a><p><b>Section:</b> 22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Christopher Conrade Zseleghovski <b>Date:</b> 7 Jun 2005</p> <p> Motivation: </p> @@ -4714,8 +3957,14 @@ sequence of input characters and not on how they are accessed. For a *_put facet, it means that the sequence of characters output depends only on the value to be formatted and not of how the characters are stored. </p> + +<p><i>[ +Berlin: Moved to Open, Need to clean up this area to make it clear +locales don't have to contain open ended sets of facets. Jack, Howard, +Bill. +]</i></p> <hr> -<a name="503"><h3>503. more on locales</h3></a><p><b>Section:</b> 22.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.categories"> [lib.locale.categories]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> P.J. Plauger <b>Date:</b> 20 Jun 2005</p> +<a name="503"><h3>503. more on locales</h3></a><p><b>Section:</b> 22.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.categories"> [lib.locale.categories]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> P.J. Plauger <b>Date:</b> 20 Jun 2005</p> <p> a) In 22.2.1.1 para. 2 we refer to "the instantiations required in Table 51" to refer to the facet *objects* associated with a locale. And we @@ -4810,8 +4059,11 @@ facet, but several also need to use a codecvt facet and we don't say so. <p><b>Proposed resolution:</b></p> <p> </p> +<p><i>[ +Berlin: Bill to provide wording. +]</i></p> <hr> -<a name="504"><h3>504. Integer types in pseudo-random number engine requirements</h3></a><p><b>Section:</b> TR1 5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.req"> [tr.rand.req]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> +<a name="504"><h3>504. Integer types in pseudo-random number engine requirements</h3></a><p><b>Section:</b> TR1 5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.req"> [tr.rand.req]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> <p> In [tr.rand.req], Paragraph 2 states that "... s is a value of integral type, g is an ... object returning values of unsigned integral type ..." @@ -4842,6 +4094,11 @@ Mont Tremblant: Both s and g should be unsigned long. This should refer to the constructor signatures. Jens provided wording post Mont Tremblant. ]</i></p> +<p><i>[ +Berlin: N1932 adopts the proposed resolution: see 26.3.1.3/1e and Table 3 row 2. Moved +to Ready. +]</i></p> + <p><b>Rationale:</b></p> <p> Jens: Just requiring X(unsigned long) still makes it possible @@ -4854,254 +4111,7 @@ signature. u.seed(s) is covered by its reference to X(s), same arguments. </p> <hr> -<a name="505"><h3>505. Result_type in random distribution requirements</h3></a><p><b>Section:</b> TR1 5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.req"> [tr.rand.req]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> -<p> -Table 17: Random distribution requirements -</p> -<p> -Row 1 requires that each random distribution provide a nested type "input_type"; -this type denotes the type of the values that the distribution consumes. -</p> -<p> -Inspection of all distributions in [tr.rand.dist] reveals that each distribution -provides a second typedef ("result_type") that denotes the type of the values the -distribution produces when called. -</p> -<p><b>Proposed resolution:</b></p> -<p> -It seems to me that this is also a requirement -for all distributions and should therefore be indicated as such via a new second -row to this table 17: -</p> -<table border="1" cellpadding="5"> -<tbody><tr> -<td>X::result_type</td> -<td>T</td> -<td>---</td> -<td>compile-time</td> -</tr> -</tbody></table> -<hr> -<a name="506"><h3>506. Requirements of Distribution parameter for variate_generator</h3></a><p><b>Section:</b> TR1 5.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.var"> [tr.rand.var]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> -<p> -Paragraph 3 requires that template argument U (which corresponds to template -parameter Engine) satisfy all uniform random number generator requirements. -However, there is no analogous requirement regarding the template argument -that corresponds to template parameter Distribution. We believe there should -be, and that it should require that this template argument satisfy all random -distribution requirements. -</p> -<p><b>Proposed resolution:</b></p> -<p> -Consequence 1: Remove the precondition clauses [tr.rand.var]/16 and /18. -</p> -<p> -Consequence 2: Add max() and min() functions to those distributions that -do not already have them. -</p> - -<p><i>[ -Mont Tremblant: Jens reccommends NAD, min/max not needed everywhere. -Marc supports having min and max to satisfy generic programming interface. -]</i></p> - -<hr> -<a name="507"><h3>507. Missing requirement for variate_generator::operator()</h3></a><p><b>Section:</b> TR1 5.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.var"> [tr.rand.var]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> -<p> -Paragraph 11 of [tr.rand.var] equires that the member template -</p> -<blockquote><pre>template<class T> result_type operator() (T value); -</pre></blockquote> -<p> -return -</p> -<blockquote><pre>distribution()(e, value) -</pre></blockquote> -<p> -However, not all distributions have an operator() with a corresponding signature. -</p> -<p><b>Proposed resolution:</b></p> -<p> -We therefore recommend that we insert the following precondition before paragraph 11: -</p> -<blockquote> -Precondition: <tt>distribution().operator()(e,value)</tt> is well-formed. -</blockquote> -<hr> -<a name="508"><h3>508. Bad parameters for ranlux64_base_01</h3></a><p><b>Section:</b> TR1 5.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.predef"> [tr.rand.predef]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> -<p> -The fifth of these engines with predefined parameters, ranlux64_base_01, -appears to have an unintentional error for which there is a simple correction. -The two pre-defined subtract_with_carry_01 engines are given as: -</p> -<blockquote><pre>typedef subtract_with_carry_01<float, 24, 10, 24> ranlux_base_01; -typedef subtract_with_carry_01<double, 48, 10, 24> ranlux64_base_01; -</pre></blockquote> -<p> -We demonstrate below that ranlux64_base_01 fails to meet the intent of the -random number generation proposal, but that the simple correction to -</p> -<blockquote><pre>typedef subtract_with_carry_01<double, 48, 5, 12> ranlux64_base_01; -</pre></blockquote> -<p> -does meet the intent of defining well-known good parameterizations. -</p> -<p> -The ranlux64_base_01 engine as presented fails to meet the intent for -predefined engines, stated in proposal N1398 (section E): -</p> -<blockquote><p> -In order to make good random numbers available to a large number of library -users, this proposal not only defines generic random-number engines, but also -provides a number of predefined well-known good parameterizations for those. -</p></blockquote> -<p> -The predefined ranlux_base_01 engine has been proven [1,2,3] to have a very -long period and so meets this criterion. This property makes it suitable for -use in the excellent discard_block engines defined subsequently. The proof -of long period relies on the fact (proven in [1]) that 2**(w*r) - 2**(w*s) -+ 1 is prime (w, r, and s are template parameters to subtract_with_carry_01, -as defined in [tr.rand.eng.sub1]). -</p> -<p> -The ranlux64_base_01 engine as presented in [tr.rand.predef] uses w=48, r=24, s=10. -For these numbers, the combination 2**(w*r)-2**(w*s)+1 is non-prime (though -explicit factorization would be a challenge). In consequence, while it is -certainly possible for some seeding states that this engine would have a very -long period, it is not at all Òwell-knownÓ that this is the case. The intent -in the N1398 proposal involved the base of the ranlux64 engine, which finds heavy -use in the physics community. This is isomorphic to the predefined ranlux_base_01, -but exploits the ability of double variables to hold (at least) 48 bits of mantissa, -to deliver 48 random bits at a time rather than 24. -</p> -<p><b>Proposed resolution:</b></p> -<p> -To achieve this intended behavior, the correct template parameteriztion would be: -</p> -<blockquote><pre>typedef subtract_with_carry_01<double, 48, 5, 12> ranlux64_base_01; -</pre></blockquote> -<p> -The sequence of mantissa bits delivered by this is isomorphic (treating each -double as having the bits of two floats) to that delivered by ranlux_base_01. -</p> -<p> -<b>References:</b> -</p> -<ol> -<li>F. James, Comput. Phys. Commun. 60(1990) 329</li> -<li>G. Marsaglia and A. Zaman, Ann. Appl. Prob 1(1991) 462</li> -<li>M. Luscher, Comput. Phys. Commun. 79(1994) 100-110</li> -</ol> - -<hr> -<a name="509"><h3>509. Uniform_int template parameters</h3></a><p><b>Section:</b> TR1 5.1.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.dist.iunif"> [tr.rand.dist.iunif]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> -<p> -In [tr.rand.dist.iunif] the uniform_int distribution currently has a single -template parameter, IntType, used as the input_type and as the result_type -of the distribution. We believe there is no reason to conflate these types -in this way. -</p> -<p><b>Proposed resolution:</b></p> -<p> -We recommend that there be a second template parameter to -reflect the distributionÕs input_type, and that the existing first template -parameter continue to reflect (solely) the result_type: -</p> -<blockquote><pre>template< class IntType = int, UIntType = unsigned int > -class uniform_int -{ -public: - // types - typedef UIntType input_type; - typedef IntType result_type; -</pre></blockquote> -<hr> -<a name="510"><h3>510. Input_type for bernoulli_distribution</h3></a><p><b>Section:</b> TR1 5.1.7.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.dist.bern"> [tr.rand.dist.bern]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> -<p> -In [tr.rand.dist.bern] the distribution currently requires; -</p> -<blockquote><pre>typedef int input_type; -</pre></blockquote> -<p><b>Proposed resolution:</b></p> -<p> -We believe this is an unfortunate choice, and recommend instead: -</p> -<blockquote><pre>typedef unsigned int input_type; -</pre></blockquote> -<hr> -<a name="511"><h3>511. Input_type for binomial_distribution</h3></a><p><b>Section:</b> TR1 5.1.7.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.dist.bin"> [tr.rand.dist.bin]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> -<p> -Unlike all other distributions in TR1, this binomial_distribution has an -implementation-defined input_type. We believe this is an unfortunate choice, -because it hinders users from writing portable code. It also hinders the -writing of compliance tests. We recommend instead: -</p> -<blockquote><pre>typedef RealType input_type; -</pre></blockquote> -<p> -While this choice is somewhat arbitrary (as it was for some of the other -distributions), we make this particular choice because (unlike all other -distributions) otherwise this template would not publish its RealType -argument and so users could not write generic code that accessed this -second template parameter. In this respect, the choice is consistent with -the other distributions in TR1. -</p> -<p> -We have two reasons for recommending that a real type be specified instead. -One reason is based specifically on characteristics of binomial distribution -implementations, while the other is based on mathematical characteristics of -probability distribution functions in general. -</p> -<p> -Implementations of binomial distributions commonly use Stirling approximations -for values in certain ranges. It is far more natural to use real values to -represent these approximations than it would be to use integral values to do -so. In other ranges, implementations reply on the Bernoulli distribution to -obtain values. While TR1Õs bernoulli_distribution::input_type is specified as -int, we believe this would be better specified as double. -</p> -<p> -This brings us to our main point: The notion of a random distribution rests -on the notion of a cumulative distribution function, which in turn mathematically -depends on a continuous dependent variable. Indeed, such a distribution function -would be meaningless if it depended on discrete values such as integersÑand this -remains true even if the distribution function were to take discrete steps. -</p> -<p> -Although this note is specifically about binomial_distribution::input_type, -we intend to recommend that all of the random distributionsÕ input_types be -specified as a real type (either a RealType template parameter, or double, -as appropriate). -</p> -<p> -Of the nine distributions in TR1, four already have this characteristic -(uniform_real, exponential_distribution, normal_distribution, and -gamma_distribution). We have already argued the case for the binomial the -remaining four distributions. -</p> -<p> -In the case of uniform_int, we believe that the calculations to produce an -integer result in a specified range from an integer in a different specified -range is best done using real arithmetic. This is because it involves a -product, one of whose terms is the ratio of the extents of the two ranges. -Without real arithmetic, the results become less uniform: some numbers become -more (or less) probable that they should be. This is, of course, undesireable -behavior in a uniform distribution. -</p> -<p> -Finally, we believe that in the case of the bernoulli_distribution (briefly -mentioned earlier), as well as the cases of the geometric_distribution and the -poisson_distribution, it would be far more natural to have a real input_type. -This is because the most natural computation involves the random number -delivered and the distributionÕs parameter p (in the case of bernoulli_distribution, -for example, the computation is a comparison against p), and p is already specified -in each case as having some real type. -</p> -<p><b>Proposed resolution:</b></p> -<blockquote><pre>typedef RealType input_type; -</pre></blockquote> -<hr> -<a name="512"><h3>512. Seeding subtract_with_carry_01 from a single unsigned long</h3></a><p><b>Section:</b> TR1 5.1.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.eng.sub1"> [tr.rand.eng.sub1]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> +<a name="512"><h3>512. Seeding subtract_with_carry_01 from a single unsigned long</h3></a><p><b>Section:</b> TR1 5.1.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.eng.sub1"> [tr.rand.eng.sub1]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> <p> Paragraph 8 specifies the algorithm by which a subtract_with_carry_01 engine is to be seeded given a single unsigned long. This algorithm is seriously @@ -5156,6 +4166,12 @@ else sets carry<tt>(-1) = 0</tt>.</del> Jens provided revised wording post Mont Tremblant. ]</i></p> +<p><i>[ +Berlin: N1932 adopts the originally-proposed resolution of the issue. +Jens's supplied wording is a clearer description of what is +intended. Moved to Ready. +]</i></p> + <p><b>Rationale:</b></p> <p> Jens: I'm using an explicit type here, because fixing the @@ -5163,70 +4179,7 @@ prose would probably not qualify for the (with issue <a href="http://www.open-st stricter) requirements we have for seed(Gen&). </p> <hr> -<a name="513"><h3>513. Size of state for subtract_with_carry_01</h3></a><p><b>Section:</b> TR1 5.1.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.eng.sub1"> [tr.rand.eng.sub1]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> -<p> -Paragraph 3 begins: -</p> -<blockquote> -The size of the state is r. -</blockquote> -<p> -However, this is not quite consistent with the remainder of the paragraph -which specifies a total of nr+1 items in the textual representation of -the state. We recommend the sentence be corrected to match: -</p> -<blockquote> -The size of the state is nr+1. -</blockquote> -<p> -To give meaning to the coefficient n, it may be also desirable to move -nÕs definition from later in the paragraph. Either of the following -seem reasonable formulations: -</p> -<blockquote> -With n=..., the size of the state is nr+1. -</blockquote> -<blockquote> -The size of the state is nr+1, where n=... . -</blockquote> -<p> -</p> -<p><b>Proposed resolution:</b></p> -<p><i>[ -Jens: I plead for "NAD" on the grounds that "size of state" is only -used as an argument for big-O complexity notation, thus -constant factors and additions don't count. -]</i></p> -<hr> -<a name="514"><h3>514. Size of state for subtract_with_carry</h3></a><p><b>Section:</b> TR1 5.1.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.eng.sub"> [tr.rand.eng.sub]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> -<p> -Paragraph 2 begins: -</p> -<blockquote> -The size of the state is r. -</blockquote> -<p> -However, the next sentence specifies a total of r+1 items in the textual -representation of the state, r specific xÕs as well as a specific carry. -This makes a total of r+1 items that constitute the size of the state, -rather than r. -</p> -<p><b>Proposed resolution:</b></p> -<p> -We recommend the sentence be corrected to match: -</p> -<blockquote> - The size of the state is r+1. -</blockquote> - -<p><i>[ -Jens: I plead for "NAD" on the grounds that "size of state" is only -used as an argument for big-O complexity notation, thus -constant factors and additions don't count. -]</i></p> - -<hr> -<a name="515"><h3>515. Random number engine traits</h3></a><p><b>Section:</b> TR1 5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.synopsis"> [tr.rand.synopsis]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> +<a name="515"><h3>515. Random number engine traits</h3></a><p><b>Section:</b> TR1 5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.synopsis"> [tr.rand.synopsis]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> <p> To accompany the concept of a pseudo-random number engine as defined in Table 17, we propose and recommend an adjunct template, engine_traits, to be declared in @@ -5275,8 +4228,14 @@ complete specialization of this new engine_traits template. <p> </p> + +<p><i>[ +Berlin: Walter: While useful for implementation per TR1, N1932 has no need for this +feature. +]</i></p> + <hr> -<a name="516"><h3>516. Seeding subtract_with_carry_01 using a generator</h3></a><p><b>Section:</b> TR1 5.1.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.eng.sub1"> [tr.rand.eng.sub1]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> +<a name="516"><h3>516. Seeding subtract_with_carry_01 using a generator</h3></a><p><b>Section:</b> TR1 5.1.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.eng.sub1"> [tr.rand.eng.sub1]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> <p> Paragraph 6 says: </p> @@ -5294,27 +4253,7 @@ as the context seems to require only 32-bit quantities be used here. </p> <p><b>Proposed resolution:</b></p> <p> - -</p> -<hr> -<a name="517"><h3>517. Should include name in external representation</h3></a><p><b>Section:</b> TR1 5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.req"> [tr.rand.req]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> -<p> -The last two rows of Table 16 deal with the i/o requirements of an engine, -specifying that the textual representation of an engineÕs state, -appropriately formatted, constitute the engineÕs external representation. -</p> -<p> -This seems adequate when an engineÕs type is known. However, it seems -inadequate in the context of generic code, where it becomes useful and -perhaps even necessary to determine an engineÕs type via input. -</p> -<p> -</p> -<p><b>Proposed resolution:</b></p> -<p> -We therefore recommend that, in each of these two rows of Table 16, the -text "textual representation" be expanded so as to read "engine name -followed by the textual representation." +Berlin: N1932 adopts the proposed resultion: see 26.3.3.4/7. Moved to Ready. </p> <hr> <a name="518"><h3>518. Are insert and erase stable for unordered_multiset and unordered_multimap?</h3></a><p><b>Section:</b> TR1 6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.hash"> [tr.hash]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 3 Jul 2005</p> @@ -5327,28 +4266,6 @@ The same issue applies to unordered_multiset and unordered_multimap. <p> </p> <hr> -<a name="519"><h3>519. Data() undocumented</h3></a><p><b>Section:</b> TR1 6.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.array.array"> [tr.array.array]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Pete Becker <b>Date:</b> 3 Jul 2005</p> -<p> -<tt>array<>::data()</tt> is present in the class synopsis, but not documented. -</p> -<p><b>Proposed resolution:</b></p> -<p> -Add a new section, after 6.2.2.3: -</p> -<blockquote><pre>T* data() -const T* data() const; -</pre></blockquote> -<p> -<b>Returns:</b> <tt>elems</tt>. -</p> -<p> -Change 6.2.2.4/2 to: -</p> -<blockquote> -In the case where <tt>N == 0</tt>, <tt>begin() == end()</tt>. The return value -of <tt>data()</tt> is unspecified. -</blockquote> -<hr> <a name="520"><h3>520. Result_of and pointers to data members</h3></a><p><b>Section:</b> TR1 3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.func.bind"> [tr.func.bind]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Pete Becker <b>Date:</b> 3 Jul 2005</p> <p> In the original proposal for binders, the return type of bind() when @@ -5365,7 +4282,7 @@ to member data. Pete and Peter will provide wording. ]</i></p> <hr> -<a name="521"><h3>521. Garbled requirements for argument_type in reference_wrapper</h3></a><p><b>Section:</b> TR1 2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.refwrp.refwrp"> [tr.util.refwrp.refwrp]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Pete Becker <b>Date:</b> 3 Jul 2005</p> +<a name="521"><h3>521. Garbled requirements for argument_type in reference_wrapper</h3></a><p><b>Section:</b> TR1 2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.refwrp.refwrp"> [tr.util.refwrp.refwrp]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Pete Becker <b>Date:</b> 3 Jul 2005</p> <p> 2.1.2/3, second bullet item currently says that reference_wrapper<T> is derived from unary_function<T, R> if T is: @@ -5391,11 +4308,48 @@ a pointer to a member function R T0::f(T2) cv (where cv represents the member function's cv-qualifiers); the type T1 is cv T0* </blockquote> <p><b>Proposed resolution:</b></p> + +<p> +Change bullet item 2 in 2.1.2/3: +</p> + +<blockquote> +<ul> +<li> +a pointer to member function <del>type with cv-qualifier <tt><i>cv</i></tt> and no arguments; +the type <tt>T1</tt> is <tt><i>cv</i> T*</tt> and <tt>R</tt> is the return +type of the pointer to member function</del> <ins><tt>R T0::f() <i>cv</i></tt> +(where <tt><i>cv</i></tt> represents the member function's cv-qualifiers); +the type <tt>T1</tt> is <tt><i>cv</i> T0*</tt></ins> +</li> +</ul> +</blockquote> + +<p> +Change bullet item 2 in 2.1.2/4: +</p> + +<blockquote> +<ul> +<li> +a pointer to member function <del>with cv-qualifier <tt><i>cv</i></tt> and taking one argument +of type <tt>T2</tt>; the type <tt>T1</tt> is <tt><i>cv</i> T*</tt> and +<tt>R</tt> is the return type of the pointer to member function</del> +<ins><tt>R T0::f(T2) <i>cv</i></tt> (where <tt><i>cv</i></tt> represents the member +function's cv-qualifiers); the type <tt>T1</tt> is <tt><i>cv</i> T0*</tt></ins> +</li> +</ul> +</blockquote> + <hr> -<a name="522"><h3>522. Tuple doesn't define swap</h3></a><p><b>Section:</b> TR1 6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.tuple"> [tr.tuple]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Andy Koenig <b>Date:</b> 3 Jul 2005</p> +<a name="522"><h3>522. Tuple doesn't define swap</h3></a><p><b>Section:</b> TR1 6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.tuple"> [tr.tuple]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Andy Koenig <b>Date:</b> 3 Jul 2005</p> <p> Tuple doesn't define swap(). It should. </p> +<p><i>[ +Berlin: Doug to provide wording. +]</i></p> + <p><b>Proposed resolution:</b></p> <hr> <a name="523"><h3>523. regex case-insensitive character ranges are unimplementable as specified</h3></a><p><b>Section:</b> TR1 7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.re"> [tr.re]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Eric Niebler <b>Date:</b> 1 Jul 2005</p> @@ -5568,15 +4522,19 @@ For what it's worth, John has also expressed his preference for option </p> <p><b>Proposed resolution:</b></p> <hr> -<a name="525"><h3>525. type traits definitions not clear</h3></a><p><b>Section:</b> TR1 4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.meta.unary"> [tr.meta.unary]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Robert Klarer <b>Date:</b> 11 Jul 2005</p> +<a name="525"><h3>525. type traits definitions not clear</h3></a><p><b>Section:</b> TR1 4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.meta.unary"> [tr.meta.unary]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Robert Klarer <b>Date:</b> 11 Jul 2005</p> <p> It is not completely clear how the primary type traits deal with cv-qualified types. And several of the secondary type traits seem to be lacking a definition. </p> + +<p><i>[ +Berlin: Howard to provide wording. +]</i></p> <p><b>Proposed resolution:</b></p> <hr> -<a name="526"><h3>526. Is it undefined if a function in the standard changes in parameters?</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#New">New</a> <b>Submitter:</b> Chris Jefferson <b>Date:</b> 14 Sep 2005</p> +<a name="526"><h3>526. Is it undefined if a function in the standard changes in parameters?</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#Open">Open</a> <b>Submitter:</b> Chris Jefferson <b>Date:</b> 14 Sep 2005</p> <p> Problem: There are a number of places in the C++ standard library where it is possible to write what appear to be sensible ways of calling @@ -5684,11 +4642,18 @@ Matt Austern adds that this issue also exists for the <tt>insert</tt> and <tt>erase</tt> members of the ordered and unordered associative containers. </p> +<p><i>[ +Berlin: Lots of controversey over how this should be solved. Lots of confusion +as to whether we're talking about self referencing iterators or references. +Needs a good survey as to the cases where this matters, for which +implementations, and how expensive it is to fix each case. +]</i></p> + <p><b>Proposed resolution:</b></p> <p> </p> <hr> -<a name="527"><h3>527. tr1::bind has lost its Throws clause</h3></a><p><b>Section:</b> TR1 3.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.func.bind.bind"> [tr.func.bind.bind]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Peter Dimov <b>Date:</b> 01 Oct 2005</p> +<a name="527"><h3>527. tr1::bind has lost its Throws clause</h3></a><p><b>Section:</b> TR1 3.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.func.bind.bind"> [tr.func.bind.bind]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Peter Dimov <b>Date:</b> 01 Oct 2005</p> <p> The original bind proposal gives the guarantee that tr1::bind(f, t1, ..., tN) does not throw when the copy constructors of f, t1, ..., tN @@ -5702,11 +4667,16 @@ This guarantee is not present in the final version of TR1. <p> I'm pretty certain that we never removed it on purpose. Editorial omission? :-) </p> + +<p><i>[ +Berlin: not quite editorial, needs proposed wording. +]</i></p> + <p><b>Proposed resolution:</b></p> <p> </p> <hr> -<a name="528"><h3>528. TR1: issue 6.19 vs 6.3.4.3/2 (and 6.3.4.5/2)</h3></a><p><b>Section:</b> TR1 6.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.unord.unord"> [tr.unord.unord]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Paolo Carlini <b>Date:</b> 12 Oct 2005</p> +<a name="528"><h3>528. TR1: issue 6.19 vs 6.3.4.3/2 (and 6.3.4.5/2)</h3></a><p><b>Section:</b> TR1 6.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.unord.unord"> [tr.unord.unord]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Paolo Carlini <b>Date:</b> 12 Oct 2005</p> <p> while implementing the resolution of issue 6.19 I'm noticing the following: according to 6.3.4.3/2 (and 6.3.4.5/2), for unordered_set and @@ -5738,13 +4708,32 @@ Add to 6.3.4.3p2 (and 6.3.4.5p2): <p> 2 ... The iterator and const_iterator types are both <del>const</del> <ins>constant</ins> iterator types. -It is unspecified whether they are the same type. <ins>If they are the -same type, those signatures that become otherwise indistinguishable -collapse into a single signature.</ins> +It is unspecified whether they are the same type. </p> +<p> +Add a new subsection to 17.4.4 [lib.conforming]: +</p> + +<blockquote> +<p> +An implementation shall not supply an overloaded function + signature specified in any library clause if such a signature + would be inherently ambiguous during overload resolution + due to two library types referring to the same type. +</p> +<p> + [Note: For example, this occurs when a container's iterator + and const_iterator types are the same. -- end note] +</p> +</blockquote> + +<p><i>[ +Post-Berlin: Beman supplied wording. +]</i></p> + <hr> -<a name="529"><h3>529. The standard encourages redundant and confusing preconditions</h3></a><p><b>Section:</b> 17.4.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.required"> [lib.res.on.required]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> David Abrahams <b>Date:</b> 25 Oct 2005</p> +<a name="529"><h3>529. The standard encourages redundant and confusing preconditions</h3></a><p><b>Section:</b> 17.4.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.required"> [lib.res.on.required]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> David Abrahams <b>Date:</b> 25 Oct 2005</p> <p> 17.4.3.8/1 says: </p> @@ -5802,8 +4791,13 @@ an exception when the precondition is violated</del>. 2. Go through and remove redundant Requires: clauses. Specifics to be provided by Dave A. </p> + +<p><i>[ +Berlin: The LWG requests a detailed survey of part 2 of the proposed resolution. +]</i></p> + <hr> -<a name="530"><h3>530. Must elements of a string be contiguous?</h3></a><p><b>Section:</b> 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 15 Nov 2005</p> +<a name="530"><h3>530. Must elements of a string be contiguous?</h3></a><p><b>Section:</b> 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 15 Nov 2005</p> <p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#69">69</a>, which was incorporated into C++03, mandated that the elements of a vector must be stored in contiguous memory. Should the same also apply to <tt>basic_string</tt>?</p> @@ -5821,7 +4815,7 @@ an exception when the precondition is violated</del>. it. </p> <p><b>Proposed resolution:</b></p> -<p>Add the following text to the end of 23.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative"> [lib.associative]</a>, +<p>Add the following text to the end of 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>, paragraph 2. </p> <blockquote> @@ -5833,7 +4827,7 @@ paragraph 2. </p> </p> </blockquote> <hr> -<a name="531"><h3>531. array forms of unformatted input functions</h3></a><p><b>Section:</b> 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 23 Nov 2005</p> +<a name="531"><h3>531. array forms of unformatted input functions</h3></a><p><b>Section:</b> 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 23 Nov 2005</p> <p> The array forms of unformatted input functions don't seem to have well-defined semantics for zero-element arrays in a couple of cases. The affected ones @@ -5885,7 +4879,7 @@ In any case, provided <tt>(n > 0)</tt> is true, it then stores a null charact </blockquote> <p></p> <hr> -<a name="532"><h3>532. Tuple comparison</h3></a><p><b>Section:</b> TR1 6.1.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.tuple.rel"> [tr.tuple.rel]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> David Abrahams <b>Date:</b> 29 Nov 2005</p> +<a name="532"><h3>532. Tuple comparison</h3></a><p><b>Section:</b> TR1 6.1.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.tuple.rel"> [tr.tuple.rel]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> David Abrahams <b>Date:</b> 29 Nov 2005</p> <p> Where possible, tuple comparison operators <,<=,=>, and > ought to be defined in terms of std::less rather than operator<, in order to @@ -5934,8 +4928,14 @@ to: otherwise, returns (bool)(x < y) </p> </blockquote> + +<p><i>[ +Berlin: This issue is much bigger than just tuple (pair, containers, +algorithms). Dietmar will survey and work up proposed wording. +]</i></p> + <hr> -<a name="534"><h3>534. Missing basic_string members</h3></a><p><b>Section:</b> 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 16 Nov 2005</p> +<a name="534"><h3>534. Missing basic_string members</h3></a><p><b>Section:</b> 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Alisdair Meredith <b>Date:</b> 16 Nov 2005</p> <p> OK, we all know std::basic_string is bloated and already has way too many members. However, I propose it is missing 3 useful members that @@ -5983,9 +4983,80 @@ added to vector, or at() member added to the maps. </p> <p><b>Proposed resolution:</b></p> <p> +Add the following members to definition of class template basic_string, 21.3p7 +</p> +<blockquote><pre>void pop_back () + +const charT & front() const +charT & front() + +const charT & back() const +charT & back() +</pre></blockquote> +<p> +Add the following paragraphs to basic_string description +</p> + +<p> +21.3.4p5 +</p> +<blockquote> +<pre>const charT & front() const +charT & front() +</pre> +<p> +<i>Precondition:</i> <tt>!empty()</tt> +</p> +<p> +<i>Effects:</i> Equivalent to <tt>operator[](0)</tt>. +</p> +</blockquote> + +<p> +21.3.4p6 +</p> +<blockquote> +<pre>const charT & back() const +charT & back() +</pre> +<p> +<i>Precondition:</i> <tt>!empty()</tt> +</p> +<p> +<i>Effects:</i> Equivalent to <tt>operator[]( size() - 1)</tt>. +</p> +</blockquote> + +<p> +21.3.5.5p10 +</p> +<blockquote> +<pre>void pop_back () +</pre> +<p> +<i>Precondition:</i> <tt>!empty()</tt> +</p> +<p> +<i>Effects:</i> Equivalent to <tt>erase( size() - 1, 1 )</tt>. </p> +</blockquote> + +<p> +Update Table 71: (optional sequence operations) +Add basic_string to the list of containers for the following operations. +</p> +<blockquote><pre>a.front() +a.back() +a.push_back() +a.pop_back() +a[n] +</pre></blockquote> + +<p><i>[ +Berlin: Has support. Alisdair provided wording. +]</i></p> <hr> -<a name="535"><h3>535. std::string::swap specification poorly worded</h3></a><p><b>Section:</b> 21.3.5.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::swap"> [lib.string::swap]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 14 Dec 2005</p> +<a name="535"><h3>535. std::string::swap specification poorly worded</h3></a><p><b>Section:</b> 21.3.5.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::swap"> [lib.string::swap]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 14 Dec 2005</p> <p> std::string::swap currently says for effects and postcondition: </p> @@ -6020,7 +5091,7 @@ characters that <del>were</del> <ins>was</ins> in <tt><i>s</i></tt>, </p> </blockquote> <hr> -<a name="536"><h3>536. Container iterator constructor and explicit convertibility</h3></a><p><b>Section:</b> 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Joaquín M López Muñoz <b>Date:</b> 17 Dec 2005</p> +<a name="536"><h3>536. Container iterator constructor and explicit convertibility</h3></a><p><b>Section:</b> 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Joaquín M López Muñoz <b>Date:</b> 17 Dec 2005</p> <p> The iterator constructor X(i,j) for containers as defined in 23.1.1 and 23.2.2 does only require that i and j be input iterators but @@ -6073,8 +5144,11 @@ int main() <p><b>Proposed resolution:</b></p> <p> </p> +<p><i>[ +Berlin: Some support, not universal, for respecting the explicit qualifier. +]</i></p> <hr> -<a name="537"><h3>537. Typos in the signatures in 27.6.1.3/42-43 and 27.6.2.4</h3></a><p><b>Section:</b> 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Paolo Carlini <b>Date:</b> 12 Feb 2006</p> +<a name="537"><h3>537. Typos in the signatures in 27.6.1.3/42-43 and 27.6.2.4</h3></a><p><b>Section:</b> 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Paolo Carlini <b>Date:</b> 12 Feb 2006</p> <p> In the most recent working draft, I'm still seeing: </p> @@ -6116,7 +5190,7 @@ After 27.6.2.4p3 change: <blockquote><pre>basic_ostream<charT,traits>& seekp(off_type<del>&</del> <i>off</i>, ios_base::seekdir <i>dir</i>); </pre></blockquote> <hr> -<a name="538"><h3>538. 241 again: Does unique_copy() require CopyConstructible and Assignable?</h3></a><p><b>Section:</b> 25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 9 Feb 2006</p> +<a name="538"><h3>538. 241 again: Does unique_copy() require CopyConstructible and Assignable?</h3></a><p><b>Section:</b> 25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 9 Feb 2006</p> <p> I believe I botched the resolution of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241"> @@ -6154,15 +5228,15 @@ This latter requirement does not necessarily imply that you can: -5- <i>Requires:</i> The ranges <tt>[<i>first</i>, <i>last</i>)</tt> and <tt>[<i>result</i>, <i>result</i>+(<i>last</i>-<i>first</i>))</tt> shall not overlap. The expression <tt>*<i>result</i> = *<i>first</i></tt> -<del>shall</del> <ins>must</ins> +shall be valid. If neither <tt>InputIterator</tt> nor <tt>OutputIterator</tt> meets the requirements of forward iterator then the <del>value type</del> <ins><tt>value_type</tt></ins> of <tt>InputIterator</tt> -must be CopyConstructible (20.1.3) <ins>and CopyAssignable</ins>. +must be CopyConstructible (20.1.3) <ins>and Assignable</ins>. Otherwise CopyConstructible is not required. </blockquote> <hr> -<a name="539"><h3>539. partial_sum and adjacent_difference should mention requirements</h3></a><p><b>Section:</b> 26.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numeric.ops"> [lib.numeric.ops]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Marc Schoolderman <b>Date:</b> 6 Feb 2006</p> +<a name="539"><h3>539. partial_sum and adjacent_difference should mention requirements</h3></a><p><b>Section:</b> 26.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numeric.ops"> [lib.numeric.ops]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Marc Schoolderman <b>Date:</b> 6 Feb 2006</p> <p> There are some problems in the definition of partial_sum and adjacent_difference in 26.4 [lib.numeric.ops] @@ -6304,8 +5378,12 @@ The type of <tt>*first</tt> shall meet the requirements of <p><b>Proposed resolution:</b></p> <p> </p> +<p><i>[ +Berlin: Giving output iterator's value_types very controversial. Suggestion of +adding signatures to allow user to specify "accumulator". +]</i></p> <hr> -<a name="540"><h3>540. shared_ptr<void>::operator*()</h3></a><p><b>Section:</b> TR1 2.2.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.smartptr.shared.obs"> [tr.util.smartptr.shared.obs]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 15 Oct 2005</p> +<a name="540"><h3>540. shared_ptr<void>::operator*()</h3></a><p><b>Section:</b> TR1 2.2.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.smartptr.shared.obs"> [tr.util.smartptr.shared.obs]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 15 Oct 2005</p> <p> I'm trying to reconcile the note in tr.util.smartptr.shared.obs, p6 that talks about the operator*() member function of shared_ptr: @@ -6552,7 +5630,7 @@ want. Shouldn't we be performing a conversion to a floating-point type first? <p> </p> <hr> -<a name="548"><h3>548. May random_device block?</h3></a><p><b>Section:</b> TR1 5.1.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.device"> [tr.rand.device]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 10 Jan 2006</p> +<a name="548"><h3>548. May random_device block?</h3></a><p><b>Section:</b> TR1 5.1.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.device"> [tr.rand.device]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 10 Jan 2006</p> <p> Class random_device "produces non-deterministic random numbers", using some external source of entropy. In most real-world systems, the amount of available @@ -6565,11 +5643,17 @@ the entropy pool is empty, reads to /dev/random will block until additional environmental noise is gathered." Programmers need to know whether random_device is permitted to (or possibly even required to?) behave the same way. </p> + +<p><i>[ +Berlin: Walter: N1932 considers this NAD. Does the standard specify whether std::cin +may block? +]</i></p> + <p><b>Proposed resolution:</b></p> <p> </p> <hr> -<a name="549"><h3>549. Undefined variable in binomial_distribution</h3></a><p><b>Section:</b> TR1 5.1.7.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.dist.bin"> [tr.rand.dist.bin]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 10 Jan 2006</p> +<a name="549"><h3>549. Undefined variable in binomial_distribution</h3></a><p><b>Section:</b> TR1 5.1.7.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.dist.bin"> [tr.rand.dist.bin]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 10 Jan 2006</p> <p> Paragraph 1 says that "A binomial distributon random distribution produces integer values i>0 with p(i) = (n choose i) * p*i * (1-p)^(t-i), where t and @@ -6578,6 +5662,7 @@ are. What's n? </p> <p><b>Proposed resolution:</b></p> <p> +Berlin: Typo: "n" replaced by "t" in N1932: see 26.3.7.2.2/1. </p> <hr> <a name="550"><h3>550. What should the return type of pow(float,int) be?</h3></a><p><b>Section:</b> 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.c.math"> [lib.c.math]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 12 Jan 2006</p> @@ -7449,5 +6534,194 @@ location of the array. </p> </blockquote> +<hr> +<a name="567"><h3>567. streambuf inserter and extractor should be unformatted</h3></a><p><b>Section:</b> 27.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.format"> [lib.iostream.format]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 25 Feb 2006</p> + <p> + +Issue 60 explicitly made the extractor and inserter operators that +take a <tt>basic_streambuf*</tt> argument formatted input and output +functions, respectively. I believe that's wrong, certainly in the +case of the extractor, since formatted functions begin by extracting +and discarding whitespace. The extractor should not discard any +characters. + + </p> +<p><b>Proposed resolution:</b></p> + <p> + +I propose to change each operator to behave as unformatted input and +output function, respectively. The changes below are relative to the +working draft document number N1804. + + </p> + <p> + +Specifically, change 27.6.1.2.3, p14 as follows: + + </p> + + <p> + </p><blockquote> + +<i>Effects</i>: Behaves as a<ins>n un</ins>formatted input function +(as described in <del>27.6.1.2.1</del><ins>27.6.1.3, paragraph +1</ins>). + + </blockquote> + <p></p> + <p> + +And change 27.6.2.5.3, p7 as follows: + + </p> + + <p> + </p><blockquote> + +<i>Effects</i>: Behaves as a<ins>n un</ins>formatted output function +(as described in <del>27.6.2.5.1</del><ins>27.6.2.6, paragraph +1</ins>). + + </blockquote> + <p></p> +<hr> +<a name="568"><h3>568. log2 overloads missing</h3></a><p><b>Section:</b> TR1 8.16.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.c99.cmath.over"> [tr.c99.cmath.over]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Paolo Carlini <b>Date:</b> 7 Mar 2006</p> +<p> +<tt>log2</tt> is missing from the list of "additional overloads" in 8.16.4p1. +</p> +<p><b>Proposed resolution:</b></p> +<p> +Add <tt>log2</tt> to the list of functions in 8.16.4p1. +</p> +<hr> +<a name="569"><h3>569. Postcondition for basic_ios::clear(iostate) incorrectly stated</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#New">New</a> <b>Submitter:</b> Seungbeom Kim <b>Date:</b> 10 Mar 2006</p> +<p> +Section: 27.4.4.3 [lib.iostate.flags] +</p> +<p> +Paragraph 4 says: +</p> +<blockquote> +<blockquote><pre>void clear(iostate <i>state</i> = goodbit); +</pre></blockquote> +<p> +<i>Postcondition:</i> If <tt>rdbuf()!=0</tt> then <tt><i>state</i> == rdstate();</tt> +otherwise <tt>rdstate()==<i>state</i>|ios_base::badbit</tt>. +</p> +</blockquote> + +<p> +The postcondition "rdstate()==state|ios_base::badbit" is parsed as +"(rdstate()==state)|ios_base::badbit", which is probably what the +committee meant. +</p> +<p><b>Proposed resolution:</b></p> +<p> +Change 27.4.4.3p4: +</p> +<blockquote> +<i>Postcondition:</i> If <tt>rdbuf()!=0</tt> then <tt><i>state</i> == rdstate();</tt> +otherwise <tt>rdstate()==<ins>(</ins><i>state</i>|ios_base::badbit</tt><ins>)</ins>. +</blockquote> +<hr> +<a name="570"><h3>570. Request adding additional explicit specializations of char_traits</h3></a><p><b>Section:</b> 21.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits"> [lib.char.traits]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Jack Reeves <b>Date:</b> 6 Apr 2006</p> +<p> +Currently, the Standard Library specifies only a declaration for template class +char_traits<> and requires the implementation provide two explicit +specializations: char_traits<char> and char_traits<wchar_t>. I feel the Standard +should require explicit specializations for all built-in character types, i.e. +char, wchar_t, unsigned char, and signed char. +</p> +<p> +I have put together a paper (N1985) that describes this in more detail and +includes all the necessary wording. +</p> +<p><b>Proposed resolution:</b></p> +<p> +</p> +<hr> +<a name="571"><h3>571. Update C90 references to C99?</h3></a><p><b>Section:</b> 1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/intro.html#intro.refs"> [intro.refs]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 8 Apr 2006</p> +<p> +1.2 Normative references [intro.refs] of the WP currently refers to ISO/IEC +9899:1990, Programming languages - C. Should that be changed to ISO/IEC +9899:1999? +</p> +<p> +What impact does this have on the library? +</p> +<p><b>Proposed resolution:</b></p> +<p> +In 1.2/1 [intro.refs] of the WP, change: +</p> +<blockquote> +<ul> +<li>ISO/IEC 9899:<del>1990</del><ins>1999 + TC1 + TC2</ins>, <i>Programming languages - C</i> +</li> +</ul> +</blockquote> + +<hr> +<a name="572"><h3>572. Oops, we gave 507 WP status</h3></a><p><b>Section:</b> TR1 5.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.var"> [tr.rand.var]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 11 Apr 2006</p> +<p> +In Berlin, as a working group, we voted in favor of N1932 which makes issue 507 moot: +variate_generator has been eliminated. Then in full committee we voted to give +this issue WP status (mistakenly). +</p> +<p><b>Proposed resolution:</b></p> +<p> +Strike the proposed resolution of issue 507. +</p> +<hr> +<a name="573"><h3>573. C++0x file positioning should handle modern file sizes</h3></a><p><b>Section:</b> 27.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos"> [lib.fpos]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Your name <b>Date:</b> 29 Feb 1900</p> +<p> +There are two deficiencies related to file sizes: +</p> +<ol> +<li>It doesn't appear that the Standard Library is specified in + a way that handles modern file sizes, which are often too + large to be represented by an unsigned long.</li> + +<li>The std::fpos class does not currently have the ability to + set/get file positions.</li> +</ol> +<p> +The Dinkumware implementation of the Standard Library as shipped with the Microsoft compiler copes with these issues by: +</p> +<ol type="A"> +<li>Defining fpos_t be long long, which is large enough to + represent any file position likely in the foreseeable future.</li> + +<li>Adding member functions to class fpos. For example, +<blockquote><pre>fpos_t seekpos() const; +</pre></blockquote> +</li> +</ol> +<p> +Because there are so many types relating to file positions and offsets (fpos_t, +fpos, pos_type, off_type, streamoff, streamsize, streampos, wstreampos, and +perhaps more), it is difficult to know if the Dinkumware extensions are +sufficient. But they seem a useful starting place for discussions, and they do +represent existing practice. +</p> + +<p><b>Proposed resolution:</b></p> +<p> +</p> +<hr> +<a name="574"><h3>574. DR 369 Contradicts Text</h3></a><p><b>Section:</b> 27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Pete Becker <b>Date:</b> 18 Apr 2006</p> +<p> +lib.iostream.objects requires that the standard stream objects are never +destroyed, and it requires that they be destroyed. +</p> +<p> +DR 369 adds words to say that we really mean for ios_base::Init objects to force +construction of standard stream objects. It ends, though, with the phrase "these +stream objects shall be destroyed after the destruction of dynamically ...". +However, the rule for destruction is stated in the standard: "The objects are +not destroyed during program execution." +</p> +<p><b>Proposed resolution:</b></p> +<p> +</p> <p>----- End of document -----</p> </body></html>
\ No newline at end of file diff --git a/libstdc++-v3/docs/html/ext/lwg-defects.html b/libstdc++-v3/docs/html/ext/lwg-defects.html index 8d91385..1907a4a 100644 --- a/libstdc++-v3/docs/html/ext/lwg-defects.html +++ b/libstdc++-v3/docs/html/ext/lwg-defects.html @@ -8,11 +8,11 @@ del {background-color:#FFFFA0}</style></head> <table> <tbody><tr> <td align="left">Doc. no.</td> -<td align="left">N1950=06-0020</td> +<td align="left">N2001=06-0071</td> </tr> <tr> <td align="left">Date:</td> -<td align="left">2006-02-24</td> +<td align="left">2006-04-21</td> </tr> <tr> <td align="left">Project:</td> @@ -23,7 +23,7 @@ del {background-color:#FFFFA0}</style></head> <td align="left">Howard Hinnant <howard.hinnant@gmail.com></td> </tr> </tbody></table> -<h1>C++ Standard Library Defect Report List (Revision R41)</h1> +<h1>C++ Standard Library Defect Report List (Revision R42)</h1> <p>Reference ISO/IEC IS 14882:1998(E)</p> <p>Also see:</p> <ul> @@ -45,6 +45,15 @@ del {background-color:#FFFFA0}</style></head> document.</p> <h2>Revision History</h2> <ul> +<li>R42: +2006-04-21 post-Berlin mailing. +Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#572">572</a>. +Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#501">501</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#517">517</a> to NAD. +Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#548">548</a> to Open. +Moved issue <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#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#549">549</a> to Ready. +Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> to WP. +Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#534">534</a> to Review. +</li> <li>R41: 2006-02-24 pre-Berlin mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#536">536</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#566">566</a>. @@ -59,9 +68,9 @@ Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active 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 issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a> from New to Open. +Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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> @@ -96,7 +105,7 @@ new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html# <li>R31: 2004-07 mid-term mailing: reflects new proposed resolutions and new issues received after the post-Sydney mailing. Added -new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#478">478</a>. +new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>. </li> <li>R30: Post-Sydney mailing: reflects decisions made at the Sydney meeting. @@ -133,7 +142,7 @@ Pre-Santa Cruz mailing. Added new issues <a href="http://www.open-std.org/jtc1/ Moved issues in the TC to TC status. </li> <li>R22: -Post-Curaçao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#362">362</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#366">366</a>. +Post-Curaçao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#366">366</a>. </li> <li>R21: Pre-Curaçao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#361">361</a>. @@ -5367,7 +5376,7 @@ not required elsewhere.</p> <p><i>[Kona: The LWG agreed there was a defect.]</i></p> <p><i>[Tokyo: The LWG crafted the proposed resolution.]</i></p> <hr> -<a name="186"><h3>186. bitset::set() second parameter should be bool</h3></a><p><b>Section:</b> 23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Darin Adler <b>Date:</b> 13 Aug 1999</p> +<a name="186"></a><h3><a name="186">186. bitset::set() second parameter should be bool</a></h3><p><b>Section:</b> 23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Darin Adler <b>Date:</b> 13 Aug 1999</p> <p>In section 23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a>, paragraph 13 defines the bitset::set operation to take a second parameter of type int. The function tests whether this value is non-zero to determine whether to @@ -7267,6 +7276,69 @@ had language that made this an unambiguous requirement; those words were moved to a place where their context made them less clear. See Jerry Schwarz's message c++std-lib-7618.</p> <hr> +<a name="247"><h3>247. <tt>vector</tt>, <tt>deque::insert</tt> complexity</h3></a><p><b>Section:</b> 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector.modifiers"> [lib.vector.modifiers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Lisa Lippincott <b>Date:</b> 06 June 2000</p> +<p>Paragraph 2 of 23.2.4.3 [lib.vector.modifiers] describes the complexity +of <tt>vector::insert</tt>:</p> + + <blockquote> + Complexity: If first and last are forward iterators, bidirectional + iterators, or random access iterators, the complexity is linear in + the number of elements in the range [first, last) plus the distance + to the end of the vector. If they are input iterators, the complexity + is proportional to the number of elements in the range [first, last) + times the distance to the end of the vector. + </blockquote> + +<p>First, this fails to address the non-iterator forms of +<tt>insert</tt>.</p> + +<p>Second, the complexity for input iterators misses an edge case -- +it requires that an arbitrary number of elements can be added at +the end of a <tt>vector</tt> in constant time.</p> + +<p>I looked to see if <tt>deque</tt> had a similar problem, and was +surprised to find that <tt>deque</tt> places no requirement on the +complexity of inserting multiple elements (23.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.modifiers"> [lib.deque.modifiers]</a>, +paragraph 3):</p> + + <blockquote> + Complexity: In the worst case, inserting a single element into a + deque takes time linear in the minimum of the distance from the + insertion point to the beginning of the deque and the distance + from the insertion point to the end of the deque. Inserting a + single element either at the beginning or end of a deque always + takes constant time and causes a single call to the copy constructor + of T. + </blockquote> +<p><b>Proposed resolution:</b></p> + +<p>Change Paragraph 2 of 23.2.4.3 [lib.vector.modifiers] to</p> + <blockquote> + Complexity: The complexity is linear in the number of elements + inserted plus the distance to the end of the vector. + </blockquote> + + <p><i>[For input iterators, one may achieve this complexity by first + inserting at the end of the <tt>vector</tt>, and then using + <tt>rotate</tt>.]</i></p> + +<p>Change 23.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.modifiers"> [lib.deque.modifiers]</a>, paragraph 3, to:</p> + + <blockquote> + Complexity: The complexity is linear in the number of elements + inserted plus the shorter of the distances to the beginning and + end of the deque. Inserting a single element at either the + beginning or the end of a deque causes a single call to the copy + constructor of T. + </blockquote> + +<p><b>Rationale:</b></p> +<p>This is a real defect, and proposed resolution fixes it: some + complexities aren't specified that should be. This proposed + resolution does constrain deque implementations (it rules out the + most naive possible implementations), but the LWG doesn't see a + reason to permit that implementation.</p> +<hr> <a name="248"><h3>248. time_get fails to set eofbit</h3></a><p><b>Section:</b> 22.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.category.time"> [lib.category.time]</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> 22 June 2000</p> <p>There is no requirement that any of time_get member functions set ios::eofbit when they reach the end iterator while parsing their input. @@ -8937,6 +9009,54 @@ assigns to the member objects of <tt>*this</tt> the corresponding member objects of <tt>rhs</tt>, except that... </blockquote> <hr> +<a name="294"><h3>294. User defined macros and standard headers</h3></a><p><b>Section:</b> 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> James Kanze <b>Date:</b> 11 Jan 2001</p> +<p>Paragraph 2 of 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a> reads: "A +translation unit that includes a header shall not contain any macros +that define names declared in that header." As I read this, it +would mean that the following program is legal:</p> + +<pre> #define npos 3.14 + #include <sstream> +</pre> + +<p>since npos is not defined in <sstream>. It is, however, defined +in <string>, and it is hard to imagine an implementation in +which <sstream> didn't include <string>.</p> + +<p>I think that this phrase was probably formulated before it was +decided that a standard header may freely include other standard +headers. The phrase would be perfectly appropriate for C, for +example. In light of 17.4.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.headers"> [lib.res.on.headers]</a> paragraph 1, however, +it isn't stringent enough.</p> +<p><b>Proposed resolution:</b></p> +<p>For 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a>, replace the current wording, which reads:</p> +<blockquote> + <p>Each name defined as a macro in a header is reserved to the + implementation for any use if the translation unit includes + the header.168)</p> + + <p>A translation unit that includes a header shall not contain any + macros that define names declared or defined in that header. Nor shall + such a translation unit define macros for names lexically + identical to keywords.</p> + + <p>168) It is not permissible to remove a library macro definition by + using the #undef directive.</p> +</blockquote> + +<p>with the wording:</p> + +<blockquote> + <p>A translation unit that includes a standard library header shall not + #define or #undef names declared in any standard library header.</p> + + <p>A translation unit shall not #define or #undef names lexically + identical to keywords.</p> +</blockquote> + +<p><i>[Lillehammer: Beman provided new wording]</i></p> + +<hr> <a name="295"><h3>295. Is abs defined in <cmath>?</h3></a><p><b>Section:</b> 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.c.math"> [lib.c.math]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Jens Maurer <b>Date:</b> 12 Jan 2001</p> <p> Table 80 lists the contents of the <cmath> header. It does not @@ -11330,6 +11450,54 @@ prevents locale from being implemented efficiently. <p>This change is reasonable becuase it clarifies the intent of this part of the standard.</p> <hr> +<a name="362"><h3>362. bind1st/bind2nd type safety</h3></a><p><b>Section:</b> 20.3.6.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.bind.1st"> [lib.bind.1st]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Andrew Demkin <b>Date:</b> 26 Apr 2002</p> +<p> +The definition of bind1st() (20.3.6.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.bind.1st"> [lib.bind.1st]</a>) can result in +the construction of an unsafe binding between incompatible pointer +types. For example, given a function whose first parameter type is +'pointer to T', it's possible without error to bind an argument of +type 'pointer to U' when U does not derive from T: +</p> +<pre> foo(T*, int); + + struct T {}; + struct U {}; + + U u; + + int* p; + int* q; + + for_each(p, q, bind1st(ptr_fun(foo), &u)); // unsafe binding +</pre> + +<p> +The definition of bind1st() includes a functional-style conversion to +map its argument to the expected argument type of the bound function +(see below): +</p> +<pre> typename Operation::first_argument_type(x) +</pre> + +<p> +A functional-style conversion (5.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/expr.html#expr.type.conv"> [expr.type.conv]</a>) is defined to be +semantically equivalent to an explicit cast expression (5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/expr.html#expr.cast"> [expr.cast]</a>), which may (according to 5.4, paragraph 5) be interpreted +as a reinterpret_cast, thus masking the error. +</p> + +<p>The problem and proposed change also apply to 20.3.6.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.bind.2nd"> [lib.bind.2nd]</a>.</p> +<p><b>Proposed resolution:</b></p> +<p>Add this sentence to the end of 20.3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.binders"> [lib.binders]</a>/1: + "Binders <tt>bind1st</tt> and <tt>bind2nd</tt> are deprecated in + favor of <tt>std::tr1::bind</tt>."</p> + +<p>(Notes to editor: (1) when and if tr1::bind is incorporated into + the standard, "std::tr1::bind" should be changed to "std::bind". (2) + 20.3.6 should probably be moved to Annex D.</p> +<p><b>Rationale:</b></p> +<p>There is no point in fixing bind1st and bind2nd. tr1::bind is a + superior solution. It solves this problem and others.</p> +<hr> <a name="363"><h3>363. Missing exception specification in 27.4.2.1.1</h3></a><p><b>Section:</b> 27.4.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Walter Brown and Marc Paterno <b>Date:</b> 20 May 2002</p> <p> The destructor of ios_base::failure should have an empty throw @@ -11414,6 +11582,102 @@ state exposed by the public interface is unchanged.</p> way by providing both overloads; this would be a conforming extension.</p> <hr> +<a name="369"><h3>369. io stream objects and static ctors</h3></a><p><b>Section:</b> 27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Ruslan Abdikeev <b>Date:</b> 8 Jul 2002</p> +<p> +Is it safe to use standard iostream objects from constructors of +static objects? Are standard iostream objects constructed and are +their associations established at that time? +</p> + +<p>Surpisingly enough, Standard does NOT require that.</p> + +<p> +27.3/2 [lib.iostream.objects] guarantees that standard iostream +objects are constructed and their associations are established before +the body of main() begins execution. It also refers to ios_base::Init +class as the panacea for constructors of static objects. +</p> + +<p> +However, there's nothing in 27.3 [lib.iostream.objects], +in 27.4.2 [lib.ios.base], and in 27.4.2.1.6 [lib.ios::Init], +that would require implementations to allow access to standard +iostream objects from constructors of static objects. +</p> + +<p>Details:</p> + +<p>Core text refers to some magic object ios_base::Init, which will +be discussed below:</p> + +<blockquote> + "The [standard iostream] objects are constructed, and their + associations are established at some time prior to or during + first time an object of class basic_ios<charT,traits>::Init + is constructed, and in any case before the body of main + begins execution." (27.3/2 [lib.iostream.objects]) +</blockquote> + +<p> +The first <i>non-normative</i> footnote encourages implementations +to initialize standard iostream objects earlier than required. +</p> + +<p>However, the second <i>non-normative</i> footnote makes an explicit +and unsupported claim:</p> + +<blockquote> + "Constructors and destructors for static objects can access these + [standard iostream] objects to read input from stdin or write output + to stdout or stderr." (27.3/2 footnote 265 [lib.iostream.objects]) +</blockquote> + +<p> +The only bit of magic is related to that ios_base::Init class. AFAIK, +the rationale behind ios_base::Init was to bring an instance of this +class to each translation unit which #included <iostream> or +related header. Such an inclusion would support the claim of footnote +quoted above, because in order to use some standard iostream object it +is necessary to #include <iostream>. +</p> + +<p> +However, while Standard explicitly describes ios_base::Init as +an appropriate class for doing the trick, I failed to found a +mention of an _instance_ of ios_base::Init in Standard. +</p> +<p><b>Proposed resolution:</b></p> + +<p>Add to 27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>, p2, immediately before the last sentence +of the paragraph, the following two sentences:</p> + +<blockquote> +If a translation unit includes <iostream>, or explicitly +constructs an ios_base::Init object, these stream objects shall +be constructed before dynamic initialization of non-local +objects defined later in that translation unit, and these stream +objects shall be destroyed after the destruction of dynamically +initialized non-local objects defined later in that translation unit. +</blockquote> + +<p><i>[Lillehammer: Matt provided wording.]</i></p> +<p><i>[Mont Tremblant: Matt provided revised wording.]</i></p> +<p><b>Rationale:</b></p> +<p> +The original proposed resolution unconditionally required +implementations to define an ios_base::Init object of some +implementation-defined name in the header <iostream>. That's an +overspecification. First, defining the object may be unnecessary +and even detrimental to performance if an implementation can +guarantee that the 8 standard iostream objects will be initialized +before any other user-defined object in a program. Second, there +is no need to require implementations to document the name of the +object.</p> + +<p> +The new proposed resolution gives users guidance on what they need to +do to ensure that stream objects are constructed during startup.</p> +<hr> <a name="370"><h3>370. Minor error in basic_istream::get</h3></a><p><b>Section:</b> 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <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> 15 Jul 2002</p> <p>Defect report for description of basic_istream::get (section 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>), paragraph 15. The description for the get function with the following signature:</p> @@ -11445,6 +11709,82 @@ with the following signature:</p> <p><b>Rationale:</b></p> <p>Fixes an obvious typo.</p> <hr> +<a name="371"><h3>371. Stability of multiset and multimap member functions</h3></a><p><b>Section:</b> 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Frank Compagner <b>Date:</b> 20 Jul 2002</p> +<p> +The requirements for multiset and multimap containers (23.1 +[lib.containers.requirements], 23.1.2 [lib.associative.reqmnts], +23.3.2 [lib.multimap] and 23.3.4 [lib.multiset]) make no mention of +the stability of the required (mutating) member functions. It appears +the standard allows these functions to reorder equivalent elements of +the container at will, yet the pervasive red-black tree implementation +appears to provide stable behaviour. +</p> + +<p>This is of most concern when considering the behaviour of erase(). +A stability requirement would guarantee the correct working of the +following 'idiom' that removes elements based on a certain predicate +function. +</p> + +<pre> multimap<int, int> m; + multimap<int, int>::iterator i = m.begin(); + while (i != m.end()) { + if (pred(i)) + m.erase (i++); + else + ++i; + } +</pre> + +<p> +Although clause 23.1.2/8 guarantees that i remains a valid iterator +througout this loop, absence of the stability requirement could +potentially result in elements being skipped. This would make +this code incorrect, and, furthermore, means that there is no way +of erasing these elements without iterating first over the entire +container, and second over the elements to be erased. This would +be unfortunate, and have a negative impact on both performance and +code simplicity. +</p> + +<p> +If the stability requirement is intended, it should be made explicit +(probably through an extra paragraph in clause 23.1.2). +</p> +<p> +If it turns out stability cannot be guaranteed, i'd argue that a +remark or footnote is called for (also somewhere in clause 23.1.2) to +warn against relying on stable behaviour (as demonstrated by the code +above). If most implementations will display stable behaviour, any +problems emerging on an implementation without stable behaviour will +be hard to track down by users. This would also make the need for an +erase_if() member function that much greater. +</p> + +<p>This issue is somewhat related to LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>.</p> + +<p><b>Proposed resolution:</b></p> + +<p>Add the following to the end of 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> paragraph 4: +"For <tt>multiset</tt> and <tt>multimap</tt>, <tt>insert</tt>and <tt>erase</tt> + are <i>stable</i>: they preserve the relative ordering of equivalent + elements.</p> + +<p><i>[Lillehammer: Matt provided wording]</i></p> +<p><i>[Joe Gottman points out that the provided wording does not address +multimap and multiset. N1780 also addresses this issue and suggests +wording.]</i></p> + +<p><i>[Mont Tremblant: Changed set and map to multiset and multimap.]</i></p> + +<p><b>Rationale:</b></p> +<p>The LWG agrees that this guarantee is necessary for common user + idioms to work, and that all existing implementations provide this + property. Note that this resolution guarantees stability for + multimap and multiset, not for all associative containers in + general.</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> <p> @@ -11476,6 +11816,42 @@ paragraph 14 to "ios_base". <p><b>Rationale:</b></p> <p>Fixes an obvious typo.</p> <hr> +<a name="376"><h3>376. basic_streambuf semantics</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> +<p> +In Section 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>, Table 90, the implication is that +the four conditions should be mutually exclusive, but they are not. +The first two cases, as written, are subcases of the third.</p> + +<p> +As written, it is unclear what should be the result if cases 1 and 2 +are both true, but case 3 is false. +</p> + +<p><b>Proposed resolution:</b></p> + +<p>Rewrite these conditions as:</p> +<blockquote> +<p> + (which & (ios_base::in|ios_base::out)) == ios_base::in +</p> + +<p> + (which & (ios_base::in|ios_base::out)) == ios_base::out +</p> + +<p> + (which & (ios_base::in|ios_base::out)) == +(ios_base::in|ios_base::out) + and way == either ios_base::beg or ios_base::end +</p> + +<p>Otherwise</p> +</blockquote> + +<p><b>Rationale:</b></p> +<p>It's clear what we wanted to say, we just failed to say it. This + fixes it.</p> +<hr> <a name="379"><h3>379. nonsensical ctype::do_widen() requirement</h3></a><p><b>Section:</b> 22.2.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.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> The last sentence in 22.2.1.1.2, p11 below doesn't seem to make sense. @@ -11651,6 +12027,64 @@ Change the guarantee to "postcondition: r is dereferenceable." <p><b>Rationale:</b></p> <p>Fixes an obvious typo</p> <hr> +<a name="384"><h3>384. equal_range has unimplementable runtime complexity</h3></a><p><b>Section:</b> 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a> <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> 18 Oct 2002</p> +<p> +Section 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a> +states that at most 2 * log(last - first) + 1 +comparisons are allowed for equal_range. +</p> + +<p>It is not possible to implement equal_range with these constraints.</p> + +<p>In a range of one element as in:</p> +<pre> int x = 1; + equal_range(&x, &x + 1, 1) +</pre> + +<p>it is easy to see that at least 2 comparison operations are needed.</p> + +<p>For this case at most 2 * log(1) + 1 = 1 comparison is allowed.</p> + +<p>I have checked a few libraries and they all use the same (nonconforming) +algorithm for equal_range that has a complexity of</p> +<pre> 2* log(distance(first, last)) + 2. +</pre> +<p>I guess this is the algorithm that the standard assumes for equal_range.</p> + +<p> +It is easy to see that 2 * log(distance) + 2 comparisons are enough +since equal range can be implemented with lower_bound and upper_bound +(both log(distance) + 1). +</p> + +<p> +I think it is better to require something like 2log(distance) + O(1) (or +even logarithmic as multiset::equal_range). +Then an implementation has more room to optimize for certain cases (e.g. +have log(distance) characteristics when at most match is found in the range +but 2log(distance) + 4 for the worst case). +</p> + +<p><b>Proposed resolution:</b></p> +<p>In 25.3.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.lower.bound"> [lib.lower.bound]</a>/4, change <tt>log(last - first) + 1</tt> +to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p> + +<p>In 25.3.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.upper.bound"> [lib.upper.bound]</a>/4, change <tt>log(last - first) + 1</tt> +to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p> + +<p>In 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a>/4, change <tt>2*log(last - first) + 1</tt> +to <tt>2*log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p> + +<p><i>[Matt provided wording]</i></p> +<p><b>Rationale:</b></p> +<p>The LWG considered just saying <i>O</i>(log n) for all three, but +Ê decided that threw away too much valuable information.Ê The fact +Ê that lower_bound is twice as fast as equal_range is important. +Ê However, it's better to allow an arbitrary additive constant than to +Ê specify an exact count.Ê An exact count would have to +Ê involve <tt>floor</tt> or <tt>ceil</tt>.Ê It would be too easy to +Ê get this wrong, and don't provide any substantial value for users.</p> +<hr> <a name="386"><h3>386. Reverse iterator's operator[] has impossible return type</h3></a><p><b>Section:</b> 24.4.1.3.11 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.opindex"> [lib.reverse.iter.opindex]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 23 Oct 2002</p> <p>In 24.4.1.3.11 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.opindex"> [lib.reverse.iter.opindex]</a>, <tt>reverse_iterator<>::operator[]</tt> is specified as having a return type of <tt>reverse_iterator::reference</tt>, @@ -13216,7 +13650,7 @@ In section 27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-ios of <tt>sentry::operator bool()</tt> to const. </p> <hr> -<a name="443"></a><h3><a name="443">443. filebuf::close() inconsistent use of EOF</a></h3><p><b>Section:</b> 27.8.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.members"> [lib.filebuf.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Vincent Leloup <b>Date:</b> 20 Nov 2003</p> +<a name="443"><h3>443. filebuf::close() inconsistent use of EOF</h3></a><p><b>Section:</b> 27.8.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.members"> [lib.filebuf.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Vincent Leloup <b>Date:</b> 20 Nov 2003</p> <p> In section 27.8.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.members"> [lib.filebuf.members]</a> par6, in effects description of basic_filebuf<charT, traits>::close(), overflow(EOF) is used twice; @@ -13888,6 +14322,194 @@ value of widen(c) is otherwise. I propose to strike the Footnote. </p> <hr> +<a name="475"><h3>475. May the function object passed to for_each modify the elements of the iterated sequence?</h3></a><p><b>Section:</b> 25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Stephan T. Lavavej, Jaakko Jarvi <b>Date:</b> 9 Jul 2004</p> +<p> +It is not clear whether the function object passed to for_each is allowed to +modify the elements of the sequence being iterated over. +</p> + +<p> +for_each is classified without explanation in [lib.alg.nonmodifying], "25.1 +Non-modifying sequence operations". 'Non-modifying sequence operation' is +never defined. +</p> + +<p> +25(5) says: "If an algorithm's Effects section says that a value pointed to +by any iterator passed as an argument is modified, then that algorithm has +an additional type requirement: The type of that argument shall satisfy the +requirements of a mutable iterator (24.1)." +</p> + +<p>for_each's Effects section does not mention whether arguments can be +modified:</p> + +<blockquote> + "Effects: Applies f to the result of dereferencing every iterator in the + range [first, last), starting from first and proceeding to last - 1." +</blockquote> + +<p> +Every other algorithm in [lib.alg.nonmodifying] is "really" non-modifying in +the sense that neither the algorithms themselves nor the function objects +passed to the algorithms may modify the sequences or elements in any way. +This DR affects only for_each. +</p> + +<p> +We suspect that for_each's classification in "non-modifying sequence +operations" means that the algorithm itself does not inherently modify the +sequence or the elements in the sequence, but that the function object +passed to it may modify the elements it operates on. +</p> + +<p> +The original STL document by Stepanov and Lee explicitly prohibited the +function object from modifying its argument. +The "obvious" implementation of for_each found in several standard library +implementations, however, does not impose this restriction. +As a result, we suspect that the use of for_each with function objects that modify +their arguments is wide-spread. +If the restriction was reinstated, all such code would become non-conforming. +Further, none of the other algorithms in the Standard +could serve the purpose of for_each (transform does not guarantee the order in +which its function object is called). +</p> + +<p> +We suggest that the standard be clarified to explicitly allow the function object +passed to for_each modify its argument.</p> + +<p><b>Proposed resolution:</b></p> +<p>Add a nonnormative note to the Effects in 25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a>: If +the type of 'first' satisfies the requirements of a mutable iterator, +'f' may apply nonconstant functions through the dereferenced iterators +passed to it. +</p> + +<p><b>Rationale:</b></p> +<p>The LWG believes that nothing in the standard prohibits function + objects that modify the sequence elements. The problem is that + for_each is in a secion entitled "nonmutating algorithms", and the + title may be confusing. A nonnormative note should clarify that.</p> +<hr> +<a name="478"><h3>478. Should forward iterator requirements table have a line for r->m?</h3></a><p><b>Section:</b> 24.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.forward.iterators"> [lib.forward.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> Dave Abrahams <b>Date:</b> 11 Jul 2004</p> +<p> +The Forward Iterator requirements table contains the following: +</p> +<pre> expression return type operational precondition + semantics + ========== ================== =========== ========================== + a->m U& if X is mutable, (*a).m pre: (*a).m is well-defined. + otherwise const U& + + r->m U& (*r).m pre: (*r).m is well-defined. +</pre> + +<p>The second line may be unnecessary. Paragraph 11 of + [lib.iterator.requirements] says: +</p> + +<blockquote> + In the following sections, a and b denote values of type const X, n + denotes a value of the difference type Distance, u, tmp, and m + denote identifiers, r denotes a value of X&, t denotes a value of + value type T, o denotes a value of some type that is writable to + the output iterator. +</blockquote> + +<p> +Because operators can be overloaded on an iterator's const-ness, the +current requirements allow iterators to make many of the operations +specified using the identifiers a and b invalid for non-const +iterators.</p> + +<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#477">477</a></p> +<p><b>Proposed resolution:</b></p> + +<p>Remove the "r->m" line from the Forward Iterator requirements +table. Change</p> +<blockquote> + "const X" +</blockquote> + +<p> to </p> + +<blockquote> + "X or const X" +</blockquote> + +<p>in paragraph 11 of [lib.iterator.requirements].</p> + + +<p><b>Rationale:</b></p> +<p> +This is a defect because it constrains an lvalue to returning a modifiable lvalue. +</p> +<hr> +<a name="495"><h3>495. Clause 22 template parameter requirements</h3></a><p><b>Section:</b> 22 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.localization"> [lib.localization]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 10 Jan 2005</p> +<p>It appears that there are no requirements specified for many of the +template parameters in clause 22. It looks like this issue has never +come up, except perhaps for Facet.</p> + +<p>Clause 22 isn't even listed in 17.3.2.1 [lib.type.descriptions], +either, which is the wording that allows requirements on template +parameters to be identified by name.</p> + +<p>So one issue is that 17.3.2.1 [lib.type.descriptions] Should be +changed to cover clause 22. A better change, which will cover us in +the future, would be to say that it applies to all the library +clauses. Then if a template gets added to any library clause we are +covered.</p> + +<p>charT, InputIterator, and other names with requirements defined +elsewhere are fine, assuming the 17.3.2.1 [lib.type.descriptions] fix. +But there are a few template arguments names which I don't think have +requirements given elsewhere:</p> + +<ul> +<li>internT and externT. The fix is to add wording saying that internT +and externT must meet the same requirements as template arguments +named charT.</li> + +<li>stateT. I'm not sure about this one. There already is some wording, +but it seems a bit vague.</li> + +<li>Intl. [lib.locale.moneypunct.byname] The fix for this one is to +rename "Intl" to "International". The name is important because other +text identifies the requirements for the name International but not +for Intl.</li> +</ul> +<p><b>Proposed resolution:</b></p> +<p>Change 17.3.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.type.descriptions"> [lib.type.descriptions]</a>, paragraph 1, from:</p> +<blockquote> +The Requirements subclauses may describe names that are used to +specify constraints on template arguments.153) These names are used in +clauses 20, 23, 25, and 26 to describe the types that may be supplied +as arguments by a C++ program when instantiating template components +from the library. +</blockquote> +<p>to:</p> +<blockquote> +The Requirements subclauses may describe names that are used to +specify constraints on template arguments.153) These names are used in +library clauses to describe the types that may be supplied as +arguments by a C++ program when instantiating template components from +the library. +</blockquote> + +<p>In the front matter of class 22, locales, add:</p> +<blockquote> +Template parameter types internT and externT shall meet the +requirements of charT (described in 21 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.strings"> [lib.strings]</a>). +</blockquote> +<p><b>Rationale:</b></p> +<p> + Again, a blanket clause isn't blanket enough. Also, we've got a + couple of names that we don't have blanket requirement statements + for. The only issue is what to do about stateT. This wording is + thin, but probably adequate.</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>, @@ -13900,6 +14522,210 @@ the non-template assign() function has the signature</p> <p><b>Proposed resolution:</b></p> <p>Replace "T" with "value_type".</p> <hr> +<a name="497"><h3>497. meaning of numeric_limits::traps for floating point types</h3></a><p><b>Section:</b> 18.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.numeric.limits.members"> [lib.numeric.limits.members]</a> <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> 2 Mar 2005</p> + +<p>18.2.1.2, p59 says this much about the traps member of numeric_limits:</p> + +<blockquote> +<p>static const bool traps;<br> +-59- true if trapping is implemented for the type.204) +<br> +Footnote 204: Required by LIA-1. +</p> +</blockquote> + +<p>It's not clear what is meant by "is implemented" here.</p> + +<p> +In the context of floating point numbers it seems reasonable to expect +to be able to use traps to determine whether a program can "safely" use +infinity(), quiet_NaN(), etc., in arithmetic expressions, that is +without causing a trap (i.e., on UNIX without having to worry about +getting a signal). When traps is true, I would expect any of the +operations in section 7 of IEEE 754 to cause a trap (and my program +to get a SIGFPE). So, for example, on Alpha, I would expect traps +to be true by default (unless I compiled my program with the -ieee +option), false by default on most other popular architectures, +including IA64, MIPS, PA-RISC, PPC, SPARC, and x86 which require +traps to be explicitly enabled by the program. +</p> + +<p> +Another possible interpretation of p59 is that traps should be true +on any implementation that supports traps regardless of whether they +are enabled by default or not. I don't think such an interpretation +makes the traps member very useful, even though that is how traps is +implemented on several platforms. It is also the only way to implement +traps on platforms that allow programs to enable and disable trapping +at runtime. +</p> +<p><b>Proposed resolution:</b></p> +<p>Change p59 to read:</p> +<blockquote>True if, at program startup, there exists a value of the type that + would cause an arithmetic operation using that value to trap.</blockquote> +<p><b>Rationale:</b></p> +<p> + Real issue, since trapping can be turned on and off. Unclear what a + static query can say about a dynamic issue. The real advice we should + give users is to use cfenv for these sorts of queries. But this new + proposed resolution is at least consistent and slightly better than + nothing.</p> +<hr> +<a name="505"><h3>505. Result_type in random distribution requirements</h3></a><p><b>Section:</b> TR1 5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.req"> [tr.rand.req]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> +<p> +Table 17: Random distribution requirements +</p> +<p> +Row 1 requires that each random distribution provide a nested type "input_type"; +this type denotes the type of the values that the distribution consumes. +</p> +<p> +Inspection of all distributions in [tr.rand.dist] reveals that each distribution +provides a second typedef ("result_type") that denotes the type of the values the +distribution produces when called. +</p> +<p><b>Proposed resolution:</b></p> +<p> +It seems to me that this is also a requirement +for all distributions and should therefore be indicated as such via a new second +row to this table 17: +</p> +<table border="1" cellpadding="5"> +<tbody><tr> +<td>X::result_type</td> +<td>T</td> +<td>---</td> +<td>compile-time</td> +</tr> +</tbody></table> + +<p><i>[ +Berlin: Voted to WP. N1932 adopts the proposed resolution: see Table 5 row 1. +]</i></p> + +<hr> +<a name="507"><h3>507. Missing requirement for variate_generator::operator()</h3></a><p><b>Section:</b> TR1 5.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.var"> [tr.rand.var]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> +<p> +Paragraph 11 of [tr.rand.var] equires that the member template +</p> +<blockquote><pre>template<class T> result_type operator() (T value); +</pre></blockquote> +<p> +return +</p> +<blockquote><pre>distribution()(e, value) +</pre></blockquote> +<p> +However, not all distributions have an operator() with a corresponding signature. +</p> + +<p><i>[ +Berlin: As a working group we voted in favor of N1932 which makes this moot: +variate_generator has been eliminated. Then in full committee we voted to give +this issue WP status (mistakenly). +]</i></p> + +<p><b>Proposed resolution:</b></p> +<p> +We therefore recommend that we insert the following precondition before paragraph 11: +</p> +<blockquote> +Precondition: <tt>distribution().operator()(e,value)</tt> is well-formed. +</blockquote> +<hr> +<a name="508"><h3>508. Bad parameters for ranlux64_base_01</h3></a><p><b>Section:</b> TR1 5.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.predef"> [tr.rand.predef]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> +<p> +The fifth of these engines with predefined parameters, ranlux64_base_01, +appears to have an unintentional error for which there is a simple correction. +The two pre-defined subtract_with_carry_01 engines are given as: +</p> +<blockquote><pre>typedef subtract_with_carry_01<float, 24, 10, 24> ranlux_base_01; +typedef subtract_with_carry_01<double, 48, 10, 24> ranlux64_base_01; +</pre></blockquote> +<p> +We demonstrate below that ranlux64_base_01 fails to meet the intent of the +random number generation proposal, but that the simple correction to +</p> +<blockquote><pre>typedef subtract_with_carry_01<double, 48, 5, 12> ranlux64_base_01; +</pre></blockquote> +<p> +does meet the intent of defining well-known good parameterizations. +</p> +<p> +The ranlux64_base_01 engine as presented fails to meet the intent for +predefined engines, stated in proposal N1398 (section E): +</p> +<blockquote><p> +In order to make good random numbers available to a large number of library +users, this proposal not only defines generic random-number engines, but also +provides a number of predefined well-known good parameterizations for those. +</p></blockquote> +<p> +The predefined ranlux_base_01 engine has been proven [1,2,3] to have a very +long period and so meets this criterion. This property makes it suitable for +use in the excellent discard_block engines defined subsequently. The proof +of long period relies on the fact (proven in [1]) that 2**(w*r) - 2**(w*s) ++ 1 is prime (w, r, and s are template parameters to subtract_with_carry_01, +as defined in [tr.rand.eng.sub1]). +</p> +<p> +The ranlux64_base_01 engine as presented in [tr.rand.predef] uses w=48, r=24, s=10. +For these numbers, the combination 2**(w*r)-2**(w*s)+1 is non-prime (though +explicit factorization would be a challenge). In consequence, while it is +certainly possible for some seeding states that this engine would have a very +long period, it is not at all Òwell-knownÓ that this is the case. The intent +in the N1398 proposal involved the base of the ranlux64 engine, which finds heavy +use in the physics community. This is isomorphic to the predefined ranlux_base_01, +but exploits the ability of double variables to hold (at least) 48 bits of mantissa, +to deliver 48 random bits at a time rather than 24. +</p> +<p><b>Proposed resolution:</b></p> +<p> +To achieve this intended behavior, the correct template parameteriztion would be: +</p> +<blockquote><pre>typedef subtract_with_carry_01<double, 48, 5, 12> ranlux64_base_01; +</pre></blockquote> +<p> +The sequence of mantissa bits delivered by this is isomorphic (treating each +double as having the bits of two floats) to that delivered by ranlux_base_01. +</p> +<p> +<b>References:</b> +</p> +<ol> +<li>F. James, Comput. Phys. Commun. 60(1990) 329</li> +<li>G. Marsaglia and A. Zaman, Ann. Appl. Prob 1(1991) 462</li> +<li>M. Luscher, Comput. Phys. Commun. 79(1994) 100-110</li> +</ol> + +<p><i>[ +Berlin: Voted to WP. N1932 adopts the proposed resolution in 26.3.5, +just above paragraph 5. +]</i></p> + +<hr> +<a name="519"><h3>519. Data() undocumented</h3></a><p><b>Section:</b> TR1 6.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.array.array"> [tr.array.array]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Pete Becker <b>Date:</b> 3 Jul 2005</p> +<p> +<tt>array<>::data()</tt> is present in the class synopsis, but not documented. +</p> +<p><b>Proposed resolution:</b></p> +<p> +Add a new section, after 6.2.2.3: +</p> +<blockquote><pre>T* data() +const T* data() const; +</pre></blockquote> +<p> +<b>Returns:</b> <tt>elems</tt>. +</p> +<p> +Change 6.2.2.4/2 to: +</p> +<blockquote> +In the case where <tt>N == 0</tt>, <tt>begin() == end()</tt>. The return value +of <tt>data()</tt> is unspecified. +</blockquote> +<hr> <a name="533"><h3>533. typo in 2.2.3.10/1</h3></a><p><b>Section:</b> TR1 2.2.3.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.smartptr.getdeleter"> [tr.util.smartptr.getdeleter]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Paolo Carlini <b>Date:</b> 9 Nov 2005</p> <p> I'm seeing something that looks like a typo. The Return of <tt>get_deleter</tt> |