Skip to content

R
riscv-gcc-1
Commit 449c4801 by Paolo Carlini Committed by Paolo Carlini
Options

lwg-active.html, [...]: Import Revision 45. 

2006-11-05  Paolo Carlini  <pcarlini@suse.de>

	* docs/html/ext/lwg-active.html, lwg-defects.html: Import Revision 45.
	* docs/html/ext/lwg-closed.html: Add.
	* docs/html/ext/howto.html: Adjust.

From-SVN: r118502
parent f4d4085c
Showing with 399 additions and 26 deletions
libstdc++-v3/ChangeLog
2006-11-05 Paolo Carlini <pcarlini@suse.de>
* docs/html/ext/lwg-active.html, lwg-defects.html: Import Revision 45.
* docs/html/ext/lwg-closed.html: Add.
* docs/html/ext/howto.html: Adjust.
2006-10-30 Paolo Carlini <pcarlini@suse.de>
* include/tr1/utility (tuple_size<std::pair<> >::value): Provide
......
libstdc++-v3/docs/html/ext/howto.html
......@@ -580,14 +580,14 @@
<dd>Fix the parameters.
</dd>
<dt><a href="lwg-active.html#512">512</a>:
<dt><a href="lwg-closed.html#512">512</a>:
<em>Seeding subtract_with_carry_01 from a single unsigned long</em>
</dt>
<dd>Construct a <code>linear_congruential</code> engine and seed with it.
</dd>
<dt><a href="lwg-active.html#538">538</a>:
<em>DR 538. 241 again: Does unique_copy() require CopyConstructible
<dt><a href="lwg-defects.html#538">538</a>:
<em>241 again: Does unique_copy() require CopyConstructible
and Assignable?</em>
</dt>
<dd>In case of input_iterator/output_iterator rely on Assignability of
......
libstdc++-v3/docs/html/ext/lwg-active.html
This source diff could not be displayed because it is too large. You can view the blob instead.
libstdc++-v3/docs/html/ext/lwg-closed.html 0 → 100644
This source diff could not be displayed because it is too large. You can view the blob instead.
libstdc++-v3/docs/html/ext/lwg-defects.html
......@@ -8,11 +8,11 @@ del {background-color:#FFFFA0}</style></head>
<table>
<tbody><tr>
<td align="left">Doc. no.</td>
<td align="left">N2092=06-0162</td>
<td align="left">N2131=06-0201</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>
......@@ -23,7 +23,7 @@ del {background-color:#FFFFA0}</style></head>
<td align="left">Howard Hinnant &lt;howard.hinnant@gmail.com&gt;</td>
</tr>
</tbody></table>
<h1>C++ Standard Library Defect Report List (Revision R44)</h1>
<h1>C++ Standard Library Defect Report List (Revision R45)</h1>
<p>Reference ISO/IEC IS 14882:1998(E)</p>
<p>Also see:</p>
<ul>
......@@ -45,6 +45,16 @@ del {background-color:#FFFFA0}</style></head>
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>.
......@@ -53,14 +63,14 @@ Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active
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>
......@@ -72,21 +82,21 @@ Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#30
</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:
......@@ -876,7 +886,7 @@ Change the entry for noconv in the table under paragraph 4 in section
unchanged, and there are no changes to the values in <tt>[to, to_limit)</tt>.</p>
</blockquote>
<hr>
<a name="20"><h3>20.&nbsp;Thousands_sep returns wrong type</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
<a name="20"></a><h3><a name="20">20.&nbsp;Thousands_sep returns wrong type</a></h3><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
<p>The synopsis for numpunct&lt;&gt;::do_thousands_sep, and the
definition of numpunct&lt;&gt;::thousands_sep which calls it, specify
that it returns a value of type char_type. Here it is erroneously
......@@ -1665,7 +1675,7 @@ base class, exception, with exception(msg). Class exception (see
<p>EFFECTS: Constructs an object of class <tt>failure</tt>.</p>
</blockquote>
<hr>
<a name="49"></a><h3><a name="49">49.&nbsp;Underspecification of ios_base::sync_with_stdio</a></h3><p><b>Section:</b>&nbsp;27.4.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;21 Jun 1998</p>
<a name="49"><h3>49.&nbsp;Underspecification of ios_base::sync_with_stdio</h3></a><p><b>Section:</b>&nbsp;27.4.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;21 Jun 1998</p>
<p>Two problems</p>
<p>(1) 27.4.2.4 doesn't say what ios_base::sync_with_stdio(f)
......@@ -3990,7 +4000,7 @@ This requirement is a bit weird. There's no similar requirement
for basic_streambuf&lt;&gt;::seekpos, or for basic_filebuf&lt;&gt;::seekoff or
basic_filebuf&lt;&gt;::seekpos.]</i></p>
<hr>
<a name="137"></a><h3><a name="137">137.&nbsp;Do use_facet and has_facet look in the global locale?</a></h3><p><b>Section:</b>&nbsp;22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;17 Mar 1999</p>
<a name="137"><h3>137.&nbsp;Do use_facet and has_facet look in the global locale?</h3></a><p><b>Section:</b>&nbsp;22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;17 Mar 1999</p>
<p>Section 22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a> says:</p>
<p>-4- In the call to use_facet&lt;Facet&gt;(loc), the type argument
......@@ -4060,7 +4070,7 @@ proposed resolution.]</i></p>
<tt><br>
</tt>&#8212; <tt>xpos &lt;= pos</tt> and <tt>xpos &lt; size();</tt></p>
<hr>
<a name="142"></a><h3><a name="142">142.&nbsp;lexicographical_compare complexity wrong</a></h3><p><b>Section:</b>&nbsp;25.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.lex.comparison"> [lib.alg.lex.comparison]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;20 Jun 1999</p>
<a name="142"><h3>142.&nbsp;lexicographical_compare complexity wrong</h3></a><p><b>Section:</b>&nbsp;25.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.lex.comparison"> [lib.alg.lex.comparison]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;20 Jun 1999</p>
<p>The lexicographical_compare complexity is specified as:<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp; "At most min((last1 - first1), (last2 - first2))
......@@ -4198,7 +4208,7 @@ follows an "all-or-none" rule.</p>
<p>For inserters, the LWG believes there is no defect; the standard is correct
as written.</p>
<hr>
<a name="147"></a><h3><a name="147">147.&nbsp;Library Intro refers to global functions that aren't global</a></h3><p><b>Section:</b>&nbsp;17.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.global.functions"> [lib.global.functions]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Lois Goldthwaite&nbsp; <b>Date:</b>&nbsp;4 Jun 1999</p>
<a name="147"><h3>147.&nbsp;Library Intro refers to global functions that aren't global</h3></a><p><b>Section:</b>&nbsp;17.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.global.functions"> [lib.global.functions]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Lois Goldthwaite&nbsp; <b>Date:</b>&nbsp;4 Jun 1999</p>
<p>The library had many global functions until 17.4.1.1 [lib.contents]
paragraph 2 was added: </p>
......@@ -4716,8 +4726,8 @@ paragraph 14 from:</p>
<p><i>[Kona: Dietmar is working on a proposed resolution.]</i></p>
<p><i>[Post-Tokyo: Dietmar supplied the above wording.]</i></p>
<hr>
<a name="172"></a><h3><a name="172">172.&nbsp;Inconsistent types for <tt>basic_istream::ignore()</tt>
</a></h3><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Greg Comeau, Dietmar Khl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
<a name="172"><h3>172.&nbsp;Inconsistent types for <tt>basic_istream::ignore()</tt>
</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Greg Comeau, Dietmar Khl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
<p>In 27.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream"> [lib.istream]</a> the function
<tt>ignore()</tt> gets an object of type <tt>streamsize</tt> as first
argument. However, 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>
......@@ -5249,7 +5259,7 @@ error. The full text was supplied by Bill Plauger; it was cross
checked against changes supplied by Andy Sawyer. It should be further
checked by the LWG.]</i></p>
<hr>
<a name="184"></a><h3><a name="184">184.&nbsp;numeric_limits&lt;bool&gt; wording problems</a></h3><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Gabriel Dos Reis&nbsp; <b>Date:</b>&nbsp;21 Jul 1999</p>
<a name="184"><h3>184.&nbsp;numeric_limits&lt;bool&gt; wording problems</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Gabriel Dos Reis&nbsp; <b>Date:</b>&nbsp;21 Jul 1999</p>
<p>bools are defined by the standard to be of integer types, as per
3.9.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/basic.html#basic.fundamental"> [basic.fundamental]</a> paragraph 7. However "integer types"
seems to have a special meaning for the author of 18.2. The net effect
......@@ -7804,7 +7814,7 @@ Change the following sentence in 21.3 paragraph 5 from
or rend().
</blockquote>
<hr>
<a name="264"><h3>264.&nbsp;Associative container <tt>insert(i, j)</tt> complexity requirements are not feasible.</h3></a><p><b>Section:</b>&nbsp;23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;John Potter&nbsp; <b>Date:</b>&nbsp;07 Sep 2000</p>
<a name="264"></a><h3><a name="264">264.&nbsp;Associative container <tt>insert(i, j)</tt> complexity requirements are not feasible.</a></h3><p><b>Section:</b>&nbsp;23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;John Potter&nbsp; <b>Date:</b>&nbsp;07 Sep 2000</p>
<p>
Table 69 requires linear time if [i, j) is sorted. Sorted is necessary but not sufficient.
Consider inserting a sorted range of even integers into a set&lt;int&gt; containing the odd
......@@ -8321,7 +8331,7 @@ the arguments it was given.
ios_base::iostate&amp; err, float&amp; val) const;
</pre>
<hr>
<a name="276"><h3>276.&nbsp;Assignable requirement for container value type overly strict</h3></a><p><b>Section:</b>&nbsp;23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Peter Dimov&nbsp; <b>Date:</b>&nbsp;07 Nov 2000</p>
<a name="276"></a><h3><a name="276">276.&nbsp;Assignable requirement for container value type overly strict</a></h3><p><b>Section:</b>&nbsp;23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Peter Dimov&nbsp; <b>Date:</b>&nbsp;07 Nov 2000</p>
<p>
23.1/3 states that the objects stored in a container must be
Assignable. 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a>, paragraph 2,
......@@ -10983,7 +10993,7 @@ declares struct tm as an incomplete type. However, table 48 in 21.4 <a href="htt
<p><b>Proposed resolution:</b></p>
<p>In section 21.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.c.strings"> [lib.c.strings]</a>, add "tm" to table 48.</p>
<hr>
<a name="346"><h3>346.&nbsp;Some iterator member functions should be const</h3></a><p><b>Section:</b>&nbsp;24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Jeremy Siek&nbsp; <b>Date:</b>&nbsp;20 Oct 2001</p>
<a name="346"></a><h3><a name="346">346.&nbsp;Some iterator member functions should be const</a></h3><p><b>Section:</b>&nbsp;24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Jeremy Siek&nbsp; <b>Date:</b>&nbsp;20 Oct 2001</p>
<p>Iterator member functions and operators that do not change the state
of the iterator should be defined as const member functions or as
functions that take iterators either by const reference or by
......@@ -11719,7 +11729,7 @@ with the following signature:</p>
<p><b>Rationale:</b></p>
<p>Fixes an obvious typo.</p>
<hr>
<a name="371"></a><h3><a name="371">371.&nbsp;Stability of multiset and multimap member functions</a></h3><p><b>Section:</b>&nbsp;23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Frank Compagner&nbsp; <b>Date:</b>&nbsp;20 Jul 2002</p>
<a name="371"><h3>371.&nbsp;Stability of multiset and multimap member functions</h3></a><p><b>Section:</b>&nbsp;23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Frank Compagner&nbsp; <b>Date:</b>&nbsp;20 Jul 2002</p>
<p>
The requirements for multiset and multimap containers (23.1
[lib.containers.requirements], 23.1.2 [lib.associative.reqmnts],
......@@ -12386,7 +12396,7 @@ In 21.3.5.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.htm
Throws: Shall not throw exceptions.
</p>
<hr>
<a name="404"></a><h3><a name="404">404.&nbsp;May a replacement allocation function be declared inline?</a></h3><p><b>Section:</b>&nbsp;17.4.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a>, 18.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete"> [lib.new.delete]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;24 Apr 2003</p>
<a name="404"><h3>404.&nbsp;May a replacement allocation function be declared inline?</h3></a><p><b>Section:</b>&nbsp;17.4.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a>, 18.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete"> [lib.new.delete]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;24 Apr 2003</p>
<p>
The eight basic dynamic memory allocation functions (single-object
and array versions of ::operator new and ::operator delete, in the
......@@ -13910,7 +13920,7 @@ to a field that is a static data member or a function member is
undefined."
</blockquote>
<hr>
<a name="453"><h3>453.&nbsp;basic_stringbuf::seekoff need not always fail for an empty stream</h3></a><p><b>Section:</b>&nbsp;27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Bill Plauger&nbsp; <b>Date:</b>&nbsp;30 Jan 2004</p>
<a name="453"></a><h3><a name="453">453.&nbsp;basic_stringbuf::seekoff need not always fail for an empty stream</a></h3><p><b>Section:</b>&nbsp;27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Bill Plauger&nbsp; <b>Date:</b>&nbsp;30 Jan 2004</p>
<pre> pos_type basic_stringbuf::seekoff(off_type, ios_base::seekdir,
ios_base::openmode);
</pre>
......@@ -14736,6 +14746,125 @@ In the case where <tt>N == 0</tt>, <tt>begin() == end()</tt>. The return value
of <tt>data()</tt> is unspecified.
</blockquote>
<hr>
<a name="520"><h3>520.&nbsp;Result_of and pointers to data members</h3></a><p><b>Section:</b>&nbsp;TR1 3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.func.bind"> [tr.func.bind]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Pete Becker&nbsp; <b>Date:</b>&nbsp;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&amp;</tt> when <tt>T1</tt> is <tt><i>cv</i> U1&amp;</tt>,
<tt>R</tt> otherwise.</li>
</ol>
<p><i>[
Peter provided wording.
]</i></p>
<hr>
<a name="521"><h3>521.&nbsp;Garbled requirements for argument_type in reference_wrapper</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Pete Becker&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
<p>
2.1.2/3, second bullet item currently says that reference_wrapper&lt;T&gt; is
derived from unary_function&lt;T, R&gt; 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="530"><h3>530.&nbsp;Must elements of a string be contiguous?</h3></a><p><b>Section:</b>&nbsp;21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;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
&nbsp;&nbsp; that the elements of a vector must be stored in contiguous memory.
&nbsp;&nbsp; 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>
&nbsp; defines <tt>operator[]</tt> as <tt>data()[pos]</tt>. What's missing
&nbsp; is a similar guarantee if we access the string's elements via the
&nbsp; iterator interface.</p>
<p>Given the existence of <tt>data()</tt>, and the definition of
&nbsp; <tt>operator[]</tt> and <tt>at</tt> in terms of <tt>data</tt>,
&nbsp; I don't believe it's possible to write a useful and standard-
&nbsp; conforming <tt>basic_string</tt> that isn't contiguous. I'm not
&nbsp; aware of any non-contiguous implementation. We should just require
&nbsp; 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>
&nbsp; <p>The characters in a string are stored contiguously, meaning that if
&nbsp; <tt>s</tt> is a <tt>basic_string&lt;charT, Allocator&gt;</tt>, then
&nbsp; it obeys the identity
&nbsp; <tt>&amp;*(s.begin() + n) == &amp;*s.begin() + n</tt>
&nbsp; for all <tt>0 &lt;= n &lt; s.size()</tt>.
</p>
</blockquote>
<hr>
<a name="533"><h3>533.&nbsp;typo in 2.2.3.10/1</h3></a><p><b>Section:</b>&nbsp;TR1 2.2.3.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.smartptr.getdeleter"> [tr.util.smartptr.getdeleter]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Paolo Carlini&nbsp; <b>Date:</b>&nbsp;9 Nov 2005</p>
<p>
I'm seeing something that looks like a typo. The Return of <tt>get_deleter</tt>
......@@ -14754,5 +14883,242 @@ Therefore, I think should be:
<blockquote>
If <tt><del>*this</del> <ins>p</ins></tt> <i>owns</i> a deleter <tt>d</tt>...
</blockquote>
<hr>
<a name="535"><h3>535.&nbsp;std::string::swap specification poorly worded</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;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="537"><h3>537.&nbsp;Typos in the signatures in 27.6.1.3/42-43 and 27.6.2.4</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Paolo Carlini&nbsp; <b>Date:</b>&nbsp;12 Feb 2006</p>
<p>
In the most recent working draft, I'm still seeing:
</p>
<blockquote><pre>seekg(off_type&amp; off, ios_base::seekdir dir)
</pre></blockquote>
<p>
and
</p>
<blockquote><pre>seekp(pos_type&amp; pos)
seekp(off_type&amp; 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&lt;charT,traits&gt;&amp; seekg(off_type<del>&amp;</del> <i>off</i>, ios_base::seekdir <i>dir</i>);
</pre></blockquote>
<p>
After 27.6.2.4p1 change:
</p>
<blockquote><pre>basic_ostream&lt;charT,traits&gt;&amp; seekp(pos_type<del>&amp;</del> <i>pos</i>);
</pre></blockquote>
<p>
After 27.6.2.4p3 change:
</p>
<blockquote><pre>basic_ostream&lt;charT,traits&gt;&amp; seekp(off_type<del>&amp;</del> <i>off</i>, ios_base::seekdir <i>dir</i>);
</pre></blockquote>
<hr>
<a name="538"></a><h3><a name="538">538.&nbsp;241 again: Does unique_copy() require CopyConstructible and Assignable?</a></h3><p><b>Section:</b>&nbsp;25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;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="540"><h3>540.&nbsp;shared_ptr&lt;void&gt;::operator*()</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;15 Oct 2005</p>
<p>
I'm trying to reconcile the note in tr.util.smartptr.shared.obs, p6
that talks about the operator*() member function of shared_ptr:
</p>
<blockquote>
Notes: When T is void, attempting to instantiate this member function
renders the program ill-formed. [Note: Instantiating shared_ptr&lt;void&gt;
does not necessarily result in instantiating this member function.
--end note]
</blockquote>
<p>
with the requirement in temp.inst, p1:
</p>
<blockquote>
The implicit instantiation of a class template specialization causes
the implicit instantiation of the declarations, but not of the
definitions...
</blockquote>
<p>
I assume that what the note is really trying to say is that
"instantiating shared_ptr&lt;void&gt; *must not* result in instantiating
this member function." That is, that this function must not be
declared a member of shared_ptr&lt;void&gt;. Is my interpretation
correct?
</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&lt;void&gt;</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.&nbsp;shared_ptr template assignment and void</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;16 Oct 2005</p>
<p>
Is the void specialization of the template assignment operator taking
a shared_ptr&lt;void&gt; as an argument supposed be well-formed?
</p>
<p>
I.e., is this snippet well-formed:
</p>
<blockquote><pre>shared_ptr&lt;void&gt; p;
p.operator=&lt;void&gt;(p);
</pre></blockquote>
<p>
Gcc complains about auto_ptr&lt;void&gt;::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&lt;void&gt;
operator*() as with the same operator in shared_ptr&lt;void&gt;.
</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 &lt;class T&gt;
struct A { T&amp; operator*() { return *(T*)0; } };
template &lt;class T&gt;
struct B {
void operator= (const B&amp;) { }
template &lt;class U&gt;
void operator= (const B&lt;U&gt;&amp;) { }
template &lt;class U&gt;
void operator= (const A&lt;U&gt;&amp;) { }
};
int main ()
{
B&lt;void&gt; b;
b.operator=&lt;void&gt;(b);
}
</pre></blockquote>
<p><b>Proposed resolution:</b></p>
<p>
In [lib.memory] change:
</p>
<blockquote><pre>template&lt;class X&gt; class auto_ptr;
<ins>template&lt;&gt; class auto_ptr&lt;void&gt;;</ins>
</pre></blockquote>
<p>
In [lib.auto.ptr]/2 add the following before the last closing brace:
</p>
<blockquote><pre>template&lt;&gt; class auto_ptr&lt;void&gt;
{
public:
&nbsp; &nbsp; typedef void element_type;
};
</pre></blockquote>
<p>----- End of document -----</p>
</body></html>
\ No newline at end of file
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment