<table>
<tbody><tr>
<td align="left">Doc. no.</td>
-<td align="left">N2091=06-0161</td>
+<td align="left">N2130=06-0200</td>
</tr>
<tr>
<td align="left">Date:</td>
-<td align="left">2006-09-08</td>
+<td align="left">2006-11-03</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 R44)</h1>
+<h1>C++ Standard Library Active Issues List (Revision R45)</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>R45:
+2006-11-03 post-Portland mailing.
+Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a> to WP.
+Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#554">554</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a> to NAD.
+Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup.
+Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.
+Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#545">545</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#598">598</a> - <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#605">605</a> to Ready.
+Moved issues <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#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#604">604</a> to Review.
+Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#593">593</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#609">609</a>.
+</li>
<li>R44:
2006-09-08 pre-Portland mailing.
Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#583">583</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#592">592</a>.
2006-06-23 mid-term mailing.
Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#575">575</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>.
Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#255">255</a>.
-Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#569">569</a> to Tentatively Ready.
+Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Tentatively Ready.
</li>
<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-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-
closed.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-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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>
<li>R40:
2005-12-16 mid-term mailing.
-Added new issues <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#535">535</a>.
+Added new issues <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-defects.html#535">535</a>.
</li>
<li>R39:
2005-10-14 post-Mont Tremblant mailing.
Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#526">526</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#528">528</a>.
Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461">461</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464">464</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#465">465</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#467">467</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#474">474</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#496">496</a> from Ready to WP as per the vote from Mont Tremblant.
Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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-active.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.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-closed.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>R38:
2005-07-03 pre-Mont Tremblant mailing.
-Merged open TR1 issues in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
active.html#504">504</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>.
+Merged open TR1 issues in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-
closed.html#504">504</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>.
Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>
</li>
<li>R37:
[Pre-Berlin] Reopened at the request of Paolo Carlini and Steve Clamage.
</p>
+<p>
+[Pre-Portland] A relevant newsgroup post:
+</p>
+
+<p>
+The current proposed resolution of issue #309
+(http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309) is
+unacceptable. I write commerical software and coding around this
+makes my code ugly, non-intuitive, and requires comments referring
+people to this very issue. Following is the full explanation of my
+experience.
+</p>
+<p>
+In the course of writing software for commercial use, I constructed
+std::ifstream's based on user-supplied pathnames on typical POSIX
+systems.
+</p>
+<p>
+It was expected that some files that opened successfully might not read
+successfully -- such as a pathname which actually refered to a
+directory. Intuitively, I expected the streambuffer underflow() code
+to throw an exception in this situation, and recent implementations of
+libstdc++'s basic_filebuf do just that (as well as many of my own
+custom streambufs).
+</p>
+<p>
+I also intuitively expected that the istream code would convert these
+exceptions to the "badbit' set on the stream object, because I had not
+requested exceptions. I refer to 27.6.1.1. P4.
+</p>
+<p>
+However, this was not the case on at least two implementations -- if
+the first thing I did with an istream was call operator>>( T& ) for T
+among the basic arithmetic types and std::string. Looking further I
+found that the sentry's constructor was invoking the exception when it
+pre-scanned for whitespace, and the extractor function (operator>>())
+was not catching exceptions in this situation.
+</p>
+<p>
+So, I was in a situation where setting 'noskipws' would change the
+istream's behavior even though no characters (whitespace or not) could
+ever be successfully read.
+</p>
+<p>
+Also, calling .peek() on the istream before calling the extractor()
+changed the behavior (.peek() had the effect of setting the badbit
+ahead of time).
+</p>
+<p>
+I found this all to be so inconsistent and inconvenient for me and my
+code design, that I filed a bugzilla entry for libstdc++. I was then
+told that the bug cannot be fixed until issue #309 is resolved by the
+committee.
+</p>
+
<p><b>Proposed resolution:</b></p>
<p><b>Rationale:</b></p>
<p>The LWG agrees there is minor variation between implementations,
or <tt>badbit</tt> is set, so using <tt>!fail()</tt>, rather
than <tt>good()</tt>, satisfies this goal.</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.byname"> [lib.locale.codecvt.byname]</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>
+<a name="382"><
/a><h3><a name="382">382. codecvt do_in/out result</a></h3><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.byname"> [lib.locale.codecvt.byname]</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
sufficient room for interpretation so that two implementations of
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#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 ..."
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-In 5.1.1 [tr.rand.req], Paragraph 2 replace
-</p>
-
-<blockquote>
-... s is a value of integral type, g is an lvalue of a type other than X that
-defines a zero-argument function object returning values of <del>unsigned integral</del> type
-<ins><tt>unsigned long int</tt></ins>,
-...
-</blockquote>
-
-<p>
-In 5.1.1 [tr.rand.seq], Table 16, replace in the line for X(s)
-</p>
-
-<blockquote>
-creates an engine with the initial internal state
-determined by <ins><tt>static_cast<unsigned long>(</tt></ins><tt><i>s</i></tt><ins><tt>)</tt></ins>
-</blockquote>
-
-<p><i>[
-Mont Tremblant: Both s and g should be unsigned long.
-This should refer to the constructor signatures. Jens provided wording post Mont Tremblant.
-]</i></p>
-
-<p><i>[
-Berlin: N1932 adopts the proposed resolution: see 26.3.1.3/1e and Table 3 row 2. Moved
-to Ready.
-]</i></p>
-
-<p><b>Rationale:</b></p>
-<p>
-Jens: Just requiring X(unsigned long) still makes it possible
-for an evil library writer to also supply a X(int) that does something
-unexpected. The wording above requires that X(s) always performs
-as if X(unsigned long) would have been called. I believe that is
-sufficient and implements our intentions from Mont Tremblant. I
-see no additional use in actually requiring a X(unsigned long)
-signature. u.seed(s) is covered by its reference to X(s), same
-arguments.
-</p>
-<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#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
-flawed in the case where the engine parameter w (also known as word_size)
-exceeds 31 [bits]. The key part of the paragraph reads:
-</p>
-<blockquote>
-sets x(-r) ... x(-1) to (lcg(1)*2**(-w)) mod 1
-</blockquote>
-<p>
-and so forth.
-</p>
-<p>
-Since the specified linear congruential engine, lcg, delivers numbers with
-a maximum of 2147483563 (just a shade under 31 bits), then when w is, for
-example, 48, each of the x(i) will be less than 2**-17. The consequence
-is that roughly the first 400 numbers delivered will be conspicuously
-close to either zero or one.
-</p>
-<p>
-Unfortunately, this is not an innocuous flaw: One of the predefined engines
-in [tr.rand.predef], namely ranlux64_base_01, has w = 48 and would exhibit
-this poor behavior, while the original N1378 proposal states that these
-pre-defined engines are intended to be of "known good properties."
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-In 5.1.4.4 [tr.rand.eng.sub1], replace the "effects" clause for
-void seed(unsigned long value = 19780503) by
-</p>
-
-<blockquote>
-<i>Effects:</i> If <tt>value == 0</tt>, sets value to <tt>19780503</tt>. In any
-case, <del>with a linear congruential generator <tt>lcg</tt>(i) having parameters
-<tt><i>m<sub>lcg</sub></i> = 2147483563</tt>, <tt><i>a<sub>lcg</sub></i> = 40014</tt>,
-<tt><i>c<sub>lcg</sub></i> = 0</tt>, and <tt><i>lcg</i>(0) = value</tt>,</del>
-sets <ins>carry<tt>(-1)</tt> and</ins> <tt>x(-r) … x(-1)</tt>
-<ins>as if executing</ins>
-
-<blockquote><pre><ins>
-linear_congruential<unsigned long, 40014, 0, 2147483563> lcg(value);
-seed(lcg);
-</ins></pre></blockquote>
-
-<del>to <tt>(<i>lcg</i>(1) · 2<sup>-<i>w</i></sup>) mod 1
-… (<i>lcg</i>(<i>r</i>) · 2<sup>-<i>w</i></sup>) mod 1</tt>,
-respectively. If <tt><i>x</i>(-1) == 0</tt>, sets carry<tt>(-1) = 2<sup>-<i>w</i></sup></tt>,
-else sets carry<tt>(-1) = 0</tt>.</del>
-</blockquote>
-
-<p><i>[
-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
-prose would probably not qualify for the (with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#504">504</a> even
-stricter) requirements we have for seed(Gen&).
-</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#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,
]</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#Ready">Ready</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p>
-<p>
-Paragraph 6 says:
-</p>
-<blockquote>
-... obtained by successive invocations of g, ...
-</blockquote>
-<p>
-We recommend instead:
-</p>
-<blockquote>
-... obtained by taking successive invocations of g mod 2**32, ...
-</blockquote>
-<p>
-as the context seems to require only 32-bit quantities be used here.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-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>
+<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#Open">Open</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 3 Jul 2005</p>
<p>
Issue 371 deals with stability of multiset/multimap under insert and erase
(i.e. do they preserve the relative order in ranges of equal elements).
The same issue applies to unordered_multiset and unordered_multimap.
</p>
<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-<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#Tentatively%20Ready">Tentatively Ready</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
-called with a pointer to member data as it's callable object was
-defined to be mem_fn(ptr); when Peter Dimov and I unified the
-descriptions of the TR1 function objects we hoisted the descriptions
-of return types into the INVOKE pseudo-function and into result_of.
-Unfortunately, we left pointer to member data out of result_of, so
-bind doesn't have any specified behavior when called with a pointer
-to member data.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p><i>[
-Pete and Peter will provide wording.
-]</i></p>
-
-<p>
-In 20.5.4 [lib.func.ret] ([tr.func.ret]) p3 add the following bullet after bullet 2:
-</p>
-<ol start="3">
-<li>If <tt>F</tt> is a member data pointer type <tt>R T::*</tt>, <tt>type</tt>
-shall be <tt><i>cv</i> R&</tt> when <tt>T1</tt> is <tt><i>cv</i> U1&</tt>,
-<tt>R</tt> otherwise.</li>
-</ol>
-
<p><i>[
-Peter provided wording.
+Moved to open (from review): There is no resolution.
]</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#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:
-</p>
-<blockquote>
-a pointer to member function type with cv-qualifier cv and no arguments;
-the type T1 is cv T* and R is the return type of the pointer to member function;
-</blockquote>
-<p>
-The type of T1 can't be cv T*, 'cause that's a pointer to a pointer to member
-function. It should be a pointer to the class that T is a pointer to member of.
-Like this:
-</p>
-<blockquote>
-a pointer to a member function R T0::f() cv (where cv represents the member
-function's cv-qualifiers); the type T1 is cv T0*
-</blockquote>
-<p>
-Similarly, bullet item 2 in 2.1.2/4 should be:
-</p>
-<blockquote>
-a pointer to a member function R T0::f(T2) cv (where cv represents the member
-function's cv-qualifiers); the type T1 is cv T0*
-</blockquote>
-<p><b>Proposed resolution:</b></p>
-
-<p>
-Change bullet item 2 in 2.1.2/3:
-</p>
-
-<blockquote>
-<ul>
-<li>
-a pointer to member function <del>type with cv-qualifier <tt><i>cv</i></tt> and no arguments;
-the type <tt>T1</tt> is <tt><i>cv</i> T*</tt> and <tt>R</tt> is the return
-type of the pointer to member function</del> <ins><tt>R T0::f() <i>cv</i></tt>
-(where <tt><i>cv</i></tt> represents the member function's cv-qualifiers);
-the type <tt>T1</tt> is <tt><i>cv</i> T0*</tt></ins>
-</li>
-</ul>
-</blockquote>
<p>
-Change bullet item 2 in 2.1.2/4:
</p>
-
-<blockquote>
-<ul>
-<li>
-a pointer to member function <del>with cv-qualifier <tt><i>cv</i></tt> and taking one argument
-of type <tt>T2</tt>; the type <tt>T1</tt> is <tt><i>cv</i> T*</tt> and
-<tt>R</tt> is the return type of the pointer to member function</del>
-<ins><tt>R T0::f(T2) <i>cv</i></tt> (where <tt><i>cv</i></tt> represents the member
-function's cv-qualifiers); the type <tt>T1</tt> is <tt><i>cv</i> T0*</tt></ins>
-</li>
-</ul>
-</blockquote>
-
<hr>
<a name="522"><h3>522. Tuple doesn't define swap</h3></a><p><b>Section:</b> TR1 6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.tuple"> [tr.tuple]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Andy Koenig <b>Date:</b> 3 Jul 2005</p>
<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>
+<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#Open">Open</a> <b>Submitter:</b> Eric Niebler <b>Date:</b> 1 Jul 2005</p>
<p>
A problem with TR1 regex is currently being discussed on the Boost
developers list. It involves the handling of case-insensitive matching
Hoping this doesn't make this even more complex that it was already,
</p>
+<p><i>[
+Portland: Alisdair: Detect as invalid, throw an exception.
+Pete: Possible general problem with case insensitive ranges.
+]</i></p>
+
<p><b>Proposed resolution:</b></p>
<hr>
-<a name="524"><h3>524. regex named character classes and case-insensitivity don't mix</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>
+<a name="524"><h3>524. regex named character classes and case-insensitivity don't mix</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#Open">Open</a> <b>Submitter:</b> Eric Niebler <b>Date:</b> 1 Jul 2005</p>
<p>
This defect is also being discussed on the Boost developers list. The
full discussion can be found here:
]</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#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>
-
-<p>We almost require contiguity already. Clause 23.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.multiset"> [lib.multiset]</a>
- defines <tt>operator[]</tt> as <tt>data()[pos]</tt>. What's missing
- is a similar guarantee if we access the string's elements via the
- iterator interface.</p>
-
-<p>Given the existence of <tt>data()</tt>, and the definition of
- <tt>operator[]</tt> and <tt>at</tt> in terms of <tt>data</tt>,
- I don't believe it's possible to write a useful and standard-
- conforming <tt>basic_string</tt> that isn't contiguous. I'm not
- aware of any non-contiguous implementation. We should just require
- it.
-</p>
-<p><b>Proposed resolution:</b></p>
-<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>The characters in a string are stored contiguously, meaning that if
- <tt>s</tt> is a <tt>basic_string<charT, Allocator></tt>, then
- it obeys the identity
- <tt>&*(s.begin() + n) == &*s.begin() + n</tt>
- for all <tt>0 <= n < s.size()</tt>.
- </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#Ready">Ready</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#Review">Review</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
</li>
</ul>
<p></p>
+<p>
+Change 27.6.1.3, p9:
+</p>
+
+<blockquote>
+If the function stores no characters, it calls <tt>setstate(failbit)</tt> (which
+may throw <tt>ios_base::failure</tt> (27.4.4.3)). In any case, <ins>if <tt>(n
+> 0)</tt> is true</ins> it then stores a null character into the next
+successive location of the array.
+</blockquote>
+
<p>
and similarly p17 (<tt>istream::getline()</tt>), bullet 3 to:
</blockquote>
<p></p>
+
+<p><i>[
+post-Redmond: Pete noticed that the current resolution for <tt>get</tt> requires
+writing to out of bounds memory when <tt>n == 0</tt>. Martin provided fix.
+]</i></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#Open">Open</a> <b>Submitter:</b> David Abrahams <b>Date:</b> 29 Nov 2005</p>
<p>
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#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>
-
-<blockquote>
-<p>
-<i>Effects:</i> Swaps the contents of the two strings.
-</p>
-
-<p>
-<i>Postcondition:</i> <tt>*this</tt> contains the characters that were in <tt><i>s</i></tt>,
-<tt><i>s</i></tt> contains the characters that were in <tt>*this</tt>.
-</p>
-</blockquote>
-
-<p>
-Specifying both Effects and Postcondition seems redundant, and the postcondition
-needs to be made stronger. Users would be unhappy if the characters were not in
-the same order after the swap.
-</p>
-<p><b>Proposed resolution:</b></p>
-<blockquote>
-<p>
-<del><i>Effects:</i> Swaps the contents of the two strings.</del>
-</p>
-
-<p>
-<i>Postcondition:</i> <tt>*this</tt> contains the <ins>same sequence of</ins>
-characters that <del>were</del> <ins>was</ins> in <tt><i>s</i></tt>,
-<tt><i>s</i></tt> contains the <ins>same sequence of</ins> characters that
-<del>were</del> <ins>was</ins> in <tt>*this</tt>.
-</p>
-</blockquote>
-<hr>
<a name="536"><h3>536. Container iterator constructor and explicit convertibility</h3></a><p><b>Section:</b> 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#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
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#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>seekg(off_type& off, ios_base::seekdir dir)
-</pre></blockquote>
-
-<p>
-and
-</p>
-
-<blockquote><pre>seekp(pos_type& pos)
-
-seekp(off_type& off, ios_base::seekdir dir)
-</pre></blockquote>
-
-<p>
-that is, by reference off and pos arguments.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-After 27.6.1.3p42 change:
-</p>
-
-<blockquote><pre>basic_istream<charT,traits>& seekg(off_type<del>&</del> <i>off</i>, ios_base::seekdir <i>dir</i>);
-</pre></blockquote>
-
-<p>
-After 27.6.2.4p1 change:
-</p>
-
-<blockquote><pre>basic_ostream<charT,traits>& seekp(pos_type<del>&</del> <i>pos</i>);
-</pre></blockquote>
-
-<p>
-After 27.6.2.4p3 change:
-</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#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">
-241 "Does unique_copy() require CopyConstructible and Assignable?"</a> which now
-has WP status.
-</p>
-
-<p>
-This talks about <tt>unique_copy</tt> requirements and currently reads:
-</p>
-
-<blockquote>
--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> shall
-be valid. If neither <tt>InputIterator</tt> nor <tt>OutputIterator</tt> meets the
-requirements of forward iterator then the value type of <tt>InputIterator</tt>
-must be CopyConstructible (20.1.3). Otherwise CopyConstructible is not required.
-</blockquote>
-
-<p>
-The problem (which Paolo discovered) is that when the iterators are at their
-most restrictive (<tt>InputIterator</tt>, <tt>OutputIterator</tt>), then we want
-<tt>InputIterator::value_type</tt> to be both <tt>CopyConstructible</tt> and
-<tt>CopyAssignable</tt> (for the most efficient implementation). However this
-proposed resolution only makes it clear that it is <tt>CopyConstructible</tt>,
-and that one can assign from <tt>*<i>first</i></tt> to <tt>*<i>result</i></tt>.
-This latter requirement does not necessarily imply that you can:
-</p>
-
-<blockquote><pre>*<i>first</i> = *<i>first</i>;
-</pre></blockquote>
-<p><b>Proposed resolution:</b></p>
-<blockquote>
--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>
-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 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.rand"> [lib.rand]</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
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#Ready">Ready</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 15 Oct 2005</p>
+<a name="542"><h3>542. shared_ptr observers</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#Open">Open</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 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:
+Peter Dimov wrote:
+To: C++ libraries mailing list
+Message c++std-lib-15614
+[...]
+The intent is for both use_count() and unique() to work in a threaded environment.
+They are intrinsically prone to race conditions, but they never return garbage.
</p>
-<blockquote>
- Notes: When T is void, attempting to instantiate this member function
- renders the program ill-formed. [Note: Instantiating shared_ptr<void>
- does not necessarily result in instantiating this member function.
- --end note]
-</blockquote>
-
<p>
-with the requirement in temp.inst, p1:
+This is a crucial piece of information that I really wish were
+captured in the text. Having this in a non-normative note would
+have made everything crystal clear to me and probably stopped
+me from ever starting this discussion :) Instead, the sentence
+in p12 "use only for debugging and testing purposes, not for
+production code" very strongly suggests that implementations
+can and even are encouraged to return garbage (when threads
+are involved) for performance reasons.
+</p>
+<p>
+How about adding an informative note along these lines:
</p>
-
<blockquote>
- The implicit instantiation of a class template specialization causes
- the implicit instantiation of the declarations, but not of the
- definitions...
+ Note: Implementations are encouraged to provide well-defined
+ behavior for use_count() and unique() even in the presence of
+ multiple threads.
</blockquote>
-
<p>
-I assume that what the note is really trying to say is that
-"instantiating shared_ptr<void> *must not* result in instantiating
-this member function." That is, that this function must not be
-declared a member of shared_ptr<void>. Is my interpretation
-correct?
+I don't necessarily insist on the exact wording, just that we
+capture the intent.
</p>
<p><b>Proposed resolution:</b></p>
<p>
-Change 2.2.3.5p6
</p>
-
-<blockquote>
--6- <del><i>Notes:</i></del> When <tt>T</tt> is <tt>void</tt>, <del>attempting to instantiate
-this member function renders the program ill-formed. [<i>Note:</i>
-Instantiating <tt>shared_ptr<void></tt> does not necessarily result in
-instantiating this member function. <i>--end note</i>]</del> <ins>it is
-unspecified whether this member function is declared or not, and if so, what its
-return type is, except that the declaration (although not necessarily the
-definition) of the function shall be well-formed.</ins>
-</blockquote>
-
<hr>
-<a name="541"><h3>541. shared_ptr template assignment and void</h3></a><p><b>Section:</b> TR1 2.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.smartptr.shared"> [tr.util.smartptr.shared]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Tentatively%20Ready">Tentatively Ready</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 16 Oct 2005</p>
-<p>
-Is the void specialization of the template assignment operator taking
-a shared_ptr<void> as an argument supposed be well-formed?
-</p>
-<p>
-I.e., is this snippet well-formed:
-</p>
-<blockquote><pre>shared_ptr<void> p;
-p.operator=<void>(p);
-</pre></blockquote>
-
-<p>
-Gcc complains about auto_ptr<void>::operator*() returning a reference
-to void. I suspect it's because shared_ptr has two template assignment
-operators, one of which takes auto_ptr, and the auto_ptr template gets
-implicitly instantiated in the process of overload resolution.
-</p>
-
-<p>
-The only way I see around it is to do the same trick with auto_ptr<void>
-operator*() as with the same operator in shared_ptr<void>.
-</p>
-
-<p>
-PS Strangely enough, the EDG front end doesn't mind the code, even
-though in a small test case (below) I can reproduce the error with
-it as well.
-</p>
-
-<blockquote><pre>template <class T>
-struct A { T& operator*() { return *(T*)0; } };
-
-template <class T>
-struct B {
- void operator= (const B&) { }
- template <class U>
- void operator= (const B<U>&) { }
- template <class U>
- void operator= (const A<U>&) { }
-};
-
-int main ()
-{
- B<void> b;
- b.operator=<void>(b);
-}
-</pre></blockquote>
-<p><b>Proposed resolution:</b></p>
-<p>
-In [lib.memory] change:
-</p>
-<blockquote><pre>template<class X> class auto_ptr;
-<ins>template<> class auto_ptr<void>;</ins>
-</pre></blockquote>
-
-<p>
-In [lib.auto.ptr]/2 add the following before the last closing brace:
-</p>
-
-<blockquote><pre>template<> class auto_ptr<void>
-{
-public:
- typedef void element_type;
-};
-</pre></blockquote>
-
-<hr>
-<a name="542"><h3>542. shared_ptr observers</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> 18 Oct 2005</p>
-<p>
-Peter Dimov wrote:
-To: C++ libraries mailing list
-Message c++std-lib-15614
-[...]
-The intent is for both use_count() and unique() to work in a threaded environment.
-They are intrinsically prone to race conditions, but they never return garbage.
-</p>
-
-<p>
-This is a crucial piece of information that I really wish were
-captured in the text. Having this in a non-normative note would
-have made everything crystal clear to me and probably stopped
-me from ever starting this discussion :) Instead, the sentence
-in p12 "use only for debugging and testing purposes, not for
-production code" very strongly suggests that implementations
-can and even are encouraged to return garbage (when threads
-are involved) for performance reasons.
-</p>
-<p>
-How about adding an informative note along these lines:
-</p>
-<blockquote>
- Note: Implementations are encouraged to provide well-defined
- behavior for use_count() and unique() even in the presence of
- multiple threads.
-</blockquote>
-<p>
-I don't necessarily insist on the exact wording, just that we
-capture the intent.
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-</p>
-<hr>
-<a name="543"><h3>543. valarray slice default constructor</h3></a><p><b>Section:</b> 26.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.members"> [lib.complex.members]</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> 3 Nov 2005</p>
+<a name="543"><h3>543. valarray slice default constructor</h3></a><p><b>Section:</b> 26.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.members"> [lib.complex.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> Howard Hinnant <b>Date:</b> 3 Nov 2005</p>
<p>
If one explicitly constructs a slice or glice with the default
constructor, does the standard require this slice to have any usable
</p>
<p><b>Proposed resolution:</b></p>
<p>
+Change 26.5.4.1 [cons.slice]:
</p>
-<hr>
-<a name="544"><h3>544. minor NULL problems in C.2</h3></a><p><b>Section:</b> C.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/diff.html#diff.library"> [diff.library]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Tentatively%20Ready">Tentatively Ready</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 25 Nov 2005</p>
-<p>
-According to C.2.2.3, p1, "the macro NULL, defined in any of <clocale>,
-<cstddef>, <cstdio>, <cstdlib>, <cstring>, <ctime>,
-or <cwchar>." This is consistent with the C standard.
-</p>
-<p>
-However, Table 95 in C.2 fails to mention <clocale> and <cstdlib>.
-</p>
-<p>
-In addition, C.2, p2 claims that "The C++ Standard library provides
-54 standard macros from the C library, as shown in Table 95." While
-table 95 does have 54 entries, since a couple of them (including the
-NULL macro) are listed more than once, the actual number of macros
-defined by the C++ Standard Library may not be 54.
-</p>
-<p><b>Proposed resolution:</b></p>
+
+<blockquote>
+1 - <del>The default constructor for <tt>slice</tt> creates a <tt>slice</tt>
+which specifies no elements.</del> <ins>The default constructor is equivalent to
+<tt>slice(0, 0, 0)</tt>.</ins> A default constructor is provided only to permit
+the declaration of arrays of slices. The constructor with arguments for a slice
+takes a start, length, and stride parameter.
+</blockquote>
+
<p>
-I propose we add <clocale> and <cstdlib> to Table 96 and remove the
-number of macros from C.2, p2 and reword the sentence as follows:
+Change 26.3.6.1 [gslice.cons]:
</p>
+
<blockquote>
-The C++ Standard library <del>provides 54 standard macros from</del>
-<ins>defines a number macros corresponding to those defined by</ins> the C
-<ins>Standard</ins> library, as shown in Table 96.
+1 - <del>The default constructor creates a <tt>gslice</tt> which specifies no
+elements.</del> <ins>The default constructor is equivalent to <tt>gslice(0,
+valarray<size_t>(), valarray<size_t>())</tt>.</ins> The constructor
+with arguments builds a <tt>gslice</tt> based on a specification of start,
+lengths, and strides, as explained in the previous section.
</blockquote>
+
<hr>
-<a name="545"><h3>545. When is a deleter deleted?</h3></a><p><b>Section:</b> TR1 2.2.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.smartptr.shared.dest"> [tr.util.smartptr.shared.dest]</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="545"><h3>545. When is a deleter deleted?</h3></a><p><b>Section:</b> TR1 2.2.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.smartptr.shared.dest"> [tr.util.smartptr.shared.dest]</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>
The description of ~shared_ptr doesn't say when the shared_ptr's deleter, if
any, is destroyed. In principle there are two possibilities: it is destroyed
<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#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 are the parameters of the distribution. OK, that tells us what t, p, and i
-are. What's n?
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Berlin: Typo: "n" replaced by "t" in N1932: see 26.3.7.2.2/1.
-</p>
-<hr>
<a name="550"><h3>550. What should the return type of pow(float,int) be?</h3></a><p><b>Section:</b> 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numarray"> [lib.numarray]</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>
Assuming we adopt the
<p>
</p>
<hr>
-<a name="551"><h3>551. <ccomplex></h3></a><p><b>Section:</b> TR1 8.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.c99.ccmplx"> [tr.c99.ccmplx]</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> 23 Jan 2006</p>
+<a name="551"></a><h3><a name="551">551. <ccomplex></a></h3><p><b>Section:</b> TR1 8.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.c99.ccmplx"> [tr.c99.ccmplx]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 23 Jan 2006</p>
<p>
Previously xxx.h was parsable by C++. But in the case of C99's <complex.h>
it isn't. Otherwise we could model it just like <string.h>, <cstring>, <string>:
<p><b>Proposed resolution:</b></p>
<p>
-Strike 8.2 and 8.3 (and any other references to <ccomplex> and
-<complex.h>).
+Change 26.3.11 [cmplxh]:
+</p>
+
+<blockquote>
+<p>
+The header behaves as if it includes the header
+<tt><ccomplex></tt><ins>.</ins><del>, and provides sufficient using
+declarations to declare in the global namespace all function and type names
+declared or defined in the neader <tt><complex></tt>.</del>
+<ins>[<i>Note:</i> <tt><complex.h></tt> does not promote any interface
+into the global namespace as there is no C interface to promote. <i>--end
+note</i>]</ins>
</p>
+</blockquote>
+
<hr>
<a name="552"><h3>552. random_shuffle and its generator</h3></a><p><b>Section:</b> 25.2.11 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.random.shuffle"> [lib.alg.random.shuffle]</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 Jan 2006</p>
<p>
<p>
</p>
<hr>
-<a name="554"><h3>554. Problem with lwg DR 184 numeric_limits<bool></h3></a><p><b>Section:</b> 18.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.numeric.special"> [lib.numeric.special]</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> 29 Jan 2006</p>
-<p>
-I believe we have a bug in the resolution of:
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#184">lwg 184</a>
-(WP status).
-</p>
-
-<p>
-The resolution spells out each member of <tt>numeric_limits<bool></tt>.
-The part I'm having a little trouble with is:
-</p>
-<blockquote><pre>static const bool traps = false;
-</pre></blockquote>
-
-<p>
-Should this not be implementation defined? Given:
-</p>
-
-<blockquote><pre>int main()
-{
- bool b1 = true;
- bool b2 = false;
- bool b3 = b1/b2;
-}
-</pre></blockquote>
-
-<p>
-If this causes a trap, shouldn't <tt>numeric_limits<bool>::traps</tt> be
-<tt>true</tt>?
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 18.2.1.5p3:
-</p>
-
-<blockquote>
--3- The specialization for <tt>bool</tt> shall be provided as follows:
-<blockquote><pre>namespace std {
- template <> class numeric_limits<bool> {
- ...
- static const bool traps = <del>false</del> <ins><i>implementation-defined</i></ins>;
- ...
- };
-}
-</pre></blockquote>
-</blockquote>
-
-<hr>
-<a name="555"><h3>555. TR1, 8.21/1: typo</h3></a><p><b>Section:</b> TR1 8.21 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.c99.boolh"> [tr.c99.boolh]</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> 2 Feb 2006</p>
-<p>
-This one, if nobody noticed it yet, seems really editorial:
-s/cstbool/cstdbool/
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 8.21p1:
-</p>
-<blockquote>
--1- The header behaves as if it defines the additional macro defined in
-<tt><cst<ins>d</ins>bool></tt> by including the header <tt><cstdbool></tt>.
-</blockquote>
-<hr>
-<a name="556"><h3>556. is Compare a BinaryPredicate?</h3></a><p><b>Section:</b> 25.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.sorting"> [lib.alg.sorting]</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> 5 Feb 2006</p>
+<a name="556"><h3>556. is Compare a BinaryPredicate?</h3></a><p><b>Section:</b> 25.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.sorting"> [lib.alg.sorting]</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 Feb 2006</p>
<p>
In 25, p8 we allow BinaryPredicates to return a type that's convertible
to bool but need not actually be bool. That allows predicates to return
will not apply any non-constant function through the dereferenced iterator.
</blockquote>
<hr>
-<a name="557"><h3>557. TR1: div(_Longlong, _Longlong) vs div(intmax_t, intmax_t)</h3></a><p><b>Section:</b> TR1 8.11.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.c99.cinttypes.syn"> [tr.c99.cinttypes.syn]</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> 6 Feb 2006</p>
+<a name="557"><h3>557. TR1: div(_Longlong, _Longlong) vs div(intmax_t, intmax_t)</h3></a><p><b>Section:</b> TR1 8.11.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.c99.cinttypes.syn"> [tr.c99.cinttypes.syn]</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> 6 Feb 2006</p>
<p>
I'm seeing a problem with such overloads: when, _Longlong == intmax_t ==
long long we end up, essentially, with the same arguments and different
<del>imaxdiv_t div(intmax_t numer, intmax_t denom);</del>
...
</pre></blockquote>
+
+<p><i>[
+Portland: no consensus.
+]</i></p>
+
<hr>
-<a name="558"><h3>558. lib.input.iterators Defect</h3></a><p><b>Section:</b> 24.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</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> 9 Feb 2006</p>
-<blockquote>
-<p>
- 24.1.1 Input iterators [lib.input.iterators]
-</p>
-<p>
- 1 A class or a built-in type X satisfies the requirements of an
- input iterator for the value type T if the following expressions are
- valid, where U is the type of any specified member of type T, as
- shown in Table 73.
-</p>
-</blockquote>
-<p>
-There is no capital U used in table 73. There is a lowercase u, but
-that is clearly not meant to denote a member of type T. Also, there's
-no description in 24.1.1 of what lowercase a means. IMO the above
-should have been...Hah, a and b are already covered in 24.1/11, so maybe it
-should have just been:
-</p>
-<p><b>Proposed resolution:</b></p>
-<p>
-Change 24.1.1p1:
-</p>
-<blockquote>
--1- A class or a built-in type <tt>X</tt> satisfies the requirements of an
-input iterator for the value type <tt>T</tt> if the following expressions
-are valid<del>, where <tt>U</tt> is the type of any specified member of type
-<tt>T</tt>,</del> as shown in Table 73.
-</blockquote>
-<hr>
-<a name="559"><h3>559. numeric_limits<const T></h3></a><p><b>Section:</b> 18.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.limits"> [lib.support.limits]</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> 19 Feb 2006</p>
+<a name="559"><h3>559. numeric_limits<const T></h3></a><p><b>Section:</b> 18.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.limits"> [lib.support.limits]</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 Feb 2006</p>
<p>
18.2.1, p2 requires implementations to provide specializations of the
member of <code>numeric_limits<T></code>.
</p>
+
+<p><i>[
+Portland: Martin will clarify that user-defined types get cv-specializations
+automatically.
+]</i></p>
+
<hr>
<a name="560"><h3>560. User-defined allocators without default constructor</h3></a><p><b>Section:</b> 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.default.con.req"> [lib.default.con.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> Sergey P. Derevyago <b>Date:</b> 17 Feb 2006</p>
<h4>1. The essence of the problem.</h4>
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#Tentatively%20Ready">Tentatively Ready</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><b>Rationale:</b></p>
-<p>
-This is a duplicate of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a>.
-</p>
-<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
<p>
Strike the proposed resolution of issue 507.
</p>
+<p><i>[
+post-Portland: Howard recommends NAD. The proposed resolution of 507 no longer
+exists in the current WD.
+]</i></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> Beman Dawes <b>Date:</b> 12 Apr 2006</p>
<p>
</p>
<hr>
-<a name="581"><
/a><h3><a name="581">581. <code>flush()</code> not unformatted function</a></h3><p><b>Section:</b> 27.6.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 14 June 2006</p>
+<a name="581"><
h3>581. <code>flush()</code> not unformatted function</h3></a><p><b>Section:</b> 27.6.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 14 June 2006</p>
<p>
The resolution of issue 60 changed <code>basic_ostream::flush()</code>
// requires: n >=0
</pre></blockquote>
<hr>
-<a name="585"><
/a><h3><a name="585">585. facet error reporting</a></h3><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> Martin Sebor, Paolo Carlini <b>Date:</b> 22 June 2006</p>
+<a name="585"><
h3>585. facet error reporting</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> Martin Sebor, Paolo Carlini <b>Date:</b> 22 June 2006</p>
<p>
Section 22.2, paragraph 2 requires facet <code>get()</code> members
(27.4.4.3)).
</blockquote>
+<hr>
+<a name="593"><h3>593. __STDC_CONSTANT_MACROS</h3></a><p><b>Section:</b> 18.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.cstdint"> [lib.cstdint]</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> 28 Aug 2006</p>
+<p>
+Clause 18.3 of the current Working Paper (N2009) deals with the new C++ headers
+<cstdint> and <stdint.h>. These are of course based on the C99 header
+<stdint.h>, and were part of TR1.
+</p>
+
+<p>
+Per 18.3.1/1, these headers define a number of macros and function macros.
+While the WP does not mention __STDC_CONSTANT_MACROS in this context, C99
+footnotes do mention __STDC_CONSTANT_MACROS. Further, 18.3.1/2 states that "The
+header defines all ... macros the same as C99 subclause 7.18."
+</p>
+
+<p>
+Therefore, if I wish to have the above-referenced macros and function macros
+defined, must I #define __STDC_CONSTANT_MACROS before I #include <cstdint>, or
+does the C++ header define these macros/function macros unconditionally?
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+To put this issue to rest for C++0X, I propose the following addition to
+18.3.1/2 of the Working Paper N2009:
+</p>
+
+<blockquote>
+[Note: The macros defined by <cstdint> are provided unconditionally: in
+particular, the symbols __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS
+(mentioned in C99 footnotes 219, 220, and 222) play no role in C++. --end note]
+</blockquote>
+<hr>
+<a name="594"><h3>594. Disadvantages of defining Swappable in terms of
+CopyConstructible and Assignable</h3></a><p><b>Section:</b> 20.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.swappable"> [lib.swappable]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Niels Dekker <b>Date:</b> 2 Nov 2006</p>
+<p>
+It seems undesirable to define the Swappable requirement in terms of
+CopyConstructible and Assignable requirements. And likewise, once the
+MoveConstructible and MoveAssignable requirements (N1860) have made it
+into the Working Draft, it seems undesirable to define the Swappable
+requirement in terms of those requirements. Instead, it appears
+preferable to have the Swappable requirement defined exclusively in
+terms of the existence of an appropriate swap function.
+</p>
+<p>
+Section 20.1.4 [lib.swappable] of the current Working Draft (N2009)
+says:
+</p><blockquote>
+The Swappable requirement is met by satisfying one or more of the
+following conditions:
+<ul>
+<li>
+T is Swappable if T satisfies the CopyConstructible requirements
+(20.1.3) and the Assignable requirements (23.1);
+</li>
+<li>
+T is Swappable if a namespace scope function named swap exists in the
+same namespace as the definition of T, such that the expression
+swap(t,u) is valid and has the semantics described in Table 33.
+</li>
+</ul>
+</blockquote>
+I can think of three disadvantages of this definition:
+<ol>
+<li>
+If a client's type T satisfies the first condition (T is both
+CopyConstructible and Assignable), the client cannot stop T from
+satisfying the Swappable requirement without stopping T from
+satisfying the first condition.
+<p>
+A client might want to stop T from satisfying the Swappable
+requirement, because swapping by means of copy construction and
+assignment might throw an exception, and she might find a throwing
+swap unacceptable for her type. On the other hand, she might not feel
+the need to fully implement her own swap function for this type. In
+this case she would want to be able to simply prevent algorithms that
+would swap objects of type T from being used, e.g., by declaring a
+swap function for T, and leaving this function purposely undefined.
+This would trigger a link error, if an attempt would be made to use
+such an algorithm for this type. For most standard library
+implementations, this practice would indeed have the effect of
+stopping T from satisfying the Swappable requirement.
+</p>
+</li>
+<li>
+A client's type T that does not satisfy the first condition can not be
+made Swappable by providing a specialization of std::swap for T.
+<p>
+While I'm aware about the fact that people have mixed feelings about
+providing a specialization of std::swap, it is well-defined to do so.
+It sounds rather counter-intuitive to say that T is not Swappable, if
+it has a valid and semantically correct specialization of std::swap.
+Also in practice, providing such a specialization will have the same
+effect as satisfying the Swappable requirement.
+</p>
+</li>
+<li>
+For a client's type T that satisfies both conditions of the Swappable
+requirement, it is not specified which of the two conditions prevails.
+After reading section 20.1.4 [lib.swappable], one might wonder whether
+objects of T will be swapped by doing copy construction and
+assignments, or by calling the swap function of T.
+<p>
+I'm aware that the intention of the Draft is to prefer calling the
+swap function of T over doing copy construction and assignments. Still
+in my opinion, it would be better to make this clear in the wording of
+the definition of Swappable.
+</p>
+</li>
+</ol>
+<p></p>
+<p>
+I would like to have the Swappable requirement defined in such a way
+that the following code fragment will correctly swap two objects of a
+type T, if and only if T is Swappable:
+</p><pre> using std::swap;
+ swap(t, u); // t and u are of type T.
+</pre>
+This is also the way Scott Meyers recommends calling a swap function,
+in Effective C++, Third Edition, item 25.
+<p></p>
+<p>
+Most aspects of this issue have been dealt with in a discussion on
+comp.std.c++ about the Swappable requirement, from 13 September to 4
+October 2006, including valuable input by David Abrahams, Pete Becker,
+Greg Herlihy, Howard Hinnant and others.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Change section 20.1.4 [lib.swappable] as follows:
+</p>
+<blockquote>
+The Swappable requirement is met by satisfying
+<del>one or more of the following conditions:</del>
+<ins>the following condition:</ins>
+<ul>
+<del>
+<li>
+T is Swappable if T satisfies the CopyConstructible requirements
+(20.1.3) and the Assignable requirements (23.1);
+</li>
+</del>
+<li>
+<del>
+T is Swappable if a namespace scope function named swap exists in the
+same namespace as the definition of T, such that the expression
+swap(t,u) is valid and has the semantics described in Table 33.
+</del>
+T is Swappable if an unqualified function call swap(t,u) is valid
+within the namespace std, and has the semantics described in Table 33.
+</li>
+</ul>
+</blockquote>
+<hr>
+<a name="595"><h3>595. TR1/C++0x: fabs(complex<T>) redundant / wrongly specified</h3></a><p><b>Section:</b> 26.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.numbers"> [lib.complex.numbers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Stefan Große Pawig <b>Date:</b> 24 Sep 2006</p>
+<p>
+TR1 introduced, in the C compatibility chapter, the function
+fabs(complex<T>):
+</p>
+<blockquote><pre>----- SNIP -----
+8.1.1 Synopsis [tr.c99.cmplx.syn]
+
+ namespace std {
+ namespace tr1 {
+[...]
+ template<class T> complex<T> fabs(const complex<T>& x);
+ } // namespace tr1
+ } // namespace std
+
+[...]
+
+8.1.8 Function fabs [tr.c99.cmplx.fabs]
+
+1 Effects: Behaves the same as C99 function cabs, defined in
+ subclause 7.3.8.1.
+----- SNIP -----
+</pre></blockquote>
+
+<p>
+The current C++0X draft document (n2009.pdf) adopted this
+definition in chapter 26.3.1 (under the comment // 26.3.7 values)
+and 26.3.7/7.
+</p>
+<p>
+But in C99 (ISO/IEC 9899:1999 as well as the 9899:TC2 draft document
+n1124), the referenced subclause reads
+</p>
+
+<blockquote><pre>----- SNIP -----
+7.3.8.1 The cabs functions
+
+ Synopsis
+
+1 #include <complex.h>
+ double cabs(double complex z);
+ float cabsf(float complex z);
+ long double cabsl(long double z);
+
+ Description
+
+2 The cabs functions compute the complex absolute value (also called
+ norm, modulus, or magnitude) of z.
+
+ Returns
+
+3 The cabs functions return the complex absolute value.
+----- SNIP -----
+</pre></blockquote>
+
+<p>
+Note that the return type of the cabs*() functions is not a complex
+type. Thus, they are equivalent to the already well established
+ template<class T> T abs(const complex<T>& x);
+(26.2.7/2 in ISO/IEC 14882:1998, 26.3.7/2 in the current draft
+document n2009.pdf).
+</p>
+<p>
+So either the return value of fabs() is specified wrongly, or fabs()
+does not behave the same as C99's cabs*().
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+This depends on the intention behind the introduction of fabs().
+</p>
+<p>
+If the intention was to provide a /complex/ valued function that
+calculates the magnitude of its argument, this should be
+explicitly specified. In TR1, the categorization under "C
+compatibility" is definitely wrong, since C99 does not provide
+such a complex valued function.
+</p>
+<p>
+Also, it remains questionable if such a complex valued function
+is really needed, since complex<T> supports construction and
+assignment from real valued arguments. There is no difference
+in observable behaviour between
+</p>
+<blockquote><pre> complex<double> x, y;
+ y = fabs(x);
+ complex<double> z(fabs(x));
+</pre></blockquote>
+<p>
+and
+</p>
+<blockquote><pre> complex<double> x, y;
+ y = abs(x);
+ complex<double> z(abs(x));
+</pre></blockquote>
+<p>
+If on the other hand the intention was to provide the intended
+functionality of C99, fabs() should be either declared deprecated
+or (for C++0X) removed from the standard, since the functionality
+is already provided by the corresponding overloads of abs().
+</p>
+<hr>
+<a name="596"><h3>596. 27.8.1.3 Table 112 omits "a+" and "a+b" modes</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#New">New</a> <b>Submitter:</b> Thomas Plum <b>Date:</b> 26 Sep 2006</p>
+<p>
+In testing 27.8.1.3, Table 112 (in the latest N2009 draft), we invoke
+</p>
+<blockquote><pre> ostr.open("somename", ios_base::out | ios_base::in | ios_base::app)
+</pre></blockquote>
+<p>
+and we expect the open to fail, because out|in|app is not listed in
+Table 92, and just before the table we see very specific words:
+</p>
+<blockquote>
+ If mode is not some combination of flags shown in the table
+ then the open fails.
+</blockquote>
+<p>
+But the corresponding table in the C standard, 7.19.5.3, provides two
+modes "a+" and "a+b", to which the C++ modes out|in|app and
+out|in|app|binary would presumably apply.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+We would like to argue that the intent of Table 112 was to match the
+semantics of 7.19.5.3 and that the omission of "a+" and "a+b" was
+unintentional. (Otherwise there would be valid and useful behaviors
+available in C file I/O which are unavailable using C++, for no
+valid functional reason.)
+</p>
+<p>
+We further request that the missing modes be explicitly restored to
+the WP, for inclusion in C++0x.
+</p>
+<hr>
+<a name="597"><h3>597. Decimal: The notion of 'promotion' cannot be emulated by user-defined types.</h3></a><p><b>Section:</b> <font color="red">Decimal 3.2</font> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Open">Open</a> <b>Submitter:</b> Daveed Vandevoorde <b>Date:</b> 5 April 2006</p>
+<p>
+In a private email, Daveed writes:
+</p>
+<blockquote>
+<p>
+I am not familiar with the C TR, but my guess is that the
+class type approach still won't match a built-in type
+approach because the notion of "promotion" cannot be
+emulated by user-defined types.
+</p>
+<p>
+Here is an example:
+</p>
+</blockquote>
+<pre>
+ struct S {
+ S(_Decimal32 const&); // Converting constructor
+ };
+ void f(S);
+
+ void f(_Decimal64);
+
+ void g(_Decimal32 d) {
+ f(d);
+ }
+</pre>
+
+<blockquote>
+<p>
+If _Decimal32 is a built-in type, the call f(d) will likely
+resolve to f(_Decimal64) because that requires only a
+promotion, whereas f(S) requires a user-defined conversion.
+</p>
+<p>
+If _Decimal32 is a class type, I think the call f(d) will be
+ambiguous because both the conversion to _Decimal64 and the
+conversion to S will be user-defined conversions with neither
+better than the other.
+</p>
+</blockquote>
+<p>
+Robert comments:
+</p>
+<p>In general, a library of arithmetic types cannot exactly emulate the
+behavior of the intrinsic numeric types. There are several ways to tell
+whether an implementation of the decimal types uses compiler
+intrinisics or a library. For example:
+</p>
+<pre> _Decimal32 d1;
+ d1.operator+=(5); // If d1 is a builtin type, this won't compile.
+</pre>
+<p>
+In preparing the decimal TR, we have three options:
+</p>
+<ol>
+<li>require that the decimal types be class types</li>
+<li>require that the decimal types be builtin types, like float and double</li>
+<li>specify a library of class types, but allow enough implementor
+latitude that a conforming implementation could instead provide builtin
+types</li>
+</ol>
+<p>
+We decided as a group to pursue option #3, but that approach implies
+that implementations may not agree on the semantics of certain use
+cases (first example, above), or on whether certain other cases are
+well-formed (second example). Another potentially important problem is
+that, under the present definition of POD, the decimal classes are not
+POD types, but builtins will be.
+</p>
+<p>Note that neither example above implies any problems with respect to
+C-to-C++ compatibility, since neither example can be expressed in C.
+</p>
+<p><b>Proposed resolution:</b></p>
+<hr>
+<a name="598"><h3>598. Decimal: Conversion to integral should truncate, not round.</h3></a><p><b>Section:</b> <font color="red">Decimal 3.2</font> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Daniel Krugler <b>Date:</b> 28 May 2006</p>
+
+<p>
+In a private email, Daniel writes:
+</p>
+<blockquote>
+<p>
+I would like to
+ask, what where the reason for the decision to
+define the semantics of the integral conversion of the decimal types, namely
+</p>
+<pre>"operator long long() const;
+
+ Returns: Returns the result of the
+conversion of *this to the type long long, as if
+performed by the expression llrounddXX(*this)."
+</pre>
+<p>
+where XX stands for either 32, 64, or 128,
+corresponding to the proper decimal type. The
+exact meaning of llrounddXX is not given in that
+paper, so I compared it to the corresponding
+definition given in C99, 2nd edition (ISO 9899), which says in 7.12.9.7 p. 2:
+</p>
+<p>
+"The lround and llround functions round their
+argument to the nearest integer value,
+rounding halfway cases away from zero, regardless
+of the current rounding direction. [..]"
+</p>
+<p>
+Now considering the fact that integral conversion
+of the usual floating-point types ("4.9
+Floating-integral conversions") has truncation
+semantic I wonder why this conversion behaviour
+has not been transferred for the decimal types.
+</p>
+</blockquote>
+<p>
+Robert comments:
+</p>
+<p>
+Also, there is a further error in the <b>Returns:</b> clause for converting <code>decimal::decimal128</code> to <code>long long</code>. It currently calls <code>llroundd64</code>, not <code>llroundd128</code>.
+</p>
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the <b>Returns:</b> clause in 3.2.2.4 to:
+</p>
+<blockquote>
+<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <code>llroundd32(*this)</code> <ins>while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
+</blockquote>
+<p>
+Change the <b>Returns:</b> clause in 3.2.3.4 to:
+</p>
+<blockquote>
+<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <code>llroundd64(*this)</code> <ins>while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
+</blockquote>
+<p>
+Change the <b>Returns:</b> clause in 3.2.4.4 to:
+</p>
+<blockquote>
+<b>Returns:</b> Returns the result of the conversion of <code>*this</code> to the type <code>long long</code>, as if performed by the expression <del><code>llroundd64(*this)</code></del> <ins><code>llroundd128(*this)</code> while the decimal rounding direction mode [3.5.2] <code>FE_DEC_TOWARD_ZERO</code> is in effect</ins>.
+</blockquote>
+
+<hr>
+<a name="599"><h3>599. Decimal: Say "octets" instead of "bytes."</h3></a><p><b>Section:</b> <font color="red">Decimal 3.1</font> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Daniel Krugler <b>Date:</b> 28 May 2006</p>
+<p>
+Daniel writes in a private email:
+</p>
+
+<blockquote>
+<p>
+- 3.1 'Decimal type encodings' says in its note:
+</p>
+<p>
+"this implies that
+sizeof(std::decimal::decimal32) == 4,
+sizeof(std::decimal::decimal64) == 8, and
+sizeof(std::decimal::decimal128) == 16."
+</p><p>
+</p>
+This is a wrong assertion, because the definition
+of 'byte' in 1.7 'The C+ + memory model' of ISO
+14882 (2nd edition) does not specify that a byte
+must be necessarily 8 bits large, which would be
+necessary to compare with the specified bit sizes
+of the types decimal32, decimal64, and decimal128.
+<p></p>
+</blockquote>
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 3.1 as follows:
+</p>
+<blockquote>
+<p>
+The three decimal encoding formats defined in IEEE-754R correspond to the three decimal floating types as follows:
+</p>
+<ul>
+<li>
+decimal32 is a <em>decimal32</em> number, which is encoded in four consecutive <del>bytes</del> <ins>octets</ins> (32 bits)
+</li>
+<li>
+decimal64 is a <em>decimal64</em> number, which is encoded in eight consecutive <del>bytes</del> <ins>octets</ins> (64 bits)
+
+</li>
+<li>
+decimal128 is a <em>decimal128</em> number, which is encoded in 16 consecutive <del>bytes</del> <ins>octets</ins> (128 bits)
+</li>
+</ul>
+<p>
+<del>[<i>Note:</i> this implies that <code>sizeof(std::decimal::decimal32) == 4</code>, <code>sizeof(std::decimal::decimal64) == 8</code>, and <code>sizeof(std::decimal::decimal128) == 16</code>. <i>--end note</i>]</del>
+</p>
+</blockquote>
+<hr>
+<a name="600"><h3>600. Decimal: Wrong parameters for wcstod* functions</h3></a><p><b>Section:</b> <font color="red">Decimal 3.9</font> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Daniel Krugler <b>Date:</b> 28 May 2006</p>
+<p>
+Daniel writes:
+</p>
+<blockquote>
+- 3.9.1 'Additions to <cwchar>' provides wrong
+signatures to the wcstod32, wcstod64, and
+wcstod128 functions ([the parameters have type pointer-to-] char instead of wchar_t).
+</blockquote>
+<p><b>Proposed resolution:</b></p>
+<p>
+Change "3.9.1 Additions to <code><cwchar></code> synopsis" to:
+</p>
+<pre> namespace std {
+ namespace decimal {
+ // 3.9.2 wcstod functions:
+ decimal32 wcstod32 (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
+ decimal64 wcstod64 (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
+ decimal128 wcstod128 (const <del>char</del> <ins>wchar_t</ins> * nptr, <del>char</del> <ins>wchar_t</ins> ** endptr);
+ }
+ }
+</pre>
+<hr>
+<a name="601"><h3>601. Decimal: numeric_limits typos</h3></a><p><b>Section:</b> <font color="red">Decimal 3.3</font> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Daniel Krugler <b>Date:</b> 28 May 2006</p>
+<p>
+Daniel writes in a private email:
+</p>
+
+<blockquote>
+<p>
+- 3.3 'Additions to header <limits>' contains two
+errors in the specialisation of numeric_limits<decimal::decimal128>:
+</p>
+<ol>
+<li>The static member max() returns DEC128_MIN, this should be DEC128_MAX.</li>
+<li>The static member digits is assigned to 384,
+this should be 34 (Probably mixed up with the
+max. exponent for decimal::decimal64).</li>
+</ol>
+</blockquote>
+<p><b>Proposed resolution:</b></p>
+<p>
+In "3.3 Additions to header <code><limits></code>" change numeric_limits<decimal::decimal128> as follows:
+</p>
+<pre> template<> class numeric_limits<decimal::decimal128> {
+ public:
+ static const bool is_specialized = true;
+
+ static decimal::decimal128 min() throw() { return DEC128_MIN; }
+ static decimal::decimal128 max() throw() { return <del>DEC128_MIN;</del> <ins>DEC128_MAX;</ins> }
+
+ static const int digits = <del>384</del> <ins>34</ins>;
+ /* ... */
+</pre>
+<hr>
+<a name="602"><h3>602. Decimal: "generic floating type" not defined.</h3></a><p><b>Section:</b> <font color="red">Decimal 3</font> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Daniel Krugler <b>Date:</b> 28 May 2006</p>
+<p>
+The document uses the term "generic floating types," but defines it nowhere.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the first paragraph of "3 Decimal floating-point types" as follows:
+</p>
+<blockquote>
+This Technical Report introduces three decimal floating-point types, named
+decimal32, decimal64, and decimal128. The set of values of type decimal32 is a
+subset of the set of values of type decimal64; the set of values of the type
+decimal64 is a subset of the set of values of the type decimal128. Support for
+decimal128 is optional. <ins>These types supplement the Standard C++ types
+<code>float</code>, <code>double</code>, and <code>long double</code>, which are
+collectively described as the <i>basic floating types</i></ins>.
+</blockquote>
+<hr>
+<a name="603"><h3>603. Decimal: Trivially simplifying decimal classes.</h3></a><p><b>Section:</b> <font color="red">Decimal 3</font> <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> 28 May 2006</p>
+<p>In c++std-lib-17198, Martin writes:</p>
+
+<blockquote>
+Each of the three classes proposed in the paper (decimal32, decimal64,
+and decimal128) explicitly declares and specifies the semantics of its
+copy constructor, copy assignment operator, and destructor. Since the
+semantics of all three functions are identical to the trivial versions
+implicitly generated by the compiler in the absence of any declarations
+it is safe to drop them from the spec. This change would make the
+proposed classes consistent with other similar classes already in the
+standard (e.g., std::complex).
+</blockquote>
+<p><b>Proposed resolution:</b></p>
+<p>
+Change "3.2.2 Class <code>decimal32</code>" as follows:
+</p>
+<pre> namespace std {
+ namespace decimal {
+ class decimal32 {
+ public:
+ // 3.2.2.1 construct/copy/destroy:
+ decimal32();
+ <del>decimal32(const decimal32 & d32);</del>
+ <del>decimal32 & operator=(const decimal32 & d32);</del>
+ <del>~decimal32();</del>
+ /* ... */
+</pre>
+<p>
+Change "3.2.2.1 construct/copy/destroy" as follows:
+</p>
+<pre> decimal32();
+
+ Effects: Constructs an object of type decimal32 with the value 0;
+
+ <del>decimal32(const decimal32 & d32);</del>
+ <del>decimal32 & operator=(const decimal32 & d32);</del>
+
+ <del>Effects: Copies an object of type decimal32.</del>
+
+ <del>~decimal32();</del>
+
+ <del>Effects: Destroys an object of type decimal32.</del>
+
+</pre>
+<p>
+Change "3.2.3 Class <code>decimal64</code>" as follows:
+</p>
+<pre> namespace std {
+ namespace decimal {
+ class decimal64 {
+ public:
+ // 3.2.3.1 construct/copy/destroy:
+ decimal64();
+ <del>decimal64(const decimal64 & d64);</del>
+ <del>decimal64 & operator=(const decimal64 & d64);</del>
+ <del>~decimal64();</del>
+ /* ... */
+</pre>
+<p>
+Change "3.2.3.1 construct/copy/destroy" as follows:
+</p>
+<pre> decimal64();
+
+ Effects: Constructs an object of type decimal64 with the value 0;
+
+ <del>decimal64(const decimal64 & d64);</del>
+ <del>decimal64 & operator=(const decimal64 & d64);</del>
+
+ <del>Effects: Copies an object of type decimal64.</del>
+
+ <del>~decimal64();</del>
+
+ <del>Effects: Destroys an object of type decimal64.</del>
+
+</pre>
+<p>
+Change "3.2.4 Class <code>decimal128</code>" as follows:
+</p>
+<pre> namespace std {
+ namespace decimal {
+ class decimal128 {
+ public:
+ // 3.2.4.1 construct/copy/destroy:
+ decimal128();
+ <del>decimal128(const decimal128 & d128);</del>
+ <del>decimal128 & operator=(const decimal128 & d128);</del>
+ <del>~decimal128();</del>
+ /* ... */
+</pre>
+<p>
+Change "3.2.4.1 construct/copy/destroy" as follows:
+</p>
+<pre> decimal128();
+
+ Effects: Constructs an object of type decimal128 with the value 0;
+
+ <del>decimal128(const decimal128 & d128);</del>
+ <del>decimal128 & operator=(const decimal128 & d128);</del>
+
+ <del>Effects: Copies an object of type decimal128.</del>
+
+ <del>~decimal128();</del>
+
+ <del>Effects: Destroys an object of type decimal128.</del>
+
+</pre>
+<hr>
+<a name="604"><h3>604. Decimal: Storing a reference to a facet unsafe.</h3></a><p><b>Section:</b> <font color="red">Decimal 3</font> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Review">Review</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 28 May 2006</p>
+<p>
+In c++std-lib-17197, Martin writes:
+</p>
+<blockquote>
+The extended_num_get and extended_num_put facets are designed
+to store a reference to a num_get or num_put facet which the
+extended facets delegate the parsing and formatting of types
+other than decimal. One form of the extended facet's ctor (the
+default ctor and the size_t overload) obtains the reference
+from the global C++ locale while the other form takes this
+reference as an argument.
+</blockquote>
+<blockquote>
+The problem with storing a reference to a facet in another
+object (as opposed to storing the locale object in which the
+facet is installed) is that doing so bypasses the reference
+counting mechanism designed to prevent a facet that is still
+being referenced (i.e., one that is still installed in some
+locale) from being destroyed when another locale that contains
+it is destroyed. Separating a facet reference from the locale
+it comes from van make it cumbersome (and in some cases might
+even make it impossible) for programs to prevent invalidating
+the reference. (The danger of this design is highlighted in
+the paper.)
+</blockquote>
+<blockquote>
+This problem could be easily avoided by having the extended
+facets store a copy of the locale from which they would extract
+the base facet either at construction time or when needed. To
+make it possible, the forms of ctors of the extended facets that
+take a reference to the base facet would need to be changed to
+take a locale argument instead.
+</blockquote>
+<p><b>Proposed resolution:</b></p>
+<p>
+1. Change the <code>extended_num_get</code> synopsis in 3.10.2 as follows:
+</p>
+<pre> extended_num_get(const <del>std::num_get<charT, InputIterator></del> <ins>std::locale</ins> & <i>b</i>, size_t <i>refs</i> = 0);
+
+ /* ... */
+
+ <del>// <i>const std::num_get<charT, InputIterator> & <b>base</b></i>; <i><b>exposition only</b></i></del>
+ <ins>// <i>std::locale <b>baseloc</b></i>; <i><b>exposition only</b></i></ins>
+</pre>
+<p>
+2. Change the description of the above constructor in 3.10.2.1:
+</p>
+<pre> extended_num_get(const <del>std::num_get<charT, InputIterator></del> <ins>std::locale</ins> & <i>b</i>, size_t <i>refs</i> = 0);
+
+</pre>
+<blockquote>
+<p>
+<b>Effects:</b> Constructs an <code>extended_num_get</code> facet as if by:
+</p>
+<pre> extended_num_get(const <del>std::num_get<charT, InputIterator></del> <ins>std::locale</ins> & <i>b</i>, size_t <i>refs</i> = 0)
+ : facet(<i>refs</i>), <i>base<ins>loc</ins></i>(<i>b</i>)
+ { /* ... */ }
+
+</pre>
+<p>
+<del><b>Notes:</b> Care must be taken by the implementation to ensure that the lifetime of the facet referenced by <i>base</i> exceeds that of the resulting <code>extended_num_get</code> facet.</del>
+</p>
+</blockquote>
+<p>
+3. Change the <b>Returns:</b> clause for <code>do_get(iter_type, iter_type, ios_base &, ios_base::iostate &, bool &) const</code>, <i>et al</i> to
+</p>
+<blockquote>
+<b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet<std::num_get<charT, InputIterator> >(<i>baseloc</i>)</ins>.get(<i>in</i>, <i>end</i>, <i>str</i>, <i>err</i>, <i>val</i>)</code>.
+</blockquote>
+<p>
+4. Change the <code>extended_num_put</code> synopsis in 3.10.3 as follows:
+</p>
+<pre> extended_num_put(const <del>std::num_put<charT, OutputIterator></del> <ins>std::locale</ins> & <i>b</i>, size_t <i>refs</i> = 0);
+
+ /* ... */
+
+ <del>// <i>const std::num_put<charT, OutputIterator> & <b>base</b></i>; <i><b>exposition only</b></i></del>
+ <ins>// <i>std::locale <b>baseloc</b></i>; <i><b>exposition only</b></i></ins>
+</pre>
+<p>
+5. Change the description of the above constructor in 3.10.3.1:
+</p>
+<pre> extended_num_put(const <del>std::num_put<charT, OutputIterator></del> <ins>std::locale</ins> & <i>b</i>, size_t <i>refs</i> = 0);
+</pre>
+<blockquote>
+<p>
+<b>Effects:</b> Constructs an <code>extended_num_put</code> facet as if by:
+</p>
+<pre> extended_num_put(const <del>std::num_put<charT, OutputIterator></del> <ins>std::locale</ins> & <i>b</i>, size_t <i>refs</i> = 0)
+ : facet(<i>refs</i>), <i>base<ins>loc</ins></i>(<i>b</i>)
+ { /* ... */ }
+
+</pre>
+<p>
+<del><b>Notes:</b> Care must be taken by the implementation to ensure that the lifetime of the facet referenced by <i>base</i> exceeds that of the resulting <code>extended_num_put</code> facet.</del>
+</p>
+</blockquote>
+<p>
+6. Change the <b>Returns:</b> clause for <code>do_put(iter_type, ios_base &, char_type, bool &) const</code>, <i>et al</i> to
+</p>
+<blockquote>
+<b>Returns:</b> <code><del><i>base</i></del> <ins>std::use_facet<std::num_put<charT, OutputIterator> >(<i>baseloc</i>)</ins>.put(<i>s</i>, <i>f</i>, <i>fill</i>, <i>val</i>)</code>.
+</blockquote>
+
+<p><i>[
+Redmond: We would prefer to rename "extended" to "decimal".
+]</i></p>
+
+<hr>
+<a name="605"><h3>605. Decimal: <decfloat.h> doesn't live here anymore.</h3></a><p><b>Section:</b> <font color="red">Decimal 3.4</font> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Ready">Ready</a> <b>Submitter:</b> Robert Klarer <b>Date:</b> 17 October 2006</p>
+<p>In Berlin, WG14 decided to drop the <decfloat.h> header. The
+contents of that header have been moved into <float.h>. For the
+sake of C compatibility, we should make corresponding changes.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+1. Change the heading of subclause 3.4, "Headers <code><cdecfloat></code> and <code><decfloat.h></code>" to "Additions to headers <code><cfloat></code> and <code><float.h></code>."
+</p>
+<p>
+2. Change the text of subclause 3.4 as follows:
+</p>
+<blockquote>
+<p>
+<del>The standard C++ headers <code><cfloat></code> and <code><float.h></code> define characteristics of the floating-point types <code>float</code>, <code>double</code>, and <code>long double</code>. Their contents remain unchanged by this Technical Report.</del>
+</p>
+<p>
+<del>Headers <code><cdecfloat></code> and <code><decfloat.h></code> define characteristics of the decimal floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>. As well, <code><decfloat.h></code> defines the convenience typedefs <code>_Decimal32</code>, <code>_Decimal64</code>, and <code>_Decimal128</code>, for compatibilty with the C programming language.</del>
+</p>
+<p>
+<ins>The header <code><cfloat></code> is described in [tr.c99.cfloat]. The header <code><float.h></code>
+is described in [tr.c99.floath]. These headers are extended by this
+Technical Report to define characteristics of the decimal
+floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>. As well, <code><float.h></code> is extended to define the convenience typedefs <code>_Decimal32</code>, <code>_Decimal64</code>, and <code>_Decimal128</code> for compatibility with the C programming language.</ins>
+</p>
+</blockquote>
+<p>
+3. Change the heading of subclause 3.4.1, "Header <code><cdecfloat></code> synopsis" to "Additions to header <code><cfloat></code> synopsis."
+</p>
+<p>
+4. Change the heading of subclause 3.4.2, "Header <code><decfloat.h></code> synopsis" to "Additions to header <code><float.h></code> synopsis."
+</p>
+<p>
+5. Change the contents of 3.4.2 as follows:
+</p>
+<pre> <del>#include <cdecfloat></del>
+
+ // <i>C-compatibility convenience typedefs:</i>
+
+ typedef std::decimal::decimal32 _Decimal32;
+ typedef std::decimal::decimal64 _Decimal64;
+ typedef std::decimal::decimal128 _Decimal128;
+</pre>
+
+<hr>
+<a name="606"><h3>606. Decimal: allow narrowing conversions</h3></a><p><b>Section:</b> <font color="red">Decimal 3.2</font> <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> 15 June 2006</p>
+<p>
+In c++std-lib-17205, Martin writes:
+</p>
+<blockquote>
+...was it a deliberate design choice to make narrowing assignments
+ill-formed while permitting narrowing compound assignments? For
+instance:
+</blockquote>
+<pre> decimal32 d32;
+ decimal64 d64;
+
+ d32 = 64; // error
+ d32 += 64; // okay
+</pre>
+<p>
+In c++std-lib-17229, Robert responds:
+</p>
+<blockquote>It is a vestige of an old idea that I forgot to remove from
+the paper. Narrowing assignments should be permitted. The bug is that
+the converting constructors that cause narrowing should not be
+explicit. Thanks for pointing this out.
+</blockquote>
+<p><b>Proposed resolution:</b></p>
+<p>
+1. In "3.2.2 Class <code>decimal32</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversions:
+</p>
+<pre> // <i>3.2.2.2 conversion from floating-point type:</i>
+ <del>explicit</del> decimal32(decimal64 <i>d64</i>);
+ <del>explicit</del> decimal32(decimal128 <i>d128</i>);
+</pre>
+<p>
+2. Do the same thing in "3.2.2.2. Conversion from floating-point type."
+</p>
+<p>
+3. In "3.2.3 Class <code>decimal64</code>" synopsis, remove the <code>explicit</code> specifier from the narrowing conversion:
+</p>
+<pre> // <i>3.2.3.2 conversion from floating-point type:</i>
+ <del>explicit</del> decimal64(decimal128 <i>d128</i>);
+</pre>
+<p>
+4. Do the same thing in "3.2.3.2. Conversion from floating-point type."
+</p>
+
+<p><i>[
+Redmond: We prefer explicit conversions for narrowing and implicit for widening.
+]</i></p>
+
+<hr>
+<a name="607"><h3>607. Concern about short seed vectors</h3></a><p><b>Section:</b> 26.4.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.rand.dist.iunif"> [lib.rand.dist.iunif]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Charles Karney <b>Date:</b> 26 Oct 2006</p>
+<p>
+Short seed vectors of 32-bit quantities all result in different states. However
+this is not true of seed vectors of 16-bit (or smaller) quantities. For example
+these two seeds
+</p>
+
+<blockquote><pre>unsigned short seed = {1, 2, 3};
+unsigned short seed = {1, 2, 3, 0};
+</pre></blockquote>
+
+<p>
+both pack to
+</p>
+
+<blockquote><pre>unsigned seed = {0x20001, 0x3};
+</pre></blockquote>
+
+<p>
+yielding the same state.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+In 26.4.7.1[rand.util.seedseq]/8a, replace
+</p>
+
+<blockquote>
+<p>
+Set <tt>begin[0]</tt> to <tt>5489 + <del>s</del><ins>N</ins></tt>.
+</p>
+<p>
+where <tt>N</tt> is the bit length of the sequence used to construct the
+seed_seq in 26.4.7.1/6 [rand.util.seedseq]. (This quantity is called <tt>n</tt>
+in 26.4.7.1/6 [rand.util.seedseq], but <tt>n</tt> has a different meaning in
+26.4.7.1/8 [rand.util.seedseq]. We have <tt>32^(s-1) < N <= 32^s</tt>.) Now
+</p>
+
+<blockquote><pre>unsigned short seed = {1, 2, 3, 0};
+unsigned seed = {0x20001, 0x3};
+</pre></blockquote>
+
+<p>
+are equivalent (<tt>N = 64</tt>), but
+</p>
+
+<blockquote><pre>unsigned short seed = {1, 2, 3};
+</pre></blockquote>
+
+<p>
+gives a distinct state (<tt>N = 48</tt>).
+</p>
+</blockquote>
+
+<hr>
+<a name="608"><h3>608. Unclear seed_seq construction details</h3></a><p><b>Section:</b> 26.4.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.rand.dist.iunif"> [lib.rand.dist.iunif]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#New">New</a> <b>Submitter:</b> Charles Karney <b>Date:</b> 26 Oct 2006</p>
+<p>
+In 26.4.7.1 [rand.util.seedseq] /6, the order of packing the inputs into b and the
+treatment of signed quantities is unclear. Better to spell it out.
+</p>
+<p><b>Proposed resolution:</b></p>
+<blockquote><pre>b = sum( unsigned(begin[i]) 2^(w i), 0 <= i < end-begin )
+</pre></blockquote>
+
+<p>
+where <tt>w</tt> is the bit-width of the InputIterator.
+</p>
+<hr>
+<a name="609"><h3>609. missing static const</h3></a><p><b>Section:</b> 26.4.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.rand.eng.mers"> [lib.rand.eng.mers]</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 E. Brown <b>Date:</b> 2 Nov 2006</p>
+<p>
+In preparing N2111, an error on my part resulted in the omission of the
+following line from the template synopsis in the cited section:
+</p>
+
+<blockquote><pre>static const size_t word_size = w;
+</pre></blockquote>
+
+<p>
+(This same constant is found, for example, in 26.4.3.3 [rand.eng.sub].)
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the above declaration as the first line after the comment in [rand.adapt.ibits] p4:
+</p>
+
+<blockquote><pre>// engine characteristics
+<ins>static const size_t word_size = w;</ins>
+</pre></blockquote>
+
+<p>
+and accept my apologies for the oversight.
+</p>
<p>----- End of document -----</p>
</body></html>
\ No newline at end of file
--- /dev/null
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
+<html><head><title>C++ Standard Library Closed Issues List</title>
+
+<style>ins {background-color:#FFFFA0}
+del {background-color:#FFFFA0}</style></head>
+
+<body bgcolor="#ffffff" text="#000000">
+<table>
+<tbody><tr>
+<td align="left">Doc. no.</td>
+<td align="left">N2132=06-0202</td>
+</tr>
+<tr>
+<td align="left">Date:</td>
+<td align="left">2006-11-03</td>
+</tr>
+<tr>
+<td align="left">Project:</td>
+<td align="left">Programming Language C++</td>
+</tr>
+<tr>
+<td align="left">Reply to:</td>
+<td align="left">Howard Hinnant <howard.hinnant@gmail.com></td>
+</tr>
+</tbody></table>
+<h1>C++ Standard Library Closed Issues List (Revision R45)</h1>
+ <p>Reference ISO/IEC IS 14882:1998(E)</p>
+ <p>Also see:</p>
+ <ul>
+ <li>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html">Table of Contents</a> for all library issues.</li>
+ <li>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html">Index by Section</a> for all library issues.</li>
+ <li>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html">Index by Status</a> for all library issues.</li>
+ <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a></li>
+ <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a></li>
+ </ul>
+
+ <p>This document contains only library issues which have been closed
+ by the Library Working Group as duplicates or not defects. That is,
+ issues which have a status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> or <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>. See the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a> active issues and more
+ information. See the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a> for issues considered
+ defects. The introductory material in that document also applies to
+ this document.</p>
+<h2>Revision History</h2>
+<ul>
+<li>R45:
+2006-11-03 post-Portland mailing.
+Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a> to WP.
+Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#554">554</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a> to NAD.
+Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup.
+Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open.
+Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#545">545</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#598">598</a> - <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#605">605</a> to Ready.
+Moved issues <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#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#604">604</a> to Review.
+Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#593">593</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#609">609</a>.
+</li>
+<li>R44:
+2006-09-08 pre-Portland mailing.
+Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#583">583</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#592">592</a>.
+</li>
+<li>R43:
+2006-06-23 mid-term mailing.
+Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#575">575</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>.
+Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#255">255</a>.
+Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Tentatively Ready.
+</li>
+<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-closed.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-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.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-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.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>.
+Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a> from Ready to Open.
+Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309">309</a>.
+</li>
+<li>R40:
+2005-12-16 mid-term mailing.
+Added new issues <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-defects.html#535">535</a>.
+</li>
+<li>R39:
+2005-10-14 post-Mont Tremblant mailing.
+Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#526">526</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#528">528</a>.
+Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461">461</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464">464</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#465">465</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#467">467</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#474">474</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#496">496</a> from Ready to WP as per the vote from Mont Tremblant.
+Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-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-closed.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-closed.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>R38:
+2005-07-03 pre-Mont Tremblant mailing.
+Merged open TR1 issues in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>.
+Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>
+</li>
+<li>R37:
+2005-06 mid-term mailing.
+Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>.
+</li>
+<li>R36:
+2005-04 post-Lillehammer mailing. All issues in "ready" status except
+for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#454">454</a> were moved to "DR" status, and all issues
+previously in "DR" status were moved to "WP".
+</li>
+<li>R35:
+2005-03 pre-Lillehammer mailing.
+</li>
+<li>R34:
+2005-01 mid-term mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#488">488</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#494">494</a>.
+</li>
+<li>R33:
+2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
+</li>
+<li>R32:
+2004-09 pre-Redmond mailing: reflects new proposed resolutions and
+new issues received after the 2004-07 mailing. Added
+new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#479">479</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#481">481</a>.
+</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-defects.html#478">478</a>.
+</li>
+<li>R30:
+Post-Sydney mailing: reflects decisions made at the Sydney meeting.
+Voted all "Ready" issues from R29 into the working paper.
+Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#462">462</a>.
+</li>
+<li>R29:
+Pre-Sydney mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>.
+</li>
+<li>R28:
+Post-Kona mailing: reflects decisions made at the Kona meeting.
+Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#432">432</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#440">440</a>.
+</li>
+<li>R27:
+Pre-Kona mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#404">404</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#431">431</a>.
+</li>
+<li>R26:
+Post-Oxford mailing: reflects decisions made at the Oxford meeting.
+All issues in Ready status were voted into DR status. All issues in
+DR status were voted into WP status.
+</li>
+<li>R25:
+Pre-Oxford mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a>.
+</li>
+<li>R24:
+Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
+meeting. All Ready issues from R23 with the exception of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, which has been given a new proposed resolution, were
+moved to DR status. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#383">383</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a>. (Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> were discussed
+at the meeting.) Made progress on issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a> have been moved to Ready status, and the only remaining
+concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
+</li>
+<li>R23:
+Pre-Santa Cruz mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#367">367</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#382">382</a>.
+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-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>.
+</li>
+<li>R20:
+Post-Redmond mailing; reflects actions taken in Redmond. Added
+new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#336">336</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, of which issues
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#347">347</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a> were added since Redmond, hence
+not discussed at the meeting.
+
+All Ready issues were moved to DR status, with the exception of issues
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a>, and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>.
+
+Noteworthy issues discussed at Redmond include
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#120">120</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#202">202</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#233">233</a>,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.
+</li>
+<li>R19:
+Pre-Redmond mailing. Added new issues
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#335">335</a>.
+</li>
+<li>R18:
+Post-Copenhagen mailing; reflects actions taken in Copenhagen.
+Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#317">317</a>, and discussed
+new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>.
+
+Changed status of issues
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#118">118</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#165">165</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#171">171</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#183">183</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#184">184</a>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#185">185</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#186">186</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#214">214</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#221">221</a>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#234">234</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#237">237</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#243">243</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#248">248</a>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#251">251</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#256">256</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#260">260</a>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#261">261</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#262">262</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#263">263</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>
+to DR.
+
+Changed status of issues
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#117">117</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#230">230</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#238">238</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#242">242</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#259">259</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#266">266</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#273">273</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#275">275</a>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#285">285</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#286">286</a>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#288">288</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#292">292</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#295">295</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#297">297</a>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#298">298</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#301">301</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#306">306</a>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#307">307</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#308">308</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>
+to Ready.
+
+Closed issues
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#277">277</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#287">287</a>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#289">289</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#293">293</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#302">302</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#313">313</a>
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
+as NAD.
+
+</li>
+<li>R17:
+Pre-Copenhagen mailing. Converted issues list to XML. Added proposed
+resolutions for issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#76">76</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>.
+Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#311">311</a>.
+</li>
+<li>R16:
+post-Toronto mailing; reflects actions taken in Toronto. Added new
+issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#277">277</a>. Changed status of issues
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3">3</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#8">8</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#9">9</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#19">19</a>,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#26">26</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#61">61</a>,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#63">63</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#108">108</a>,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#115">115</a>,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#122">122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#142">142</a>,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#144">144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#146">146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#147">147</a>,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#159">159</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#164">164</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#170">170</a>,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#181">181</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#208">208</a>,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#209">209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#210">210</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#217">217</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#220">220</a>,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#222">222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#223">223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#224">224</a>,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a> to "DR". Reopened issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#23">23</a>. Reopened
+issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#187">187</a>. Changed issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#2">2</a> and
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> to NAD. Fixed a typo in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a>. Fixed
+issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>: signature should be changed both places it
+appears. Fixed issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#160">160</a>: previous version didn't fix
+the bug in enough places.
+</li>
+<li>R15:
+pre-Toronto mailing. Added issues
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#233">233</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a>. Some small HTML formatting
+changes so that we pass Weblint tests.
+</li>
+<li>R14:
+post-Tokyo II mailing; reflects committee actions taken in
+Tokyo. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a>. (00-0019R1/N1242)
+</li>
+<li>R13:
+pre-Tokyo II updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a>.
+</li>
+<li>R12:
+pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>. Added "and paragraph 5" to the proposed resolution
+of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>. Add further rationale to issue
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>.
+</li>
+<li>R11:
+post-Kona mailing: Updated to reflect LWG and full committee actions
+in Kona (99-0048/N1224). Note changed resolution of issues
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#196">196</a>
+to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#198">198</a>. Closed issues list split into "defects" and
+"closed" documents. Changed the proposed resolution of issue
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> to NAD, and changed the wording of proposed resolution
+of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>.
+</li>
+<li>R10:
+pre-Kona updated. Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a> to
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
+</li>
+<li>R9:
+pre-Kona mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
+"closed" documents. (99-0030/N1206, 25 Aug 99)
+</li>
+<li>R8:
+post-Dublin mailing. Updated to reflect LWG and full committee actions
+in Dublin. (99-0016/N1193, 21 Apr 99)
+</li>
+<li>R7:
+pre-Dublin updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#131">131</a>,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#132">132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#133">133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#135">135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a> (31 Mar 99)
+</li>
+<li>R6:
+pre-Dublin mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>,
+and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>. (99-0007/N1194, 22 Feb 99)
+</li>
+<li>R5:
+update issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>; added issues
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#126">126</a>. Format revisions to prepare
+for making list public. (30 Dec 98)
+</li>
+<li>R4:
+post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#113">113</a> added, several
+issues corrected. (22 Oct 98)
+</li>
+<li>R3:
+post-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#94">94</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>
+added, many issues updated to reflect LWG consensus (12 Oct 98)
+</li>
+<li>R2:
+pre-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#93">93</a> added,
+issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98)
+</li>
+<li>R1:
+Correction to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#55">55</a> resolution, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a> code
+format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98)
+</li>
+</ul>
+<h2>Closed Issues</h2>
+<hr>
+<a name="2"><h3>2. Auto_ptr conversions effects incorrect</h3></a><p><b>Section:</b> 20.4.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.unary.prop"> [lib.meta.unary.prop]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 4 Dec 1997</p>
+<p>Paragraph 1 in "Effects", says "Calls
+p->release()" where it clearly must be "Calls
+p.release()". (As it is, it seems to require using
+auto_ptr<>::operator-> to refer to X::release, assuming that
+exists.)</p>
+<p><b>Proposed resolution:</b></p>
+<p>Change 20.4.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.unary.prop"> [lib.meta.unary.prop]</a> paragraph 1 Effects from
+"Calls p->release()" to "Calls p.release()".</p>
+<p><b>Rationale:</b></p>
+<p>Not a defect: the proposed change is already found in the standard.
+[Originally classified as a defect, later reclassified.]</p>
+<hr>
+<a name="4"><h3>4. Basic_string size_type and difference_type should be implementation defined</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#NAD">NAD</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 16 Nov 1997</p>
+<p>In Morristown we changed the size_type and difference_type typedefs
+for all the other containers to implementation defined with a
+reference to 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>. This should probably also have been
+done for strings. </p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>Not a defect. [Originally classified as a defect, later
+reclassified.] basic_string, unlike the other standard library
+template containers, is severely constrained by its use of
+char_traits. Those types are dictated by the traits class, and are far
+from implementation defined.</p>
+<hr>
+<a name="6"><h3>6. File position not an offset unimplementable</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#NAD">NAD</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 15 Dec 1997</p>
+<p>Table 88, in I/O, is too strict; it's unimplementable on systems
+where a file position isn't just an offset. It also never says just
+what fpos<> is really supposed to be. [Here's my summary, which
+Jerry agrees is more or less accurate. "I think I now know what
+the class really is, at this point: it's a magic cookie that
+encapsulates an mbstate_t and a file position (possibly represented as
+an fpos_t), it has syntactic support for pointer-like arithmetic, and
+implementors are required to have real, not just syntactic, support
+for arithmetic." This isn't standardese, of course.] </p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>Not a defect. The LWG believes that the Standard is already clear,
+and that the above summary is what the Standard in effect says.</p>
+<hr>
+<a name="10"><h3>10. Codecvt<>::do unclear</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.byname"> [lib.locale.codecvt.byname]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 14 Jan 1998</p>
+<p>Section 22.2.1.5.2 says that codecvt<>::do_in and do_out
+should return the value noconv if "no conversion was
+needed". However, I don't see anything anywhere that defines what
+it means for a conversion to be needed or not needed. I can think of
+several circumstances where one might plausibly think that a
+conversion is not "needed", but I don't know which one is
+intended here. </p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>Duplicate. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#19">19</a>.</p>
+<hr>
+<a name="12"><h3>12. Way objects hold allocators unclear</h3></a><p><b>Section:</b> 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.default.con.req"> [lib.default.con.req]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 23 Feb 1998</p>
+<p>I couldn't find a statement in the standard saying whether the allocator object held by
+a container is held as a copy of the constructor argument or whether a pointer of
+reference is maintained internal. There is an according statement for compare objects and
+how they are maintained by the associative containers, but I couldn't find anything
+regarding allocators. </p>
+
+<p>Did I overlook it? Is it an open issue or known defect? Or is it deliberately left
+unspecified? </p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>Not a defect. The LWG believes that the Standard is already
+clear. See 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>, paragraph 8.</p>
+<hr>
+<a name="43"><h3>43. Locale table correction</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.byname"> [lib.locale.codecvt.byname]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Brendan Kehoe <b>Date:</b> 1 Jun 1998</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>Duplicate. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#33">33</a>.</p>
+<hr>
+<a name="45"><h3>45. Stringstreams read/write pointers initial position unclear</h3></a><p><b>Section:</b> 27.7.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostringstream"> [lib.ostringstream]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Matthias Mueller <b>Date:</b> 27 May 1998</p>
+<p>In a comp.lang.c++.moderated Matthias Mueller wrote:</p>
+
+<p>"We are not sure how to interpret the CD2 (see 27.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.forward"> [lib.iostream.forward]</a>, 27.7.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostringstream.cons"> [lib.ostringstream.cons]</a>, 27.7.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.cons"> [lib.stringbuf.cons]</a>)
+with respect to the question as to what the correct initial positions
+of the write and read pointers of a stringstream should
+be."</p>
+
+<p>"Is it the same to output two strings or to initialize the stringstream with the
+first and to output the second?"</p>
+
+<p><i>[PJ Plauger, Bjarne Stroustrup, Randy Smithey, Sean Corfield, and
+Jerry Schwarz have all offered opinions; see reflector messages
+lib-6518, 6519, 6520, 6521, 6523, 6524.]</i></p>
+
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>The LWG believes the Standard is correct as written. The behavior
+of stringstreams is consistent with fstreams, and there is a
+constructor which can be used to obtain the desired effect. This
+behavior is known to be different from strstreams.</p>
+<hr>
+<a name="58"><h3>58. Extracting a char from a wide-oriented stream</h3></a><p><b>Section:</b> 27.6.1.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 1 Jul 1998</p>
+<p>27.6.1.2.3 has member functions for extraction of signed char and
+unsigned char, both singly and as strings. However, it doesn't say
+what it means to extract a <tt>char</tt> from a
+<tt>basic_streambuf<charT, Traits></tt>. </p>
+
+<p>basic_streambuf, after all, has no members to extract a char, so
+basic_istream must somehow convert from charT to signed char or
+unsigned char. The standard doesn't say how it is to perform that
+conversion. </p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>The Standard is correct as written. There is no such extractor and
+this is the intent of the LWG.</p>
+<hr>
+<a name="65"><h3>65. Underspecification of strstreambuf::seekoff</h3></a><p><b>Section:</b> D.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 18 Aug 1998</p>
+<p>The standard says how this member function affects the current
+stream position. (<tt>gptr</tt> or <tt>pptr</tt>) However, it does not
+say how this member function affects the beginning and end of the
+get/put area. </p>
+
+<p>This is an issue when seekoff is used to position the get pointer
+beyond the end of the current read area. (Which is legal. This is
+implicit in the definition of <i>seekhigh</i> in D.7.1, paragraph 4.)
+</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>The LWG agrees that seekoff() is underspecified, but does not wish
+to invest effort in this deprecated feature.</p>
+<hr>
+<a name="67"><h3>67. Setw useless for strings</h3></a><p><b>Section:</b> 21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 9 Jul 1998</p>
+<p>In a comp.std.c++ posting Michel Michaud wrote: What
+should be output by: </p>
+
+<pre> string text("Hello");
+ cout << '[' << setw(10) << right << text << ']';
+</pre>
+
+<p>Shouldn't it be:</p>
+
+<pre> [ Hello]</pre>
+
+<p>Another person replied: Actually, according to the FDIS, the width
+of the field should be the minimum of width and the length of the
+string, so the output shouldn't have any padding. I think that this is
+a typo, however, and that what is wanted is the maximum of the
+two. (As written, setw is useless for strings. If that had been the
+intent, one wouldn't expect them to have mentioned using its value.)
+</p>
+
+<p>It's worth pointing out that this is a recent correction anyway;
+IIRC, earlier versions of the draft forgot to mention formatting
+parameters whatsoever.</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>Duplicate. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#25">25</a>.</p>
+<hr>
+<a name="72"><h3>72. Do_convert phantom member function</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.byname"> [lib.locale.codecvt.byname]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 24 Aug 1998</p>
+<p>In 22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a> par 3, and in <font color="red">22.2.1.5.2</font> par 8, a nonexistent member function
+"do_convert" is mentioned. This member was replaced with
+"do_in" and "do_out", the proper referents in the
+contexts above.</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>Duplicate: see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#24">24</a>.</p>
+<hr>
+<a name="73"><h3>73. <tt>is_open</tt> should be const</h3></a><p><b>Section:</b> 27.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstreams"> [lib.fstreams]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 27 Aug 1998</p>
+<p>Classes <tt>basic_ifstream</tt>, <tt>basic_ofstream</tt>, and
+<tt>basic_fstream</tt> all have a member function <tt>is_open</tt>. It
+should be a <tt>const</tt> member function, since it does nothing but
+call one of <tt>basic_filebuf</tt>'s const member functions. </p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>Not a defect. This is a deliberate feature; const streams would be
+meaningless.</p>
+<hr>
+<a name="77"></a><h3><a name="77">77. Valarray operator[] const returning value</a></h3><p><b>Section:</b> 26.5.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.access"> [lib.valarray.access]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Levente Farkas <b>Date:</b> 9 Sep 1998</p>
+<p>valarray:<br>
+<br>
+ <tt>T operator[] (size_t) const;</tt><br>
+<br>
+why not <br>
+<br>
+ <tt>const T& operator[] (size_t) const;</tt><br>
+<br>
+as in vector ???<br>
+<br>
+One can't copy even from a const valarray eg:<br>
+<br>
+ <tt>memcpy(ptr, &v[0], v.size() * sizeof(double));<br>
+</tt><br>
+[I] find this bug in valarray is very difficult.</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>The LWG believes that the interface was deliberately designed that
+way. That is what valarray was designed to do; that's where the
+"value array" name comes from. LWG members further comment
+that "we don't want valarray to be a full STL container."
+26.5.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.access"> [lib.valarray.access]</a> specifies properties that indicate "an
+absence of aliasing" for non-constant arrays; this allows
+optimizations, including special hardware optimizations, that are not
+otherwise possible. </p>
+<hr>
+<a name="81"><h3>81. Wrong declaration of slice operations</h3></a><p><b>Section:</b> 26.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.member.ops"> [lib.complex.member.ops]</a>, 26.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a>, 26.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.transcendentals"> [lib.complex.transcendentals]</a>, 26.3.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.cmplx.over"> [lib.cmplx.over]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
+<p>Isn't the definition of copy constructor and assignment operators wrong?
+ Instead of</p>
+
+<pre> slice_array(const slice_array&);
+ slice_array& operator=(const slice_array&);</pre>
+
+<p>IMHO they have to be</p>
+
+<pre> slice_array(const slice_array<T>&);
+ slice_array& operator=(const slice_array<T>&);</pre>
+
+<p>Same for gslice_array. </p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>Not a defect. The Standard is correct as written. </p>
+<hr>
+<a name="82"><h3>82. Missing constant for set elements</h3></a><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
+<p>Paragraph 5 specifies:</p>
+
+<blockquote>
+For set and multiset the value type is the same as the key type. For
+map and multimap it is equal to pair<const Key, T>.
+</blockquote>
+
+<p>Strictly speaking, this is not correct because for set and multiset
+the value type is the same as the <b>constant</b> key type.</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>Not a defect. The Standard is correct as written; it uses a
+different mechanism (const &) for <tt>set</tt> and
+<tt>multiset</tt>. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> for a related
+issue.</p>
+<hr>
+<a name="84"><h3>84. Ambiguity with string::insert()</h3></a><p><b>Section:</b> 21.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.modifiers"> [lib.string.modifiers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
+<p>If I try</p>
+<pre> s.insert(0,1,' ');</pre>
+
+<p> I get an nasty ambiguity. It might be</p>
+<pre> s.insert((size_type)0,(size_type)1,(charT)' ');</pre>
+
+<p>which inserts 1 space character at position 0, or</p>
+<pre> s.insert((char*)0,(size_type)1,(charT)' ')</pre>
+
+<p>which inserts 1 space character at iterator/address 0 (bingo!), or</p>
+<pre> s.insert((char*)0, (InputIterator)1, (InputIterator)' ')</pre>
+
+<p>which normally inserts characters from iterator 1 to iterator '
+'. But according to 23.1.1.9 (the "do the right thing" fix)
+it is equivalent to the second. However, it is still ambiguous,
+because of course I mean the first!</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>Not a defect. The LWG believes this is a "genetic
+misfortune" inherent in the design of string and thus not a
+defect in the Standard as such .</p>
+<hr>
+<a name="85"><h3>85. String char types</h3></a><p><b>Section:</b> 21 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.strings"> [lib.strings]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
+<p>The standard seems not to require that charT is equivalent to
+traits::char_type. So, what happens if charT is not equivalent to
+traits::char_type?</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>There is already wording in 21.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits"> [lib.char.traits]</a> paragraph 3 that
+requires them to be the same.</p>
+<hr>
+<a name="87"><h3>87. Error in description of string::compare()</h3></a><p><b>Section:</b> 21.3.6.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::compare"> [lib.string::compare]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
+<p>The following compare() description is obviously a bug:</p>
+
+<pre>int compare(size_type pos, size_type n1,
+ charT *s, size_type n2 = npos) const;
+</pre>
+
+<p>because without passing n2 it should compare up to the end of the
+string instead of comparing npos characters (which throws an
+exception) </p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>Duplicate; see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#5">5</a>.</p>
+<hr>
+<a name="88"><h3>88. Inconsistency between string::insert() and string::append()</h3></a><p><b>Section:</b> 21.3.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::insert"> [lib.string::insert]</a>, 21.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::append"> [lib.string::append]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
+<p>Why does </p>
+<pre> template<class InputIterator>
+ basic_string& append(InputIterator first, InputIterator last);</pre>
+
+<p>return a string, while</p>
+<pre> template<class InputIterator>
+ void insert(iterator p, InputIterator first, InputIterator last);</pre>
+
+<p>returns nothing ?</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>The LWG believes this stylistic inconsistency is not sufficiently
+serious to constitute a defect.</p>
+<hr>
+<a name="89"><h3>89. Missing throw specification for string::insert() and string::replace()</h3></a><p><b>Section:</b> 21.3.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::insert"> [lib.string::insert]</a>, 21.3.5.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::replace"> [lib.string::replace]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
+<p>All insert() and replace() members for strings with an iterator as
+first argument lack a throw specification. The throw
+specification should probably be: length_error if size exceeds
+maximum. </p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>Considered a duplicate because it will be solved by the resolution
+of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>.</p>
+<hr>
+<a name="93"><h3>93. Incomplete Valarray Subset Definitions</h3></a><p><b>Section:</b> 26.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.numbers"> [lib.complex.numbers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p>
+<p>You can easily create subsets, but you can't easily combine them
+with other subsets. Unfortunately, you almost always needs an
+explicit type conversion to valarray. This is because the standard
+does not specify that valarray subsets provide the same operations as
+valarrays. </p>
+
+<p>For example, to multiply two subsets and assign the result to a third subset, you can't
+write the following:</p>
+
+<pre>va[slice(0,4,3)] = va[slice(1,4,3)] * va[slice(2,4,3)];</pre>
+
+<p>Instead, you have to code as follows:</p>
+
+<pre>va[slice(0,4,3)] = static_cast<valarray<double> >(va[slice(1,4,3)]) *
+ static_cast<valarray<double> >(va[slice(2,4,3)]);</pre>
+
+<p>This is tedious and error-prone. Even worse, it costs performance because each cast
+creates a temporary objects, which could be avoided without the cast. </p>
+<p><b>Proposed resolution:</b></p>
+<p>Extend all valarray subset types so that they offer all valarray operations.</p>
+<p><b>Rationale:</b></p>
+<p>This is not a defect in the Standard; it is a request for an extension.</p>
+<hr>
+<a name="94"><h3>94. May library implementors add template parameters to Standard Library classes?</h3></a><p><b>Section:</b> 17.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.conforming"> [lib.conforming]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 22 Jan 1998</p>
+<p>Is it a permitted extension for library implementors to add template parameters to
+standard library classes, provided that those extra parameters have defaults? For example,
+instead of defining <tt>template <class T, class Alloc = allocator<T> > class
+vector;</tt> defining it as <tt>template <class T, class Alloc = allocator<T>,
+int N = 1> class vector;</tt> </p>
+
+<p>The standard may well already allow this (I can't think of any way that this extension
+could break a conforming program, considering that users are not permitted to
+forward-declare standard library components), but it ought to be explicitly permitted or
+forbidden. </p>
+
+<p>comment from Steve Cleary via comp.std.c++:</p>
+<blockquote>
+<p>I disagree [with the proposed resolution] for the following reason:
+consider user library code with template template parameters. For
+example, a user library object may be templated on the type of
+underlying sequence storage to use (deque/list/vector), since these
+classes all take the same number and type of template parameters; this
+would allow the user to determine the performance tradeoffs of the
+user library object. A similar example is a user library object
+templated on the type of underlying set storage (set/multiset) or map
+storage (map/multimap), which would allow users to change (within
+reason) the semantic meanings of operations on that object.</p>
+<p>I think that additional template parameters should be forbidden in
+the Standard classes. Library writers don't lose any expressive power,
+and can still offer extensions because additional template parameters
+may be provided by a non-Standard implementation class:</p>
+<pre>
+ template <class T, class Allocator = allocator<T>, int N = 1>
+ class __vector
+ { ... };
+ template <class T, class Allocator = allocator<T> >
+ class vector: public __vector<T, Allocator>
+ { ... };
+</pre>
+
+</blockquote>
+
+<p><b>Proposed resolution:</b></p>
+<p>Add a new subclause [presumably 17.4.4.9] following 17.4.4.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a>:</p>
+
+<blockquote>
+ <p>17.4.4.9 Template Parameters</p> <p>A specialization of a
+ template class described in the C++ Standard Library behaves the
+ same as if the implementation declares no additional template
+ parameters.</p> <p>Footnote: Additional template parameters with
+ default values are thus permitted.</p>
+</blockquote>
+
+<p>Add "template parameters" to the list of subclauses at
+the end of 17.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.conforming"> [lib.conforming]</a> paragraph 1.</p>
+
+<p><i>[Kona: The LWG agreed the standard needs clarification. After
+discussion with John Spicer, it seems added template parameters can be
+detected by a program using template-template parameters. A straw vote
+- "should implementors be allowed to add template
+parameters?" found no consensus ; 5 - yes, 7 - no.]</i></p>
+
+<p><b>Rationale:</b></p>
+<p>
+There is no ambiguity; the standard is clear as written. Library
+implementors are not permitted to add template parameters to standard
+library classes. This does not fall under the "as if" rule,
+so it would be permitted only if the standard gave explicit license
+for implementors to do this. This would require a change in the
+standard.
+</p>
+
+<p>
+The LWG decided against making this change, because it would break
+user code involving template template parameters or specializations
+of standard library class templates.
+</p>
+<hr>
+<a name="95"><h3>95. Members added by the implementation</h3></a><p><b>Section:</b> 17.4.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.member.functions"> [lib.member.functions]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p>
+<p>In 17.3.4.4/2 vs 17.3.4.7/0 there is a hole; an implementation could add virtual
+members a base class and break user derived classes.</p>
+
+<p>Example: </p>
+
+<blockquote>
+ <pre>// implementation code:
+struct _Base { // _Base is in the implementer namespace
+ virtual void foo ();
+};
+class vector : _Base // deriving from a class is allowed
+{ ... };
+
+// user code:
+class vector_checking : public vector
+{
+ void foo (); // don't want to override _Base::foo () as the
+ // user doesn't know about _Base::foo ()
+};</pre>
+</blockquote>
+<p><b>Proposed resolution:</b></p>
+<p>Clarify the wording to make the example illegal.</p>
+<p><b>Rationale:</b></p>
+<p>This is not a defect in the Standard. The example is already
+illegal. See 17.4.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.member.functions"> [lib.member.functions]</a> paragraph 2.</p>
+<hr>
+<a name="97"><h3>97. Insert inconsistent definition</h3></a><p><b>Section:</b> 23 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.containers"> [lib.containers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p>
+<p><tt>insert(iterator, const value_type&)</tt> is defined both on
+sequences and on set, with unrelated semantics: insert here (in
+sequences), and insert with hint (in associative containers). They
+should have different names (B.S. says: do not abuse overloading).</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>This is not a defect in the Standard. It is a genetic misfortune of
+the design, for better or for worse.</p>
+<hr>
+<a name="99"><h3>99. Reverse_iterator comparisons completely wrong</h3></a><p><b>Section:</b> 24.4.1.3.13 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.op=="> [lib.reverse.iter.op==]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p>
+<p>The <, >, <=, >= comparison operator are wrong: they
+return the opposite of what they should.</p>
+
+<p>Note: same problem in CD2, these were not even defined in CD1. SGI
+STL code is correct; this problem is known since the Morristown
+meeting but there it was too late</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>This is not a defect in the Standard. A careful reading shows the Standard is correct
+as written. A review of several implementations show that they implement
+exactly what the Standard says.</p>
+<hr>
+<a name="100"><h3>100. Insert iterators/ostream_iterators overconstrained</h3></a><p><b>Section:</b> 24.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.insert.iterators"> [lib.insert.iterators]</a>, 24.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.ostreambuf.iterator"> [lib.ostreambuf.iterator]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p>
+<p>Overspecified For an insert iterator it, the expression *it is
+required to return a reference to it. This is a simple possible
+implementation, but as the SGI STL documentation says, not the only
+one, and the user should not assume that this is the case.</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>The LWG believes this causes no harm and is not a defect in the
+standard. The only example anyone could come up with caused some
+incorrect code to work, rather than the other way around.</p>
+<hr>
+<a name="101"><h3>101. No way to free storage for vector and deque</h3></a><p><b>Section:</b> 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.adaptors"> [lib.container.adaptors]</a>, 23.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.array"> [lib.array]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p>
+<p>Reserve can not free storage, unlike string::reserve</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>This is not a defect in the Standard. The LWG has considered this
+issue in the past and sees no need to change the Standard. Deque has
+no reserve() member function. For vector, shrink-to-fit can be
+expressed in a single line of code (where <tt>v</tt> is
+<tt>vector<T></tt>):
+</p>
+
+<blockquote>
+ <p><tt>vector<T>(v).swap(v); // shrink-to-fit v</tt></p>
+</blockquote>
+<hr>
+<a name="102"><h3>102. Bug in insert range in associative containers</h3></a><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p>
+<p>Table 69 of Containers say that a.insert(i,j) is linear if [i, j) is ordered. It seems
+impossible to implement, as it means that if [i, j) = [x], insert in an associative
+container is O(1)!</p>
+<p><b>Proposed resolution:</b></p>
+<p>N+log (size()) if [i,j) is sorted according to value_comp()</p>
+<p><b>Rationale:</b></p>
+<p>Subsumed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a>.</p>
+<hr>
+<a name="104"><h3>104. Description of basic_string::operator[] is unclear</h3></a><p><b>Section:</b> 21.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.access"> [lib.string.access]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p>
+<p>It is not clear that undefined behavior applies when pos == size ()
+for the non const version.</p>
+<p><b>Proposed resolution:</b></p>
+<p>Rewrite as: Otherwise, if pos > size () or pos == size () and
+the non-const version is used, then the behavior is undefined.</p>
+<p><b>Rationale:</b></p>
+<p>The Standard is correct. The proposed resolution already appears in
+the Standard.</p>
+<hr>
+<a name="105"><h3>105. fstream ctors argument types desired</h3></a><p><b>Section:</b> 27.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p>
+<p>fstream ctors take a const char* instead of string.<br>
+fstream ctors can't take wchar_t</p>
+
+<p>An extension to add a const wchar_t* to fstream would make the
+implementation non conforming.</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>This is not a defect in the Standard. It might be an
+interesting extension for the next Standard. </p>
+<hr>
+<a name="107"><h3>107. Valarray constructor is strange</h3></a><p><b>Section:</b> 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex"> [lib.complex]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p>
+<p>The order of the arguments is (elem, size) instead of the normal
+(size, elem) in the rest of the library. Since elem often has an
+integral or floating point type, both types are convertible to each
+other and reversing them leads to a well formed program.</p>
+<p><b>Proposed resolution:</b></p>
+<p>Inverting the arguments could silently break programs. Introduce
+the two signatures (const T&, size_t) and (size_t, const T&),
+but make the one we do not want private so errors result in a
+diagnosed access violation. This technique can also be applied to STL
+containers.</p>
+<p><b>Rationale:</b></p>
+<p>The LWG believes that while the order of arguments is unfortunate,
+it does not constitute a defect in the standard. The LWG believes that
+the proposed solution will not work for valarray<size_t> and
+perhaps other cases.</p>
+<hr>
+<a name="111"><h3>111. istreambuf_iterator::equal overspecified, inefficient</h3></a><p><b>Section:</b> 24.5.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator::equal"> [lib.istreambuf.iterator::equal]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 15 Oct 1998</p>
+<p>The member istreambuf_iterator<>::equal is specified to be
+unnecessarily inefficient. While this does not affect the efficiency
+of conforming implementations of iostreams, because they can
+"reach into" the iterators and bypass this function, it does
+affect users who use istreambuf_iterators. </p>
+
+<p>The inefficiency results from a too-scrupulous definition, which
+requires a "true" result if neither iterator is at eof. In
+practice these iterators can only usefully be compared with the
+"eof" value, so the extra test implied provides no benefit,
+but slows down users' code. </p>
+
+<p>The solution is to weaken the requirement on the function to return
+true only if both iterators are at eof. </p>
+<p><b>Proposed resolution:</b></p>
+<p>Replace 24.5.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator::equal"> [lib.istreambuf.iterator::equal]</a>,
+paragraph 1, </p>
+
+<blockquote>
+ <p>-1- Returns: true if and only if both iterators are at end-of-stream, or neither is at
+ end-of-stream, regardless of what streambuf object they use. </p>
+</blockquote>
+
+<p>with</p>
+
+<blockquote>
+ <p>-1- Returns: true if and only if both iterators are at
+ end-of-stream, regardless of what streambuf object they use. </p>
+</blockquote>
+
+<p><b>Rationale:</b></p>
+<p>It is not clear that this is a genuine defect. Additionally, the
+LWG was reluctant to make a change that would result in
+operator== not being a equivalence relation. One consequence of
+this change is that an algorithm that's passed the range [i, i)
+would no longer treat it as an empty range.</p>
+<hr>
+<a name="113"><h3>113. Missing/extra iostream sync semantics</h3></a><p><b>Section:</b> 27.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream"> [lib.istream]</a>, 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#NAD">NAD</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 13 Oct 1998</p>
+<p>In 27.6.1.1, class basic_istream has a member function sync, described in 27.6.1.3,
+paragraph 36. </p>
+
+<p>Following the chain of definitions, I find that the various sync functions have defined
+semantics for output streams, but no semantics for input streams. On the other hand,
+basic_ostream has no sync function. </p>
+
+<p>The sync function should at minimum be added to basic_ostream, for internal
+consistency. </p>
+
+<p>A larger question is whether sync should have assigned semantics for input streams. </p>
+
+<p>Classic iostreams said streambuf::sync flushes pending output and attempts to return
+unread input characters to the source. It is a protected member function. The filebuf
+version (which is public) has that behavior (it backs up the read pointer). Class
+strstreambuf does not override streambuf::sync, and so sync can't be called on a
+strstream. </p>
+
+<p>If we can add corresponding semantics to the various sync functions, we should. If not,
+we should remove sync from basic_istream.</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>A sync function is not needed in basic_ostream because the flush function provides the
+desired functionality.</p>
+
+<p>As for the other points, the LWG finds the standard correct as written.</p>
+<hr>
+<a name="116"><h3>116. bitset cannot be constructed with a const char*</h3></a><p><b>Section:</b> 23.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 6 Nov 1998</p>
+<p>The following code does not compile with the EDG compiler:</p>
+
+<blockquote>
+ <pre>#include <bitset>
+using namespace std;
+bitset<32> b("111111111");</pre>
+</blockquote>
+
+<p>If you cast the ctor argument to a string, i.e.:</p>
+
+<blockquote>
+ <pre>bitset<32> b(string("111111111"));</pre>
+</blockquote>
+
+<p>then it will compile. The reason is that bitset has the following templatized
+constructor:</p>
+
+<blockquote>
+ <pre>template <class charT, class traits, class Allocator>
+explicit bitset (const basic_string<charT, traits, Allocator>& str, ...);</pre>
+</blockquote>
+
+<p>According to the compiler vendor, Steve Adamcyk at EDG, the user
+cannot pass this template constructor a <tt>const char*</tt> and
+expect a conversion to <tt>basic_string</tt>. The reason is
+"When you have a template constructor, it can get used in
+contexts where type deduction can be done. Type deduction basically
+comes up with exact matches, not ones involving conversions."
+</p>
+
+<p>I don't think the intention when this constructor became
+templatized was for construction from a <tt>const char*</tt> to no
+longer work.</p>
+<p><b>Proposed resolution:</b></p>
+<p>Add to 23.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a> a bitset constructor declaration</p>
+
+<blockquote>
+ <pre>explicit bitset(const char*);</pre>
+</blockquote>
+
+<p>and in Section 23.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</a> add:</p>
+
+<blockquote>
+ <pre>explicit bitset(const char* str);</pre>
+ <p>Effects: <br>
+ Calls <tt>bitset((string) str, 0, string::npos);</tt></p>
+</blockquote>
+<p><b>Rationale:</b></p>
+<p>Although the problem is real, the standard is designed that way so
+it is not a defect. Education is the immediate workaround. A future
+standard may wish to consider the Proposed Resolution as an
+extension.</p>
+<hr>
+<a name="121"><h3>121. Detailed definition for ctype<wchar_t> specialization</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#NAD">NAD</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p>
+<p>Section 22.1.1.1.1 has the following listed in Table 51: ctype<char> ,
+ctype<wchar_t>. </p>
+
+<p>Also Section 22.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype"> [lib.locale.ctype]</a> says: </p>
+
+<blockquote>
+ <p>The instantiations required in Table 51 (22.1.1.1.1) namely ctype<char> and
+ ctype<wchar_t> , implement character classing appropriate to the implementation's
+ native character set. </p>
+</blockquote>
+
+<p>However, Section 22.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.ctype.special"> [lib.facet.ctype.special]</a>
+only has a detailed description of the ctype<char> specialization, not the
+ctype<wchar_t> specialization. </p>
+<p><b>Proposed resolution:</b></p>
+<p>Add the ctype<wchar_t> detailed class description to Section
+22.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.ctype.special"> [lib.facet.ctype.special]</a>. </p>
+<p><b>Rationale:</b></p>
+<p>Specialization for wchar_t is not needed since the default is acceptable.</p>
+<hr>
+<a name="128"><h3>128. Need open_mode() function for file stream, string streams, file buffers, and string buffers</h3></a><p><b>Section:</b> 27.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.string.streams"> [lib.string.streams]</a>, 27.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 22 Feb 1999</p>
+<p>The following question came from Thorsten Herlemann:</p>
+
+<blockquote>
+ <p>You can set a mode when constructing or opening a file-stream or
+ filebuf, e.g. ios::in, ios::out, ios::binary, ... But how can I get
+ that mode later on, e.g. in my own operator << or operator
+ >> or when I want to check whether a file-stream or
+ file-buffer object passed as parameter is opened for input or output
+ or binary? Is there no possibility? Is this a design-error in the
+ standard C++ library? </p>
+</blockquote>
+
+<p>It is indeed impossible to find out what a stream's or stream
+buffer's open mode is, and without that knowledge you don't know
+how certain operations behave. Just think of the append mode. </p>
+
+<p>Both streams and stream buffers should have a <tt>mode()</tt> function that returns the
+current open mode setting. </p>
+<p><b>Proposed resolution:</b></p>
+<p>For stream buffers, add a function to the base class as a non-virtual function
+qualified as const to 27.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a>:</p>
+
+<p> <tt>openmode mode() const</tt>;</p>
+
+<p><b> Returns</b> the current open mode.</p>
+
+<p>With streams, I'm not sure what to suggest. In principle, the mode
+could already be returned by <tt>ios_base</tt>, but the mode is only
+initialized for file and string stream objects, unless I'm overlooking
+anything. For this reason it should be added to the most derived
+stream classes. Alternatively, it could be added to <tt>basic_ios</tt>
+and would be default initialized in <tt>basic_ios<>::init()</tt>.</p>
+<p><b>Rationale:</b></p>
+<p>This might be an interesting extension for some future, but it is
+not a defect in the current standard. The Proposed Resolution is
+retained for future reference.</p>
+<hr>
+<a name="131"><h3>131. list::splice throws nothing</h3></a><p><b>Section:</b> 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.special"> [lib.deque.special]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 6 Mar 1999</p>
+<p>What happens if a splice operation causes the size() of a list to grow
+beyond max_size()?</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>Size() cannot grow beyond max_size(). </p>
+<hr>
+<a name="135"><h3>135. basic_iostream doubly initialized</h3></a><p><b>Section:</b> 27.6.1.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.cons"> [lib.iostream.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 6 Mar 1999</p>
+<p>-1- Effects Constructs an object of class basic_iostream, assigning
+initial values to the base classes by calling
+basic_istream<charT,traits>(sb) (lib.istream) and
+basic_ostream<charT,traits>(sb) (lib.ostream)</p>
+
+<p>The called for basic_istream and basic_ostream constructors call
+init(sb). This means that the basic_iostream's virtual base class is
+initialized twice.</p>
+<p><b>Proposed resolution:</b></p>
+<p>Change 27.6.1.5.1, paragraph 1 to:</p>
+
+<p>-1- Effects Constructs an object of class basic_iostream, assigning
+initial values to the base classes by calling
+basic_istream<charT,traits>(sb) (lib.istream).</p>
+<p><b>Rationale:</b></p>
+<p>The LWG agreed that the <tt> init()</tt> function is called
+twice, but said that this is harmless and so not a defect in the
+standard.</p>
+<hr>
+<a name="138"><h3>138. Class ctype_byname<char> redundant and misleading</h3></a><p><b>Section:</b> 22.2.1.4 <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#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> March 18, 1999</p>
+<p>Section 22.2.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a> specifies that
+ctype_byname<char> must be a specialization of the ctype_byname
+template.</p>
+
+<p>It is common practice in the standard that specializations of class templates are only
+mentioned where the interface of the specialization deviates from the interface of the
+template that it is a specialization of. Otherwise, the fact whether or not a required
+instantiation is an actual instantiation or a specialization is left open as an
+implementation detail. </p>
+
+<p>Clause 22.2.1.4 deviates from that practice and for that reason is misleading. The
+fact, that ctype_byname<char> is specified as a specialization suggests that there
+must be something "special" about it, but it has the exact same interface as the
+ctype_byname template. Clause 22.2.1.4 does not have any explanatory value, is at best
+redundant, at worst misleading - unless I am missing anything. </p>
+
+<p>Naturally, an implementation will most likely implement ctype_byname<char> as a
+specialization, because the base class ctype<char> is a specialization with an
+interface different from the ctype template, but that's an implementation detail and need
+not be mentioned in the standard. </p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p> The standard as written is mildly misleading, but the correct fix
+is to deal with the underlying problem in the ctype_byname base class,
+not in the specialization. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>.</p>
+<hr>
+<a name="140"><h3>140. map<Key, T>::value_type does not satisfy the assignable requirement</h3></a><p><b>Section:</b> 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Mark Mitchell <b>Date:</b> 14 Apr 1999</p>
+<blockquote>
+ <p>23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a><br>
+ <br>
+ expression return type
+ pre/post-condition<br>
+ ------------- -----------
+ -------------------<br>
+ X::value_type T
+
+ T is assignable<br>
+ <br>
+ 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a><br>
+ <br>
+ A map satisfies all the requirements of a container.<br>
+ <br>
+ For a map<Key, T> ... the value_type is pair<const Key, T>.</p>
+</blockquote>
+
+<p>There's a contradiction here. In particular, `pair<const Key,
+T>' is not assignable; the `const Key' cannot be assigned
+to. So, map<Key, T>::value_type does not satisfy the
+assignable requirement imposed by a container.</p>
+
+<p><i>[See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> for the slightly related issue of
+modification of set keys.]</i></p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>The LWG believes that the standard is inconsistent, but that this
+is a design problem rather than a strict defect. May wish to
+reconsider for the next standard.</p>
+<hr>
+<a name="143"><h3>143. C .h header wording unclear</h3></a><p><b>Section:</b> D.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.c.headers"> [depr.c.headers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Christophe de Dinechin <b>Date:</b> 4 May 1999</p>
+<p>[depr.c.headers] paragraph 2 reads:</p>
+
+<blockquote>
+
+<p>Each C header, whose name has the form name.h, behaves as if each
+name placed in the Standard library namespace by the corresponding
+cname header is also placed within the namespace scope of the
+namespace std and is followed by an explicit using-declaration
+(_namespace.udecl_)</p>
+
+</blockquote>
+
+<p>I think it should mention the global name space somewhere...
+Currently, it indicates that name placed in std is also placed in
+std...</p>
+
+<p>I don't know what is the correct wording. For instance, if struct
+tm is defined in time.h, ctime declares std::tm. However, the current
+wording seems ambiguous regarding which of the following would occur
+for use of both ctime and time.h:</p>
+
+<blockquote>
+ <pre>// version 1:
+namespace std {
+ struct tm { ... };
+}
+using std::tm;
+
+// version 2:
+struct tm { ... };
+namespace std {
+ using ::tm;
+}
+
+// version 3:
+struct tm { ... };
+namespace std {
+ struct tm { ... };
+}</pre>
+</blockquote>
+
+<p>I think version 1 is intended.</p>
+
+<p><i>[Kona: The LWG agreed that the wording is not clear. It also
+agreed that version 1 is intended, version 2 is not equivalent to
+version 1, and version 3 is clearly not intended. The example below
+was constructed by Nathan Myers to illustrate why version 2 is not
+equivalent to version 1.</i></p>
+
+<p><i>Although not equivalent, the LWG is unsure if (2) is enough of
+a problem to be prohibited. Points discussed in favor of allowing
+(2):</i></p>
+
+<blockquote>
+ <ul>
+ <li><i>It may be a convenience to implementors.</i></li>
+ <li><i>The only cases that fail are structs, of which the C library
+ contains only a few.</i></li>
+ </ul>
+</blockquote>
+
+<p><i>]</i></p>
+
+<p><b>Example:</b></p>
+
+<blockquote>
+
+<pre>#include <time.h>
+#include <utility>
+
+int main() {
+ std::tm * t;
+ make_pair( t, t ); // okay with version 1 due to Koenig lookup
+ // fails with version 2; make_pair not found
+ return 0;
+}</pre>
+
+</blockquote>
+<p><b>Proposed resolution:</b></p>
+
+<p>Replace D.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.c.headers"> [depr.c.headers]</a> paragraph 2 with:</p>
+
+<blockquote>
+
+<p> Each C header, whose name has the form name.h, behaves as if each
+name placed in the Standard library namespace by the corresponding
+cname header is also placed within the namespace scope of the
+namespace std by name.h and is followed by an explicit
+using-declaration (_namespace.udecl_) in global scope.</p>
+
+</blockquote>
+
+<p><b>Rationale:</b></p>
+<p> The current wording in the standard is the result of a difficult
+compromise that averted delay of the standard. Based on discussions
+in Tokyo it is clear that there is no still no consensus on stricter
+wording, so the issue has been closed. It is suggested that users not
+write code that depends on Koenig lookup of C library functions.</p>
+<hr>
+<a name="145"><h3>145. adjustfield lacks default value</h3></a><p><b>Section:</b> 27.4.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 12 May 1999</p>
+<p>There is no initial value for the adjustfield defined, although
+many people believe that the default adjustment were right. This is a
+common misunderstanding. The standard only defines that, if no
+adjustment is specified, all the predefined inserters must add fill
+characters before the actual value, which is "as if" the
+right flag were set. The flag itself need not be set.</p>
+
+<p>When you implement a user-defined inserter you cannot rely on right
+being the default setting for the adjustfield. Instead, you must be
+prepared to find none of the flags set and must keep in mind that in
+this case you should make your inserter behave "as if" the
+right flag were set. This is surprising to many people and complicates
+matters more than necessary.</p>
+
+<p>Unless there is a good reason why the adjustfield should not be
+initialized I would suggest to give it the default value that
+everybody expects anyway.</p>
+
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>This is not a defect. It is deliberate that the default is no bits
+set. Consider Arabic or Hebrew, for example. See 22.2.2.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a> paragraph 19, Table 61 - Fill padding.</p>
+<hr>
+<a name="149"><h3>149. Insert should return iterator to first element inserted</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#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 28 Jun 1999</p>
+<p>Suppose that c and c1 are sequential containers and i is an
+iterator that refers to an element of c. Then I can insert a copy of
+c1's elements into c ahead of element i by executing </p>
+
+<blockquote>
+
+<pre>c.insert(i, c1.begin(), c1.end());</pre>
+
+</blockquote>
+
+<p>If c is a vector, it is fairly easy for me to find out where the
+newly inserted elements are, even though i is now invalid: </p>
+
+<blockquote>
+
+<pre>size_t i_loc = i - c.begin();
+c.insert(i, c1.begin(), c1.end());</pre>
+
+</blockquote>
+
+<p>and now the first inserted element is at c.begin()+i_loc and one
+past the last is at c.begin()+i_loc+c1.size().<br>
+<br>
+But what if c is a list? I can still find the location of one past the
+last inserted element, because i is still valid. To find the location
+of the first inserted element, though, I must execute something like </p>
+
+<blockquote>
+
+<pre>for (size_t n = c1.size(); n; --n)
+ --i;</pre>
+
+</blockquote>
+
+<p>because i is now no longer a random-access iterator.<br>
+<br>
+Alternatively, I might write something like </p>
+
+<blockquote>
+
+<pre>bool first = i == c.begin();
+list<T>::iterator j = i;
+if (!first) --j;
+c.insert(i, c1.begin(), c1.end());
+if (first)
+ j = c.begin();
+else
+ ++j;</pre>
+
+</blockquote>
+
+<p>which, although wretched, requires less overhead.<br>
+<br>
+But I think the right solution is to change the definition of insert
+so that instead of returning void, it returns an iterator that refers
+to the first element inserted, if any, and otherwise is a copy of its
+first argument. </p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>The LWG believes this was an intentional design decision and so is
+not a defect. It may be worth revisiting for the next standard.</p>
+<hr>
+<a name="157"><h3>157. Meaningless error handling for <tt>pword()</tt> and <tt>iword()</tt>
+</h3></a><p><b>Section:</b> 27.4.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.storage"> [lib.ios.base.storage]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
+<p>According to paragraphs 2 and 4 of 27.4.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.storage"> [lib.ios.base.storage]</a>, the
+functions <tt>iword()</tt> and <tt>pword()</tt> "set the
+<tt>badbit</tt> (which might throw an exception)" on
+failure. ... but what does it mean for <tt>ios_base</tt> to set the
+<tt>badbit</tt>? The state facilities of the IOStream library are
+defined in <tt>basic_ios</tt>, a derived class! It would be possible
+to attempt a down cast but then it would be necessary to know the
+character type used...</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>Duplicate. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#41">41</a>.</p>
+<hr>
+<a name="162"><h3>162. Really "formatted input functions"?</h3></a><p><b>Section:</b> 27.6.1.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
+<p>It appears to be somewhat nonsensical to consider the functions
+defined in the paragraphs 1 to 5 to be "Formatted input
+function" but since these functions are defined in a section
+labeled "Formatted input functions" it is unclear to me
+whether these operators are considered formatted input functions which
+have to conform to the "common requirements" from 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>: If this is the case, all manipulators, not just
+<tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is set
+(... but setting <tt>noskipws</tt> using the manipulator syntax would
+also skip whitespace :-)</p>
+
+<p>See also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#166">166</a> for the same problem in formatted
+output</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>Duplicate. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a>.</p>
+<hr>
+<a name="163"><h3>163. Return of <tt>gcount()</tt> after a call to <tt>gcount</tt>
+</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#Dup">Dup</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
+<p>It is not clear which functions are to be considered unformatted
+input functions. As written, it seems that all functions in 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> are unformatted input functions. However, it does not
+really make much sense to construct a sentry object for
+<tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is unclear what
+happens to the <tt>gcount()</tt> if eg. <tt>gcount()</tt>,
+<tt>putback()</tt>, <tt>unget()</tt>, or <tt>sync()</tt> is called:
+These functions don't extract characters, some of them even
+"unextract" a character. Should this still be reflected in
+<tt>gcount()</tt>? Of course, it could be read as if after a call to
+<tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt> (the last
+unformatted input function, <tt>gcount()</tt>, didn't extract any
+character) and after a call to <tt>putback()</tt> <tt>gcount()</tt>
+returns <tt>-1</tt> (the last unformatted input function
+<tt>putback()</tt> did "extract" back into the
+stream). Correspondingly for <tt>unget()</tt>. Is this what is
+intended? If so, this should be clarified. Otherwise, a corresponding
+clarification should be used.</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>Duplicate. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a>.</p>
+<hr>
+<a name="166"><h3>166. Really "formatted output functions"?</h3></a><p><b>Section:</b> 27.6.2.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.inserters"> [lib.ostream.inserters]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p>
+<p>From 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> it appears that all the functions
+defined in 27.6.2.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.inserters"> [lib.ostream.inserters]</a> have to construct a
+<tt>sentry</tt> object. Is this really intended?</p>
+
+<p>This is basically the same problem as issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#162">162</a> but
+for output instead of input.</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>Duplicate. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a>.</p>
+<hr>
+<a name="177"><h3>177. Complex operators cannot be explicitly instantiated</h3></a><p><b>Section:</b> 26.3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.ops"> [lib.complex.ops]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 2 Jul 1999</p>
+<p>A user who tries to explicitly instantiate a complex non-member operator will
+get compilation errors. Below is a simplified example of the reason why. The
+problem is that iterator_traits cannot be instantiated on a non-pointer type
+like float, yet when the compiler is trying to decide which operator+ needs to
+be instantiated it must instantiate the declaration to figure out the first
+argument type of a reverse_iterator operator.</p>
+<pre>namespace std {
+template <class Iterator>
+struct iterator_traits
+{
+ typedef typename Iterator::value_type value_type;
+};
+
+template <class T> class reverse_iterator;
+
+// reverse_iterator operator+
+template <class T>
+reverse_iterator<T> operator+
+(typename iterator_traits<T>::difference_type, const reverse_iterator<T>&);
+
+template <class T> struct complex {};
+
+// complex operator +
+template <class T>
+complex<T> operator+ (const T& lhs, const complex<T>& rhs)
+{ return complex<T>();}
+}
+
+// request for explicit instantiation
+template std::complex<float> std::operator+<float>(const float&,
+ const std::complex<float>&);</pre>
+<p>See also c++-stdlib reflector messages: lib-6814, 6815, 6816.</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>Implementors can make minor changes and the example will
+work. Users are not affected in any case.</p> <p>According to John
+Spicer, It is possible to explicitly instantiate these operators using
+different syntax: change "std::operator+<float>" to
+"std::operator+".</p>
+
+<p>The proposed resolution of issue 120 is that users will not be able
+to explicitly instantiate standard library templates. If that
+resolution is accepted then library implementors will be the only ones
+that will be affected by this problem, and they must use the indicated
+syntax.</p>
+<hr>
+<a name="178"><h3>178. Should clog and cerr initially be tied to cout?</h3></a><p><b>Section:</b> 27.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.narrow.stream.objects"> [lib.narrow.stream.objects]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 2 Jul 1999</p>
+<p>
+Section 27.3.1 says "After the object cerr is initialized,
+cerr.flags() & unitbuf is nonzero. Its state is otherwise the same as
+required for ios_base::init (lib.basic.ios.cons). It doesn't say
+anything about the the state of clog. So this means that calling
+cerr.tie() and clog.tie() should return 0 (see Table 89 for
+ios_base::init effects).
+</p>
+<p>
+Neither of the popular standard library implementations
+that I tried does this, they both tie cerr and clog
+to &cout. I would think that would be what users expect.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>The standard is clear as written.</p>
+<p>27.3.1/5 says that "After the object cerr is initialized, cerr.flags()
+& unitbuf is nonzero. Its state is otherwise the same as required for
+ios_base::init (27.4.4.1)." Table 89 in 27.4.4.1, which gives the
+postconditions of basic_ios::init(), says that tie() is 0. (Other issues correct
+ios_base::init to basic_ios::init().)</p>
+<hr>
+<a name="180"><h3>180. Container member iterator arguments constness has unintended consequences</h3></a><p><b>Section:</b> 23 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.containers"> [lib.containers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 1 Jul 1999</p>
+<p>It is the constness of the container which should control whether
+it can be modified through a member function such as erase(), not the
+constness of the iterators. The iterators only serve to give
+positioning information.</p>
+
+<p>Here's a simple and typical example problem which is currently very
+difficult or impossible to solve without the change proposed
+below.</p>
+
+<p>Wrap a standard container C in a class W which allows clients to
+find and read (but not modify) a subrange of (C.begin(), C.end()]. The
+only modification clients are allowed to make to elements in this
+subrange is to erase them from C through the use of a member function
+of W.</p>
+<p><b>Proposed resolution:</b></p>
+<p>Change all non-const iterator parameters of standard library
+container member functions to accept const_iterator parameters.
+Note that this change applies to all library clauses, including
+strings.</p>
+
+<p>For example, in 21.3.5.5 change:<br>
+<br>
+ <tt>iterator erase(iterator p);</tt><br>
+<br>
+to:<br>
+ <tt>iterator erase(const_iterator p);</tt>
+</p>
+<p><b>Rationale:</b></p>
+<p>The issue was discussed at length. It was generally agreed that 1)
+There is no major technical argument against the change (although
+there is a minor argument that some obscure programs may break), and
+2) Such a change would not break const correctness. The concerns about
+making the change were 1) it is user detectable (although only in
+boundary cases), 2) it changes a large number of signatures, and 3) it
+seems more of a design issue that an out-and-out defect.</p>
+
+<p>The LWG believes that this issue should be considered as part of a
+general review of const issues for the next revision of the
+standard. Also see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>.</p>
+<hr>
+<a name="188"><h3>188. valarray helpers missing augmented assignment operators</h3></a><p><b>Section:</b> 26.5.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.cassign"> [lib.valarray.cassign]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 15 Aug 1999</p>
+<p>26.5.2.6 defines augmented assignment operators
+valarray<T>::op=(const T&), but fails to provide
+corresponding versions for the helper classes. Thus making the
+following illegal:</p>
+<blockquote>
+<pre>#include <valarray>
+
+int main()
+{
+std::valarray<double> v(3.14, 1999);
+
+v[99] *= 2.0; // Ok
+
+std::slice s(0, 50, 2);
+
+v[s] *= 2.0; // ERROR
+}</pre>
+</blockquote>
+<p>I can't understand the intent of that omission. It makes the
+valarray library less intuitive and less useful.</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>Although perhaps an unfortunate
+design decision, the omission is not a defect in the current
+standard. A future standard may wish to add the missing
+operators.</p>
+<hr>
+<a name="190"><h3>190. min() and max() functions should be std::binary_functions</h3></a><p><b>Section:</b> 25.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.min.max"> [lib.alg.min.max]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Mark Rintoul <b>Date:</b> 26 Aug 1999</p>
+<p>Both std::min and std::max are defined as template functions. This
+is very different than the definition of std::plus (and similar
+structs) which are defined as function objects which inherit
+std::binary_function.<br>
+<br>
+ This lack of inheritance leaves std::min and std::max somewhat useless in standard library algorithms which require
+a function object that inherits std::binary_function.</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>Although perhaps an unfortunate design decision, the omission is not a defect
+in the current standard. A future standard may wish to consider additional
+function objects.</p>
+<hr>
+<a name="191"><h3>191. Unclear complexity for algorithms such as binary search</h3></a><p><b>Section:</b> 25.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.binary.search"> [lib.alg.binary.search]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 10 Oct 1999</p>
+<p>The complexity of binary_search() is stated as "At most
+log(last-first) + 2 comparisons", which seems to say that the
+algorithm has logarithmic complexity. However, this algorithms is
+defined for forward iterators. And for forward iterators, the need to
+step element-by-element results into linear complexity. But such a
+statement is missing in the standard. The same applies to
+lower_bound(), upper_bound(), and equal_range(). <br>
+<br>
+However, strictly speaking the standard contains no bug here. So this
+might considered to be a clarification or improvement.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>The complexity is expressed in terms of comparisons, and that
+complexity can be met even if the number of iterators accessed is
+linear. Paragraph 1 already says exactly what happens to
+iterators.</p>
+<hr>
+<a name="192"><h3>192. a.insert(p,t) is inefficient and overconstrained</h3></a><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Ed Brey <b>Date:</b> 6 Jun 1999</p>
+<p>As defined in 23.1.2, paragraph 7 (table 69), a.insert(p,t) suffers from
+several problems:</p>
+<table border="1" cellpadding="5">
+ <tbody><tr>
+ <td><b>expression</b></td>
+ <td><b>return type</b></td>
+ <td><b>pre/post-condition</b></td>
+ <td><b>complexity</b></td>
+ </tr>
+ <tr>
+ <td><tt>a.insert(p,t)</tt></td>
+ <td><tt>iterator</tt></td>
+ <td>inserts t if and only if there is no element with key equivalent to the key of
+ t in containers with unique keys; always inserts t in containers with equivalent
+ keys. always returns the iterator pointing to the element with key equivalent to
+ the key of t . iterator p is a hint pointing to where the insert should start to search.</td>
+ <td>logarithmic in general, but amortized constant if t is inserted right after p .</td>
+ </tr>
+</tbody></table>
+<p>1. For a container with unique keys, only logarithmic complexity is
+guaranteed if no element is inserted, even though constant complexity is always
+possible if p points to an element equivalent to t.</p>
+<p>2. For a container with equivalent keys, the amortized constant complexity
+guarantee is only useful if no key equivalent to t exists in the container.
+Otherwise, the insertion could occur in one of multiple locations, at least one
+of which would not be right after p.</p>
+<p>3. By guaranteeing amortized constant complexity only when t is inserted
+after p, it is impossible to guarantee constant complexity if t is inserted at
+the beginning of the container. Such a problem would not exist if amortized
+constant complexity was guaranteed if t is inserted before p, since there is
+always some p immediately before which an insert can take place.</p>
+<p>4. For a container with equivalent keys, p does not allow specification of
+where to insert the element, but rather only acts as a hint for improving
+performance. This negates the added functionality that p would provide if it
+specified where within a sequence of equivalent keys the insertion should occur.
+Specifying the insert location provides more control to the user, while
+providing no disadvantage to the container implementation.</p>
+<p><b>Proposed resolution:</b></p>
+<p>In 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 7, replace the row in table 69
+for a.insert(p,t) with the following two rows:</p>
+<table border="1" cellpadding="5">
+ <tbody><tr>
+ <td><b>expression</b></td>
+ <td><b>return type</b></td>
+ <td><b>pre/post-condition</b></td>
+ <td><b>complexity</b></td>
+ </tr>
+ <tr>
+ <td><tt>a_uniq.insert(p,t)</tt></td>
+ <td><tt>iterator</tt></td>
+ <td>inserts t if and only if there is no element with key equivalent to the
+ key of t. returns the iterator pointing to the element with key equivalent
+ to the key of t.</td>
+ <td>logarithmic in general, but amortized constant if t is inserted right
+ before p or p points to an element with key equivalent to t.</td>
+ </tr>
+ <tr>
+ <td><tt>a_eq.insert(p,t)</tt></td>
+ <td><tt>iterator</tt></td>
+ <td>inserts t and returns the iterator pointing to the newly inserted
+ element. t is inserted right before p if doing so preserves the container
+ ordering.</td>
+ <td>logarithmic in general, but amortized constant if t is inserted right
+ before p.</td>
+ </tr>
+</tbody></table>
+
+<p><b>Rationale:</b></p>
+<p>Too big a change. Furthermore, implementors report checking
+both before p and after p, and don't want to change this behavior.</p>
+<hr>
+<a name="194"><h3>194. rdbuf() functions poorly specified</h3></a><p><b>Section:</b> 27.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios"> [lib.ios]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 7 Sep 1999</p>
+<p>In classic iostreams, base class ios had an rdbuf function that returned a
+pointer to the associated streambuf. Each derived class had its own rdbuf
+function that returned a pointer of a type reflecting the actual type derived
+from streambuf. Because in ARM C++, virtual function overrides had to have the
+same return type, rdbuf could not be virtual.</p>
+<p>In standard iostreams, we retain the non-virtual rdbuf function design, and
+in addition have an overloaded rdbuf function that sets the buffer pointer.
+There is no need for the second function to be virtual nor to be implemented in
+derived classes.</p>
+<p>Minor question: Was there a specific reason not to make the original rdbuf
+function virtual?</p>
+<p>Major problem: Friendly compilers warn about functions in derived classes
+that hide base-class overloads. Any standard implementation of iostreams will
+result in such a warning on each of the iostream classes, because of the
+ill-considered decision to overload rdbuf only in a base class.</p>
+<p>In addition, users of the second rdbuf function must use explicit
+qualification or a cast to call it from derived classes. An explicit
+qualification or cast to basic_ios would prevent access to any later overriding
+version if there was one.</p>
+<p>What I'd like to do in an implementation is add a using- declaration for the
+second rdbuf function in each derived class. It would eliminate warnings about
+hiding functions, and would enable access without using explicit qualification.
+Such a change I don't think would change the behavior of any valid program, but
+would allow invalid programs to compile:</p>
+<blockquote>
+ <pre> filebuf mybuf;
+ fstream f;
+ f.rdbuf(mybuf); // should be an error, no visible rdbuf</pre>
+</blockquote>
+<p>I'd like to suggest this problem as a defect, with the proposed resolution to
+require the equivalent of a using-declaration for the rdbuf function that is not
+replaced in a later derived class. We could discuss whether replacing the
+function should be allowed.</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>For historical reasons, the standard is correct as written. There is a subtle difference between the base
+class <tt> rdbuf()</tt> and derived class <tt>rdbuf()</tt>. The derived
+class <tt> rdbuf()</tt> always returns the original streambuf, whereas the base class
+<tt> rdbuf()</tt> will return the "current streambuf" if that has been changed by the variant you mention.</p>
+
+<p>Permission is not required to add such an extension. See
+17.4.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.member.functions"> [lib.member.functions]</a>.</p>
+<hr>
+<a name="196"><h3>196. Placement new example has alignment problems</h3></a><p><b>Section:</b> 18.5.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.placement"> [lib.new.delete.placement]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Herb Sutter <b>Date:</b> 15 Dec 1998</p>
+<p>The example in 18.5.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.placement"> [lib.new.delete.placement]</a> paragraph 4 reads: </p>
+
+<blockquote>
+
+<p>[Example: This can be useful for constructing an object at a known address:<br>
+<br>
+<tt> char place[sizeof(Something)];<br>
+ Something* p = new (place) Something();<br>
+<br>
+</tt>end example] </p>
+
+</blockquote>
+
+<p>This example has potential alignment problems. </p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>Duplicate: see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a>.</p>
+<hr>
+<a name="197"><h3>197. max_size() underspecified</h3></a><p><b>Section:</b> 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.default.con.req"> [lib.default.con.req]</a>, 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#NAD">NAD</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 21 Oct 1999</p>
+<p>Must the value returned by max_size() be unchanged from call to call? </p>
+
+<p>Must the value returned from max_size() be meaningful? </p>
+
+<p>Possible meanings identified in lib-6827: </p>
+
+<p>1) The largest container the implementation can support given "best
+case" conditions - i.e. assume the run-time platform is "configured to
+the max", and no overhead from the program itself. This may possibly
+be determined at the point the library is written, but certainly no
+later than compile time.<br>
+<br>
+2) The largest container the program could create, given "best case"
+conditions - i.e. same platform assumptions as (1), but take into
+account any overhead for executing the program itself. (or, roughly
+"storage=storage-sizeof(program)"). This does NOT include any resource
+allocated by the program. This may (or may not) be determinable at
+compile time.<br>
+<br>
+3) The largest container the current execution of the program could
+create, given knowledge of the actual run-time platform, but again,
+not taking into account any currently allocated resource. This is
+probably best determined at program start-up.<br>
+<br>
+4) The largest container the current execution program could create at
+the point max_size() is called (or more correctly at the point
+max_size() returns :-), given it's current environment (i.e. taking
+into account the actual currently available resources). This,
+obviously, has to be determined dynamically each time max_size() is
+called. </p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>max_size() isn't useful for very many things, and the existing
+ wording is sufficiently clear for the few cases that max_size() can
+ be used for. None of the attempts to change the existing wording
+ were an improvement.</p>
+
+<p>It is clear to the LWG that the value returned by max_size() can't
+ change from call to call.</p>
+
+<hr>
+<a name="203"><h3>203. basic_istream::sentry::sentry() is uninstantiable with ctype<user-defined type></h3></a><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Matt McClure and Dietmar Kühl <b>Date:</b> 1 Jan 2000</p>
+<p>27.6.1.1.2 Paragraph 4 states:</p>
+<blockquote>
+ <p>To decide if the character c is a whitespace character, the constructor
+ performs ''as if'' it executes the following code fragment: </p>
+ <pre>const ctype<charT>& ctype = use_facet<ctype<charT> >(is.getloc());
+if (ctype.is(ctype.space,c)!=0)
+// c is a whitespace character.</pre>
+</blockquote>
+
+<p> But Table 51 in 22.1.1.1.1 only requires an implementation to
+provide specializations for ctype<char> and
+ctype<wchar_t>. If sentry's constructor is implemented using
+ctype, it will be uninstantiable for a user-defined character type
+charT, unless the implementation has provided non-working (since it
+would be impossible to define a correct ctype<charT> specialization
+for an arbitrary charT) definitions of ctype's virtual member
+functions.</p>
+
+<p>
+It seems the intent the standard is that sentry should behave, in
+every respect, not just during execution, as if it were implemented
+using ctype, with the burden of providing a ctype specialization
+falling on the user. But as it is written, nothing requires the
+translation of sentry's constructor to behave as if it used the above
+code, and it would seem therefore, that sentry's constructor should be
+instantiable for all character types.
+</p>
+
+<p>
+Note: If I have misinterpreted the intent of the standard with
+respect to sentry's constructor's instantiability, then a note should
+be added to the following effect:
+</p>
+
+<blockquote>
+An implementation is forbidden from using the above code if it renders
+the constructor uninstantiable for an otherwise valid character
+type.
+</blockquote>
+
+<p>In any event, some clarification is needed.</p>
+
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>It is possible but not easy to instantiate on types other than char
+or wchar_t; many things have to be done first. That is by intention
+and is not a defect.</p>
+<hr>
+<a name="204"><h3>204. distance(first, last) when "last" is before "first"</h3></a><p><b>Section:</b> 24.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.operations"> [lib.iterator.operations]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Rintala Matti <b>Date:</b> 28 Jan 2000</p>
+<p>Section 24.3.4 describes the function distance(first, last) (where first and
+last are iterators) which calculates "the number of increments or
+decrements needed to get from 'first' to 'last'".</p>
+<p>The function should work for forward, bidirectional and random access
+iterators, and there is a requirement 24.3.4.5 which states that "'last'
+must be reachable from 'first'".</p>
+<p>With random access iterators the function is easy to implement as "last
+- first".</p>
+<p>With forward iterators it's clear that 'first' must point to a place before
+'last', because otherwise 'last' would not be reachable from 'first'.</p>
+<p>But what about bidirectional iterators? There 'last' is reachable from
+'first' with the -- operator even if 'last' points to an earlier position than
+'first'. However, I cannot see how the distance() function could be implemented
+if the implementation does not know which of the iterators points to an earlier
+position (you cannot use ++ or -- on either iterator if you don't know which
+direction is the "safe way to travel").</p>
+<p>The paragraph 24.3.4.1 states that "for ... bidirectional iterators they
+use ++ to provide linear time implementations". However, the ++ operator is
+not mentioned in the reachability requirement. Furthermore 24.3.4.4 explicitly
+mentions that distance() returns the number of increments _or decrements_,
+suggesting that it could return a negative number also for bidirectional
+iterators when 'last' points to a position before 'first'.</p>
+<p>Is a further requirement is needed to state that for forward and
+bidirectional iterators "'last' must be reachable from 'first' using the ++
+operator". Maybe this requirement might also apply to random access
+iterators so that distance() would work the same way for every iterator
+category?</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>"Reachable" is defined in the standard in 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> paragraph 6.
+The definition is only in terms of operator++(). The LWG sees no defect in
+the standard.</p>
+<hr>
+<a name="205"><h3>205. numeric_limits unclear on how to determine 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#NAD">NAD</a> <b>Submitter:</b> Steve Cleary <b>Date:</b> 28 Jan 2000</p>
+<p>In several places in 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>, a member is
+described as "Meaningful for all floating point types."
+However, no clear method of determining a floating point type is
+provided.</p>
+
+<p>In 18.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.numeric.special"> [lib.numeric.special]</a>, paragraph 1 states ". . . (for
+example, epsilon() is only meaningful if is_integer is
+false). . ." which suggests that a type is a floating point type
+if is_specialized is true and is_integer is false; however, this is
+unclear.</p>
+
+<p>When clarifying this, please keep in mind this need of users: what
+exactly is the definition of floating point? Would a fixed point or
+rational representation be considered one? I guess my statement here
+is that there could also be types that are neither integer or
+(strictly) floating point.</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>It is up to the implementor of a user define type to decide if it is a
+floating point type.</p>
+<hr>
+<a name="207"><h3>207. ctype<char> members return clause incomplete</h3></a><p><b>Section:</b> 22.2.1.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Robert Klarer <b>Date:</b> 2 Nov 1999</p>
+<p>
+The <tt>widen</tt> and <tt>narrow</tt> member functions are described
+in 22.2.1.3.2, paragraphs 9-11. In each case we have two overloaded
+signatures followed by a <b>Returns</b> clause. The <b>Returns</b>
+clause only describes one of the overloads.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>Change the returns clause in 22.2.1.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a>
+paragraph 10 from:</p>
+<p> Returns: do_widen(low, high, to).</p>
+
+<p>to:</p>
+<p> Returns: do_widen(c) or do_widen(low, high, to),
+respectively.</p>
+
+<p>Change the returns clause in 22.2.1.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a> paragraph 11
+from:</p>
+<p> Returns: do_narrow(low, high, to).</p>
+
+<p>to:</p>
+<p> Returns: do_narrow(c) or do_narrow(low, high, to),
+respectively.</p>
+<p><b>Rationale:</b></p>
+<p>Subsumed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a>, which addresses the same
+paragraphs.</p>
+<hr>
+<a name="213"><h3>213. Math function overloads ambiguous</h3></a><p><b>Section:</b> 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numarray"> [lib.numarray]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 26 Feb 2000</p>
+<p>Due to the additional overloaded versions of numeric functions for
+float and long double according to Section 26.5, calls such as int x;
+std::pow (x, 4) are ambiguous now in a standard conforming
+implementation. Current implementations solve this problem very
+different (overload for all types, don't overload for float and long
+double, use preprocessor, follow the standard and get
+ambiguities).</p> <p>This behavior should be standardized or at least
+identified as implementation defined.</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>These math issues are an
+understood and accepted consequence of the design. They have
+been discussed several times in the past. Users must write casts
+or write floating point expressions as arguments.</p>
+<hr>
+<a name="215"><h3>215. Can a map's key_type be const?</h3></a><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 29 Feb 2000</p>
+<p>A user noticed that this doesn't compile with the Rogue Wave library because
+the rb_tree class declares a key_allocator, and allocator<const int> is
+not legal, I think:</p>
+<blockquote>
+ <pre>map < const int, ... > // legal?</pre>
+</blockquote>
+<p>which made me wonder whether it is legal for a map's key_type to be const. In
+email from Matt Austern he said:</p>
+<blockquote>
+<p>I'm not sure whether it's legal to declare a map with a const key type. I
+hadn't thought about that question until a couple weeks ago. My intuitive
+feeling is that it ought not to be allowed, and that the standard ought to say
+so. It does turn out to work in SGI's library, though, and someone in the
+compiler group even used it. Perhaps this deserves to be written up as an issue
+too.</p>
+</blockquote>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>The "key is assignable" requirement from table 69 in
+23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> already implies the key cannot be const.</p>
+<hr>
+<a name="216"><h3>216. setbase manipulator description flawed</h3></a><p><b>Section:</b> 27.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Hyman Rosen <b>Date:</b> 29 Feb 2000</p>
+<p>27.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a> paragraph 5 says:</p>
+<blockquote>
+<pre>smanip setbase(int base);</pre>
+<p> Returns: An object s of unspecified type such that if out is an
+(instance of) basic_ostream then the expression out<<s behaves
+as if f(s) were called, in is an (instance of) basic_istream then the
+expression in>>s behaves as if f(s) were called. Where f can be
+defined as:</p>
+<pre>ios_base& f(ios_base& str, int base)
+{
+ // set basefield
+ str.setf(n == 8 ? ios_base::oct :
+ n == 10 ? ios_base::dec :
+ n == 16 ? ios_base::hex :
+ ios_base::fmtflags(0), ios_base::basefield);
+ return str;
+}</pre>
+</blockquote>
+<p>There are two problems here. First, f takes two parameters, so the
+description needs to say that out<<s and in>>s behave as if f(s,base)
+had been called. Second, f is has a parameter named base, but is written as if
+the parameter was named n.</p>
+<p>Actually, there's a third problem. The paragraph has grammatical errors.
+There needs to be an "and" after the first comma, and the "Where
+f" sentence fragment needs to be merged into its preceding sentence. You
+may also want to format the function a little better. The formatting above is
+more-or-less what the Standard contains.</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>The resolution of this defect is subsumed by the proposed resolution for
+issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#193">193</a>.</p>
+
+<p><i>[Tokyo: The LWG agrees that this is a defect and notes that it
+occurs additional places in the section, all requiring fixes.]</i></p>
+<hr>
+<a name="218"><h3>218. Algorithms do not use binary predicate objects for default comparisons</h3></a><p><b>Section:</b> 25.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.sorting"> [lib.alg.sorting]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Pablo Halpern <b>Date:</b> 6 Mar 2000</p>
+<p>Many of the algorithms take an argument, pred, of template parameter type
+BinaryPredicate or an argument comp of template parameter type Compare. These
+algorithms usually have an overloaded version that does not take the predicate
+argument. In these cases pred is usually replaced by the use of operator== and
+comp is replaced by the use of operator<.</p>
+<p>This use of hard-coded operators is inconsistent with other parts of the
+library, particularly the containers library, where equality is established
+using equal_to<> and ordering is established using less<>. Worse,
+the use of operator<, would cause the following innocent-looking code to have
+undefined behavior:</p>
+<blockquote>
+ <pre>vector<string*> vec;
+sort(vec.begin(), vec.end());</pre>
+</blockquote>
+<p>The use of operator< is not defined for pointers to unrelated objects. If
+std::sort used less<> to compare elements, then the above code would be
+well-defined, since less<> is explicitly specialized to produce a total
+ordering of pointers.</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>This use of operator== and operator< was a very deliberate, conscious, and
+explicitly made design decision; these operators are often more efficient. The
+predicate forms are available for users who don't want to rely on operator== and
+operator<.</p>
+<hr>
+<a name="219"><h3>219. find algorithm missing version that takes a binary predicate argument</h3></a><p><b>Section:</b> 25.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.find"> [lib.alg.find]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Pablo Halpern <b>Date:</b> 6 Mar 2000</p>
+<p>The find function always searches for a value using operator== to compare the
+value argument to each element in the input iterator range. This is inconsistent
+with other find-related functions such as find_end and find_first_of, which
+allow the caller to specify a binary predicate object to be used for determining
+equality. The fact that this can be accomplished using a combination of find_if
+and bind_1st or bind_2nd does not negate the desirability of a consistent,
+simple, alternative interface to find.</p>
+<p><b>Proposed resolution:</b></p>
+<blockquote>
+<p>In section 25.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.find"> [lib.alg.find]</a>, add a second prototype for find
+(between the existing prototype and the prototype for find_if), as
+follows:</p>
+<pre> template<class InputIterator, class T, class BinaryPredicate>
+ InputIterator find(InputIterator first, InputIterator last,
+ const T& value, BinaryPredicate bin_pred);</pre>
+<p>Change the description of the return from:</p>
+<blockquote>
+ <p>Returns: The first iterator i in the range [first, last) for which the following corresponding
+ conditions hold: *i == value, pred(*i) != false. Returns last if no such iterator is found.</p>
+</blockquote>
+<p> to:</p>
+<blockquote>
+ <p>Returns: The first iterator i in the range [first, last) for which the following
+ corresponding condition holds: *i == value, bin_pred(*i,value) != false, pred(*)
+ != false. Return last if no such iterator is found.</p>
+</blockquote>
+</blockquote>
+<p><b>Rationale:</b></p>
+<p>This is request for a pure extension, so it is not a defect in the
+current standard. As the submitter pointed out, "this can
+be accomplished using a combination of find_if and bind_1st or
+bind_2nd".</p>
+<hr>
+<a name="236"><h3>236. ctype<char>::is() member modifies facet</h3></a><p><b>Section:</b> 22.2.1.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 24 Apr 2000</p>
+<p>The description of the <tt>is()</tt> member in paragraph 4 of 22.2.1.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a> is broken: According to this description, the
+second form of the <tt>is()</tt> method modifies the masks in the
+<tt>ctype</tt> object. The correct semantics if, of course, to obtain
+an array of masks. The corresponding method in the general case,
+ie. the <tt>do_is()</tt> method as described in 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> paragraph 1 does the right thing.</p>
+<p><b>Proposed resolution:</b></p>
+ <p>Change paragraph 4 from</p>
+ <blockquote>
+ The second form, for all *p in the range [low, high), assigns
+ vec[p-low] to table()[(unsigned char)*p].
+ </blockquote>
+ <p>to become</p>
+ <blockquote>
+ The second form, for all *p in the range [low, high), assigns
+ table()[(unsigned char)*p] to vec[p-low].
+ </blockquote>
+<p><b>Rationale:</b></p>
+<p>Duplicate. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#28">28</a>.</p>
+<hr>
+<a name="244"><h3>244. Must <tt>find</tt>'s third argument be CopyConstructible?</h3></a><p><b>Section:</b> 25.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.find"> [lib.alg.find]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 02 May 2000</p>
+<p>Is the following implementation of <tt>find</tt> acceptable?</p>
+
+<pre> template<class Iter, class X>
+ Iter find(Iter begin, Iter end, const X& x)
+ {
+ X x1 = x; // this is the crucial statement
+ while (begin != end && *begin != x1)
+ ++begin;
+ return begin;
+ }
+</pre>
+
+<p>If the answer is yes, then it is implementation-dependent as to
+whether the following fragment is well formed:</p>
+
+<pre> vector<string> v;
+
+ find(v.begin(), v.end(), "foo");
+</pre>
+
+<p>At issue is whether there is a requirement that the third argument
+of find be CopyConstructible. There may be no problem here, but
+analysis is necessary.</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>There is no indication in the standard that find's third argument
+is required to be Copy Constructible. The LWG believes that no such
+requirement was intended. As noted above, there are times when a user
+might reasonably pass an argument that is not Copy Constructible.</p>
+<hr>
+<a name="245"><h3>245. Which operations on <tt>istream_iterator</tt> trigger input operations?</h3></a><p><b>Section:</b> 24.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istream.iterator"> [lib.istream.iterator]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 02 May 2000</p>
+<p>I do not think the standard specifies what operation(s) on istream
+iterators trigger input operations. So, for example:</p>
+
+<pre> istream_iterator<int> i(cin);
+
+ int n = *i++;
+</pre>
+
+<p>I do not think it is specified how many integers have been read
+from cin. The number must be at least 1, of course, but can it be 2?
+More?</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>The standard is clear as written: the stream is read every time
+operator++ is called, and it is also read either when the iterator is
+constructed or when operator* is called for the first time. In the
+example above, exactly two integers are read from cin.</p>
+
+<p>There may be a problem with the interaction between istream_iterator
+and some STL algorithms, such as find. There are no guarantees about
+how many times find may invoke operator++.</p>
+<hr>
+<a name="246"><h3>246. <tt>a.insert(p,t)</tt> is incorrectly specified</h3></a><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Mark Rodgers <b>Date:</b> 19 May 2000</p>
+<p>Closed issue 192 raised several problems with the specification of
+this function, but was rejected as Not A Defect because it was too big
+a change with unacceptable impacts on existing implementations.
+However, issues remain that could be addressed with a smaller change
+and with little or no consequent impact.</p>
+
+<ol>
+ <li>
+<p> The specification is inconsistent with the original
+ proposal and with several implementations.</p>
+
+ <p>The initial implementation by Hewlett Packard only ever looked
+ immediately <i>before</i> p, and I do not believe there was any
+ intention to standardize anything other than this behavior.
+ Consequently, current implementations by several leading
+ implementors also look immediately before p, and will only insert
+ after p in logarithmic time. I am only aware of one implementation
+ that does actually look after p, and it looks before p as well. It
+ is therefore doubtful that existing code would be relying on the
+ behavior defined in the standard, and it would seem that fixing
+ this defect as proposed below would standardize existing
+ practice.</p>
+</li>
+
+ <li>
+<p>
+ The specification is inconsistent with insertion for sequence
+ containers.</p>
+
+ <p>This is difficult and confusing to teach to newcomers. All
+ insert operations that specify an iterator as an insertion location
+ should have a consistent meaning for the location represented by
+ that iterator.</p>
+</li>
+
+ <li>
+<p> As specified, there is no way to hint that the insertion
+ should occur at the beginning of the container, and the way to hint
+ that it should occur at the end is long winded and unnatural.</p>
+
+ <p>For a container containing n elements, there are n+1 possible
+ insertion locations and n+1 valid iterators. For there to be a
+ one-to-one mapping between iterators and insertion locations, the
+ iterator must represent an insertion location immediately before
+ the iterator.</p>
+</li>
+
+ <li>
+<p> When appending sorted ranges using insert_iterators,
+ insertions are guaranteed to be sub-optimal.</p>
+
+ <p>In such a situation, the optimum location for insertion is
+ always immediately after the element previously inserted. The
+ mechanics of the insert iterator guarantee that it will try and
+ insert after the element after that, which will never be correct.
+ However, if the container first tried to insert before the hint,
+ all insertions would be performed in amortized constant
+ time.</p>
+</li>
+</ol>
+<p><b>Proposed resolution:</b></p>
+<p>In 23.1.2 [lib.associative.reqmts] paragraph 7, table 69, make
+the following changes in the row for a.insert(p,t):</p>
+
+<p><i>assertion/note pre/post condition:</i>
+<br>Change the last sentence from</p>
+ <blockquote>
+ "iterator p is a hint pointing to where the insert should
+ start to search."
+ </blockquote>
+<p>to</p>
+ <blockquote>
+ "iterator p is a hint indicating that immediately before p
+ may be a correct location where the insertion could occur."
+ </blockquote>
+
+<p><i>complexity:</i><br>
+Change the words "right after" to "immediately before".</p>
+<p><b>Rationale:</b></p>
+<p>Duplicate; see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#233">233</a>.</p>
+<hr>
+<a name="249"><h3>249. Return Type of <tt>auto_ptr::operator=</tt>
+</h3></a><p><b>Section:</b> 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.unary"> [lib.meta.unary]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Joseph Gottman <b>Date:</b> 30 Jun 2000</p>
+<p>According to section 20.4.5, the function
+<tt>auto_ptr::operator=()</tt> returns a reference to an auto_ptr.
+The reason that <tt>operator=()</tt> usually returns a reference is to
+facilitate code like</p>
+
+<pre> int x,y,z;
+ x = y = z = 1;
+</pre>
+
+<p>However, given analogous code for <tt>auto_ptr</tt>s,</p>
+<pre> auto_ptr<int> x, y, z;
+ z.reset(new int(1));
+ x = y = z;
+</pre>
+
+<p>the result would be that <tt>z</tt> and <tt>y</tt> would both be set to
+NULL, instead of all the <tt>auto_ptr</tt>s being set to the same value.
+This makes such cascading assignments useless and counterintuitive for
+<tt>auto_ptr</tt>s.</p>
+<p><b>Proposed resolution:</b></p>
+<p>Change <tt>auto_ptr::operator=()</tt> to return <tt>void</tt> instead
+of an <tt>auto_ptr</tt> reference.</p>
+<p><b>Rationale:</b></p>
+<p>The return value has uses other than cascaded assignments: a user can
+call an auto_ptr member function, pass the auto_ptr to a
+function, etc. Removing the return value could break working user
+code.</p>
+<hr>
+<a name="257"><h3>257. STL functional object and iterator inheritance.</h3></a><p><b>Section:</b> 20.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.tuple.tuple"> [lib.tuple.tuple]</a>, 24.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.basic"> [lib.iterator.basic]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Robert Dick <b>Date:</b> 17 Aug 2000</p>
+<p>
+According to the November 1997 Draft Standard, the results of deleting an
+object of a derived class through a pointer to an object of its base class are
+undefined if the base class has a non-virtual destructor. Therefore, it is
+potentially dangerous to publicly inherit from such base classes.
+</p>
+
+<p>Defect:
+<br>
+The STL design encourages users to publicly inherit from a number of classes
+which do nothing but specify interfaces, and which contain non-virtual
+destructors.
+</p>
+
+<p>Attribution:
+<br>
+Wil Evers and William E. Kempf suggested this modification for functional
+objects.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+When a base class in the standard library is useful only as an interface
+specifier, i.e., when an object of the class will never be directly
+instantiated, specify that the class contains a protected destructor. This
+will prevent deletion through a pointer to the base class without performance,
+or space penalties (on any implementation I'm aware of).
+</p>
+
+<p>
+As an example, replace...
+</p>
+
+<pre> template <class Arg, class Result>
+ struct unary_function {
+ typedef Arg argument_type;
+ typedef Result result_type;
+ };
+</pre>
+
+<p>
+... with...
+</p>
+
+<pre> template <class Arg, class Result>
+ struct unary_function {
+ typedef Arg argument_type;
+ typedef Result result_type;
+ protected:
+ ~unary_function() {}
+ };
+</pre>
+
+<p>
+Affected definitions:
+<br>
+ 20.3.1 [lib.function.objects] -- unary_function, binary_function
+ <br>
+ 24.3.2 [lib.iterator.basic] -- iterator
+</p>
+<p><b>Rationale:</b></p>
+<p>
+The standard is clear as written; this is a request for change, not a
+defect in the strict sense. The LWG had several different objections
+to the proposed change. One is that it would prevent users from
+creating objects of type <tt>unary_function</tt> and
+<tt>binary_function</tt>. Doing so can sometimes be legitimate, if users
+want to pass temporaries as traits or tag types in generic code.
+</p>
+<hr>
+<a name="267"><h3>267. interaction of strstreambuf::overflow() and seekoff()</h3></a><p><b>Section:</b> D.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 5 Oct 2000</p>
+<p>
+It appears that the interaction of the strstreambuf members overflow()
+and seekoff() can lead to undefined behavior in cases where defined
+behavior could reasonably be expected. The following program
+demonstrates this behavior:
+</p>
+
+<pre> #include <strstream>
+
+ int main ()
+ {
+ std::strstreambuf sb;
+ sb.sputc ('c');
+
+ sb.pubseekoff (-1, std::ios::end, std::ios::in);
+ return !('c' == sb.sgetc ());
+ }
+</pre>
+
+<p>
+D.7.1.1, p1 initializes strstreambuf with a call to basic_streambuf<>(),
+which in turn sets all pointers to 0 in 27.5.2.1, p1.
+</p>
+
+<p>
+27.5.2.2.5, p1 says that basic_streambuf<>::sputc(c) calls
+overflow(traits::to_int_type(c)) if a write position isn't available (it
+isn't due to the above).
+</p>
+
+<p>
+D.7.1.3, p3 says that strstreambuf::overflow(off, ..., ios::in) makes at
+least one write position available (i.e., it allows the function to make
+any positive number of write positions available).
+</p>
+
+<p>
+D.7.1.3, p13 computes newoff = seekhigh - eback(). In D.7.1, p4 we see
+seekhigh = epptr() ? epptr() : egptr(), or seekhigh = epptr() in this
+case. newoff is then epptr() - eback().
+</p>
+
+<p>
+D.7.1.4, p14 sets gptr() so that gptr() == eback() + newoff + off, or
+gptr() == epptr() + off holds.
+</p>
+
+<p>
+If strstreambuf::overflow() made exactly one write position available
+then gptr() will be set to just before epptr(), and the program will
+return 0. Buf if the function made more than one write position
+available, epptr() and gptr() will both point past pptr() and the
+behavior of the program is undefined.
+</p>
+<p><b>Proposed resolution:</b></p>
+
+
+ <p>Change the last sentence of D.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.strstreambuf"> [depr.strstreambuf]</a> paragraph 4 from</p>
+
+ <blockquote>
+ Otherwise, seeklow equals gbeg and seekhigh is either pend, if
+ pend is not a null pointer, or gend.
+ </blockquote>
+
+ <p>to become</p>
+
+ <blockquote>
+ Otherwise, seeklow equals gbeg and seekhigh is either gend if
+ 0 == pptr(), or pbase() + max where max is the maximum value of
+ pptr() - pbase() ever reached for this stream.
+ </blockquote>
+
+<p><i>[
+ pre-Copenhagen: Dietmar provided wording for proposed resolution.
+]</i></p>
+
+<p><i>[
+ post-Copenhagen: Fixed a typo: proposed resolution said to fix
+ 4.7.1, not D.7.1.
+]</i></p>
+
+<p><b>Rationale:</b></p>
+<p>This is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a>: it's not clear what it
+means to seek beyond the current area. Without resolving issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a> we can't resolve this. As with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a>,
+the library working group does not wish to invest time nailing down
+corner cases in a deprecated feature.</p>
+<hr>
+<a name="269"><h3>269. cstdarg and unnamed parameters</h3></a><p><b>Section:</b> 18.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.exception"> [lib.support.exception]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> J. Stephen Adamczyk <b>Date:</b> 10 Oct 2000</p>
+<p>
+One of our customers asks whether this is valid C++:
+</p>
+
+<pre> #include <cstdarg>
+
+ void bar(const char *, va_list);
+
+ void
+ foo(const char *file, const char *, ...)
+ {
+ va_list ap;
+ va_start(ap, file);
+ bar(file, ap);
+ va_end(ap);
+ }
+</pre>
+
+<p>
+The issue being whether it is valid to use cstdarg when the final
+parameter before the "..." is unnamed. cstdarg is, as far
+as I can tell, inherited verbatim from the C standard. and the
+definition there (7.8.1.1 in the ISO C89 standard) refers to "the
+identifier of the rightmost parameter". What happens when there
+is no such identifier?
+</p>
+
+<p>
+My personal opinion is that this should be allowed, but some tweak
+might be required in the C++ standard.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>
+Not a defect, the C and C++ standards are clear. It is impossible to
+use varargs if the parameter immediately before "..." has no
+name, because that is the parameter that must be passed to va_start.
+The example given above is broken, because va_start is being passed
+the wrong parameter.
+</p>
+
+<p>
+There is no support for extending varargs to provide additional
+functionality beyond what's currently there. For reasons of C/C++
+compatibility, it is especially important not to make gratuitous
+changes in this part of the C++ standard. The C committee has already
+been requested not to touch this part of the C standard unless
+necessary.
+</p>
+<hr>
+<a name="277"><h3>277. Normative encouragement in allocator requirements unclear</h3></a><p><b>Section:</b> 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.default.con.req"> [lib.default.con.req]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 07 Nov 2000</p>
+<p>
+In 20.1.5, paragraph 5, the standard says that "Implementors are
+encouraged to supply libraries that can accept allocators that
+encapsulate more general memory models and that support non-equal
+instances." This is intended as normative encouragement to
+standard library implementors. However, it is possible to interpret
+this sentence as applying to nonstandard third-party libraries.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.1.5, paragraph 5, change "Implementors" to
+"Implementors of the library described in this International
+Standard".
+</p>
+<p><b>Rationale:</b></p>
+<p>The LWG believes the normative encouragement is already
+sufficiently clear, and that there are no important consequences
+even if it is misunderstood.</p>
+<hr>
+<a name="279"><h3>279. const and non-const iterators should have equivalent typedefs</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#NAD">NAD</a> <b>Submitter:</b> Steve Cleary <b>Date:</b> 27 Nov 2000</p>
+
+<p>
+This came from an email from Steve Cleary to Fergus in reference to
+issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>. The library working group briefly discussed
+this in Toronto and believes it should be a separate issue.
+</p>
+
+<p>
+Steve said: "We may want to state that the const/non-const iterators must have
+the same difference type, size_type, and category."
+</p>
+
+<p>
+(Comment from Judy)
+I'm not sure if the above sentence should be true for all
+const and non-const iterators in a particular container, or if it means
+the container's iterator can't be compared with the container's
+const_iterator unless the above it true. I suspect the former.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+In <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>,
+table 65, in the assertion/note pre/post condition for X::const_iterator,
+add the following:
+</p>
+
+<blockquote>
+<p>
+typeid(X::const_iterator::difference_type) == typeid(X::iterator::difference_type)
+</p>
+
+<p>
+typeid(X::const_iterator::size_type) == typeid(X::iterator::size_type)
+</p>
+
+<p>
+typeid(X::const_iterator::category) == typeid(X::iterator::category)
+</p>
+</blockquote>
+<p><b>Rationale:</b></p>
+<p>Going through the types one by one: Iterators don't have a
+<tt>size_type</tt>. We already know that the difference types are
+identical, because the container requirements already say that the
+difference types of both X::iterator and X::const_iterator are both
+X::difference_type. The standard does not require that X::iterator
+and X::const_iterator have the same iterator category, but the LWG
+does not see this as a defect: it's possible to imagine cases in which
+it would be useful for the categories to be different.</p>
+
+<p>It may be desirable to require X::iterator and X::const_iterator to
+have the same value type, but that is a new issue. (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#322">322</a>.)</p>
+
+<hr>
+<a name="287"><h3>287. conflicting ios_base fmtflags</h3></a><p><b>Section:</b> 27.4.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fmtflags.state"> [lib.fmtflags.state]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 30 Dec 2000</p>
+<p>
+The Effects clause for ios_base::setf(fmtflags fmtfl) says
+"Sets fmtfl in flags()". What happens if the user first calls
+ios_base::scientific and then calls ios_base::fixed or vice-versa?
+This is an issue for all of the conflicting flags, i.e. ios_base::left
+and ios_base::right or ios_base::dec, ios_base::hex and ios_base::oct.
+</p>
+
+<p>
+I see three possible solutions:
+</p>
+
+<ol>
+<li>Set ios_base::failbit whenever the user specifies a conflicting
+flag with one previously explicitly set. If the constructor is
+supposed to set ios_base::dec (see discussion below), then
+the user setting hex or oct format after construction will not
+set failbit. </li>
+<li>The last call to setf "wins", i.e. it clears any conflicting
+previous setting.</li>
+<li>All the flags that the user specifies are set, but when actually
+interpreting them, fixed always override scientific, right always
+overrides left, dec overrides hex which overrides oct.</li>
+</ol>
+
+<p>
+Most existing implementations that I tried seem to conform to resolution #3,
+except that when using the iomanip manipulator hex or oct then that always
+overrides dec, but calling setf(ios_base::hex) doesn't.
+</p>
+
+<p>
+There is a sort of related issue, which is that although the ios_base
+constructor says that each ios_base member has an indeterminate value
+after construction, all the existing implementations I tried explicitly set
+ios_base::dec.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>
+<tt>adjustfield</tt>, <tt>basefield</tt>, and <tt>floatfield</tt>
+are each multi-bit fields. It is possible to set multiple bits within
+each of those fields. (For example, <tt>dec</tt> and
+<tt>oct</tt>). These fields are used by locale facets. The LWG
+reviewed the way in which each of those three fields is used, and
+believes that in each case the behavior is well defined for any
+possible combination of bits. See for example Table 58, in 22.2.2.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>, noting the requirement in paragraph 6 of that
+section.
+</p>
+<p>
+Users are advised to use manipulators, or else use the two-argument
+version of <tt>setf</tt>, to avoid unexpected behavior.
+</p>
+<hr>
+<a name="289"><h3>289. <cmath> requirements missing C float and long double versions</h3></a><p><b>Section:</b> 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numarray"> [lib.numarray]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 30 Dec 2000</p>
+<p>
+ In ISO/IEC 9899:1990 Programming Languages C we find the following
+ concerning <math.h>:
+</p>
+
+<blockquote>
+ 7.13.4 Mathematics <math.h>
+ <br>
+ The names of all existing functions declared in the <math.h>
+ header, suffixed with f or l, are reserved respectively for
+ corresponding functions with float and long double arguments
+ are return values.
+</blockquote>
+
+<p>
+ For example, <tt>float sinf(float)</tt>
+ is reserved.
+</p>
+
+<p>
+ In the C99 standard, <math.h> must contain declarations
+ for these functions.
+</p>
+
+<p>
+So, is it acceptable for an implementor to add these prototypes to the
+C++ versions of the math headers? Are they required?
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Add these Functions to Table 80, section 26.5 and to Table 99,
+section C.2:
+</p>
+
+<pre> acosf asinf atanf atan2f ceilf cosf coshf
+ expf fabsf floorf fmodf frexpf ldexpf
+ logf log10f modff powf sinf sinhf sqrtf
+ tanf tanhf
+ acosl asinl atanl atan2l ceill cosl coshl
+ expl fabsl floorl fmodl frexpl ldexpl
+ logl log10l modfl powl sinl sinhl sqrtl
+ tanl tanhl
+</pre>
+
+<p>
+There should probably be a note saying that these functions
+are optional and, if supplied, should match the description in
+the 1999 version of the C standard. In the next round
+of C++ standardization they can then become mandatory.
+</p>
+<p><b>Rationale:</b></p>
+<p>The C90 standard, as amended, already permits (but does not
+require) these functions, and the C++ standard incorporates the
+C90 standard by reference. C99 is not an issue, because it is
+never referred to by the C++ standard.</p>
+<hr>
+<a name="293"><h3>293. Order of execution in transform algorithm</h3></a><p><b>Section:</b> 25.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.transform"> [lib.alg.transform]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 04 Jan 2001</p>
+<p>This issue is related to issue 242. In case that the resolution
+proposed for issue 242 is accepted, we have have the following
+situation: The 4 numeric algorithms (accumulate and consorts) as well
+as transform would allow a certain category of side effects. The
+numeric algorithms specify that they invoke the functor "for
+every iterator i in the range [first, last) in order". transform,
+in contrast, would not give any guarantee regarding order of
+invocation of the functor, which means that the functor can be invoked
+in any arbitrary order.
+</p>
+
+<p>Why would that be a problem? Consider an example: say the
+transformator that is a simple enumerator ( or more generally
+speaking, "is order-sensitive" ). Since a standard
+compliant implementation of transform is free to invoke the enumerator
+in no definite order, the result could be a garbled enumeration.
+Strictly speaking this is not a problem, but it is certainly at odds
+with the prevalent understanding of transform as an algorithms that
+assigns "a new _corresponding_ value" to the output
+elements.
+</p>
+
+<p>All implementations that I know of invoke the transformator in
+definite order, namely starting from first and proceeding to last -
+1. Unless there is an optimization conceivable that takes advantage of
+the indefinite order I would suggest to specify the order, because it
+eliminate the uncertainty that users would otherwise have regarding
+the order of execution of their potentially order-sensitive function
+objects.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>In section 25.2.3 - Transform [lib.alg.transform] change:</p>
+<blockquote>
+-1- Effects: Assigns through every iterator i in the range [result,
+result + (last1 - first1)) a new corresponding
+value equal to op(*(first1 + (i - result)) or binary_op(*(first1 +
+(i - result), *(first2 + (i - result))).
+</blockquote>
+<p>to:</p>
+<blockquote>
+-1- Effects: Computes values by invoking the operation op or binary_op
+for every iterator in the range [first1, last1) in order. Assigns through
+every iterator i in the range [result, result + (last1 - first1)) a new
+corresponding
+value equal to op(*(first1 + (i - result)) or binary_op(*(first1 +
+(i - result), *(first2 + (i - result))).
+</blockquote>
+<p><b>Rationale:</b></p>
+<p>For Input Iterators an order is already guaranteed, because
+only one order is possible. If a user who passes a Forward
+Iterator to one of these algorithms really needs a specific
+order of execution, it's possible to achieve that effect by
+wrapping it in an Input Iterator adaptor.</p>
+<hr>
+<a name="296"><h3>296. Missing descriptions and requirements of pair operators</h3></a><p><b>Section:</b> 20.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.pairs"> [lib.pairs]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 14 Jan 2001</p>
+<p>The synopsis of the header <tt><utility></tt> in 20.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.utility"> [lib.utility]</a>
+lists the complete set of equality and relational operators for <tt>pair</tt>
+but the section describing the template and the operators only describes
+<tt>operator==()</tt> and <tt>operator<()</tt>, and it fails to mention
+any requirements on the template arguments. The remaining operators are
+not mentioned at all.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>20.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.operators"> [lib.operators]</a> paragraph 10 already specifies the semantics.
+That paragraph says that, if declarations of operator!=, operator>,
+operator<=, and operator>= appear without definitions, they are
+defined as specified in 20.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.operators"> [lib.operators]</a>. There should be no user
+confusion, since that paragraph happens to immediately precede the
+specification of <tt>pair</tt>.</p>
+<hr>
+<a name="302"><h3>302. Need error indication from codecvt<>::do_length</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.byname"> [lib.locale.codecvt.byname]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Gregory Bumgardner <b>Date:</b> 25 Jan 2001</p>
+<p>
+The effects of <tt>codecvt<>::do_length()</tt> are described in
+22.2.1.5.2, paragraph 10. As implied by that paragraph, and clarified
+in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#75">75</a>, <tt>codecvt<>::do_length()</tt> must
+process the source data and update the <tt>stateT</tt> argument just
+as if the data had been processed by <tt>codecvt<>::in()</tt>.
+However, the standard does not specify how <tt>do_length()</tt> would
+report a translation failure, should the source sequence contain
+untranslatable or illegal character sequences.
+</p>
+
+<p>
+The other conversion methods return an "error" result value
+to indicate that an untranslatable character has been encountered, but
+<tt>do_length()</tt> already has a return value (the number of source
+characters that have been processed by the method).
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+This issue cannot be resolved without modifying the interface. An exception
+cannot be used, as there would be no way to determine how many characters
+have been processed and the state object would be left in an indeterminate
+state.
+</p>
+
+<p>
+A source compatible solution involves adding a fifth argument to length()
+and do_length() that could be used to return position of the offending
+character sequence. This argument would have a default value that would
+allow it to be ignored:
+</p>
+
+<pre> int length(stateT& state,
+ const externT* from,
+ const externT* from_end,
+ size_t max,
+ const externT** from_next = 0);
+
+ virtual
+ int do_length(stateT& state,
+ const externT* from,
+ const externT* from_end,
+ size_t max,
+ const externT** from_next);
+</pre>
+
+<p>
+Then an exception could be used to report any translation errors and
+the from_next argument, if used, could then be used to retrieve the
+location of the offending character sequence.
+</p>
+<p><b>Rationale:</b></p>
+<p>The standard is already clear: the return value is the number of
+"valid complete characters". If it encounters an invalid sequence of
+external characters, it stops.</p>
+<hr>
+<a name="304"><h3>304. Must <tt>*a</tt> return an lvalue when <tt>a</tt> is an input iterator?</h3></a><p><b>Section:</b> 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 5 Feb 2001</p>
+<p>
+We all "know" that input iterators are allowed to produce
+values when dereferenced of which there is no other in-memory copy.
+</p>
+
+<p>
+But: Table 72, with a careful reading, seems to imply that this can only be
+the case if the value_type has no members (e.g. is a built-in type).
+</p>
+
+<p>The problem occurs in the following entry:</p>
+
+<pre> a->m pre: (*a).m is well-defined
+ Equivalent to (*a).m
+</pre>
+
+<p>
+<tt>*a.m</tt> can be well-defined if <tt>*a</tt> is not a reference
+type, but since <tt>operator->()</tt> must return a pointer for
+<tt>a->m</tt> to be well-formed, it needs something to return a
+pointer <i>to</i>. This seems to indicate that <tt>*a</tt> must be
+buffered somewhere to make a legal input iterator.
+</p>
+
+<p>I don't think this was intentional.</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>The current standard is clear and consistent. Input iterators that
+ return rvalues are in fact implementable. They may in some cases
+ require extra work, but it is still possible to define an operator->
+ in such cases: it doesn't have to return a T*, but may return a
+ proxy type. No change to the standard is justified.</p>
+<hr>
+<a name="313"><h3>313. set_terminate and set_unexpected question</h3></a><p><b>Section:</b> 18.7.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.terminate"> [lib.terminate]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 3 Apr 2001</p>
+<p>
+According to section 18.7.3.3 of the standard, std::terminate() is
+supposed to call the terminate_handler in effect immediately after
+evaluating the throw expression.
+</p>
+
+<p>
+Question: what if the terminate_handler in effect is itself
+std::terminate?
+</p>
+
+<p>For example:</p>
+
+<pre> #include <exception>
+
+ int main () {
+ std::set_terminate(std::terminate);
+ throw 5;
+ return 0;
+ }
+</pre>
+
+<p>
+Is the implementation allowed to go into an infinite loop?
+</p>
+
+<p>
+I think the same issue applies to std::set_unexpected.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>Infinite recursion is to be expected: users who set the terminate
+handler to <tt>terminate</tt> are explicitly asking for <tt>terminate</tt>
+to call itself.</p>
+<hr>
+<a name="314"><h3>314. Is the stack unwound when terminate() is called?</h3></a><p><b>Section:</b> 18.7.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.terminate"> [lib.terminate]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Detlef Vollmann <b>Date:</b> 11 Apr 2001</p>
+
+<p>
+The standard appears to contradict itself about whether the stack is
+unwound when the implementation calls terminate().
+</p>
+
+<p>From 18.7.3.3p2:</p>
+<blockquote>
+ Calls the terminate_handler function in effect immediately
+ after evaluating the throw-expression (lib.terminate.handler),
+ if called by the implementation [...]
+</blockquote>
+
+<p>So the stack is guaranteed not to be unwound.</p>
+
+<p>But from 15.3p9:</p>
+<blockquote>
+ [...]whether or not the stack is unwound before this call
+ to terminate() is implementation-defined (except.terminate).
+</blockquote>
+
+<p>
+And 15.5.1 actually defines that in most cases the stack is unwound.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>There is definitely no contradiction between the core and library
+clauses; nothing in the core clauses says that stack unwinding happens
+after <tt>terminate</tt> is called. 18.7.3.3p2 does not say anything
+about when terminate() is called; it merely specifies which
+<tt>terminate_handler</tt> is used.</p>
+<hr>
+<a name="323"><h3>323. abs() overloads in different headers</h3></a><p><b>Section:</b> 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numarray"> [lib.numarray]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 4 June 2001</p>
+<p>Currently the standard mandates the following overloads of
+abs():</p>
+
+<pre> abs(long), abs(int) in <cstdlib>
+
+ abs(float), abs(double), abs(long double) in <cmath>
+
+ template<class T> T abs(const complex<T>&) in <complex>
+
+ template<class T> valarray<T> abs(const valarray<T>&); in <valarray>
+</pre>
+
+<p>
+The problem is that having only some overloads visible of a function
+that works on "implicitly inter-convertible" types is dangerous in
+practice. The headers that get included at any point in a translation
+unit can change unpredictably during program
+development/maintenance. The wrong overload might be unintentionally
+selected.
+</p>
+
+<p>
+Currently, there is nothing that mandates the simultaneous visibility
+of these overloads. Indeed, some vendors have begun fastidiously
+reducing dependencies among their (public) headers as a QOI issue: it
+helps people to write portable code by refusing to compile unless all
+the correct headers are #included.
+</p>
+
+<p>The same issue may exist for other functions in the library.</p>
+
+<p>Redmond: PJP reports that C99 adds two new kinds of abs: complex,
+and int_max_abs.</p>
+
+<p>Related issue: <font color="red">343</font>.</p>
+
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>The programs that could potentially be broken by this situation are
+ already fragile, and somewhat contrived: For example, a user-defined
+ class that has conversion overloads both to <tt>long</tt> and
+ to <tt>float</tt>. If <tt>x</tt> is a value of such a class, then
+ <tt>abs(x)</tt> would give the <tt>long</tt> version if the user
+ included <cstdlib>, the <tt>float</tt> version if the user
+ included <cmath>, and would be diagnosed as ambiguous at
+ compile time if the user included both headers. The LWG couldn't
+ find an example of a program whose meaning would be changed (as
+ opposed to changing it from well-formed to ill-formed) simply by
+ adding another standard header.</p>
+
+<p>Since the harm seems minimal, and there don't seem to be any simple
+ and noninvasive solutions, this is being closed as NAD. It is
+ marked as "Future" for two reasons. First, it might be useful to
+ define an <tt><all></tt> header that would include all
+ Standard Library headers. Second, we should at least make sure that
+ future library extensions don't make this problem worse.</p>
+<hr>
+<a name="326"><h3>326. Missing typedef in moneypunct_byname</h3></a><p><b>Section:</b> 22.2.6.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.moneypunct.byname"> [lib.locale.moneypunct.byname]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 05 Jul 2001</p>
+<p>The definition of the moneypunct facet contains the typedefs char_type
+and string_type. Only one of these names, string_type, is defined in
+the derived facet, moneypunct_byname.</p>
+<p><b>Proposed resolution:</b></p>
+<p>For consistency with the numpunct facet, add a typedef for
+char_type to the definition of the moneypunct_byname facet in
+22.2.6.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.moneypunct.byname"> [lib.locale.moneypunct.byname]</a>.</p>
+<p><b>Rationale:</b></p>
+<p>The absence of the typedef is irrelevant. Users can still access
+the typedef, because it is inherited from the base class.</p>
+<hr>
+<a name="330"><h3>330. Misleading "exposition only" value in class locale definition</h3></a><p><b>Section:</b> 22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 15 Jul 2001</p>
+<p>
+The "exposition only" value of the std::locale::none constant shown in
+the definition of class locale is misleading in that it on many
+systems conflicts with the value assigned to one if the LC_XXX
+constants (specifically, LC_COLLATE on AIX, LC_ALL on HP-UX, LC_CTYPE
+on Linux and SunOS). This causes incorrect behavior when such a
+constant is passed to one of the locale member functions that accept a
+locale::category argument and interpret it as either the C LC_XXX
+constant or a bitmap of locale::category values. At least three major
+implementations adopt the suggested value without a change and
+consequently suffer from this problem.
+</p>
+
+<p>
+For instance, the following code will (presumably) incorrectly copy facets
+belonging to the collate category from the German locale on AIX:
+</p>
+
+<pre> std::locale l (std::locale ("C"), "de_DE", std::locale::none);
+</pre>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>The LWG agrees that it may be difficult to implement locale member
+functions in such a way that they can take either <tt>category</tt>
+arguments or the LC_ constants defined in <cctype>. In light of
+this requirement (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>, paragraph 2), and in light
+of the requirement in the preceding paragraph that it is possible to
+combine <tt>category</tt> bitmask elements with bitwise operations,
+defining the <tt>category</tt> elements is delicate,
+particularly if an implementor is constrained to work with a
+preexisting C library. (Just using the existing LC_ constants would
+not work in general.) There's no set of "exposition only" values that
+could give library implementors proper guidance in such a delicate
+matter. The non-normative example we're giving is no worse than
+any other choice would be.</p>
+
+<p>See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#347">347</a>.</p>
+<hr>
+<a name="332"><h3>332. Consider adding increment and decrement operators to std::fpos< T > </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#NAD">NAD</a> <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 27 Aug 2001</p>
+<p>
+Increment and decrement operators are missing from
+Table 88 -- Position type requirements in 27.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos"> [lib.fpos]</a>.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Table 88 (section 27.4.3) -- Position type requirements
+be updated to include increment and decrement operators.
+</p>
+
+<pre>expression return type operational note
+
+++p fpos& p += O(1)
+p++ fpos { P tmp = p;
+ ++p;
+ return tmp; }
+--p fpos& p -= O(1)
+p-- fpos { P tmp = p;
+ --p;
+ return tmp; }
+</pre>
+
+<p><b>Rationale:</b></p>
+<p>The LWG believes this is a request for extension, not a defect
+report. Additionally, nobody saw a clear need for this extension;
+<tt>fpos</tt> is used only in very limited ways.</p>
+<hr>
+<a name="344"><h3>344. grouping + showbase</h3></a><p><b>Section:</b> 22.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.category.numeric"> [lib.category.numeric]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 13 Oct 2001</p>
+<p>
+When both grouping and showbase are active and the basefield is octal,
+does the leading 0 participate in the grouping or not? For example,
+should one format as: 0,123,456 or 0123,456?
+</p>
+<p>
+An analogy can be drawn with hexadecimal. It appears that 0x123,456 is
+preferred over 0x,123,456. However, this analogy is not universally
+accepted to apply to the octal base. The standard is not clear on how
+to format (or parse) in this manner.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Insert into 22.2.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a> paragraph 3, just before the last
+sentence:
+</p>
+<blockquote>
+The leading hexadecimal base specifier "0x" does not participate in
+grouping. The leading '0' octal base specifier may participate in
+grouping. It is unspecified if the leading '0' participates in
+formatting octal numbers. In parsing octal numbers, the implementation
+is encouraged to accept both the leading '0' participating in the
+grouping, and not participating (e.g. 0123,456 or 0,123,456).
+</blockquote>
+<p><b>Rationale:</b></p>
+<p>
+The current behavior may be unspecified, but it's not clear that it
+matters. This is an obscure corner case, since grouping is usually
+intended for the benefit of humans and oct/hex prefixes are usually
+intended for the benefit of machines. There is not a strong enough
+consensus in the LWG for action.
+</p>
+<hr>
+<a name="348"></a><h3><a name="348">348. Minor issue with std::pair operator<</a></h3><p><b>Section:</b> 20.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.pairs"> [lib.pairs]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 23 Oct 2001</p>
+<p>
+The current wording of 20.2.2 [lib.pairs] p6 precludes the use of
+operator< on any pair type which contains a pointer.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>In 20.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.pairs"> [lib.pairs]</a> paragraph 6, replace:</p>
+<pre> Returns: x.first < y.first || (!(y.first < x.first) && x.second <
+ y.second).
+</pre>
+<p>With:</p>
+<pre> Returns: std::less<T1>()( x.first, y.first ) ||
+ (!std::less<T1>()( y.first, x.first) &&
+ std::less<T2>()( x.second, y.second ) )
+</pre>
+
+<p><b>Rationale:</b></p>
+<p>This is an instance of a much more general problem. If we want
+ operator< to translate to std::less for pairs of pointers, where
+ do we draw the line? The same issue applies to individual
+ pointers, smart pointer wrappers, std::vector<T*>, and so
+ on.</p>
+
+<p>Andy Koenig suggests that the real issue here is that we aren't
+ distinguishing adequately between two different orderings, a
+ "useful ordering" and a "canonical ordering" that's used just
+ because we sometimes need <i>some</i> ordering without caring much
+ which ordering it is. Another example of the later is typeinfo's
+ <tt>before</tt>.</p>
+
+<hr>
+<a name="350"><h3>350. allocator<>::address</h3></a><p><b>Section:</b> 20.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a>, 20.1.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>, 17.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.contents"> [lib.contents]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 25 Oct 2001</p>
+<p>See c++std-lib-9006 and c++std-lib-9007. This issue is taken
+verbatim from -9007.</p>
+
+<p>
+The core language feature allowing definition of operator&() applied
+to any non-builtin type makes that operator often unsafe to use in
+implementing libraries, including the Standard Library. The result
+is that many library facilities fail for legal user code, such as
+the fragment</p>
+<pre> class A { private: A* operator&(); };
+ std::vector<A> aa;
+
+ class B { };
+ B* operator&(B&) { return 0; }
+ std::vector<B> ba;
+</pre>
+
+<p>
+In particular, the requirements table for Allocator (Table 32) specifies
+no semantics at all for member address(), and allocator<>::address is
+defined in terms of unadorned operator &.
+</p>
+
+<p><b>Proposed resolution:</b></p>
+<p>
+In 20.6.1.1, Change the definition of allocator<>::address from:</p>
+<blockquote>
+ Returns: &x
+</blockquote>
+
+<p>to:</p>
+
+<p>
+ Returns: The value that the built in operator&(x) would return if not
+ overloaded.
+</p>
+
+<p>
+In 20.1.6, Table 32, add to the Notes column of the a.address(r) and
+a.address(s) lines, respectively:
+</p>
+
+<pre> allocator<T>::address(r)
+ allocator<T>::address(s)
+</pre>
+
+<p>In addition, in clause 17.4.1.1, add a statement:</p>
+
+<blockquote>
+ The Standard Library does not apply operator& to any type for which
+ operator& may be overloaded.
+</blockquote>
+
+<p><b>Rationale:</b></p>
+<p>The LWG believes both examples are ill-formed. The contained type
+is required to be CopyConstructible (20.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.copyconstructible"> [lib.copyconstructible]</a>), and that
+includes the requirement that &t return the usual types and
+values. Since allocators are intended to be used in conjunction with
+containers, and since the CopyConstructible requirements appear to
+have been written to deal with the concerns of this issue, the LWG
+feels it is NAD unless someone can come up with a well-formed example
+exhibiting a problem.</p>
+
+<p>It may well be that the CopyConstructible requirements are too
+ restrictive and that either the container requirements or the
+ CopyConstructive requirements should be relaxed, but that's a far
+ larger issue. Marking this issue as "future" as a pointer to that
+ larger issue.</p>
+<hr>
+<a name="351"><h3>351. unary_negate and binary_negate: struct or class?</h3></a><p><b>Section:</b> 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.tuple"> [lib.tuple]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Dale Riley <b>Date:</b> 12 Nov 2001</p>
+<p>
+In 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.tuple"> [lib.tuple]</a> the header <functional> synopsis declares
+the unary_negate and binary_negate function objects as struct.
+However in <font color="red">20.3.5</font> the unary_negate and binary_negate
+function objects are defined as class. Given the context, they are
+not "basic function objects" like negate, so this is either a typo or
+an editorial oversight.
+</p>
+
+<p><i>[Taken from comp.std.c++]</i></p>
+<p><b>Proposed resolution:</b></p>
+<p>Change the synopsis to reflect the useage in <font color="red">20.3.5</font></p>
+
+<p><i>[Curaçao: Since the language permits "struct", the LWG
+views this as NAD. They suggest, however, that the Project Editor
+might wish to make the change as editorial.]</i></p>
+
+<hr>
+<a name="353"><h3>353. <tt>std::pair</tt> missing template assignment</h3></a><p><b>Section:</b> 20.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.pairs"> [lib.pairs]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2 Dec 2001</p>
+<p>
+The class template <tt>std::pair</tt> defines a template ctor (20.2.2, p4) but
+no template assignment operator. This may lead to inefficient code since
+assigning an object of <tt>pair<C, D></tt> to <tt>pair<A, B></tt>
+where the types <tt>C</tt> and <tt>D</tt> are distinct from but convertible to
+<tt>A</tt> and <tt>B</tt>, respectively, results in a call to the template copy
+ctor to construct an unnamed temporary of type <tt>pair<A, B></tt>
+followed by an ordinary (perhaps implicitly defined) assignment operator,
+instead of just a straight assignment.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Add the following declaration to the definition of <tt>std::pair</tt>:
+</p>
+<pre> template<class U, class V>
+ pair& operator=(const pair<U, V> &p);
+</pre>
+<p>
+And also add a paragraph describing the effects of the function template to the
+end of 20.2.2:
+</p>
+<pre> template<class U, class V>
+ pair& operator=(const pair<U, V> &p);
+</pre>
+<p>
+ <b>Effects</b>: <tt>first = p.first;</tt>
+ <tt>second = p.second;</tt>
+ <b>Returns</b>: <tt>*this</tt>
+</p>
+
+<p><i>[Curaçao: There is no indication this is was anything other than
+a design decision, and thus NAD. May be appropriate for a future
+standard.]</i></p>
+
+<hr>
+<a name="356"><h3>356. Meaning of ctype_base::mask enumerators</h3></a><p><b>Section:</b> 22.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 23 Jan 2002</p>
+
+<p>What should the following program print?</p>
+
+<pre> #include <locale>
+ #include <iostream>
+
+ class my_ctype : public std::ctype<char>
+ {
+ typedef std::ctype<char> base;
+ public:
+ my_ctype(std::size_t refs = 0) : base(my_table, false, refs)
+ {
+ std::copy(base::classic_table(), base::classic_table() + base::table_size,
+ my_table);
+ my_table[(unsigned char) '_'] = (base::mask) (base::print | base::space);
+ }
+ private:
+ mask my_table[base::table_size];
+ };
+
+ int main()
+ {
+ my_ctype ct;
+ std::cout << "isspace: " << ct.is(std::ctype_base::space, '_') << " "
+ << "isalpha: " << ct.is(std::ctype_base::alpha, '_') << std::endl;
+ }
+</pre>
+
+<p>The goal is to create a facet where '_' is treated as whitespace.</p>
+
+<p>On gcc 3.0, this program prints "isspace: 1 isalpha: 0". On
+Microsoft C++ it prints "isspace: 1 isalpha: 1".</p>
+
+<p>
+I believe that both implementations are legal, and the standard does not
+give enough guidance for users to be able to use std::ctype's
+protected interface portably.</p>
+
+<p>
+The above program assumes that ctype_base::mask enumerators like
+<tt>space</tt> and <tt>print</tt> are disjoint, and that the way to
+say that a character is both a space and a printing character is to or
+those two enumerators together. This is suggested by the "exposition
+only" values in 22.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a>, but it is nowhere specified in
+normative text. An alternative interpretation is that the more
+specific categories subsume the less specific. The above program
+gives the results it does on the Microsoft compiler because, on that
+compiler, <tt>print</tt> has all the bits set for each specific
+printing character class.
+</p>
+
+<p>From the point of view of std::ctype's public interface, there's no
+important difference between these two techniques. From the point of
+view of the protected interface, there is. If I'm defining a facet
+that inherits from std::ctype<char>, I'm the one who defines the
+value that table()['a'] returns. I need to know what combination of
+mask values I should use. This isn't so very esoteric: it's exactly
+why std::ctype has a protected interface. If we care about users
+being able to write their own ctype facets, we have to give them a
+portable way to do it.
+</p>
+
+<p>
+Related reflector messages:
+lib-9224, lib-9226, lib-9229, lib-9270, lib-9272, lib-9273, lib-9274,
+lib-9277, lib-9279.
+</p>
+
+<p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a> is related, but not identical. The
+proposed resolution if issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a> says that
+ctype_base::mask must be a bitmask type. It does not say that the
+ctype_base::mask elements are bitmask elements, so it doesn't
+directly affect this issue.</p>
+
+<p>More comments from Benjamin Kosnik, who believes that
+that C99 compatibility essentially requires what we're
+calling option 1 below.</p>
+
+<blockquote>
+<pre>I think the C99 standard is clear, that isspace -> !isalpha.
+--------
+
+#include <locale>
+#include <iostream>
+
+class my_ctype : public std::ctype<char>
+{
+private:
+ typedef std::ctype<char> base;
+ mask my_table[base::table_size];
+
+public:
+ my_ctype(std::size_t refs = 0) : base(my_table, false, refs)
+ {
+ std::copy(base::classic_table(), base::classic_table() + base::table_size,
+ my_table);
+ mask both = base::print | base::space;
+ my_table[static_cast<mask>('_')] = both;
+ }
+};
+
+int main()
+{
+ using namespace std;
+ my_ctype ct;
+ cout << "isspace: " << ct.is(ctype_base::space, '_') << endl;
+ cout << "isprint: " << ct.is(ctype_base::print, '_') << endl;
+
+ // ISO C99, isalpha iff upper | lower set, and !space.
+ // 7.5, p 193
+ // -> looks like g++ behavior is correct.
+ // 356 -> bitmask elements are required for ctype_base
+ // 339 -> bitmask type required for mask
+ cout << "isalpha: " << ct.is(ctype_base::alpha, '_') << endl;
+}
+</pre>
+</blockquote>
+
+<p><b>Proposed resolution:</b></p>
+<p>Informally, we have three choices:</p>
+<ol>
+<li>Require that the enumerators are disjoint (except for alnum and
+graph)</li>
+<li>Require that the enumerators are not disjoint, and specify which
+of them subsume which others. (e.g. mandate that lower includes alpha
+and print)</li>
+<li>Explicitly leave this unspecified, which the result that the above
+program is not portable.</li>
+</ol>
+
+<p>Either of the first two options is just as good from the standpoint
+of portability. Either one will require some implementations to
+change.</p>
+<p><b>Rationale:</b></p>
+<p>The LWG agrees that this is a real ambiguity, and that both
+interpretations are conforming under the existing standard. However,
+there's no evidence that it's causing problems for real users. Users
+who want to define ctype facets portably can test the ctype_base masks
+to see which interpretation is being used.</p>
+<hr>
+<a name="357"><h3>357. <cmath> float functions cannot return HUGE_VAL</h3></a><p><b>Section:</b> 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numarray"> [lib.numarray]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 26 Feb 2002</p>
+<p>
+The float versions of the math functions have no meaningful value to return
+for a range error. The long double versions have a value they can return,
+but it isn't necessarily the most reasonable value.
+</p>
+
+<p>
+Section 26.5 [lib.c.math], paragraph 5, says that C++ "adds float and long
+double overloaded versions of these functions, with the same semantics,"
+referring to the math functions from the C90 standard.
+</p>
+
+<p>
+The C90 standard, in section 7.5.1, paragraph 3, says that functions return
+"the value of the macro HUGE_VAL" when they encounter a range error.
+Section 7.5, paragraph 2, defines HUGE_VAL as a macro that "expands to a
+positive double expression, not necessarily representable as a float."
+</p>
+
+<p>
+Therefore, the float versions of the math functions have no way to
+signal a range error. <i>[Curaçao: The LWG notes that this isn't
+strictly correct, since errno is set.]</i> The semantics require that they
+return HUGE_VAL, but they cannot because HUGE_VAL might not be
+representable as a float.
+</p>
+
+<p>
+The problem with long double functions is less severe because HUGE_VAL is
+representable as a long double. On the other hand, it might not be a "huge"
+long double value, and might fall well within the range of normal return
+values for a long double function. Therefore, it does not make sense for a
+long double function to return a double (HUGE_VAL) for a range error.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>Curaçao: C99 was faced with a similar problem, which they fixed by
+adding HUGE_VALF and HUGE_VALL in addition to HUGE_VAL.</p>
+
+<p>C++ must also fix, but it should be done in the context of the
+general C99 based changes to C++, not via DR. Thus the LWG in Curaçao
+felt the resolution should be NAD, FUTURE, but the issue is being held
+open for one more meeting to ensure LWG members not present during the
+discussion concur.</p>
+<p><b>Rationale:</b></p>
+<p>Will be fixed as part of more general work in the TR.</p>
+<hr>
+<a name="361"><h3>361. num_get<>::do_get (..., void*&) checks grouping</h3></a><p><b>Section:</b> 22.2.2.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 12 Mar 2002</p>
+<p>
+22.2.2.2.2, p12 specifies that <tt>thousands_sep</tt> is to be inserted only
+for integral types (issue 282 suggests that this should be done for
+all arithmetic types).
+</p>
+
+<p>
+22.2.2.1.2, p12 requires that grouping be checked for all extractors
+including that for <tt>void*</tt>.
+</p>
+
+<p>
+I don't think that's right. <tt>void*</tt> values should not be checked for
+grouping, should they? (Although if they should, then <tt>num_put</tt> needs
+to write them out, otherwise their extraction will fail.)
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the first sentence of 22.2.2.2.2, p12 from
+</p>
+<blockquote>
+ Digit grouping is checked. That is, the positions of discarded
+ separators is examined for consistency with
+ use_facet<numpunct<charT> >(loc).grouping().
+ If they are not consistent then ios_base::failbit is assigned
+ to err.
+</blockquote>
+
+<p>to</p>
+<blockquote>
+ Except for conversions to void*, digit grouping is checked...
+</blockquote>
+
+<p><b>Rationale:</b></p>
+<p>This would be a change: as it stands, the standard clearly
+ specifies that grouping applies to void*. A survey of existing
+ practice shows that most existing implementations do that, as they
+ should.</p>
+<hr>
+<a name="366"><h3>366. Excessive const-qualification</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#NAD">NAD</a> <b>Submitter:</b> Walter Brown, Marc Paterno <b>Date:</b> 10 May 2002</p>
+<p>
+The following member functions are declared const, yet return non-const
+pointers. We believe they are should be changed, because they allow code
+that may surprise the user. See document N1360 for details and
+rationale.
+</p>
+
+<p><i>[Santa Cruz: the real issue is that we've got const member
+functions that return pointers to non-const, and N1360 proposes
+replacing them by overloaded pairs. There isn't a consensus about
+whether this is a real issue, since we've never said what our
+constness policy is for iostreams. N1360 relies on a distinction
+between physical constness and logical constness; that distinction, or
+those terms, does not appear in the standard.]</i></p>
+
+<p><b>Proposed resolution:</b></p>
+<p>In 27.4.4 and 27.4.4.2</p>
+<p>Replace</p>
+<pre> basic_ostream<charT,traits>* tie() const;
+</pre>
+<p>with</p>
+<pre> basic_ostream<charT,traits>* tie();
+ const basic_ostream<charT,traits>* tie() const;
+</pre>
+
+<p>and replace</p>
+<pre> basic_streambuf<charT,traits>* rdbuf() const;
+</pre>
+<p>with</p>
+<pre> basic_streambuf<charT,traits>* rdbuf();
+ const basic_streambuf<charT,traits>* rdbuf() const;
+</pre>
+
+<p>In 27.5.2 and 27.5.2.3.1</p>
+<p>Replace</p>
+<pre> char_type* eback() const;
+</pre>
+<p>with</p>
+<pre> char_type* eback();
+ const char_type* eback() const;
+</pre>
+
+<p>Replace</p>
+<pre> char_type gptr() const;
+</pre>
+<p>with</p>
+<pre> char_type* gptr();
+ const char_type* gptr() const;
+</pre>
+
+<p>Replace</p>
+<pre> char_type* egptr() const;
+</pre>
+<p>with</p>
+<pre> char_type* egptr();
+ const char_type* egptr() const;
+</pre>
+
+<p>In 27.5.2 and 27.5.2.3.2</p>
+<p>Replace</p>
+<pre> char_type* pbase() const;
+</pre>
+<p>with</p>
+<pre> char_type* pbase();
+ const char_type* pbase() const;
+</pre>
+
+<p>Replace</p>
+<pre> char_type* pptr() const;
+</pre>
+<p>with</p>
+<pre> char_type* pptr();
+ const char_type* pptr() const;
+</pre>
+
+<p>Replace</p>
+<pre> char_type* epptr() const;
+</pre>
+<p>with</p>
+<pre> char_type* epptr();
+ const char_type* epptr() const;
+</pre>
+
+<p>In 27.7.2, 27.7.2.2, 27.7.3 27.7.3.2, 27.7.4, and 27.7.6</p>
+<p>Replace</p>
+<pre> basic_stringbuf<charT,traits,Allocator>* rdbuf() const;
+</pre>
+<p>with</p>
+<pre> basic_stringbuf<charT,traits,Allocator>* rdbuf();
+ const basic_stringbuf<charT,traits,Allocator>* rdbuf() const;
+</pre>
+
+<p>In 27.8.1.5, 27.8.1.7, 27.8.1.8, 27.8.1.10, 27.8.1.11, and 27.8.1.13</p>
+<p>Replace</p>
+<pre> basic_filebuf<charT,traits>* rdbuf() const;
+</pre>
+<p>with</p>
+<pre> basic_filebuf<charT,traits>* rdbuf();
+ const basic_filebuf<charT,traits>* rdbuf() const;
+</pre>
+<p><b>Rationale:</b></p>
+<p>The existing specification is a bit sloppy, but there's no
+ particular reason to change this other than tidiness, and there are
+ a number of ways in which streams might have been designed
+ differently if we were starting today. There's no evidence that the
+ existing constness policy is harming users. We might consider
+ a different constness policy as part of a full stream redesign.</p>
+<hr>
+<a name="367"><h3>367. remove_copy/remove_copy_if and Input Iterators</h3></a><p><b>Section:</b> 25.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.remove"> [lib.alg.remove]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Anthony Williams <b>Date:</b> 13 May 2002</p>
+<p>
+remove_copy and remove_copy_if (25.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.remove"> [lib.alg.remove]</a>) permit their
+input range to be marked with Input Iterators. However, since two
+operations are required against the elements to copy (comparison and
+assigment), when the input range uses Input Iterators, a temporary
+copy must be taken to avoid dereferencing the iterator twice. This
+therefore requires the value type of the InputIterator to be
+CopyConstructible. If the iterators are at least Forward Iterators,
+then the iterator can be dereferenced twice, or a reference to the
+result maintained, so the temporary is not required.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Add "If InputIterator does not meet the requirements of forward
+iterator, then the value type of InputIterator must be copy
+constructible. Otherwise copy constructible is not required." to
+25.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.remove"> [lib.alg.remove]</a> paragraph 6.
+</p>
+<p><b>Rationale:</b></p>
+<p>The assumption is that an input iterator can't be dereferenced
+ twice. There's no basis for that assumption in the Standard.</p>
+<hr>
+<a name="368"><h3>368. basic_string::replace has two "Throws" paragraphs</h3></a><p><b>Section:</b> 21.3.5.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::replace"> [lib.string::replace]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 3 Jun 2002</p>
+<p>
+21.3.5.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::replace"> [lib.string::replace]</a> basic_string::replace, second
+signature, given in paragraph 1, has two "Throws" paragraphs (3 and
+5).
+</p>
+
+<p>
+In addition, the second "Throws" paragraph (5) includes specification
+(beginning with "Otherwise, the function replaces ...") that should be
+part of the "Effects" paragraph.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>This is editorial. Both "throws" statements are true. The bug is
+ just that the second one should be a sentence, part of the "Effects"
+ clause, not a separate "Throws". The project editor has been
+ notified.</p>
+<hr>
+<a name="372"><h3>372. Inconsistent description of stdlib exceptions</h3></a><p><b>Section:</b> 17.4.4.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a>, 18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.type.info"> [lib.type.info]</a>, <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Randy Maddox <b>Date:</b> 22 Jul 2002</p>
+
+<p>Paragraph 3 under clause 17.4.4.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a>, Restrictions on
+Exception Handling, states that "Any other functions defined in the
+C++ Standard Library that do not have an exception-specification may
+throw implementation-defined exceptions unless otherwise specified."
+This statement is followed by a reference to footnote 178 at the
+bottom of that page which states, apparently in reference to the C++
+Standard Library, that "Library implementations are encouraged (but
+not required) to report errors by throwing exceptions from (or derived
+from) the standard exceptions."</p>
+
+<p>These statements appear to be in direct contradiction to clause
+18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.type.info"> [lib.type.info]</a>, which states "The class exception defines the
+base class for the types of objects thrown as exceptions by the C++
+Standard library components ...".</p>
+
+<p>Is this inconsistent?</p>
+
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>Clause 17 is setting the overall library requirements, and it's
+ clear and consistent. This sentence from Clause 18 is descriptive,
+ not setting a requirement on any other class.
+</p>
+<hr>
+<a name="374"><h3>374. moneypunct::frac_digits returns int not unsigned</h3></a><p><b>Section:</b> 22.2.6.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.moneypunct.members"> [lib.locale.moneypunct.members]</a>, 22.2.6.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.moneypunct.virtuals"> [lib.locale.moneypunct.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 8 Aug 2002</p>
+<p>
+In section 22.2.6.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.moneypunct.members"> [lib.locale.moneypunct.members]</a>, frac_digits() returns type
+"int". This implies that frac_digits() might return a negative value,
+but a negative value is nonsensical. It should return "unsigned".
+</p>
+
+<p>
+Similarly, in section 22.2.6.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.moneypunct.virtuals"> [lib.locale.moneypunct.virtuals]</a>, do_frac_digits()
+should return "unsigned".
+</p>
+
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>Regardless of whether the return value is int or unsigned, it's
+always conceivable that frac_digits might return a nonsensical
+value. (Is 4294967295 really any better than -1?) The clients of
+moneypunct, the get and put facets, can and do perform range
+checks.</p>
+<hr>
+<a name="377"><h3>377. basic_string::insert and length_error</h3></a><p><b>Section:</b> 21.3.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::insert"> [lib.string::insert]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 16 Aug 2002</p>
+<p>
+Section 21.3.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::insert"> [lib.string::insert]</a>, paragraph 4, contains the following,
+"Then throws length_error if size() >= npos - rlen."
+</p>
+
+<p>
+Related to DR 83, this sentence should probably be removed.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>This requirement is redundant but correct. No change is
+needed.</p>
+<hr>
+<a name="378"><h3>378. locale immutability and locale::operator=()</h3></a><p><b>Section:</b> 22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 6 Sep 2002</p>
+<p>
+I think there is a problem with 22.1.1, p6 which says that
+</p>
+<pre> -6- An instance of locale is immutable; once a facet reference
+ is obtained from it, that reference remains usable as long
+ as the locale value itself exists.
+</pre>
+<p>
+and 22.1.1.2, p4:
+</p>
+<pre> const locale& operator=(const locale& other) throw();
+
+ -4- Effects: Creates a copy of other, replacing the current value.
+</pre>
+<p>
+How can a reference to a facet obtained from a locale object remain
+valid after an assignment that clearly must replace all the facets
+in the locale object? Imagine a program such as this
+</p>
+<pre> std::locale loc ("de_DE");
+ const std::ctype<char> &r0 = std::use_facet<std::ctype<char> >(loc);
+ loc = std::locale ("en_US");
+ const std::ctype<char> &r1 = std::use_facet<std::ctype<char> >(loc);
+</pre>
+<p>
+Is r0 really supposed to be preserved and destroyed only when loc goes
+out of scope?
+</p>
+<p><b>Proposed resolution:</b></p>
+<p><i>[Summer '04 mid-meeting mailing: Martin and Dietmar believe this
+ is a duplicate of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a> and recommend that it be
+ closed.
+]</i></p>
+
+<hr>
+<a name="388"><h3>388. Use of complex as a key in associative containers</h3></a><p><b>Section:</b> 26.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.cfenv"> [lib.cfenv]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 8 Nov 2002</p>
+<p>
+Practice with std::complex<> and the associative containers
+occasionally reveals artificial and distracting issues with constructs
+resembling: std::set<std::complex<double> > s;
+</p>
+
+<p>
+The main reason for the above to fail is the absence of an approriate
+definition for std::less<std::complex<T> >. That in turn comes from
+the definition of the primary template std::less<> in terms of
+operator<.
+</p>
+
+<p>
+The usual argument goes as follows: Since there is no ordering over
+the complex field compatible with field operations it makes little
+sense to define a function operator< operating on the datatype
+std::complex<T>. That is fine. However, that reasoning does not carry
+over to std::less<T> which is used, among other things, by associative
+containers as an ordering useful to meet complexity requirements.
+</p>
+
+<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>.</p>
+
+<p><b>Proposed resolution:</b></p>
+<p>Informally: Add a specialization of std::less for std::complex.</p>
+<p><b>Rationale:</b></p>
+<p>Discussed in Santa Cruz. An overwhelming majority of the LWG
+believes this should not be treated a DR: it's a request for a design
+change, not a defect in the existing standard. Most people (10-3)
+believed that we probably don't want this change, period: as with
+issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, it's hard to know where to draw the line.
+The LWG noted that users who want to put objects into an associative
+container for which <tt>operator<</tt> isn't defined can simply
+provide their own comparison function object.</p>
+<hr>
+<a name="390"><h3>390. CopyConstructible requirements too strict</h3></a><p><b>Section:</b> 20.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.copyconstructible"> [lib.copyconstructible]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Doug Gregor <b>Date:</b> 24 Oct 2002</p>
+<p>
+The CopyConstructible requirements in Table 30 state that for an
+object t of type T (where T is CopyConstructible), the expression &t
+returns the address of t (with type T*). This requirement is overly
+strict, in that it disallows types that overload operator& to not
+return a value of type T*. This occurs, for instance, in the <a href="http://www.boost.org/libs/lambda">Boost.Lambda</a> library, where
+operator& is overloaded for a Boost.Lambda function object to return
+another function object.
+</p>
+
+<p>Example:</p>
+
+<pre> std::vector<int> u, v;
+ int x;
+ // ...
+ std::transform(u.begin(), u.end(), std::back_inserter(v), _1 * x);
+</pre>
+
+<p>
+_1 * x returns an unnamed function object with operator& overloaded to
+not return T* , therefore rendering the std::transform call ill-formed.
+However, most standard library implementations will compile this code
+properly, and the viability of such binder libraries is severely hindered
+by the unnecessary restriction in the CopyConstructible requirements.
+</p>
+
+<p>
+For reference, the address of an object can be retrieved without using
+the address-of operator with the following function template:
+</p>
+
+<pre> template <typename T> T* addressof(T& v)
+ {
+ return reinterpret_cast<T*>(
+ &const_cast<char&>(reinterpret_cast<const volatile char &>(v)));
+ }
+</pre>
+
+<p>
+Note: this relates directly to library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, which
+will need to be reexamined if the CopyConstructible requirements
+change.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Remove the last two rows of Table 30, eliminating the requirements
+that &t and &u return the address of t and u, respectively.
+</p>
+<p><b>Rationale:</b></p>
+<p>This was a deliberate design decision. Perhaps it should be
+ reconsidered for C++0x. </p>
+<hr>
+<a name="392"><h3>392. 'equivalence' for input iterators</h3></a><p><b>Section:</b> 24.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Corwin Joy <b>Date:</b> 11 Dec 2002</p>
+
+<p>
+In section 24.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a> table 72 -
+'Input Iterator Requirements' we have as a postcondition of *a:
+"If a==b and (a, b) is in the domain of == then *a is equivalent to *b".
+</p>
+
+<p>
+In section 24.5.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator::equal"> [lib.istreambuf.iterator::equal]</a> it states that
+"istreambuf_iterator::equal returns true if and only if both iterators
+are at end-of-stream, or neither is at end-of-stream, <i>regardless of
+what streambuf object they use</i>." (My emphasis).
+</p>
+
+<p>
+The defect is that either 'equivalent' needs to be more precisely
+defined or the conditions for equality in 24.5.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator::equal"> [lib.istreambuf.iterator::equal]</a>
+are incorrect. (Or both).
+</p>
+
+<p>Consider the following example:</p>
+<pre> #include <iostream>
+ #include <fstream>
+ #include <iterator>
+ using namespace std;
+
+ int main() {
+ ifstream file1("file1.txt"), file2("file2.txt");
+ istreambuf_iterator<char> f1(file1), f2(file2);
+ cout << "f1 == f2 : " << boolalpha << (f1 == f2) << endl;
+ cout << "f1 = " << *f1 << endl;
+ cout << "f2 = " << *f2 << endl;
+ return 0;
+ }
+</pre>
+
+<p>Now assuming that neither f1 or f2 are at the end-of-stream then
+f1 == f2 by 24.5.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator::equal"> [lib.istreambuf.iterator::equal]</a>.</p>
+
+<p>However, it is unlikely that *f1 will give the same value as *f2 except
+by accident.</p>
+
+<p>So what does *f1 'equivalent' to *f2 mean? I think the standard should
+be clearer on this point, or at least be explicit that this does not
+mean that *f1 and *f2 are required to have the same value in the case
+of input iterators.</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>The two iterators aer not in the domain of ==</p>
+<hr>
+<a name="399"><h3>399. volations of unformatted input function requirements</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#NAD">NAD</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 5 Jan 2003</p>
+ <p>
+The Effects clauses for the two functions below violate the
+general requirements on unformatted input functions outlined
+in 27.6.1.3: they do not begin by constructing a sentry object.
+Instead, they begin by calling widen ('\n'), which may throw
+an exception. The exception is then allowed to propagate from
+the unformatted input function irrespective of the setting of
+exceptions().
+ </p>
+ <p>
+Note that in light of 27.6.1.1, p3 and p4, the fact that the
+functions allow exceptions thrown from widen() to propagate
+may not strictly speaking be a defect (but the fact that the
+functions do not start by constructing a sentry object still
+is). However, since an exception thrown from ctype<charT>
+::widen() during any other input operation (say, from within
+a call to num_get<charT>::get()) will be caught and cause
+badbit to be set, these two functions should not be treated
+differently for the sake of consistency.
+ </p>
+ <p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>
+Not a defect. The standard is consistent, and the behavior required
+by the standard is unambiguous. Yes, it's theoretically possible for
+widen to throw. (Not that this will happen for the default ctype
+facet or for most real-world replacement ctype facets.) Users who
+define ctype facets that can throw, and who care about this behavior,
+can use alternative signatures that don't call widen.
+</p>
+<hr>
+<a name="429"><h3>429. typo in basic_ios::clear(iostate)</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#Dup">Dup</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p>
+ <p>
+
+The Effects clause in 27.4.4.3, p5 describing the effects of a call to
+the ios_base member function clear(iostate state) says that the function
+only throws if the respective bits are already set prior to the function
+call. That's obviously not the intent. If it was, a call to clear(badbit)
+on an object for which (rdstate() == goodbit && exceptions() == badbit)
+holds would not result in an exception being thrown.
+
+ </p>
+ <p><b>Proposed resolution:</b></p>
+ <p>
+
+The text ought to be changed from
+<br>
+
+"If (rdstate() & exceptions()) == 0, returns. ..."
+<br>
+
+to
+<br>
+
+"If (state & exceptions()) == 0, returns. ..."
+ </p>
+<p><b>Rationale:</b></p>
+<p>This is a duplicate of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#412">412</a>.</p>
+<hr>
+<a name="433"><h3>433. Contradiction in specification of unexpected()</h3></a><p><b>Section:</b> 18.7.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.unexpected"> [lib.unexpected]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Vyatcheslav Sysoltsev <b>Date:</b> 29 Sep 2003</p>
+<p>
+Clause 15.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/except.html#except.unexpected"> [except.unexpected]</a> paragraph 1 says that "void unexpected();
+is called (18.7.2) immediately after completing the stack unwinding
+for the former function", but 18.7.2.4 (Effects) says that "void
+unexpected(); . . . Calls the unexpected_handler function in effect
+immediately after evaluating the throwexpression (18.7.2.2),". Isn't
+here a contradiction: 15.5.2 requires stack have been unwound when in
+void unexpected() and therefore in unexpected_handler but 18.7.2.4
+claims that unexpected_handler is called "in effect immediately" after
+evaluation of throw expression is finished, so there is no space left
+for stack to be unwound therefore? I think the phrase "in effect
+immediately" should be removed from the standard because it brings
+ambiguity in understanding.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>There is no contradiction. The phrase "in effect immediately" is
+ just to clarify which handler is to be called.</p>
+<hr>
+<a name="437"><h3>437. Formatted output of function pointers is confusing</h3></a><p><b>Section:</b> 27.6.2.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.inserters.arithmetic"> [lib.ostream.inserters.arithmetic]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Ivan Godard <b>Date:</b> 24 Oct 2003</p>
+<p>
+Given:
+</p>
+<pre>void f(int) {}
+void(*g)(int) = f;
+cout << g;
+</pre>
+
+<p>
+(with the expected #include and usings), the value printed is a rather
+surprising "true". Rather useless too.
+</p>
+
+<p>The standard defines:</p>
+
+<pre>ostream& operator<<(ostream&, void*);</pre>
+
+<p>which picks up all data pointers and prints their hex value, but does
+not pick up function pointers because there is no default conversion
+from function pointer to void*. Absent that, we fall back to legacy
+conversions from C and the function pointer is converted to bool.
+</p>
+
+<p>There should be an analogous inserter that prints the address of a
+ function pointer.</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>This is indeed a wart, but there is no good way to solve it. C
+ doesn't provide a portable way of outputting the address of a
+ function point either.</p>
+<hr>
+<a name="439"><h3>439. Should facets be copyable?</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#NAD">NAD</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 2 Nov 2003</p>
+<p>The following facets classes have no copy constructors described in
+ the standard, which, according to the standard, means that they are
+ supposed to use the compiler-generated defaults. Default copy
+ behavior is probably inappropriate. We should either make these
+ classes uncopyable or else specify exactly what their constructors do.</p>
+
+<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#421">421</a>.</p>
+
+<pre> ctype_base
+ ctype
+ ctype_byname
+ ctype<char>
+ ctype_byname<char>
+ codecvt_base
+ codecvt
+ codecvt_byname
+ num_get
+ num_put
+ numpunct
+ numpunct_byname
+ collate
+ collate_byname
+ time_base
+ time_get
+ time_get_byname
+ time_put
+ time_put_byname
+ money_get
+ money_put
+ money_base
+ moneypunct
+ moneypunct_byname
+ messages_base
+ messages
+ messages_byname
+</pre>
+
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>The copy constructor in the base class is private.</p>
+<hr>
+<a name="440"></a><h3><a name="440">440. Should std::complex use unqualified transcendentals?</a></h3><p><b>Section:</b> 26.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.transcendentals"> [lib.complex.transcendentals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 5 Nov 2003</p>
+<p>
+Operations like <tt>pow</tt> and <tt>exp</tt> on
+<tt>complex<T></tt> are typically implemented in terms of
+operations like <tt>sin</tt> and <tt>cos</tt> on <tt>T</tt>.
+Should implementations write this as <tt>std::sin</tt>, or as plain
+unqualified <tt>sin</tt>?
+</p>
+
+<p>The issue, of course, is whether we want to use
+argument-dependent lookup in the case where <tt>T</tt> is a
+user-defined type. This is similar to the issue of valarray
+transcendentals, as discussed in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>.</p>
+
+<p>This issue differs from valarray transcendentals in two important
+ways. First, "the effect of instantiating the template
+<tt>complex</tt> for types other than float, double or long double is
+unspecified." (26.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>) Second, the standard does not
+dictate implementation, so there is no guarantee that a particular
+real math function is used in the implementation of a particular
+complex function.</p>
+
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>If you instantiate std::complex for user-defined types, all bets
+are off.</p>
+<hr>
+<a name="447"><h3>447. Wrong template argument for time facets</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#Dup">Dup</a> <b>Submitter:</b> Pete Becker <b>Date:</b> 26 Dec 2003</p>
+<p>
+22.1.1.1.1/4, table 52, "Required Instantiations", lists, among others:
+</p>
+<pre> time_get<char,InputIterator>
+ time_get_byname<char,InputIterator>
+ time_get<wchar_t,OutputIterator>
+ time_get_byname<wchar_t,OutputIterator>
+</pre>
+
+<p>
+The second argument to the last two should be InputIterator, not
+OutputIterator.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Change the second template argument to InputIterator.
+</p>
+<p><b>Rationale:</b></p>
+Duplicate of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#327">327</a>
+<hr>
+<a name="450"><h3>450. set::find is inconsistent with associative container requirements</h3></a><p><b>Section:</b> 23.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.set"> [lib.set]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 30 Jan 2004</p>
+<p>map/multimap have:</p>
+
+<pre> iterator find(const key_type& x) const;
+ const_iterator find(const key_type& x) const;
+</pre>
+
+<p>
+which is consistent with the table of associative container requirements.
+But set/multiset have:
+</p>
+<pre> iterator find(const key_type&) const;
+</pre>
+
+<p>
+set/multiset should look like map/multimap, and honor the requirements
+table, in this regard.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>Duplicate of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#214">214</a>.</p>
+<hr>
+<a name="451"><h3>451. Associative erase should return an iterator</h3></a><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, 23.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative"> [lib.associative]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 30 Jan 2004</p>
+<p>map/multimap/set/multiset have:</p>
+<pre> void erase(iterator);
+ void erase(iterator, iterator);
+</pre>
+
+<p>But there's no good reason why these can't return an iterator, as for
+vector/deque/list:</p>
+<pre> iterator erase(iterator);
+ iterator erase(iterator, iterator);
+</pre>
+
+<p><b>Proposed resolution:</b></p>
+<p>
+Informally: The table of associative container requirements, and the
+relevant template classes, should return an iterator designating the
+first element beyond the erased subrange.
+</p>
+<p><b>Rationale:</b></p>
+<p>Duplicate of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a></p>
+<hr>
+<a name="452"><h3>452. locale::combine should be permitted to generate a named locale</h3></a><p><b>Section:</b> 22.1.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.members"> [lib.locale.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 30 Jan 2004</p>
+<pre>template<class Facet>
+ locale::combine(const locale&) const;
+</pre>
+<p>
+is obliged to create a locale that has no name. This is overspecification
+and overkill. The resulting locale should follow the usual rules -- it
+has a name if the locale argument has a name and Facet is one of the
+standard facets.
+</p>
+
+<p><i>[
+ Sydney and post-Sydney (see c++std-lib-13439, c++std-lib-13440,
+ c++std-lib-13443): agreed that it's overkill to say that the locale
+ is obligated to be nameless. However, we also can't require it to
+ have a name. At the moment, locale names are based on categories
+ and not on individual facets. If a locale contains two different
+ facets of different names from the same category, then this would
+ not fit into existing naming schemes. We need to give
+ implementations more freedom. Bill will provide wording.
+]</i></p>
+
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>After further discussion the LWG decided to close this as NAD.
+ The fundamental problem is that names right now are per-category,
+ not per-facet. The <tt>combine</tt> member function works at the
+ wrong level of granularity.</p>
+<hr>
+<a name="472"><h3>472. Missing "Returns" clause in std::equal_range</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#Dup">Dup</a> <b>Submitter:</b> Prateek R Karandikar <b>Date:</b> 29 Feb 1900</p>
+<p>
+There is no "Returns:" clause for std::equal_range, which returns non-void.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>Fixed as part of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a>.</p>
+<hr>
+<a name="476"><h3>476. Forward Iterator implied mutability</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#NAD">NAD</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 9 Jul 2004</p>
+
+<p>24.1/3 says:</p>
+<blockquote>
+ Forward iterators satisfy all the requirements of the input and
+ output iterators and can be used whenever either kind is specified
+</blockquote>
+
+<p>
+The problem is that satisfying the requirements of output iterator
+means that you can always assign *something* into the result of
+dereferencing it. That makes almost all non-mutable forward
+iterators non-conforming. I think we need to sever the refinement
+relationship between forward iterator and output iterator.
+</p>
+
+<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>. But this is not a dup.</p>
+
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>Yes, 24.1/3 does say that. But it's introductory material. The
+precise specification is in 24.1.3, and the requrements table there is
+right. We don't need to fine-tune introductory wording. (Especially
+since this wording is likely to be changed as part of the iterator
+overhaul.)</p>
+<hr>
+<a name="477"><h3>477. Operator-> for const forward iterators</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#Dup">Dup</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 first line is exactly right. The second line is wrong. Basically
+it implies that the const-ness of the iterator affects the const-ness
+of referenced members. But 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>AFAICT if we need the second line at all, it should read the same
+as the first line.</p>
+
+<p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a></p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>The LWG agrees that this is a real problem. Marked as a DUP
+ because the LWG chose to adopt the solution proposed in
+ <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>.
+</p>
+<hr>
+<a name="480"><h3>480. unary_function and binary_function should have protected nonvirtual destructors</h3></a><p><b>Section:</b> 20.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.tuple.tuple"> [lib.tuple.tuple]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Joe Gottman <b>Date:</b> 19 Aug 2004</p>
+<p>The classes std::unary_function and std::binary_function are both
+designed to be inherited from but contain no virtual functions. This
+makes it too easy for a novice programmer to write code like
+binary_function<int, int, int> *p = new plus<int>; delete p;</p>
+
+<p>There are two common ways to prevent this source of undefined
+behavior: give the base class a public virtual destructor, or give it
+a protected nonvirtual destructor. Since unary_function and
+binary_function have no other virtual functions, (note in particular
+the absence of an operator()() ), it would cost too much to give them
+public virtual destructors. Therefore, they should be given protected
+nonvirtual destructors.</p>
+<p><b>Proposed resolution:</b></p>
+<p>Change Paragraph 20.3.1 of the Standard from</p>
+<pre> template <class Arg, class Result>
+ struct unary_function {
+ typedef Arg argument_type;
+ typedef Result result_type;
+ };
+
+ template <class Arg1, class Arg2, class Result>
+ struct binary_function {
+ typedef Arg1 first_argument_type;
+ typedef Arg2 second_argument_type;
+ typedef Result result_type;
+ };
+</pre>
+
+<p>to</p>
+<pre> template <class Arg, class Result>
+ struct unary_function {
+ typedef Arg argument_type;
+ typedef Result result_type;
+ protected:
+ ~unary_function() {}
+ };
+
+ template <class Arg1, class Arg2, class Result>
+ struct binary_function {
+ typedef Arg1 first_argument_type;
+ typedef Arg2 second_argument_type;
+ typedef Result result_type;
+ protected:
+ ~binary_function() {}
+ };
+</pre>
+<p><b>Rationale:</b></p>
+<p>The LWG doesn't believe the existing definition causes anybody any
+ concrete harm.</p>
+<hr>
+<a name="481"><h3>481. unique's effects on the range [result, last)</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#NAD">NAD</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 30 Aug 2004</p>
+<p>
+The standard says that unique(first, last) "eliminates all but the
+first element from every consecutive group of equal elements" in
+[first, last) and returns "the end of the resulting range". So a
+postcondition is that [first, result) is the same as the old [first,
+last) except that duplicates have been eliminated.
+</p>
+
+<p>What postconditions are there on the range [result, last)? One
+ might argue that the standard says nothing about those values, so
+ they can be anything. One might also argue that the standard
+ doesn't permit those values to be changed, so they must not be.
+ Should the standard say something explicit one way or the other?</p>
+
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+<p><b>Rationale:</b></p>
+<p>We don't want to make many guarantees about what's in [result,
+end). Maybe we aren't being quite explicit enough about not being
+explicit, but it's hard to think that's a major problem.</p>
+<hr>
+<a name="483"><h3>483. Heterogeneous equality and EqualityComparable</h3></a><p><b>Section:</b> 25.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.nonmodifying"> [lib.alg.nonmodifying]</a>, 25.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.modifying.operations"> [lib.alg.modifying.operations]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Peter Dimov <b>Date:</b> 20 Sep 2004</p>
+<p>c++std-lib-14262</p>
+
+<p>[lib.alg.find] requires T to be EqualityComparable:</p>
+
+<pre>template <class InputIterator, class T>
+ InputIterator find(InputIterator first, InputIterator last,
+ const T& value);
+</pre>
+
+<p>
+However the condition being tested, as specified in the Effects
+clause, is actually *i == value, where i is an InputIterator.
+</p>
+
+<p>
+The two clauses are in agreement only if the type of *i is T, but this
+isn't necessarily the case. *i may have a heterogeneous comparison
+operator that takes a T, or a T may be convertible to the type of *i.
+</p>
+
+<p>Further discussion (c++std-lib-14264): this problem affects a
+ number of algorithsm in clause 25, not just <tt>find</tt>. We
+ should try to resolve this problem everywhere it appears.</p>
+<p><b>Proposed resolution:</b></p>
+
+<p>[lib.alg.find]:</p>
+<blockquote>
+ Remove [lib.alg.find]/1.
+</blockquote>
+
+<p>[lib.alg.count]:</p>
+<blockquote>
+ Remove [lib.alg.count]/1.
+</blockquote>
+
+<p>[lib.alg.search]:</p>
+<blockquote>
+ Remove "Type T is EqualityComparable (20.1.1), " from [lib.alg.search]/4.
+</blockquote>
+
+<p>[lib.alg.replace]:</p>
+
+<blockquote>
+ <p>
+ Remove [lib.alg.replace]/1.
+ Replace [lb.alg.replace]/2 with:
+ </p>
+
+ <blockquote>
+ For every iterator i in the range [first, last) for which *i == value
+ or pred(*i) holds perform *i = new_value.
+ </blockquote>
+
+ <p>
+ Remove the first sentence of /4.
+ Replace the beginning of /5 with:
+ </p>
+
+ <blockquote>
+ For every iterator i in the range [result, result + (last -
+ first)), assign to *i either...
+ </blockquote>
+
+ <p>(Note the defect here, current text says assign to i, not *i).</p>
+</blockquote>
+
+<p>[lib.alg.fill]:</p>
+
+<blockquote>
+ <p>
+ Remove "Type T is Assignable (23.1), " from /1.
+ Replace /2 with:
+ </p>
+
+ <blockquote>
+ For every iterator i in the range [first, last) or [first, first + n),
+ perform *i = value.
+ </blockquote>
+</blockquote>
+
+<p>[lib.alg.remove]:</p>
+<blockquote>
+ Remove /1.
+ Remove the first sentence of /6.
+</blockquote>
+
+<p><b>Rationale:</b></p>
+<p>Duplicate of (a subset of) issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a>.</p>
+<hr>
+<a name="486"><h3>486. min/max CopyConstructible requirement is too strict</h3></a><p><b>Section:</b> 25.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.min.max"> [lib.alg.min.max]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 13 Oct 2004</p>
+<p>A straightforward implementation of these algorithms does not need to
+copy T.</p>
+<p><b>Proposed resolution:</b></p>
+<p>drop the the words "and CopyConstructible" from paragraphs 1 and 4</p>
+<p><b>Rationale:</b></p>
+<p>Dup of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a>.</p>
+<hr>
+<a name="487"><h3>487. Allocator::construct is too limiting</h3></a><p><b>Section:</b> 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.default.con.req"> [lib.default.con.req]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Dhruv Matani <b>Date:</b> 17 Oct 2004</p>
+<p>
+The standard's version of allocator::construct(pointer,
+const_reference) severely limits what you can construct using this
+function. Say you can construct a socket from a file descriptor. Now,
+using this syntax, I first have to manually construct a socket from
+the fd, and then pass the constructed socket to the construct()
+function so it will just to an uninitialized copy of the socket I
+manually constructed. Now it may not always be possible to copy
+construct a socket eh! So, I feel that the changes should go in the
+allocator::construct(), making it:
+</p>
+<pre> template<typename T>
+ struct allocator{
+ template<typename T1>
+ void construct(pointer T1 const& rt1);
+ };
+</pre>
+
+<p>
+Now, the ctor of the class T which matches the one that takes a T1 can
+be called! Doesn't that sound great?
+</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>NAD. STL uses copying all the time, and making it possible for
+ allocators to construct noncopyable objects is useless in the
+ absence of corresponding container changes. We might consider this
+ as part of a larger redesign of STL.</p>
+<hr>
+<a name="489"><h3>489. std::remove / std::remove_if wrongly specified</h3></a><p><b>Section:</b> 25.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.remove"> [lib.alg.remove]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Thomas Mang <b>Date:</b> 12 Dec 2004</p>
+<p>In Section 25.2.7 [lib.alg.remove], paragraphs 1 to 5 describe the
+behavior of the mutating sequence operations std::remove and
+std::remove_if. However, the wording does not reflect the intended
+behavior [Note: See definition of intended behavior below] of these
+algorithms, as it is known to the C++ community [1].
+</p>
+
+
+
+<p>1) Analysis of current wording:</p>
+
+
+<p>25.2.7 [lib.alg.remove], paragraph 2:</p>
+
+<p>Current wording says:
+"Effects: Eliminates all the elements referred to by iterator i in the
+range [first, last) for which the following corresponding conditions
+hold: *i == value, pred(*i) != false."</p>
+
+<p>
+This sentences expresses specifically that all elements denoted by the
+(original) range [first, last) for which the corresponding condition
+hold will be eliminated. Since there is no formal definition of the term
+"eliminate" provided, the meaning of "eliminate" in everyday language
+implies that as postcondition, no element in the range denoted by
+[first, last) will hold the corresponding condition on reiteration over
+the range [first, last).
+</p>
+
+<p>
+However, this is neither the intent [Note: See definition of intended
+behavior below] nor a general possible approach. It can be easily proven
+that if all elements of the original range[first, last) will hold the
+condition, it is not possible to substitute them by an element for which
+the condition will not hold.
+</p>
+
+
+<p>25.2.7 [lib.alg.remove], paragraph 3:</p>
+
+<p>
+Current wording says:
+"Returns: The end of the resulting range."
+</p>
+
+<p>
+The resulting range is not specified. In combination with 25.2.7
+[lib.alg.remove], paragraph 2, the only reasonable interpretation of
+this so-called resulting range is the range [first,last) - thus
+returning always the ForwardIterator 'last' parameter.
+</p>
+
+
+<p>
+25.2.7 [lib.alg.remove], paragraph 4:
+</p>
+
+<p>
+Current wording says:
+"Notes: Stable: the relative order of the elements that are not removed
+is the same as their relative order in the original range"
+</p>
+
+<p>
+This sentences makes use of the term "removed", which is neither
+specified, nor used in a previous paragraph (which uses the term
+"eliminate"), nor unamgiuously separated from the name of the algorithm.
+</p>
+
+
+<p>2) Description of intended behavior:</p>
+
+<p>
+For the rest of this Defect Report, it is assumed that the intended
+behavior was that all elements of the range [first, last) which do not
+hold the condition *i == value (std::remove) or pred(*i) != false
+(std::remove_if)], call them s-elements [Note: s...stay], will be placed
+into a contiguous subrange of [first, last), denoted by the iterators
+[first, return value). The number of elements in the resulting range
+[first, return value) shall be equal to the number of s-elements in the
+original range [first, last). The relative order of the elements in the
+resulting subrange[first, return value) shall be the same as the
+relative order of the corresponding elements in the original range. It
+is undefined whether any elements in the resulting subrange [return
+value, last) will hold the corresponding condition, or not.
+</p>
+
+<p>
+All implementations known to the author of this Defect Report comply
+with this intent. Since the intent of the behavior (contrary to the
+current wording) is also described in various utility references serving
+the C++ community [1], it is not expected that fixing the paragraphs
+will influence current code - unless the code relies on the behavior as
+it is described by current wording and the implementation indeed
+reflects the current wording, and not the intent.
+</p>
+
+
+
+<p>3) Proposed fixes:</p>
+
+
+<p>Change 25.2.7 [lib.alg.remove], paragraph 2 to:</p>
+
+<p>
+"Effect: Places all the elements referred to by iterator i in the range
+[first, last) for which the following corresponding conditions hold :
+!(*i == value), pred(*i) == false into the subrange [first, k) of the
+original range, where k shall denote a value of type ForwardIterator. It
+is undefined whether any elements in the resulting subrange [k, last)
+will hold the corresponding condition, or not."
+</p>
+
+<p>Comments to the new wording:</p>
+
+<p>
+a) "Places" has no special meaning, and the everyday language meaning
+should fit.
+b) The corresponding conditions were negated compared to the current
+wording, becaue the new wording requires it.
+c) The wording "of the original range" might be redundant, since any
+subrange starting at 'first' and containing no more elements than the
+original range is implicitly a subrange of the original range [first,
+last).
+d) The iterator k was introduced instead of "return value" in order to
+avoid a cyclic dependency on 25.2.7/3. The wording ", where k shall
+denote a value of type ForwardIterator" might be redundant, because it
+follows implicitly by 25.2.7/3.
+e) "Places" does, in the author's opinion, explicitly forbid duplicating
+any element holding the corresponding condition in the original range
+[first, last) within the resulting range [first, k). If there is doubt
+this term might be not unambiguous regarding this, it is suggested that
+k is specified more closely by the following wording: "k shall denote a
+value of type ForwardIterator [Note: see d)] so that k - first is equal
+to the number of elements in the original range [first, last) for which
+the corresponding condition did hold". This could also be expressed as a
+separate paragraph "Postcondition:"
+f) The senctence "It is undefined whether any elements in the resulting
+subrange [k, last) will hold the corresponding condition, or not." was
+added consciously so the term "Places" does not imply if the original
+range [first, last) contains n elements holding the corresponding
+condition, the identical range[first, last) will also contain exactly n
+elements holding the corresponding condition after application of the
+algorithm.
+</p>
+
+<p>
+Change 25.2.7 [lib.alg.remove], paragraph 3 to:
+
+"Returns: The iterator k."
+</p>
+
+<p>
+Change 25.2.7 [lib.alg.remove], paragraph 4 to:
+
+"Notes: Stable: the relative order of the elements that are placed into
+the subrange [first, return value) shall be the same as their relative
+order was in the original range [first, last) prior to application of
+the algorithm."
+</p>
+
+<p>
+Comments to the new wording:
+</p>
+
+<p>
+a) the wording "was ... prior to application of the algorithm" is used
+to explicitly distinguish the original range not only by means of
+iterators, but also by a 'chronological' factor from the resulting range
+[first, return value). It might be redundant.
+</p>
+
+<p>
+[1]:
+The wording of these references is not always unambiguous, and provided
+examples partially contradict verbal description of the algorithms,
+because the verbal description resembles the problematic wording of
+ISO/IEC 14882:2003.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>The LWG believes that the standard is sufficiently clear, and that
+ there is no evidence of any real-world confusion about this point.</p>
+<hr>
+<a name="490"><h3>490. std::unique wrongly specified</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#NAD">NAD</a> <b>Submitter:</b> Thomas Mang <b>Date:</b> 12 Dec 2004</p>
+<p>In Section 25.2.8 [lib.alg.unique], paragraphs 1 to 3 describe the
+behavior of the mutating sequence operation std::unique. However, the
+wording does not reflect the intended behavior [Note: See definition of
+intended behavior below] of these algorithms, as it is known to the C++
+community [1].</p>
+
+
+
+<p>1) Analysis of current wording:</p>
+
+
+<p>25.2.8 [lib.alg.unique], paragraph 1:</p>
+
+<p>
+Current wording says:
+"Effects: Eliminates all but the first element from every consecutive
+group of equal elements referred to by the iterator i in the range
+[first, last) for which the following corresponding conditions hold: *i
+== *(i - 1) or pred(*i, *(i -1)) != false"
+</p>
+
+<p>
+This sentences expresses specifically that all elements denoted by the
+(original) range [first, last) which are not but the first element from
+a consecutive group of equal elements (where equality is defined as *i
+== *(i - 1) or pred(*i, *(i - 1)) ! = false) [Note: See DR 202], call
+them r-elements [Note: r...remove], will be eliminated. Since there is
+no formal definition of the term "eliminate" provided, it is undefined
+how this "elimination" takes place. But the meaning of "eliminate" in
+everyday language seems to disallow explicitly that after application of
+the algorithm, any r-element will remain at any position of the range
+[first, last) [2].
+</p>
+
+<p>
+Another defect in the current wording concerns the iterators used to
+compare two elements for equality: The current wording contains the
+expression "(i - 1)", which is not covered by 25/9 [Note: See DR
+submitted by Thomas Mang regarding invalid iterator arithmetic
+expressions].
+</p>
+
+
+<p>
+25.2.8 [lib.alg.unique], paragraph 2:
+</p>
+<p>Current wording says:
+"Returns: The end of the resulting range."</p>
+
+<p>
+The resulting range is not specified. In combination with 25.2.8
+[lib.alg.unique], paragraph 1, one reasonable interpretation (in the
+author's opinion even the only possible interpretation) of this
+so-called resulting range is the range [first, last) - thus returning
+always the ForwardIterator 'last' parameter.
+</p>
+
+<p>2) Description of intended behavior:</p>
+
+<p>
+For the rest of this Defect Report, it is assumed that the intended
+behavior was that all elements denoted by the original range [first,
+last) which are the first element from a consecutive group of elements
+for which the corresponding conditions: *(i-1) == *i (for the version of
+unique without a predicate argument) or pred(*(i-1), *i) ! = false (for
+the version of unique with a predicate argument) [Note: If such a group
+of elements consists of only a single element, this is also considered
+the first element] [Note: See resolutions of DR 202], call them
+s-elements [Note: s...stay], will be placed into a contiguous subrange
+of [first, last), denoted by the iterators [first, return value). The
+number of elements in the resulting range [first, return value) shall be
+equal to the number of s-elements in the original range [first, last).
+Invalid iterator arithmetic expressions are expected to be resolved as
+proposed in DR submitted by Thomas Mang regarding invalid iterator
+arithmetic expressions. It is also assumed by the author that the
+relative order of the elements in the resulting subrange [first, return
+value) shall be the same as the relative order of the corresponding
+elements (the s-elements) in the original range [Note: If this was not
+intended behavior, the additional proposed paragraph about stable order
+will certainly become obsolete].
+Furthermore, the resolutions of DR 202 are partially considered.
+</p>
+
+<p>
+All implementations known to the author of this Defect Report comply
+with this intent [Note: Except possible effects of DR 202]. Since this
+intent of the behavior (contrary to the current wording) is also
+described in various utility references serving the C++ community [1],
+it is not expected that fixing the paragraphs will influence current
+code [Note: Except possible effects of DR 202] - unless the code relies
+on the behavior as it is described by current wording and the
+implementation indeed reflects the current wording, and not the intent.
+</p>
+
+
+
+<p>3) Proposed fixes:</p>
+
+<p>
+Change 25.2.8 [lib.alg.unique], paragraph 1 to:
+</p>
+
+<p>
+"Effect: Places the first element from every consecutive group of
+elements, referred to by the iterator i in the range [first, last), for
+which the following conditions hold: *(i-1) == *i (for the version of
+unique without a predicate argument) or pred(*(i -1), *i) != false (for
+the version of unique with a predicate argument), into the subrange
+[first, k) of the original range, where k shall denote a value of type
+ForwardIterator."
+</p>
+
+<p>Comments to the new wording:</p>
+
+<p>
+a) The new wording was influenced by the resolutions of DR 202. If DR
+202 is resolved in another way, the proposed wording need also
+additional review.
+b) "Places" has no special meaning, and the everyday language meaning
+should fit.
+c) The expression "(i - 1)" was left, but is expected that DR submitted
+by Thomas Mang regarding invalid iterator arithmetic expressions will
+take this into account.
+d) The wording "(for the version of unique without a predicate
+argument)" and "(for the version of unique with a predicate argument)"
+was added consciously for clarity and is in resemblence with current
+23.2.2.4 [lib.list.ops], paragraph 19. It might be considered redundant.
+e) The wording "of the original range" might be redundant, since any
+subrange starting at first and containing no more elements than the
+original range is implicitly a subrange of the original range [first,
+last).
+f) The iterator k was introduced instead of "return value" in order to
+avoid a cyclic dependency on 25.2.8 [lib.alg.unique], paragraph 2. The
+wording ", where k shall denote a value of type ForwardIterator" might
+be redundant, because it follows implicitly by 25.2.8 [lib.alg.unique],
+paragraph 2.
+g) "Places" does, in the author's opinion, explicitly forbid duplicating
+any s-element in the original range [first, last) within the resulting
+range [first, k). If there is doubt this term might be not unambiguous
+regarding this, it is suggested that k is specified more closely by the
+following wording: "k shall denote a value of type ForwardIterator
+[Note: See f)] so that k - first is equal to the number of elements in
+the original range [first, last) being the first element from every
+consecutive group of elements for which the corresponding condition did
+hold". This could also be expressed as a separate paragraph
+"Postcondition:".
+h) If it is considered that the wording is unclear whether it declares
+the element of a group which consists of only a single element
+implicitly to be the first element of this group [Note: Such an
+interpretation could eventually arise especially in case last - first ==
+1] , the following additional sentence is proposed: "If such a group of
+elements consists of only a single element, this element is also
+considered the first element."
+</p>
+
+<p>
+Change 25.2.8 [lib.alg.unique], paragraph 2 to:
+"Returns: The iterator k."
+</p>
+
+<p>
+Add a separate paragraph "Notes:" as 25.2.8 [lib.alg.unique], paragraph
+2a or 3a, or a separate paragraph "Postcondition:" before 25.2.8
+[lib.alg.unique], paragraph 2 (wording inside {} shall be eliminated if
+the preceding expressions are used, or the preceding expressions shall
+be eliminated if wording inside {} is used):
+</p>
+
+<p>
+"Notes:{Postcondition:} Stable: the relative order of the elements that
+are placed into the subrange [first, return value {k}) shall be the same
+as their relative order was in the original range [first, last) prior to
+application of the algorithm."
+</p>
+
+<p>Comments to the new wording:</p>
+
+<p>
+a) It is assumed by the author that the algorithm was intended to be
+stable.
+In case this was not the intent, this paragraph becomes certainly
+obsolete.
+b) The wording "was ... prior to application of the algorithm" is used
+to explicitly distinguish the original range not only by means of
+iterators, but also by a 'chronological' factor from the resulting range
+[first, return value). It might be redundant.
+</p>
+
+<p>
+25.2.8 [lib.alg.unique], paragraph 3:
+</p>
+<p>See DR 239.</p>
+
+<p>
+4) References to other DRs:
+</p>
+
+<p>
+See DR 202, but which does not address any of the problems described in
+this Defect Report [Note: This DR is supposed to complement DR 202].
+See DR 239.
+See DR submitted by Thomas Mang regarding invalid iterator arithmetic
+expressions.
+</p>
+
+<p>
+[1]:
+The wording of these references is not always unambiguous, and provided
+examples partially contradict verbal description of the algorithms,
+because the verbal description resembles the problematic wording of
+ISO/IEC 14882:2003.
+</p>
+
+<p>
+[2]:
+Illustration of conforming implementations according to current wording:
+</p>
+
+<p>
+One way the author of this DR considers how this "elimination" could be
+achieved by a conforming implementation according to current wording is
+by substituting each r-element by _any_ s-element [Note: s...stay; any
+non-r-element], since all r-elements are "eliminated".
+</p>
+
+<p>
+In case of a sequence consisting of elements being all 'equal' [Note:
+See DR 202], substituting each r-element by the single s-element is the
+only possible solution according to current wording.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>The LWG believes the standard is sufficiently clear. No
+implementers get it wrong, and changing it wouldn't cause any code to
+change, so there is no real-world harm here.</p>
+<hr>
+<a name="491"><h3>491. std::list<>::unique incorrectly specified</h3></a><p><b>Section:</b> 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.special"> [lib.deque.special]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Thomas Mang <b>Date:</b> 12 Dec 2004</p>
+<p>In Section 23.2.2.4 [lib.list.ops], paragraphs 19 to 21 describe the
+behavior of the std::list<T, Allocator>::unique operation. However, the
+current wording is defective for various reasons.</p>
+
+
+
+<p>
+1) Analysis of current wording:
+</p>
+
+<p>23.2.2.4 [lib.list.ops], paragraph 19:</p>
+
+<p>
+Current wording says:
+"Effects: Eliminates all but the first element from every consecutive
+group of equal elements referred to by the iterator i in the range
+[first + 1, last) for which *i == *(i - 1) (for the version of unique
+with no argument) or pred(*i, *(i -1)) (for the version of unique with a
+predicate argument) holds."</p>
+
+<p>
+This sentences makes use of the undefined term "Eliminates". Although it
+is, to a certain degree, reasonable to consider the term "eliminate"
+synonymous with "erase", using "Erase" in the first place, as the
+wording of 23.2.2.4 [lib.list.ops], paragraph 15 does, would be clearer.</p>
+
+<p>
+The range of the elements referred to by iterator i is "[first + 1,
+last)". However, neither "first" nor "last" is defined.</p>
+
+<p>
+The sentence makes three times use of iterator arithmetic expressions (
+"first + 1", "*i == *(i - 1)", "pred(*i, *(i -1))" ) which is not
+defined for bidirectional iterator [see DR submitted by Thomas Mang
+regarding invalid iterator arithmetic expressions].</p>
+
+<p>
+The same problems as pointed out in DR 202 (equivalence relation / order
+of arguments for pred()) apply to this paragraph.</p>
+
+<p>
+23.2.2.4 [lib.list.ops], paragraph 20:
+</p>
+
+<p>
+Current wording says:
+"Throws: Nothing unless an exception in thrown by *i == *(i-1) or
+pred(*i, *(i - 1))"</p>
+
+<p>
+The sentence makes two times use of invalid iterator arithmetic
+expressions ( "*i == *(i - 1)", "pred(*i, *(i -1))" ).
+</p>
+<p>
+[Note: Minor typos: "in" / missing dot at end of sentence.]
+</p>
+
+<p>
+23.2.2.4 [lib.list.ops], paragraph 21:</p>
+
+<p>
+Current wording says:
+"Complexity: If the range (last - first) is not empty, exactly (last -
+first) - 1 applications of the corresponding predicate, otherwise no
+application of the predicate.</p>
+
+<p>
+See DR 315 regarding "(last - first)" not yielding a range.</p>
+
+<p>
+Invalid iterator arithmetic expression "(last - first) - 1" left .</p>
+
+
+<p>2) Description of intended behavior:</p>
+
+<p>
+For the rest of this Defect Report, it is assumed that "eliminate" is
+supposed to be synonymous to "erase", that "first" is equivalent to an
+iterator obtained by a call to begin(), "last" is equivalent to an
+iterator obtained by a call to end(), and that all invalid iterator
+arithmetic expressions are resolved as described in DR submitted by
+Thomas Mang regarding invalid iterator arithmetic expressions.</p>
+
+<p>
+Furthermore, the resolutions of DR 202 are considered regarding
+equivalence relation and order of arguments for a call to pred.</p>
+
+<p>
+All implementations known to the author of this Defect Report comply
+with these assumptions, apart from the impact of the alternative
+resolution of DR 202. Except for the changes implied by the resolutions
+of DR 202, no impact on current code is expected.</p>
+
+<p>
+3) Proposed fixes:</p>
+
+<p>
+Change 23.2.2.4 [lib.list.ops], paragraph 19 to:</p>
+
+<p>
+"Effect: Erases all but the first element from every consecutive group
+of elements, referred to by the iterator i in the range [begin(),
+end()), for which the following conditions hold: *(i-1) == *i (for the
+version of unique with no argument) or pred(*(i-1), *i) != false (for
+the version of unique with a predicate argument)."</p>
+
+<p>
+Comments to the new wording:</p>
+
+<p>
+a) The new wording was influenced by DR 202 and the resolutions
+presented there. If DR 202 is resolved in another way, the proposed
+wording need also additional review.
+b) "Erases" refers in the author's opinion unambiguously to the member
+function "erase". In case there is doubt this might not be unamgibuous,
+a direct reference to the member function "erase" is suggested [Note:
+This would also imply a change of 23.2.2.4 [lib.list.ops], paragraph
+15.].
+c) The expression "(i - 1)" was left, but is expected that DR submitted
+by Thomas Mang regarding invalid iterator arithmetic expressions will
+take this into account.
+d) The wording "(for the version of unique with no argument)" and "(for
+the version of unique with a predicate argument)" was kept consciously
+for clarity.
+e) "begin()" substitutes "first", and "end()" substitutes "last". The
+range need adjustment from "[first + 1, last)" to "[begin(), end())" to
+ensure a valid range in case of an empty list.
+f) If it is considered that the wording is unclear whether it declares
+the element of a group which consists of only a single element
+implicitly to be the first element of this group [Note: Such an
+interpretation could eventually arise especially in case size() == 1] ,
+the following additional sentence is proposed: "If such a group of
+elements consists of only a single element, this element is also
+considered the first element."</p>
+
+<p>
+Change 23.2.2.4 [lib.list.ops], paragraph 20 to:</p>
+
+<p>
+"Throws: Nothing unless an exception is thrown by *(i-1) == *i or
+pred(*(i-1), *i)."</p>
+
+<p>
+Comments to the new wording:</p>
+
+<p>
+a) The wording regarding the conditions is identical to proposed
+23.2.2.4 [lib.list.ops], paragraph 19. If 23.2.2.4 [lib.list.ops],
+paragraph 19 is resolved in another way, the proposed wording need also
+additional review.
+b) The expression "(i - 1)" was left, but is expected that DR submitted
+by Thomas Mang regarding invalid iterator arithmetic expressions will
+take this into account.
+c) Typos fixed.</p>
+
+<p>
+Change 23.2.2.4 [lib.list.ops], paragraph 21 to:</p>
+
+<p>
+"Complexity: If empty() == false, exactly size() - 1 applications of the
+corresponding predicate, otherwise no applications of the corresponding
+predicate."</p>
+
+<p>
+Comments to the new wording:</p>
+
+<p>
+a) The new wording is supposed to also replace the proposed resolution
+of DR 315, which suffers from the problem of undefined "first" / "last".
+</p>
+
+<p>
+5) References to other DRs:</p>
+
+<p>See DR 202.
+See DR 239.
+See DR 315.
+See DR submitted by Thomas Mang regarding invalid iterator arithmetic
+expressions.</p>
+
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>"All implementations known to the author of this Defect Report
+comply with these assumption", and "no impact on current code is
+expected", i.e. there is no evidence of real-world confusion or
+harm.</p>
+<hr>
+<a name="493"><h3>493. Undefined Expression in Input Iterator Note Title</h3></a><p><b>Section:</b> 24.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Chris Jefferson <b>Date:</b> 13 Dec 2004</p>
+<p>1) In 24.1.1/3, the following text is currently present.</p>
+
+<p>"Note: For input iterators, a==b does not imply ++a=++b (Equality does
+not guarantee the substitution property or referential transparency)."</p>
+
+<p>However, when in Table 72, part of the definition of ++r is given as:</p>
+
+<p>"pre: r is dereferenceable.
+post: any copies of the previous value of r are no longer required
+either to be dereferenceable ..."</p>
+
+<p>While a==b does not imply that b is a copy of a, this statement should
+perhaps still be made more clear.</p>
+
+<p>2) There are no changes to intended behaviour</p>
+
+<p>
+3) This Note should be altered to say "Note: For input iterators a==b,
+when its behaviour is defined ++a==++b may still be false (Equality does
+not guarantee the substitution property or referential transparency).</p>
+
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>This is descriptive text, not normative, and the meaning is clear.</p>
+<hr>
+<a name="494"><h3>494. Wrong runtime complexity for associative container's insert and delete</h3></a><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Hans B os <b>Date:</b> 19 Dec 2004</p>
+<p>According to [lib.associative.reqmts] table 69, the runtime comlexity
+of insert(p, t) and erase(q) can be done in amortized constant time.</p>
+
+<p>It was my understanding that an associative container could be
+implemented as a balanced binary tree.</p>
+
+<p>For inser(p, t), you 'll have to iterate to p's next node to see if t
+can be placed next to p. Furthermore, the insertion usually takes
+place at leaf nodes. An insert next to the root node will be done at
+the left of the root next node</p>
+
+<p>So when p is the root node you 'll have to iterate from the root to
+its next node, which takes O(log(size)) time in a balanced tree.</p>
+
+<p>If you insert all values with insert(root, t) (where root is the
+root of the tree before insertion) then each insert takes O(log(size))
+time. The amortized complexity per insertion will be O(log(size))
+also.</p>
+
+<p>For erase(q), the normal algorithm for deleting a node that has no
+empty left or right subtree, is to iterate to the next (or previous),
+which is a leaf node. Then exchange the node with the next and delete
+the leaf node. Furthermore according to DR 130, erase should return
+the next node of the node erased. Thus erasing the root node,
+requires iterating to the next node.</p>
+
+<p>Now if you empty a map by deleting the root node until the map is
+empty, each operation will take O(log(size)), and the amortized
+complexity is still O(log(size)).</p>
+
+<p>The operations can be done in amortized constant time if iterating
+to the next node can be done in (non amortized) constant time. This
+can be done by putting all nodes in a double linked list. This
+requires two extra links per node. To me this is a bit overkill since
+you can already efficiently insert or erase ranges with erase(first,
+last) and insert(first, last).</p>
+
+<p><b>Proposed resolution:</b></p>
+<p><b>Rationale:</b></p>
+<p>Only "amortized constant" in special circumstances, and we believe
+ that's implementable. That is: doing this N times will be O(N), not
+ O(log N).</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#NAD">NAD</a> <b>Submitter:</b> Prateek Karandikar <b>Date:</b> 12 Apr 2005</p>
+<blockquote>
+<p>
+17.3.1.1 Summary</p>
+
+<p>
+1 The Summary provides a synopsis of the category, and introduces the
+first-level subclauses. Each subclause also provides a summary, listing
+the headers specified in the subclause and the library entities
+provided in each header.
+</p>
+<p>
+2 Paragraphs labelled "Note(s):" or "Example(s):" are informative,
+other paragraphs are normative.
+</p>
+</blockquote>
+
+<p>So this means that a "Notes" paragraph wouldn't be normative. </p>
+
+<blockquote>
+<p>
+25.3.1.2 stable_sort
+</p>
+<pre>template<class RandomAccessIterator>
+void stable_sort(RandomAccessIterat or first, RandomAccessIterator last);
+
+template<class RandomAccessIterator, class Compare>
+void stable_sort(RandomAccessIterat or first, RandomAccessIterator last, Compare comp);
+</pre>
+<p>
+1 Effects: Sorts the elements in the range [first, last).
+</p>
+<p>
+2 Complexity: It does at most N(log N)^2 (where N == last - first)
+comparisons; if enough extra memory is available, it is N log N.
+</p>
+<p>
+3 Notes: Stable: the relative order of the equivalent elements is
+preserved.
+</p>
+</blockquote>
+
+<p>
+The Notes para is informative, and nowhere else is stability mentioned above.
+</p>
+
+<p>
+Also, I just searched for the word "stable" in my copy of the Standard.
+and the phrase "Notes: Stable: the relative order of the elements..."
+is repeated several times in the Standard library clauses for
+describing various functions. How is it that stability is talked about
+in the informative paragraph? Or am I missing something obvious?
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+</p>
+<p><b>Rationale:</b></p>
+<p>
+This change has already been made.
+</p>
+<hr>
+<a name="500"><h3>500. do_length cannot be implemented correctly</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.byname"> [lib.locale.codecvt.byname]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Krzysztof ¯elechowski <b>Date:</b> 24 May 2005</p>
+<ol>
+<li>codecvt::do_length is of type int;</li>
+<li>it is assumed to be sort-of returning from_next - from of type ptrdiff_t;</li>
+<li>ptrdiff_t cannot be cast to an int without data loss.</li>
+</ol>
+<p>
+Contradiction.
+</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.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.base"> [lib.base]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</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.5.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.5.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>
+
+<p><b>Rationale:</b></p>
+less is already required to provide a strict weak ordering which is good enough
+to detect overlapping memory situations.
+<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#NAD">NAD</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 ..."
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+In 5.1.1 [tr.rand.req], Paragraph 2 replace
+</p>
+
+<blockquote>
+... s is a value of integral type, g is an lvalue of a type other than X that
+defines a zero-argument function object returning values of <del>unsigned integral</del> type
+<ins><tt>unsigned long int</tt></ins>,
+...
+</blockquote>
+
+<p>
+In 5.1.1 [tr.rand.seq], Table 16, replace in the line for X(s)
+</p>
+
+<blockquote>
+creates an engine with the initial internal state
+determined by <ins><tt>static_cast<unsigned long>(</tt></ins><tt><i>s</i></tt><ins><tt>)</tt></ins>
+</blockquote>
+
+<p><i>[
+Mont Tremblant: Both s and g should be unsigned long.
+This should refer to the constructor signatures. Jens provided wording post Mont Tremblant.
+]</i></p>
+
+<p><i>[
+Berlin: N1932 adopts the proposed resolution: see 26.3.1.3/1e and Table 3 row 2. Moved
+to Ready.
+]</i></p>
+
+<p><b>Rationale:</b></p>
+<p>
+Jens: Just requiring X(unsigned long) still makes it possible
+for an evil library writer to also supply a X(int) that does something
+unexpected. The wording above requires that X(s) always performs
+as if X(unsigned long) would have been called. I believe that is
+sufficient and implements our intentions from Mont Tremblant. I
+see no additional use in actually requiring a X(unsigned long)
+signature. u.seed(s) is covered by its reference to X(s), same
+arguments.
+</p>
+<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#NAD">NAD</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>
+
+<p><b>Rationale:</b></p>
+Berlin: N1932 makes this moot: variate_generator has been eliminated.
+<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#NAD">NAD</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>
+
+<p><i>[
+Berlin: Moved to NAD. N1932 makes this moot: the input_type template parameter has been
+eliminated.
+]</i></p>
+
+<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#NAD">NAD</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>
+
+<p><i>[
+Berlin: Moved to NAD. N1932 makes this moot: the input_type template parameter has been
+eliminated.
+]</i></p>
+
+<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#NAD">NAD</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>
+
+<p><i>[
+Berlin: Moved to NAD. N1932 makes this moot: the input_type template parameter has been
+eliminated.
+]</i></p>
+<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#NAD">NAD</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
+flawed in the case where the engine parameter w (also known as word_size)
+exceeds 31 [bits]. The key part of the paragraph reads:
+</p>
+<blockquote>
+sets x(-r) ... x(-1) to (lcg(1)*2**(-w)) mod 1
+</blockquote>
+<p>
+and so forth.
+</p>
+<p>
+Since the specified linear congruential engine, lcg, delivers numbers with
+a maximum of 2147483563 (just a shade under 31 bits), then when w is, for
+example, 48, each of the x(i) will be less than 2**-17. The consequence
+is that roughly the first 400 numbers delivered will be conspicuously
+close to either zero or one.
+</p>
+<p>
+Unfortunately, this is not an innocuous flaw: One of the predefined engines
+in [tr.rand.predef], namely ranlux64_base_01, has w = 48 and would exhibit
+this poor behavior, while the original N1378 proposal states that these
+pre-defined engines are intended to be of "known good properties."
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+In 5.1.4.4 [tr.rand.eng.sub1], replace the "effects" clause for
+void seed(unsigned long value = 19780503) by
+</p>
+
+<blockquote>
+<i>Effects:</i> If <tt>value == 0</tt>, sets value to <tt>19780503</tt>. In any
+case, <del>with a linear congruential generator <tt>lcg</tt>(i) having parameters
+<tt><i>m<sub>lcg</sub></i> = 2147483563</tt>, <tt><i>a<sub>lcg</sub></i> = 40014</tt>,
+<tt><i>c<sub>lcg</sub></i> = 0</tt>, and <tt><i>lcg</i>(0) = value</tt>,</del>
+sets <ins>carry<tt>(-1)</tt> and</ins> <tt>x(-r) … x(-1)</tt>
+<ins>as if executing</ins>
+
+<blockquote><pre><ins>
+linear_congruential<unsigned long, 40014, 0, 2147483563> lcg(value);
+seed(lcg);
+</ins></pre></blockquote>
+
+<del>to <tt>(<i>lcg</i>(1) · 2<sup>-<i>w</i></sup>) mod 1
+… (<i>lcg</i>(<i>r</i>) · 2<sup>-<i>w</i></sup>) mod 1</tt>,
+respectively. If <tt><i>x</i>(-1) == 0</tt>, sets carry<tt>(-1) = 2<sup>-<i>w</i></sup></tt>,
+else sets carry<tt>(-1) = 0</tt>.</del>
+</blockquote>
+
+<p><i>[
+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
+prose would probably not qualify for the (with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a> even
+stricter) requirements we have for seed(Gen&).
+</p>
+
+<p><i>[
+Portland: Subsumed by N2111.
+]</i></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#NAD">NAD</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>
+
+<p><i>[
+Berlin: N1932 adopts the proposed NAD.
+]</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#NAD">NAD</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>
+
+<p><i>[
+Berlin: N1932 adopts the proposed NAD.
+]</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#NAD">NAD</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p>
+<p>
+Paragraph 6 says:
+</p>
+<blockquote>
+... obtained by successive invocations of g, ...
+</blockquote>
+<p>
+We recommend instead:
+</p>
+<blockquote>
+... obtained by taking successive invocations of g mod 2**32, ...
+</blockquote>
+<p>
+as the context seems to require only 32-bit quantities be used here.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Berlin: N1932 adopts the proposed resultion: see 26.3.3.4/7. Moved to Ready.
+</p>
+
+<p><i>[
+Portland: Subsumed by N2111.
+]</i></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#NAD">NAD</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."
+</p>
+
+<p><i>[
+Berlin: N1932 considers this NAD. This is a QOI issue.
+]</i></p>
+
+<hr>
+<a name="544"><h3>544. minor NULL problems in C.2</h3></a><p><b>Section:</b> C.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/diff.html#diff.library"> [diff.library]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 25 Nov 2005</p>
+<p>
+According to C.2.2.3, p1, "the macro NULL, defined in any of <clocale>,
+<cstddef>, <cstdio>, <cstdlib>, <cstring>, <ctime>,
+or <cwchar>." This is consistent with the C standard.
+</p>
+<p>
+However, Table 95 in C.2 fails to mention <clocale> and <cstdlib>.
+</p>
+<p>
+In addition, C.2, p2 claims that "The C++ Standard library provides
+54 standard macros from the C library, as shown in Table 95." While
+table 95 does have 54 entries, since a couple of them (including the
+NULL macro) are listed more than once, the actual number of macros
+defined by the C++ Standard Library may not be 54.
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+I propose we add <clocale> and <cstdlib> to Table 96 and remove the
+number of macros from C.2, p2 and reword the sentence as follows:
+</p>
+<blockquote>
+The C++ Standard library <del>provides 54 standard macros from</del>
+<ins>defines a number macros corresponding to those defined by</ins> the C
+<ins>Standard</ins> library, as shown in Table 96.
+</blockquote>
+
+<p><i>[
+Portland: Resolution is considered editorial. It will be incorporated into the WD.
+]</i></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#NAD">NAD</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 are the parameters of the distribution. OK, that tells us what t, p, and i
+are. What's n?
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Berlin: Typo: "n" replaced by "t" in N1932: see 26.3.7.2.2/1.
+</p>
+
+<p><i>[
+Portland: Subsumed by N2111.
+]</i></p>
+<hr>
+<a name="554"><h3>554. Problem with lwg DR 184 numeric_limits<bool></h3></a><p><b>Section:</b> 18.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.numeric.special"> [lib.numeric.special]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 29 Jan 2006</p>
+<p>
+I believe we have a bug in the resolution of:
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#184">lwg 184</a>
+(WP status).
+</p>
+
+<p>
+The resolution spells out each member of <tt>numeric_limits<bool></tt>.
+The part I'm having a little trouble with is:
+</p>
+<blockquote><pre>static const bool traps = false;
+</pre></blockquote>
+
+<p>
+Should this not be implementation defined? Given:
+</p>
+
+<blockquote><pre>int main()
+{
+ bool b1 = true;
+ bool b2 = false;
+ bool b3 = b1/b2;
+}
+</pre></blockquote>
+
+<p>
+If this causes a trap, shouldn't <tt>numeric_limits<bool>::traps</tt> be
+<tt>true</tt>?
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 18.2.1.5p3:
+</p>
+
+<blockquote>
+-3- The specialization for <tt>bool</tt> shall be provided as follows:
+<blockquote><pre>namespace std {
+ template <> class numeric_limits<bool> {
+ ...
+ static const bool traps = <del>false</del> <ins><i>implementation-defined</i></ins>;
+ ...
+ };
+}
+</pre></blockquote>
+</blockquote>
+
+<p><i>[
+Redmond: NAD because traps refers to values, not operations. There is no bool
+value that will trap.
+]</i></p>
+
+<hr>
+<a name="555"><h3>555. TR1, 8.21/1: typo</h3></a><p><b>Section:</b> TR1 8.21 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.c99.boolh"> [tr.c99.boolh]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2 Feb 2006</p>
+<p>
+This one, if nobody noticed it yet, seems really editorial:
+s/cstbool/cstdbool/
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 8.21p1:
+</p>
+<blockquote>
+-1- The header behaves as if it defines the additional macro defined in
+<tt><cst<ins>d</ins>bool></tt> by including the header <tt><cstdbool></tt>.
+</blockquote>
+
+<p><i>[
+Redmond: Editorial.
+]</i></p>
+
+<hr>
+<a name="558"><h3>558. lib.input.iterators Defect</h3></a><p><b>Section:</b> 24.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> David Abrahams <b>Date:</b> 9 Feb 2006</p>
+<blockquote>
+<p>
+ 24.1.1 Input iterators [lib.input.iterators]
+</p>
+<p>
+ 1 A class or a built-in type X satisfies the requirements of an
+ input iterator for the value type T if the following expressions are
+ valid, where U is the type of any specified member of type T, as
+ shown in Table 73.
+</p>
+</blockquote>
+<p>
+There is no capital U used in table 73. There is a lowercase u, but
+that is clearly not meant to denote a member of type T. Also, there's
+no description in 24.1.1 of what lowercase a means. IMO the above
+should have been...Hah, a and b are already covered in 24.1/11, so maybe it
+should have just been:
+</p>
+<p><b>Proposed resolution:</b></p>
+<p>
+Change 24.1.1p1:
+</p>
+<blockquote>
+-1- A class or a built-in type <tt>X</tt> satisfies the requirements of an
+input iterator for the value type <tt>T</tt> if the following expressions
+are valid<del>, where <tt>U</tt> is the type of any specified member of type
+<tt>T</tt>,</del> as shown in Table 73.
+</blockquote>
+
+<p><i>[
+Portland: Editorial.
+]</i></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#Dup">Dup</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><b>Rationale:</b></p>
+<p>
+This is a duplicate of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a>.
+</p>
+<p>----- End of document -----</p>
+</body></html>
\ No newline at end of file
OSDN Git Service
