<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>
<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>
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>.
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>
<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.
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>.
<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
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>
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
saying that user code operating on a range may not invalidate
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>
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
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
seem sufficient for C++0x. Bill supports general N-to-M conversions;
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>
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>
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
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>
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>
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>
+<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>
-17.3.1.1 Summary</p>
+Motivation:
+</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.
+This requirement seems obvious to me, it is the essence of code modularity.
+I have complained to Mr. Plauger that the Dinkumware library does not
+observe this principle but he objected that this behaviour is not covered in
+the standard.
</p>
+<p><b>Proposed resolution:</b></p>
<p>
-2 Paragraphs labelled "Note(s):" or "Example(s):" are informative,
-other paragraphs are normative.
+Append the following point to 22.1.1.1.1:
</p>
-</blockquote>
-<p>So this means that a "Notes" paragraph wouldn't be normative. </p>
-
-<blockquote>
<p>
-25.3.1.2 stable_sort
+6. The implementation of a facet of Table 52 parametrized with an
+InputIterator/OutputIterator should use that iterator only as character
+source/sink respectively.
+For a *_get facet, it means that the value received depends only on the
+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>
-<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>
-<p>
-Motivation:
-</p>
-
-<p>
-This requirement seems obvious to me, it is the essence of code modularity.
-I have complained to Mr. Plauger that the Dinkumware library does not
-observe this principle but he objected that this behaviour is not covered in
-the standard.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Append the following point to 22.1.1.1.1:
-</p>
-
-<p>
-6. The implementation of a facet of Table 52 parametrized with an
-InputIterator/OutputIterator should use that iterator only as character
-source/sink respectively.
-For a *_get facet, it means that the value received depends only on the
-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
<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 ..."
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
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
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
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
<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>
</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>
<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
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:
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>
</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
<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
<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
<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>
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>
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>
</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
</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
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
</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>
</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
<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>
<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">
-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]
<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:
<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
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
</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>
</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
<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>
<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>
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>.
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>
<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.
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>.
<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
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.
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>
<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
<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
<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><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.
<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>,
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;
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>,
<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>
projects / gcc.git / commitdiff