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
This commit is contained in:
Paolo Carlini
Paolo Carlini
parent
1464eeb8be
commit
db03587b6c
|
|
@ -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
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
|
|
@ -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.
|
||||
|
|
@ -8936,6 +9008,54 @@ the corresponding member objects of <tt>rhs</tt>, except that...
|
|||
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>
|
||||
|
|
@ -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
|
||||
|
|
@ -11413,6 +11581,102 @@ state exposed by the public interface is unchanged.</p>
|
|||
<p>Note that implementers can make this change in a binary compatible
|
||||
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
|
||||
|
|
@ -11444,6 +11708,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>
|
||||
|
||||
|
|
@ -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>
|
||||
|
|
|
|||
Loading…
Reference in New Issue