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
This commit is contained in:
Paolo Carlini
Paolo Carlini
parent
f4d4085c10
commit
449c480110
|
|
@ -1,3 +1,9 @@
|
|||
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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
|
|
@ -8,11 +8,11 @@ del {background-color:#FFFFA0}</style></head>
|
|||
<table>
|
||||
<tbody><tr>
|
||||
<td align="left">Doc. no.</td>
|
||||
<td align="left">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 <howard.hinnant@gmail.com></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. Thousands_sep returns wrong type</h3></a><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
||||
<a name="20"></a><h3><a name="20">20. Thousands_sep returns wrong type</a></h3><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 6 Aug 1998</p>
|
||||
<p>The synopsis for numpunct<>::do_thousands_sep, and the
|
||||
definition of numpunct<>::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. Underspecification of ios_base::sync_with_stdio</a></h3><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 21 Jun 1998</p>
|
||||
<a name="49"><h3>49. Underspecification of ios_base::sync_with_stdio</h3></a><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 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<>::seekpos, or for basic_filebuf<>::seekoff or
|
||||
basic_filebuf<>::seekpos.]</i></p>
|
||||
<hr>
|
||||
<a name="137"></a><h3><a name="137">137. Do use_facet and has_facet look in the global locale?</a></h3><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#TC">TC</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 17 Mar 1999</p>
|
||||
<a name="137"><h3>137. Do use_facet and has_facet look in the global locale?</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#TC">TC</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 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<Facet>(loc), the type argument
|
||||
|
|
@ -4060,7 +4070,7 @@ proposed resolution.]</i></p>
|
|||
<tt><br>
|
||||
</tt>— <tt>xpos <= pos</tt> and <tt>xpos < size();</tt></p>
|
||||
<hr>
|
||||
<a name="142"></a><h3><a name="142">142. lexicographical_compare complexity wrong</a></h3><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 20 Jun 1999</p>
|
||||
<a name="142"><h3>142. lexicographical_compare complexity wrong</h3></a><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 20 Jun 1999</p>
|
||||
<p>The lexicographical_compare complexity is specified as:<br>
|
||||
<br>
|
||||
"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. Library Intro refers to global functions that aren't global</a></h3><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Lois Goldthwaite <b>Date:</b> 4 Jun 1999</p>
|
||||
<a name="147"><h3>147. Library Intro refers to global functions that aren't global</h3></a><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a> <b>Submitter:</b> Lois Goldthwaite <b>Date:</b> 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. Inconsistent types for <tt>basic_istream::ignore()</tt>
|
||||
</a></h3><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#TC">TC</a> <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 23 Jul 1999</p>
|
||||
<a name="172"><h3>172. Inconsistent types for <tt>basic_istream::ignore()</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#TC">TC</a> <b>Submitter:</b> Greg Comeau, Dietmar Kühl <b>Date:</b> 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. numeric_limits<bool> wording problems</a></h3><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#WP">WP</a> <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 21 Jul 1999</p>
|
||||
<a name="184"><h3>184. numeric_limits<bool> wording problems</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#WP">WP</a> <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 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. Associative container <tt>insert(i, j)</tt> complexity requirements are not feasible.</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#WP">WP</a> <b>Submitter:</b> John Potter <b>Date:</b> 07 Sep 2000</p>
|
||||
<a name="264"></a><h3><a name="264">264. Associative container <tt>insert(i, j)</tt> complexity requirements are not feasible.</a></h3><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#WP">WP</a> <b>Submitter:</b> John Potter <b>Date:</b> 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<int> containing the odd
|
||||
|
|
@ -8321,7 +8331,7 @@ the arguments it was given.
|
|||
ios_base::iostate& err, float& val) const;
|
||||
</pre>
|
||||
<hr>
|
||||
<a name="276"><h3>276. Assignable requirement for container value type overly strict</h3></a><p><b>Section:</b> 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Peter Dimov <b>Date:</b> 07 Nov 2000</p>
|
||||
<a name="276"></a><h3><a name="276">276. Assignable requirement for container value type overly strict</a></h3><p><b>Section:</b> 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Peter Dimov <b>Date:</b> 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. Some iterator member functions should be const</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#WP">WP</a> <b>Submitter:</b> Jeremy Siek <b>Date:</b> 20 Oct 2001</p>
|
||||
<a name="346"></a><h3><a name="346">346. Some iterator member functions should be const</a></h3><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#WP">WP</a> <b>Submitter:</b> Jeremy Siek <b>Date:</b> 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. Stability of multiset and multimap member functions</a></h3><p><b>Section:</b> 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Frank Compagner <b>Date:</b> 20 Jul 2002</p>
|
||||
<a name="371"><h3>371. Stability of multiset and multimap member functions</h3></a><p><b>Section:</b> 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Frank Compagner <b>Date:</b> 20 Jul 2002</p>
|
||||
<p>
|
||||
The requirements for multiset and multimap containers (23.1
|
||||
[lib.containers.requirements], 23.1.2 [lib.associative.reqmnts],
|
||||
|
|
@ -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. May a replacement allocation function be declared inline?</a></h3><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 24 Apr 2003</p>
|
||||
<a name="404"><h3>404. May a replacement allocation function be declared inline?</h3></a><p><b>Section:</b> 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> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 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. basic_stringbuf::seekoff need not always fail for an empty stream</h3></a><p><b>Section:</b> 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 30 Jan 2004</p>
|
||||
<a name="453"></a><h3><a name="453">453. basic_stringbuf::seekoff need not always fail for an empty stream</a></h3><p><b>Section:</b> 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 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. 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#WP">WP</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.
|
||||
]</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#WP">WP</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="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#WP">WP</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="533"><h3>533. typo in 2.2.3.10/1</h3></a><p><b>Section:</b> TR1 2.2.3.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.smartptr.getdeleter"> [tr.util.smartptr.getdeleter]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a> <b>Submitter:</b> Paolo Carlini <b>Date:</b> 9 Nov 2005</p>
|
||||
<p>
|
||||
I'm seeing something that looks like a typo. The Return of <tt>get_deleter</tt>
|
||||
|
|
@ -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. 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#WP">WP</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="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#WP">WP</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"></a><h3><a name="538">538. 241 again: Does unique_copy() require CopyConstructible and Assignable?</a></h3><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#WP">WP</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="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#WP">WP</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 15 Oct 2005</p>
|
||||
<p>
|
||||
I'm trying to reconcile the note in tr.util.smartptr.shared.obs, p6
|
||||
that talks about the operator*() member function of shared_ptr:
|
||||
</p>
|
||||
|
||||
<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:
|
||||
</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<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?
|
||||
</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#WP">WP</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>
|
||||
|
||||
<p>----- End of document -----</p>
|
||||
</body></html>
|
||||
Loading…
Reference in New Issue