| <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> |
| <html><head><title>C++ Standard Library Closed Issues List</title> |
| |
| <style>ins {background-color:#FFFFA0} |
| del {background-color:#FFFFA0}</style></head> |
| |
| <body bgcolor="#ffffff" text="#000000"> |
| <table> |
| <tbody><tr> |
| <td align="left">Doc. no.</td> |
| <td align="left">N2132=06-0202</td> |
| </tr> |
| <tr> |
| <td align="left">Date:</td> |
| <td align="left">2006-11-03</td> |
| </tr> |
| <tr> |
| <td align="left">Project:</td> |
| <td align="left">Programming Language C++</td> |
| </tr> |
| <tr> |
| <td align="left">Reply to:</td> |
| <td align="left">Howard Hinnant <howard.hinnant@gmail.com></td> |
| </tr> |
| </tbody></table> |
| <h1>C++ Standard Library Closed Issues List (Revision R45)</h1> |
| <p>Reference ISO/IEC IS 14882:1998(E)</p> |
| <p>Also see:</p> |
| <ul> |
| <li> |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html">Table of Contents</a> for all library issues.</li> |
| <li> |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html">Index by Section</a> for all library issues.</li> |
| <li> |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html">Index by Status</a> for all library issues.</li> |
| <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a></li> |
| <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a></li> |
| </ul> |
| |
| <p>This document contains only library issues which have been closed |
| by the Library Working Group as duplicates or not defects. That is, |
| issues which have a status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> or <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a>. See the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a> active issues and more |
| information. See the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">Library Defect Reports List</a> for issues considered |
| defects. The introductory material in that document also applies to |
| this document.</p> |
| <h2>Revision History</h2> |
| <ul> |
| <li>R45: |
| 2006-11-03 post-Portland mailing. |
| Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a> to WP. |
| Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#554">554</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#555">555</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#558">558</a> to NAD. |
| Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup. |
| Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#524">524</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#542">542</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#556">556</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#557">557</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#559">559</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#597">597</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#606">606</a> to Open. |
| Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#543">543</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#545">545</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#598">598</a> - <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#603">603</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#605">605</a> to Ready. |
| Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#551">551</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#604">604</a> to Review. |
| Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#593">593</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#609">609</a>. |
| </li> |
| <li>R44: |
| 2006-09-08 pre-Portland mailing. |
| Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#583">583</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#592">592</a>. |
| </li> |
| <li>R43: |
| 2006-06-23 mid-term mailing. |
| Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#575">575</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#582">582</a>. |
| Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#255">255</a>. |
| Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#520">520</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">541</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#544">544</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Tentatively Ready. |
| </li> |
| <li>R42: |
| 2006-04-21 post-Berlin mailing. |
| Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#567">567</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#572">572</a>. |
| Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#499">499</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#501">501</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#517">517</a> to NAD. |
| Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#502">502</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#515">515</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#516">516</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#525">525</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#532">532</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#536">536</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539">539</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#548">548</a> to Open. |
| Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#521">521</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#530">530</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#531">531</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#537">537</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#538">538</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#540">540</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#549">549</a> to Ready. |
| Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> to WP. |
| Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#534">534</a> to Review. |
| </li> |
| <li>R41: |
| 2006-02-24 pre-Berlin mailing. |
| Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#536">536</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#566">566</a>. |
| Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a> from Ready to Open. |
| Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309">309</a>. |
| </li> |
| <li>R40: |
| 2005-12-16 mid-term mailing. |
| Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#529">529</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#535">535</a>. |
| </li> |
| <li>R39: |
| 2005-10-14 post-Mont Tremblant mailing. |
| Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#526">526</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#528">528</a>. |
| Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#461">461</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#464">464</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#465">465</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#467">467</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#468">468</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#474">474</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#496">496</a> from Ready to WP as per the vote from Mont Tremblant. |
| Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#247">247</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#294">294</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#369">369</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#371">371</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#376">376</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#384">384</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#475">475</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#495">495</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#497">497</a> from Review to Ready. |
| Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#506">506</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#509">509</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#510">510</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#511">511</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#512">512</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#513">513</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#514">514</a> from New to Open. |
| Moved issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#505">505</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#507">507</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#508">508</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#519">519</a> from New to Ready. |
| Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD. |
| Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a> from New to Review. |
| </li> |
| <li>R38: |
| 2005-07-03 pre-Mont Tremblant mailing. |
| Merged open TR1 issues in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#522">522</a>. |
| Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#523">523</a> |
| </li> |
| <li>R37: |
| 2005-06 mid-term mailing. |
| Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#498">498</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#503">503</a>. |
| </li> |
| <li>R36: |
| 2005-04 post-Lillehammer mailing. All issues in "ready" status except |
| for <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#454">454</a> were moved to "DR" status, and all issues |
| previously in "DR" status were moved to "WP". |
| </li> |
| <li>R35: |
| 2005-03 pre-Lillehammer mailing. |
| </li> |
| <li>R34: |
| 2005-01 mid-term mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#488">488</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#494">494</a>. |
| </li> |
| <li>R33: |
| 2004-11 post-Redmond mailing. Reflects actions taken in Redmond. |
| </li> |
| <li>R32: |
| 2004-09 pre-Redmond mailing: reflects new proposed resolutions and |
| new issues received after the 2004-07 mailing. Added |
| new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#479">479</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#481">481</a>. |
| </li> |
| <li>R31: |
| 2004-07 mid-term mailing: reflects new proposed resolutions and |
| new issues received after the post-Sydney mailing. Added |
| new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463">463</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>. |
| </li> |
| <li>R30: |
| Post-Sydney mailing: reflects decisions made at the Sydney meeting. |
| Voted all "Ready" issues from R29 into the working paper. |
| Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#460">460</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#462">462</a>. |
| </li> |
| <li>R29: |
| Pre-Sydney mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#441">441</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#457">457</a>. |
| </li> |
| <li>R28: |
| Post-Kona mailing: reflects decisions made at the Kona meeting. |
| Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#432">432</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#440">440</a>. |
| </li> |
| <li>R27: |
| Pre-Kona mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#404">404</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#431">431</a>. |
| </li> |
| <li>R26: |
| Post-Oxford mailing: reflects decisions made at the Oxford meeting. |
| All issues in Ready status were voted into DR status. All issues in |
| DR status were voted into WP status. |
| </li> |
| <li>R25: |
| Pre-Oxford mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#390">390</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#402">402</a>. |
| </li> |
| <li>R24: |
| Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz |
| meeting. All Ready issues from R23 with the exception of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, which has been given a new proposed resolution, were |
| moved to DR status. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#383">383</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a>. (Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#387">387</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#389">389</a> were discussed |
| at the meeting.) Made progress on issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a> have been moved to Ready status, and the only remaining |
| concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording. |
| </li> |
| <li>R23: |
| Pre-Santa Cruz mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#367">367</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#382">382</a>. |
| Moved issues in the TC to TC status. |
| </li> |
| <li>R22: |
| Post-Curaçao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#362">362</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#366">366</a>. |
| </li> |
| <li>R21: |
| Pre-Curaçao mailing. Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#351">351</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#361">361</a>. |
| </li> |
| <li>R20: |
| Post-Redmond mailing; reflects actions taken in Redmond. Added |
| new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#336">336</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, of which issues |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#347">347</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a> were added since Redmond, hence |
| not discussed at the meeting. |
| |
| All Ready issues were moved to DR status, with the exception of issues |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a>, and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>. |
| |
| Noteworthy issues discussed at Redmond include |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#120">120</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#202">202</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#233">233</a>, |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#254">254</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>. |
| </li> |
| <li>R19: |
| Pre-Redmond mailing. Added new issues |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#335">335</a>. |
| </li> |
| <li>R18: |
| Post-Copenhagen mailing; reflects actions taken in Copenhagen. |
| Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#317">317</a>, and discussed |
| new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>. |
| |
| Changed status of issues |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#118">118</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a> |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#165">165</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#171">171</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#183">183</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#184">184</a> |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#185">185</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#186">186</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#214">214</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#221">221</a> |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#234">234</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#237">237</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#243">243</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#248">248</a> |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#251">251</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#256">256</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#260">260</a> |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#261">261</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#262">262</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#263">263</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a> |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a> |
| to DR. |
| |
| Changed status of issues |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#117">117</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a> |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#230">230</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a> |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#238">238</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">241</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#242">242</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a> |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#259">259</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#266">266</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a> |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#271">271</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#273">273</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#275">275</a> |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#284">284</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#285">285</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#286">286</a> |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#288">288</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#292">292</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#295">295</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#297">297</a> |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#298">298</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#301">301</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#303">303</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#306">306</a> |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#307">307</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#308">308</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#312">312</a> |
| to Ready. |
| |
| Closed issues |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#277">277</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#287">287</a> |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#289">289</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#293">293</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#302">302</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#313">313</a> |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a> |
| as NAD. |
| |
| </li> |
| <li>R17: |
| Pre-Copenhagen mailing. Converted issues list to XML. Added proposed |
| resolutions for issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#49">49</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#76">76</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#235">235</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#267">267</a>. |
| Added new issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278">278</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#311">311</a>. |
| </li> |
| <li>R16: |
| post-Toronto mailing; reflects actions taken in Toronto. Added new |
| issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#265">265</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#277">277</a>. Changed status of issues |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#3">3</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#8">8</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#9">9</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#19">19</a>, |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#26">26</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#61">61</a>, |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#63">63</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#108">108</a>, |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#115">115</a>, |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#122">122</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>, |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#142">142</a>, |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#144">144</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#146">146</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#147">147</a>, |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#159">159</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#164">164</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#170">170</a>, |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#181">181</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#208">208</a>, |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#209">209</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#210">210</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>, |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#217">217</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#220">220</a>, |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#222">222</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#223">223</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#224">224</a>, |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a> to "DR". Reopened issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#23">23</a>. Reopened |
| issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#187">187</a>. Changed issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#2">2</a> and |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> to NAD. Fixed a typo in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a>. Fixed |
| issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#70">70</a>: signature should be changed both places it |
| appears. Fixed issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#160">160</a>: previous version didn't fix |
| the bug in enough places. |
| </li> |
| <li>R15: |
| pre-Toronto mailing. Added issues |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#233">233</a>-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a>. Some small HTML formatting |
| changes so that we pass Weblint tests. |
| </li> |
| <li>R14: |
| post-Tokyo II mailing; reflects committee actions taken in |
| Tokyo. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#232">232</a>. (00-0019R1/N1242) |
| </li> |
| <li>R13: |
| pre-Tokyo II updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#212">212</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a>. |
| </li> |
| <li>R12: |
| pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#211">211</a>. Added "and paragraph 5" to the proposed resolution |
| of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>. Add further rationale to issue |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>. |
| </li> |
| <li>R11: |
| post-Kona mailing: Updated to reflect LWG and full committee actions |
| in Kona (99-0048/N1224). Note changed resolution of issues |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#196">196</a> |
| to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#198">198</a>. Closed issues list split into "defects" and |
| "closed" documents. Changed the proposed resolution of issue |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#4">4</a> to NAD, and changed the wording of proposed resolution |
| of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>. |
| </li> |
| <li>R10: |
| pre-Kona updated. Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>, |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#86">86</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#91">91</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#92">92</a>, |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a>. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#190">190</a> to |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99) |
| </li> |
| <li>R9: |
| pre-Kona mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and |
| "closed" documents. (99-0030/N1206, 25 Aug 99) |
| </li> |
| <li>R8: |
| post-Dublin mailing. Updated to reflect LWG and full committee actions |
| in Dublin. (99-0016/N1193, 21 Apr 99) |
| </li> |
| <li>R7: |
| pre-Dublin updated: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#131">131</a>, |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#132">132</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#133">133</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#134">134</a>, |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#135">135</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#136">136</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#137">137</a>, |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#139">139</a> (31 Mar 99) |
| </li> |
| <li>R6: |
| pre-Dublin mailing. Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#127">127</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#128">128</a>, |
| and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>. (99-0007/N1194, 22 Feb 99) |
| </li> |
| <li>R5: |
| update issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>; added issues |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#126">126</a>. Format revisions to prepare |
| for making list public. (30 Dec 98) |
| </li> |
| <li>R4: |
| post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>, |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#111">111</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#112">112</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#113">113</a> added, several |
| issues corrected. (22 Oct 98) |
| </li> |
| <li>R3: |
| post-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#94">94</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109">109</a> |
| added, many issues updated to reflect LWG consensus (12 Oct 98) |
| </li> |
| <li>R2: |
| pre-Santa Cruz II: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a> to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#93">93</a> added, |
| issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98) |
| </li> |
| <li>R1: |
| Correction to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#55">55</a> resolution, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a> code |
| format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98) |
| </li> |
| </ul> |
| <h2>Closed Issues</h2> |
| <hr> |
| <a name="2"><h3>2. Auto_ptr conversions effects incorrect</h3></a><p><b>Section:</b> 20.4.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.unary.prop"> [lib.meta.unary.prop]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 4 Dec 1997</p> |
| <p>Paragraph 1 in "Effects", says "Calls |
| p->release()" where it clearly must be "Calls |
| p.release()". (As it is, it seems to require using |
| auto_ptr<>::operator-> to refer to X::release, assuming that |
| exists.)</p> |
| <p><b>Proposed resolution:</b></p> |
| <p>Change 20.4.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.unary.prop"> [lib.meta.unary.prop]</a> paragraph 1 Effects from |
| "Calls p->release()" to "Calls p.release()".</p> |
| <p><b>Rationale:</b></p> |
| <p>Not a defect: the proposed change is already found in the standard. |
| [Originally classified as a defect, later reclassified.]</p> |
| <hr> |
| <a name="4"><h3>4. Basic_string size_type and difference_type should be implementation defined</h3></a><p><b>Section:</b> 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 16 Nov 1997</p> |
| <p>In Morristown we changed the size_type and difference_type typedefs |
| for all the other containers to implementation defined with a |
| reference to 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>. This should probably also have been |
| done for strings. </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>Not a defect. [Originally classified as a defect, later |
| reclassified.] basic_string, unlike the other standard library |
| template containers, is severely constrained by its use of |
| char_traits. Those types are dictated by the traits class, and are far |
| from implementation defined.</p> |
| <hr> |
| <a name="6"><h3>6. File position not an offset unimplementable</h3></a><p><b>Section:</b> 27.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos"> [lib.fpos]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 15 Dec 1997</p> |
| <p>Table 88, in I/O, is too strict; it's unimplementable on systems |
| where a file position isn't just an offset. It also never says just |
| what fpos<> is really supposed to be. [Here's my summary, which |
| Jerry agrees is more or less accurate. "I think I now know what |
| the class really is, at this point: it's a magic cookie that |
| encapsulates an mbstate_t and a file position (possibly represented as |
| an fpos_t), it has syntactic support for pointer-like arithmetic, and |
| implementors are required to have real, not just syntactic, support |
| for arithmetic." This isn't standardese, of course.] </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>Not a defect. The LWG believes that the Standard is already clear, |
| and that the above summary is what the Standard in effect says.</p> |
| <hr> |
| <a name="10"><h3>10. Codecvt<>::do unclear</h3></a><p><b>Section:</b> 22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 14 Jan 1998</p> |
| <p>Section 22.2.1.5.2 says that codecvt<>::do_in and do_out |
| should return the value noconv if "no conversion was |
| needed". However, I don't see anything anywhere that defines what |
| it means for a conversion to be needed or not needed. I can think of |
| several circumstances where one might plausibly think that a |
| conversion is not "needed", but I don't know which one is |
| intended here. </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>Duplicate. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#19">19</a>.</p> |
| <hr> |
| <a name="12"><h3>12. Way objects hold allocators unclear</h3></a><p><b>Section:</b> 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.default.con.req"> [lib.default.con.req]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 23 Feb 1998</p> |
| <p>I couldn't find a statement in the standard saying whether the allocator object held by |
| a container is held as a copy of the constructor argument or whether a pointer of |
| reference is maintained internal. There is an according statement for compare objects and |
| how they are maintained by the associative containers, but I couldn't find anything |
| regarding allocators. </p> |
| |
| <p>Did I overlook it? Is it an open issue or known defect? Or is it deliberately left |
| unspecified? </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>Not a defect. The LWG believes that the Standard is already |
| clear. See 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>, paragraph 8.</p> |
| <hr> |
| <a name="43"><h3>43. Locale table correction</h3></a><p><b>Section:</b> 22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Brendan Kehoe <b>Date:</b> 1 Jun 1998</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>Duplicate. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#33">33</a>.</p> |
| <hr> |
| <a name="45"><h3>45. Stringstreams read/write pointers initial position unclear</h3></a><p><b>Section:</b> 27.7.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostringstream"> [lib.ostringstream]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Matthias Mueller <b>Date:</b> 27 May 1998</p> |
| <p>In a comp.lang.c++.moderated Matthias Mueller wrote:</p> |
| |
| <p>"We are not sure how to interpret the CD2 (see 27.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.forward"> [lib.iostream.forward]</a>, 27.7.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostringstream.cons"> [lib.ostringstream.cons]</a>, 27.7.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.cons"> [lib.stringbuf.cons]</a>) |
| with respect to the question as to what the correct initial positions |
| of the write and read pointers of a stringstream should |
| be."</p> |
| |
| <p>"Is it the same to output two strings or to initialize the stringstream with the |
| first and to output the second?"</p> |
| |
| <p><i>[PJ Plauger, Bjarne Stroustrup, Randy Smithey, Sean Corfield, and |
| Jerry Schwarz have all offered opinions; see reflector messages |
| lib-6518, 6519, 6520, 6521, 6523, 6524.]</i></p> |
| |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>The LWG believes the Standard is correct as written. The behavior |
| of stringstreams is consistent with fstreams, and there is a |
| constructor which can be used to obtain the desired effect. This |
| behavior is known to be different from strstreams.</p> |
| <hr> |
| <a name="58"><h3>58. Extracting a char from a wide-oriented stream</h3></a><p><b>Section:</b> 27.6.1.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 1 Jul 1998</p> |
| <p>27.6.1.2.3 has member functions for extraction of signed char and |
| unsigned char, both singly and as strings. However, it doesn't say |
| what it means to extract a <tt>char</tt> from a |
| <tt>basic_streambuf<charT, Traits></tt>. </p> |
| |
| <p>basic_streambuf, after all, has no members to extract a char, so |
| basic_istream must somehow convert from charT to signed char or |
| unsigned char. The standard doesn't say how it is to perform that |
| conversion. </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>The Standard is correct as written. There is no such extractor and |
| this is the intent of the LWG.</p> |
| <hr> |
| <a name="65"><h3>65. Underspecification of strstreambuf::seekoff</h3></a><p><b>Section:</b> D.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 18 Aug 1998</p> |
| <p>The standard says how this member function affects the current |
| stream position. (<tt>gptr</tt> or <tt>pptr</tt>) However, it does not |
| say how this member function affects the beginning and end of the |
| get/put area. </p> |
| |
| <p>This is an issue when seekoff is used to position the get pointer |
| beyond the end of the current read area. (Which is legal. This is |
| implicit in the definition of <i>seekhigh</i> in D.7.1, paragraph 4.) |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>The LWG agrees that seekoff() is underspecified, but does not wish |
| to invest effort in this deprecated feature.</p> |
| <hr> |
| <a name="67"><h3>67. Setw useless for strings</h3></a><p><b>Section:</b> 21.3.7.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.io"> [lib.string.io]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 9 Jul 1998</p> |
| <p>In a comp.std.c++ posting Michel Michaud wrote: What |
| should be output by: </p> |
| |
| <pre> string text("Hello"); |
| cout << '[' << setw(10) << right << text << ']'; |
| </pre> |
| |
| <p>Shouldn't it be:</p> |
| |
| <pre> [ Hello]</pre> |
| |
| <p>Another person replied: Actually, according to the FDIS, the width |
| of the field should be the minimum of width and the length of the |
| string, so the output shouldn't have any padding. I think that this is |
| a typo, however, and that what is wanted is the maximum of the |
| two. (As written, setw is useless for strings. If that had been the |
| intent, one wouldn't expect them to have mentioned using its value.) |
| </p> |
| |
| <p>It's worth pointing out that this is a recent correction anyway; |
| IIRC, earlier versions of the draft forgot to mention formatting |
| parameters whatsoever.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>Duplicate. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#25">25</a>.</p> |
| <hr> |
| <a name="72"><h3>72. Do_convert phantom member function</h3></a><p><b>Section:</b> 22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 24 Aug 1998</p> |
| <p>In 22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a> par 3, and in <font color="red">22.2.1.5.2</font> par 8, a nonexistent member function |
| "do_convert" is mentioned. This member was replaced with |
| "do_in" and "do_out", the proper referents in the |
| contexts above.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>Duplicate: see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#24">24</a>.</p> |
| <hr> |
| <a name="73"><h3>73. <tt>is_open</tt> should be const</h3></a><p><b>Section:</b> 27.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstreams"> [lib.fstreams]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 27 Aug 1998</p> |
| <p>Classes <tt>basic_ifstream</tt>, <tt>basic_ofstream</tt>, and |
| <tt>basic_fstream</tt> all have a member function <tt>is_open</tt>. It |
| should be a <tt>const</tt> member function, since it does nothing but |
| call one of <tt>basic_filebuf</tt>'s const member functions. </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>Not a defect. This is a deliberate feature; const streams would be |
| meaningless.</p> |
| <hr> |
| <a name="77"></a><h3><a name="77">77. Valarray operator[] const returning value</a></h3><p><b>Section:</b> 26.5.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.access"> [lib.valarray.access]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Levente Farkas <b>Date:</b> 9 Sep 1998</p> |
| <p>valarray:<br> |
| <br> |
| <tt>T operator[] (size_t) const;</tt><br> |
| <br> |
| why not <br> |
| <br> |
| <tt>const T& operator[] (size_t) const;</tt><br> |
| <br> |
| as in vector ???<br> |
| <br> |
| One can't copy even from a const valarray eg:<br> |
| <br> |
| <tt>memcpy(ptr, &v[0], v.size() * sizeof(double));<br> |
| </tt><br> |
| [I] find this bug in valarray is very difficult.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>The LWG believes that the interface was deliberately designed that |
| way. That is what valarray was designed to do; that's where the |
| "value array" name comes from. LWG members further comment |
| that "we don't want valarray to be a full STL container." |
| 26.5.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.access"> [lib.valarray.access]</a> specifies properties that indicate "an |
| absence of aliasing" for non-constant arrays; this allows |
| optimizations, including special hardware optimizations, that are not |
| otherwise possible. </p> |
| <hr> |
| <a name="81"><h3>81. Wrong declaration of slice operations</h3></a><p><b>Section:</b> 26.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.member.ops"> [lib.complex.member.ops]</a>, 26.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.value.ops"> [lib.complex.value.ops]</a>, 26.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.transcendentals"> [lib.complex.transcendentals]</a>, 26.3.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.cmplx.over"> [lib.cmplx.over]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p> |
| <p>Isn't the definition of copy constructor and assignment operators wrong? |
| Instead of</p> |
| |
| <pre> slice_array(const slice_array&); |
| slice_array& operator=(const slice_array&);</pre> |
| |
| <p>IMHO they have to be</p> |
| |
| <pre> slice_array(const slice_array<T>&); |
| slice_array& operator=(const slice_array<T>&);</pre> |
| |
| <p>Same for gslice_array. </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>Not a defect. The Standard is correct as written. </p> |
| <hr> |
| <a name="82"><h3>82. Missing constant for set elements</h3></a><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p> |
| <p>Paragraph 5 specifies:</p> |
| |
| <blockquote> |
| For set and multiset the value type is the same as the key type. For |
| map and multimap it is equal to pair<const Key, T>. |
| </blockquote> |
| |
| <p>Strictly speaking, this is not correct because for set and multiset |
| the value type is the same as the <b>constant</b> key type.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>Not a defect. The Standard is correct as written; it uses a |
| different mechanism (const &) for <tt>set</tt> and |
| <tt>multiset</tt>. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> for a related |
| issue.</p> |
| <hr> |
| <a name="84"><h3>84. Ambiguity with string::insert()</h3></a><p><b>Section:</b> 21.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.modifiers"> [lib.string.modifiers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p> |
| <p>If I try</p> |
| <pre> s.insert(0,1,' ');</pre> |
| |
| <p> I get an nasty ambiguity. It might be</p> |
| <pre> s.insert((size_type)0,(size_type)1,(charT)' ');</pre> |
| |
| <p>which inserts 1 space character at position 0, or</p> |
| <pre> s.insert((char*)0,(size_type)1,(charT)' ')</pre> |
| |
| <p>which inserts 1 space character at iterator/address 0 (bingo!), or</p> |
| <pre> s.insert((char*)0, (InputIterator)1, (InputIterator)' ')</pre> |
| |
| <p>which normally inserts characters from iterator 1 to iterator ' |
| '. But according to 23.1.1.9 (the "do the right thing" fix) |
| it is equivalent to the second. However, it is still ambiguous, |
| because of course I mean the first!</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>Not a defect. The LWG believes this is a "genetic |
| misfortune" inherent in the design of string and thus not a |
| defect in the Standard as such .</p> |
| <hr> |
| <a name="85"><h3>85. String char types</h3></a><p><b>Section:</b> 21 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.strings"> [lib.strings]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p> |
| <p>The standard seems not to require that charT is equivalent to |
| traits::char_type. So, what happens if charT is not equivalent to |
| traits::char_type?</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>There is already wording in 21.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits"> [lib.char.traits]</a> paragraph 3 that |
| requires them to be the same.</p> |
| <hr> |
| <a name="87"><h3>87. Error in description of string::compare()</h3></a><p><b>Section:</b> 21.3.6.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::compare"> [lib.string::compare]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p> |
| <p>The following compare() description is obviously a bug:</p> |
| |
| <pre>int compare(size_type pos, size_type n1, |
| charT *s, size_type n2 = npos) const; |
| </pre> |
| |
| <p>because without passing n2 it should compare up to the end of the |
| string instead of comparing npos characters (which throws an |
| exception) </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>Duplicate; see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#5">5</a>.</p> |
| <hr> |
| <a name="88"><h3>88. Inconsistency between string::insert() and string::append()</h3></a><p><b>Section:</b> 21.3.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::insert"> [lib.string::insert]</a>, 21.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::append"> [lib.string::append]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p> |
| <p>Why does </p> |
| <pre> template<class InputIterator> |
| basic_string& append(InputIterator first, InputIterator last);</pre> |
| |
| <p>return a string, while</p> |
| <pre> template<class InputIterator> |
| void insert(iterator p, InputIterator first, InputIterator last);</pre> |
| |
| <p>returns nothing ?</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>The LWG believes this stylistic inconsistency is not sufficiently |
| serious to constitute a defect.</p> |
| <hr> |
| <a name="89"><h3>89. Missing throw specification for string::insert() and string::replace()</h3></a><p><b>Section:</b> 21.3.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::insert"> [lib.string::insert]</a>, 21.3.5.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::replace"> [lib.string::replace]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p> |
| <p>All insert() and replace() members for strings with an iterator as |
| first argument lack a throw specification. The throw |
| specification should probably be: length_error if size exceeds |
| maximum. </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>Considered a duplicate because it will be solved by the resolution |
| of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>.</p> |
| <hr> |
| <a name="93"><h3>93. Incomplete Valarray Subset Definitions</h3></a><p><b>Section:</b> 26.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.numbers"> [lib.complex.numbers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 29 Sep 1998</p> |
| <p>You can easily create subsets, but you can't easily combine them |
| with other subsets. Unfortunately, you almost always needs an |
| explicit type conversion to valarray. This is because the standard |
| does not specify that valarray subsets provide the same operations as |
| valarrays. </p> |
| |
| <p>For example, to multiply two subsets and assign the result to a third subset, you can't |
| write the following:</p> |
| |
| <pre>va[slice(0,4,3)] = va[slice(1,4,3)] * va[slice(2,4,3)];</pre> |
| |
| <p>Instead, you have to code as follows:</p> |
| |
| <pre>va[slice(0,4,3)] = static_cast<valarray<double> >(va[slice(1,4,3)]) * |
| static_cast<valarray<double> >(va[slice(2,4,3)]);</pre> |
| |
| <p>This is tedious and error-prone. Even worse, it costs performance because each cast |
| creates a temporary objects, which could be avoided without the cast. </p> |
| <p><b>Proposed resolution:</b></p> |
| <p>Extend all valarray subset types so that they offer all valarray operations.</p> |
| <p><b>Rationale:</b></p> |
| <p>This is not a defect in the Standard; it is a request for an extension.</p> |
| <hr> |
| <a name="94"><h3>94. May library implementors add template parameters to Standard Library classes?</h3></a><p><b>Section:</b> 17.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.conforming"> [lib.conforming]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 22 Jan 1998</p> |
| <p>Is it a permitted extension for library implementors to add template parameters to |
| standard library classes, provided that those extra parameters have defaults? For example, |
| instead of defining <tt>template <class T, class Alloc = allocator<T> > class |
| vector;</tt> defining it as <tt>template <class T, class Alloc = allocator<T>, |
| int N = 1> class vector;</tt> </p> |
| |
| <p>The standard may well already allow this (I can't think of any way that this extension |
| could break a conforming program, considering that users are not permitted to |
| forward-declare standard library components), but it ought to be explicitly permitted or |
| forbidden. </p> |
| |
| <p>comment from Steve Cleary via comp.std.c++:</p> |
| <blockquote> |
| <p>I disagree [with the proposed resolution] for the following reason: |
| consider user library code with template template parameters. For |
| example, a user library object may be templated on the type of |
| underlying sequence storage to use (deque/list/vector), since these |
| classes all take the same number and type of template parameters; this |
| would allow the user to determine the performance tradeoffs of the |
| user library object. A similar example is a user library object |
| templated on the type of underlying set storage (set/multiset) or map |
| storage (map/multimap), which would allow users to change (within |
| reason) the semantic meanings of operations on that object.</p> |
| <p>I think that additional template parameters should be forbidden in |
| the Standard classes. Library writers don't lose any expressive power, |
| and can still offer extensions because additional template parameters |
| may be provided by a non-Standard implementation class:</p> |
| <pre> |
| template <class T, class Allocator = allocator<T>, int N = 1> |
| class __vector |
| { ... }; |
| template <class T, class Allocator = allocator<T> > |
| class vector: public __vector<T, Allocator> |
| { ... }; |
| </pre> |
| |
| </blockquote> |
| |
| <p><b>Proposed resolution:</b></p> |
| <p>Add a new subclause [presumably 17.4.4.9] following 17.4.4.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a>:</p> |
| |
| <blockquote> |
| <p>17.4.4.9 Template Parameters</p> <p>A specialization of a |
| template class described in the C++ Standard Library behaves the |
| same as if the implementation declares no additional template |
| parameters.</p> <p>Footnote: Additional template parameters with |
| default values are thus permitted.</p> |
| </blockquote> |
| |
| <p>Add "template parameters" to the list of subclauses at |
| the end of 17.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.conforming"> [lib.conforming]</a> paragraph 1.</p> |
| |
| <p><i>[Kona: The LWG agreed the standard needs clarification. After |
| discussion with John Spicer, it seems added template parameters can be |
| detected by a program using template-template parameters. A straw vote |
| - "should implementors be allowed to add template |
| parameters?" found no consensus ; 5 - yes, 7 - no.]</i></p> |
| |
| <p><b>Rationale:</b></p> |
| <p> |
| There is no ambiguity; the standard is clear as written. Library |
| implementors are not permitted to add template parameters to standard |
| library classes. This does not fall under the "as if" rule, |
| so it would be permitted only if the standard gave explicit license |
| for implementors to do this. This would require a change in the |
| standard. |
| </p> |
| |
| <p> |
| The LWG decided against making this change, because it would break |
| user code involving template template parameters or specializations |
| of standard library class templates. |
| </p> |
| <hr> |
| <a name="95"><h3>95. Members added by the implementation</h3></a><p><b>Section:</b> 17.4.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.member.functions"> [lib.member.functions]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p> |
| <p>In 17.3.4.4/2 vs 17.3.4.7/0 there is a hole; an implementation could add virtual |
| members a base class and break user derived classes.</p> |
| |
| <p>Example: </p> |
| |
| <blockquote> |
| <pre>// implementation code: |
| struct _Base { // _Base is in the implementer namespace |
| virtual void foo (); |
| }; |
| class vector : _Base // deriving from a class is allowed |
| { ... }; |
| |
| // user code: |
| class vector_checking : public vector |
| { |
| void foo (); // don't want to override _Base::foo () as the |
| // user doesn't know about _Base::foo () |
| };</pre> |
| </blockquote> |
| <p><b>Proposed resolution:</b></p> |
| <p>Clarify the wording to make the example illegal.</p> |
| <p><b>Rationale:</b></p> |
| <p>This is not a defect in the Standard. The example is already |
| illegal. See 17.4.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.member.functions"> [lib.member.functions]</a> paragraph 2.</p> |
| <hr> |
| <a name="97"><h3>97. Insert inconsistent definition</h3></a><p><b>Section:</b> 23 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.containers"> [lib.containers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p> |
| <p><tt>insert(iterator, const value_type&)</tt> is defined both on |
| sequences and on set, with unrelated semantics: insert here (in |
| sequences), and insert with hint (in associative containers). They |
| should have different names (B.S. says: do not abuse overloading).</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>This is not a defect in the Standard. It is a genetic misfortune of |
| the design, for better or for worse.</p> |
| <hr> |
| <a name="99"><h3>99. Reverse_iterator comparisons completely wrong</h3></a><p><b>Section:</b> 24.4.1.3.13 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.op=="> [lib.reverse.iter.op==]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p> |
| <p>The <, >, <=, >= comparison operator are wrong: they |
| return the opposite of what they should.</p> |
| |
| <p>Note: same problem in CD2, these were not even defined in CD1. SGI |
| STL code is correct; this problem is known since the Morristown |
| meeting but there it was too late</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>This is not a defect in the Standard. A careful reading shows the Standard is correct |
| as written. A review of several implementations show that they implement |
| exactly what the Standard says.</p> |
| <hr> |
| <a name="100"><h3>100. Insert iterators/ostream_iterators overconstrained</h3></a><p><b>Section:</b> 24.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.insert.iterators"> [lib.insert.iterators]</a>, 24.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.ostreambuf.iterator"> [lib.ostreambuf.iterator]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p> |
| <p>Overspecified For an insert iterator it, the expression *it is |
| required to return a reference to it. This is a simple possible |
| implementation, but as the SGI STL documentation says, not the only |
| one, and the user should not assume that this is the case.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>The LWG believes this causes no harm and is not a defect in the |
| standard. The only example anyone could come up with caused some |
| incorrect code to work, rather than the other way around.</p> |
| <hr> |
| <a name="101"><h3>101. No way to free storage for vector and deque</h3></a><p><b>Section:</b> 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.adaptors"> [lib.container.adaptors]</a>, 23.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.array"> [lib.array]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p> |
| <p>Reserve can not free storage, unlike string::reserve</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>This is not a defect in the Standard. The LWG has considered this |
| issue in the past and sees no need to change the Standard. Deque has |
| no reserve() member function. For vector, shrink-to-fit can be |
| expressed in a single line of code (where <tt>v</tt> is |
| <tt>vector<T></tt>): |
| </p> |
| |
| <blockquote> |
| <p><tt>vector<T>(v).swap(v); // shrink-to-fit v</tt></p> |
| </blockquote> |
| <hr> |
| <a name="102"><h3>102. Bug in insert range in associative containers</h3></a><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p> |
| <p>Table 69 of Containers say that a.insert(i,j) is linear if [i, j) is ordered. It seems |
| impossible to implement, as it means that if [i, j) = [x], insert in an associative |
| container is O(1)!</p> |
| <p><b>Proposed resolution:</b></p> |
| <p>N+log (size()) if [i,j) is sorted according to value_comp()</p> |
| <p><b>Rationale:</b></p> |
| <p>Subsumed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#264">264</a>.</p> |
| <hr> |
| <a name="104"><h3>104. Description of basic_string::operator[] is unclear</h3></a><p><b>Section:</b> 21.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.access"> [lib.string.access]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p> |
| <p>It is not clear that undefined behavior applies when pos == size () |
| for the non const version.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p>Rewrite as: Otherwise, if pos > size () or pos == size () and |
| the non-const version is used, then the behavior is undefined.</p> |
| <p><b>Rationale:</b></p> |
| <p>The Standard is correct. The proposed resolution already appears in |
| the Standard.</p> |
| <hr> |
| <a name="105"><h3>105. fstream ctors argument types desired</h3></a><p><b>Section:</b> 27.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p> |
| <p>fstream ctors take a const char* instead of string.<br> |
| fstream ctors can't take wchar_t</p> |
| |
| <p>An extension to add a const wchar_t* to fstream would make the |
| implementation non conforming.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>This is not a defect in the Standard. It might be an |
| interesting extension for the next Standard. </p> |
| <hr> |
| <a name="107"><h3>107. Valarray constructor is strange</h3></a><p><b>Section:</b> 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex"> [lib.complex]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> AFNOR <b>Date:</b> 7 Oct 1998</p> |
| <p>The order of the arguments is (elem, size) instead of the normal |
| (size, elem) in the rest of the library. Since elem often has an |
| integral or floating point type, both types are convertible to each |
| other and reversing them leads to a well formed program.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p>Inverting the arguments could silently break programs. Introduce |
| the two signatures (const T&, size_t) and (size_t, const T&), |
| but make the one we do not want private so errors result in a |
| diagnosed access violation. This technique can also be applied to STL |
| containers.</p> |
| <p><b>Rationale:</b></p> |
| <p>The LWG believes that while the order of arguments is unfortunate, |
| it does not constitute a defect in the standard. The LWG believes that |
| the proposed solution will not work for valarray<size_t> and |
| perhaps other cases.</p> |
| <hr> |
| <a name="111"><h3>111. istreambuf_iterator::equal overspecified, inefficient</h3></a><p><b>Section:</b> 24.5.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator::equal"> [lib.istreambuf.iterator::equal]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 15 Oct 1998</p> |
| <p>The member istreambuf_iterator<>::equal is specified to be |
| unnecessarily inefficient. While this does not affect the efficiency |
| of conforming implementations of iostreams, because they can |
| "reach into" the iterators and bypass this function, it does |
| affect users who use istreambuf_iterators. </p> |
| |
| <p>The inefficiency results from a too-scrupulous definition, which |
| requires a "true" result if neither iterator is at eof. In |
| practice these iterators can only usefully be compared with the |
| "eof" value, so the extra test implied provides no benefit, |
| but slows down users' code. </p> |
| |
| <p>The solution is to weaken the requirement on the function to return |
| true only if both iterators are at eof. </p> |
| <p><b>Proposed resolution:</b></p> |
| <p>Replace 24.5.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator::equal"> [lib.istreambuf.iterator::equal]</a>, |
| paragraph 1, </p> |
| |
| <blockquote> |
| <p>-1- Returns: true if and only if both iterators are at end-of-stream, or neither is at |
| end-of-stream, regardless of what streambuf object they use. </p> |
| </blockquote> |
| |
| <p>with</p> |
| |
| <blockquote> |
| <p>-1- Returns: true if and only if both iterators are at |
| end-of-stream, regardless of what streambuf object they use. </p> |
| </blockquote> |
| |
| <p><b>Rationale:</b></p> |
| <p>It is not clear that this is a genuine defect. Additionally, the |
| LWG was reluctant to make a change that would result in |
| operator== not being a equivalence relation. One consequence of |
| this change is that an algorithm that's passed the range [i, i) |
| would no longer treat it as an empty range.</p> |
| <hr> |
| <a name="113"><h3>113. Missing/extra iostream sync semantics</h3></a><p><b>Section:</b> 27.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream"> [lib.istream]</a>, 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 13 Oct 1998</p> |
| <p>In 27.6.1.1, class basic_istream has a member function sync, described in 27.6.1.3, |
| paragraph 36. </p> |
| |
| <p>Following the chain of definitions, I find that the various sync functions have defined |
| semantics for output streams, but no semantics for input streams. On the other hand, |
| basic_ostream has no sync function. </p> |
| |
| <p>The sync function should at minimum be added to basic_ostream, for internal |
| consistency. </p> |
| |
| <p>A larger question is whether sync should have assigned semantics for input streams. </p> |
| |
| <p>Classic iostreams said streambuf::sync flushes pending output and attempts to return |
| unread input characters to the source. It is a protected member function. The filebuf |
| version (which is public) has that behavior (it backs up the read pointer). Class |
| strstreambuf does not override streambuf::sync, and so sync can't be called on a |
| strstream. </p> |
| |
| <p>If we can add corresponding semantics to the various sync functions, we should. If not, |
| we should remove sync from basic_istream.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>A sync function is not needed in basic_ostream because the flush function provides the |
| desired functionality.</p> |
| |
| <p>As for the other points, the LWG finds the standard correct as written.</p> |
| <hr> |
| <a name="116"><h3>116. bitset cannot be constructed with a const char*</h3></a><p><b>Section:</b> 23.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 6 Nov 1998</p> |
| <p>The following code does not compile with the EDG compiler:</p> |
| |
| <blockquote> |
| <pre>#include <bitset> |
| using namespace std; |
| bitset<32> b("111111111");</pre> |
| </blockquote> |
| |
| <p>If you cast the ctor argument to a string, i.e.:</p> |
| |
| <blockquote> |
| <pre>bitset<32> b(string("111111111"));</pre> |
| </blockquote> |
| |
| <p>then it will compile. The reason is that bitset has the following templatized |
| constructor:</p> |
| |
| <blockquote> |
| <pre>template <class charT, class traits, class Allocator> |
| explicit bitset (const basic_string<charT, traits, Allocator>& str, ...);</pre> |
| </blockquote> |
| |
| <p>According to the compiler vendor, Steve Adamcyk at EDG, the user |
| cannot pass this template constructor a <tt>const char*</tt> and |
| expect a conversion to <tt>basic_string</tt>. The reason is |
| "When you have a template constructor, it can get used in |
| contexts where type deduction can be done. Type deduction basically |
| comes up with exact matches, not ones involving conversions." |
| </p> |
| |
| <p>I don't think the intention when this constructor became |
| templatized was for construction from a <tt>const char*</tt> to no |
| longer work.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p>Add to 23.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a> a bitset constructor declaration</p> |
| |
| <blockquote> |
| <pre>explicit bitset(const char*);</pre> |
| </blockquote> |
| |
| <p>and in Section 23.3.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.cons"> [lib.bitset.cons]</a> add:</p> |
| |
| <blockquote> |
| <pre>explicit bitset(const char* str);</pre> |
| <p>Effects: <br> |
| Calls <tt>bitset((string) str, 0, string::npos);</tt></p> |
| </blockquote> |
| <p><b>Rationale:</b></p> |
| <p>Although the problem is real, the standard is designed that way so |
| it is not a defect. Education is the immediate workaround. A future |
| standard may wish to consider the Proposed Resolution as an |
| extension.</p> |
| <hr> |
| <a name="121"><h3>121. Detailed definition for ctype<wchar_t> specialization</h3></a><p><b>Section:</b> 22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 15 Dec 1998</p> |
| <p>Section 22.1.1.1.1 has the following listed in Table 51: ctype<char> , |
| ctype<wchar_t>. </p> |
| |
| <p>Also Section 22.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype"> [lib.locale.ctype]</a> says: </p> |
| |
| <blockquote> |
| <p>The instantiations required in Table 51 (22.1.1.1.1) namely ctype<char> and |
| ctype<wchar_t> , implement character classing appropriate to the implementation's |
| native character set. </p> |
| </blockquote> |
| |
| <p>However, Section 22.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.ctype.special"> [lib.facet.ctype.special]</a> |
| only has a detailed description of the ctype<char> specialization, not the |
| ctype<wchar_t> specialization. </p> |
| <p><b>Proposed resolution:</b></p> |
| <p>Add the ctype<wchar_t> detailed class description to Section |
| 22.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.ctype.special"> [lib.facet.ctype.special]</a>. </p> |
| <p><b>Rationale:</b></p> |
| <p>Specialization for wchar_t is not needed since the default is acceptable.</p> |
| <hr> |
| <a name="128"><h3>128. Need open_mode() function for file stream, string streams, file buffers, and string buffers</h3></a><p><b>Section:</b> 27.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.string.streams"> [lib.string.streams]</a>, 27.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 22 Feb 1999</p> |
| <p>The following question came from Thorsten Herlemann:</p> |
| |
| <blockquote> |
| <p>You can set a mode when constructing or opening a file-stream or |
| filebuf, e.g. ios::in, ios::out, ios::binary, ... But how can I get |
| that mode later on, e.g. in my own operator << or operator |
| >> or when I want to check whether a file-stream or |
| file-buffer object passed as parameter is opened for input or output |
| or binary? Is there no possibility? Is this a design-error in the |
| standard C++ library? </p> |
| </blockquote> |
| |
| <p>It is indeed impossible to find out what a stream's or stream |
| buffer's open mode is, and without that knowledge you don't know |
| how certain operations behave. Just think of the append mode. </p> |
| |
| <p>Both streams and stream buffers should have a <tt>mode()</tt> function that returns the |
| current open mode setting. </p> |
| <p><b>Proposed resolution:</b></p> |
| <p>For stream buffers, add a function to the base class as a non-virtual function |
| qualified as const to 27.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a>:</p> |
| |
| <p> <tt>openmode mode() const</tt>;</p> |
| |
| <p><b> Returns</b> the current open mode.</p> |
| |
| <p>With streams, I'm not sure what to suggest. In principle, the mode |
| could already be returned by <tt>ios_base</tt>, but the mode is only |
| initialized for file and string stream objects, unless I'm overlooking |
| anything. For this reason it should be added to the most derived |
| stream classes. Alternatively, it could be added to <tt>basic_ios</tt> |
| and would be default initialized in <tt>basic_ios<>::init()</tt>.</p> |
| <p><b>Rationale:</b></p> |
| <p>This might be an interesting extension for some future, but it is |
| not a defect in the current standard. The Proposed Resolution is |
| retained for future reference.</p> |
| <hr> |
| <a name="131"><h3>131. list::splice throws nothing</h3></a><p><b>Section:</b> 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.special"> [lib.deque.special]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 6 Mar 1999</p> |
| <p>What happens if a splice operation causes the size() of a list to grow |
| beyond max_size()?</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>Size() cannot grow beyond max_size(). </p> |
| <hr> |
| <a name="135"><h3>135. basic_iostream doubly initialized</h3></a><p><b>Section:</b> 27.6.1.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.cons"> [lib.iostream.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 6 Mar 1999</p> |
| <p>-1- Effects Constructs an object of class basic_iostream, assigning |
| initial values to the base classes by calling |
| basic_istream<charT,traits>(sb) (lib.istream) and |
| basic_ostream<charT,traits>(sb) (lib.ostream)</p> |
| |
| <p>The called for basic_istream and basic_ostream constructors call |
| init(sb). This means that the basic_iostream's virtual base class is |
| initialized twice.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p>Change 27.6.1.5.1, paragraph 1 to:</p> |
| |
| <p>-1- Effects Constructs an object of class basic_iostream, assigning |
| initial values to the base classes by calling |
| basic_istream<charT,traits>(sb) (lib.istream).</p> |
| <p><b>Rationale:</b></p> |
| <p>The LWG agreed that the <tt> init()</tt> function is called |
| twice, but said that this is harmless and so not a defect in the |
| standard.</p> |
| <hr> |
| <a name="138"><h3>138. Class ctype_byname<char> redundant and misleading</h3></a><p><b>Section:</b> 22.2.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> March 18, 1999</p> |
| <p>Section 22.2.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt"> [lib.locale.codecvt]</a> specifies that |
| ctype_byname<char> must be a specialization of the ctype_byname |
| template.</p> |
| |
| <p>It is common practice in the standard that specializations of class templates are only |
| mentioned where the interface of the specialization deviates from the interface of the |
| template that it is a specialization of. Otherwise, the fact whether or not a required |
| instantiation is an actual instantiation or a specialization is left open as an |
| implementation detail. </p> |
| |
| <p>Clause 22.2.1.4 deviates from that practice and for that reason is misleading. The |
| fact, that ctype_byname<char> is specified as a specialization suggests that there |
| must be something "special" about it, but it has the exact same interface as the |
| ctype_byname template. Clause 22.2.1.4 does not have any explanatory value, is at best |
| redundant, at worst misleading - unless I am missing anything. </p> |
| |
| <p>Naturally, an implementation will most likely implement ctype_byname<char> as a |
| specialization, because the base class ctype<char> is a specialization with an |
| interface different from the ctype template, but that's an implementation detail and need |
| not be mentioned in the standard. </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p> The standard as written is mildly misleading, but the correct fix |
| is to deal with the underlying problem in the ctype_byname base class, |
| not in the specialization. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>.</p> |
| <hr> |
| <a name="140"><h3>140. map<Key, T>::value_type does not satisfy the assignable requirement</h3></a><p><b>Section:</b> 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Mark Mitchell <b>Date:</b> 14 Apr 1999</p> |
| <blockquote> |
| <p>23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a><br> |
| <br> |
| expression return type |
| pre/post-condition<br> |
| ------------- ----------- |
| -------------------<br> |
| X::value_type T |
| |
| T is assignable<br> |
| <br> |
| 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a><br> |
| <br> |
| A map satisfies all the requirements of a container.<br> |
| <br> |
| For a map<Key, T> ... the value_type is pair<const Key, T>.</p> |
| </blockquote> |
| |
| <p>There's a contradiction here. In particular, `pair<const Key, |
| T>' is not assignable; the `const Key' cannot be assigned |
| to. So, map<Key, T>::value_type does not satisfy the |
| assignable requirement imposed by a container.</p> |
| |
| <p><i>[See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> for the slightly related issue of |
| modification of set keys.]</i></p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>The LWG believes that the standard is inconsistent, but that this |
| is a design problem rather than a strict defect. May wish to |
| reconsider for the next standard.</p> |
| <hr> |
| <a name="143"><h3>143. C .h header wording unclear</h3></a><p><b>Section:</b> D.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.c.headers"> [depr.c.headers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Christophe de Dinechin <b>Date:</b> 4 May 1999</p> |
| <p>[depr.c.headers] paragraph 2 reads:</p> |
| |
| <blockquote> |
| |
| <p>Each C header, whose name has the form name.h, behaves as if each |
| name placed in the Standard library namespace by the corresponding |
| cname header is also placed within the namespace scope of the |
| namespace std and is followed by an explicit using-declaration |
| (_namespace.udecl_)</p> |
| |
| </blockquote> |
| |
| <p>I think it should mention the global name space somewhere... |
| Currently, it indicates that name placed in std is also placed in |
| std...</p> |
| |
| <p>I don't know what is the correct wording. For instance, if struct |
| tm is defined in time.h, ctime declares std::tm. However, the current |
| wording seems ambiguous regarding which of the following would occur |
| for use of both ctime and time.h:</p> |
| |
| <blockquote> |
| <pre>// version 1: |
| namespace std { |
| struct tm { ... }; |
| } |
| using std::tm; |
| |
| // version 2: |
| struct tm { ... }; |
| namespace std { |
| using ::tm; |
| } |
| |
| // version 3: |
| struct tm { ... }; |
| namespace std { |
| struct tm { ... }; |
| }</pre> |
| </blockquote> |
| |
| <p>I think version 1 is intended.</p> |
| |
| <p><i>[Kona: The LWG agreed that the wording is not clear. It also |
| agreed that version 1 is intended, version 2 is not equivalent to |
| version 1, and version 3 is clearly not intended. The example below |
| was constructed by Nathan Myers to illustrate why version 2 is not |
| equivalent to version 1.</i></p> |
| |
| <p><i>Although not equivalent, the LWG is unsure if (2) is enough of |
| a problem to be prohibited. Points discussed in favor of allowing |
| (2):</i></p> |
| |
| <blockquote> |
| <ul> |
| <li><i>It may be a convenience to implementors.</i></li> |
| <li><i>The only cases that fail are structs, of which the C library |
| contains only a few.</i></li> |
| </ul> |
| </blockquote> |
| |
| <p><i>]</i></p> |
| |
| <p><b>Example:</b></p> |
| |
| <blockquote> |
| |
| <pre>#include <time.h> |
| #include <utility> |
| |
| int main() { |
| std::tm * t; |
| make_pair( t, t ); // okay with version 1 due to Koenig lookup |
| // fails with version 2; make_pair not found |
| return 0; |
| }</pre> |
| |
| </blockquote> |
| <p><b>Proposed resolution:</b></p> |
| |
| <p>Replace D.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.c.headers"> [depr.c.headers]</a> paragraph 2 with:</p> |
| |
| <blockquote> |
| |
| <p> Each C header, whose name has the form name.h, behaves as if each |
| name placed in the Standard library namespace by the corresponding |
| cname header is also placed within the namespace scope of the |
| namespace std by name.h and is followed by an explicit |
| using-declaration (_namespace.udecl_) in global scope.</p> |
| |
| </blockquote> |
| |
| <p><b>Rationale:</b></p> |
| <p> The current wording in the standard is the result of a difficult |
| compromise that averted delay of the standard. Based on discussions |
| in Tokyo it is clear that there is no still no consensus on stricter |
| wording, so the issue has been closed. It is suggested that users not |
| write code that depends on Koenig lookup of C library functions.</p> |
| <hr> |
| <a name="145"><h3>145. adjustfield lacks default value</h3></a><p><b>Section:</b> 27.4.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.basic.ios.cons"> [lib.basic.ios.cons]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 12 May 1999</p> |
| <p>There is no initial value for the adjustfield defined, although |
| many people believe that the default adjustment were right. This is a |
| common misunderstanding. The standard only defines that, if no |
| adjustment is specified, all the predefined inserters must add fill |
| characters before the actual value, which is "as if" the |
| right flag were set. The flag itself need not be set.</p> |
| |
| <p>When you implement a user-defined inserter you cannot rely on right |
| being the default setting for the adjustfield. Instead, you must be |
| prepared to find none of the flags set and must keep in mind that in |
| this case you should make your inserter behave "as if" the |
| right flag were set. This is surprising to many people and complicates |
| matters more than necessary.</p> |
| |
| <p>Unless there is a good reason why the adjustfield should not be |
| initialized I would suggest to give it the default value that |
| everybody expects anyway.</p> |
| |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>This is not a defect. It is deliberate that the default is no bits |
| set. Consider Arabic or Hebrew, for example. See 22.2.2.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a> paragraph 19, Table 61 - Fill padding.</p> |
| <hr> |
| <a name="149"><h3>149. Insert should return iterator to first element inserted</h3></a><p><b>Section:</b> 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 28 Jun 1999</p> |
| <p>Suppose that c and c1 are sequential containers and i is an |
| iterator that refers to an element of c. Then I can insert a copy of |
| c1's elements into c ahead of element i by executing </p> |
| |
| <blockquote> |
| |
| <pre>c.insert(i, c1.begin(), c1.end());</pre> |
| |
| </blockquote> |
| |
| <p>If c is a vector, it is fairly easy for me to find out where the |
| newly inserted elements are, even though i is now invalid: </p> |
| |
| <blockquote> |
| |
| <pre>size_t i_loc = i - c.begin(); |
| c.insert(i, c1.begin(), c1.end());</pre> |
| |
| </blockquote> |
| |
| <p>and now the first inserted element is at c.begin()+i_loc and one |
| past the last is at c.begin()+i_loc+c1.size().<br> |
| <br> |
| But what if c is a list? I can still find the location of one past the |
| last inserted element, because i is still valid. To find the location |
| of the first inserted element, though, I must execute something like </p> |
| |
| <blockquote> |
| |
| <pre>for (size_t n = c1.size(); n; --n) |
| --i;</pre> |
| |
| </blockquote> |
| |
| <p>because i is now no longer a random-access iterator.<br> |
| <br> |
| Alternatively, I might write something like </p> |
| |
| <blockquote> |
| |
| <pre>bool first = i == c.begin(); |
| list<T>::iterator j = i; |
| if (!first) --j; |
| c.insert(i, c1.begin(), c1.end()); |
| if (first) |
| j = c.begin(); |
| else |
| ++j;</pre> |
| |
| </blockquote> |
| |
| <p>which, although wretched, requires less overhead.<br> |
| <br> |
| But I think the right solution is to change the definition of insert |
| so that instead of returning void, it returns an iterator that refers |
| to the first element inserted, if any, and otherwise is a copy of its |
| first argument. </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>The LWG believes this was an intentional design decision and so is |
| not a defect. It may be worth revisiting for the next standard.</p> |
| <hr> |
| <a name="157"><h3>157. Meaningless error handling for <tt>pword()</tt> and <tt>iword()</tt> |
| </h3></a><p><b>Section:</b> 27.4.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.storage"> [lib.ios.base.storage]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p> |
| <p>According to paragraphs 2 and 4 of 27.4.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.storage"> [lib.ios.base.storage]</a>, the |
| functions <tt>iword()</tt> and <tt>pword()</tt> "set the |
| <tt>badbit</tt> (which might throw an exception)" on |
| failure. ... but what does it mean for <tt>ios_base</tt> to set the |
| <tt>badbit</tt>? The state facilities of the IOStream library are |
| defined in <tt>basic_ios</tt>, a derived class! It would be possible |
| to attempt a down cast but then it would be necessary to know the |
| character type used...</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>Duplicate. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#41">41</a>.</p> |
| <hr> |
| <a name="162"><h3>162. Really "formatted input functions"?</h3></a><p><b>Section:</b> 27.6.1.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::extractors"> [lib.istream::extractors]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p> |
| <p>It appears to be somewhat nonsensical to consider the functions |
| defined in the paragraphs 1 to 5 to be "Formatted input |
| function" but since these functions are defined in a section |
| labeled "Formatted input functions" it is unclear to me |
| whether these operators are considered formatted input functions which |
| have to conform to the "common requirements" from 27.6.1.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a>: If this is the case, all manipulators, not just |
| <tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is set |
| (... but setting <tt>noskipws</tt> using the manipulator syntax would |
| also skip whitespace :-)</p> |
| |
| <p>See also issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#166">166</a> for the same problem in formatted |
| output</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>Duplicate. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a>.</p> |
| <hr> |
| <a name="163"><h3>163. Return of <tt>gcount()</tt> after a call to <tt>gcount</tt> |
| </h3></a><p><b>Section:</b> 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p> |
| <p>It is not clear which functions are to be considered unformatted |
| input functions. As written, it seems that all functions in 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> are unformatted input functions. However, it does not |
| really make much sense to construct a sentry object for |
| <tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is unclear what |
| happens to the <tt>gcount()</tt> if eg. <tt>gcount()</tt>, |
| <tt>putback()</tt>, <tt>unget()</tt>, or <tt>sync()</tt> is called: |
| These functions don't extract characters, some of them even |
| "unextract" a character. Should this still be reflected in |
| <tt>gcount()</tt>? Of course, it could be read as if after a call to |
| <tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt> (the last |
| unformatted input function, <tt>gcount()</tt>, didn't extract any |
| character) and after a call to <tt>putback()</tt> <tt>gcount()</tt> |
| returns <tt>-1</tt> (the last unformatted input function |
| <tt>putback()</tt> did "extract" back into the |
| stream). Correspondingly for <tt>unget()</tt>. Is this what is |
| intended? If so, this should be clarified. Otherwise, a corresponding |
| clarification should be used.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>Duplicate. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a>.</p> |
| <hr> |
| <a name="166"><h3>166. Really "formatted output functions"?</h3></a><p><b>Section:</b> 27.6.2.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.inserters"> [lib.ostream.inserters]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 20 Jul 1999</p> |
| <p>From 27.6.2.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a> it appears that all the functions |
| defined in 27.6.2.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.inserters"> [lib.ostream.inserters]</a> have to construct a |
| <tt>sentry</tt> object. Is this really intended?</p> |
| |
| <p>This is basically the same problem as issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#162">162</a> but |
| for output instead of input.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>Duplicate. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#60">60</a>.</p> |
| <hr> |
| <a name="177"><h3>177. Complex operators cannot be explicitly instantiated</h3></a><p><b>Section:</b> 26.3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.ops"> [lib.complex.ops]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 2 Jul 1999</p> |
| <p>A user who tries to explicitly instantiate a complex non-member operator will |
| get compilation errors. Below is a simplified example of the reason why. The |
| problem is that iterator_traits cannot be instantiated on a non-pointer type |
| like float, yet when the compiler is trying to decide which operator+ needs to |
| be instantiated it must instantiate the declaration to figure out the first |
| argument type of a reverse_iterator operator.</p> |
| <pre>namespace std { |
| template <class Iterator> |
| struct iterator_traits |
| { |
| typedef typename Iterator::value_type value_type; |
| }; |
| |
| template <class T> class reverse_iterator; |
| |
| // reverse_iterator operator+ |
| template <class T> |
| reverse_iterator<T> operator+ |
| (typename iterator_traits<T>::difference_type, const reverse_iterator<T>&); |
| |
| template <class T> struct complex {}; |
| |
| // complex operator + |
| template <class T> |
| complex<T> operator+ (const T& lhs, const complex<T>& rhs) |
| { return complex<T>();} |
| } |
| |
| // request for explicit instantiation |
| template std::complex<float> std::operator+<float>(const float&, |
| const std::complex<float>&);</pre> |
| <p>See also c++-stdlib reflector messages: lib-6814, 6815, 6816.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>Implementors can make minor changes and the example will |
| work. Users are not affected in any case.</p> <p>According to John |
| Spicer, It is possible to explicitly instantiate these operators using |
| different syntax: change "std::operator+<float>" to |
| "std::operator+".</p> |
| |
| <p>The proposed resolution of issue 120 is that users will not be able |
| to explicitly instantiate standard library templates. If that |
| resolution is accepted then library implementors will be the only ones |
| that will be affected by this problem, and they must use the indicated |
| syntax.</p> |
| <hr> |
| <a name="178"><h3>178. Should clog and cerr initially be tied to cout?</h3></a><p><b>Section:</b> 27.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.narrow.stream.objects"> [lib.narrow.stream.objects]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 2 Jul 1999</p> |
| <p> |
| Section 27.3.1 says "After the object cerr is initialized, |
| cerr.flags() & unitbuf is nonzero. Its state is otherwise the same as |
| required for ios_base::init (lib.basic.ios.cons). It doesn't say |
| anything about the the state of clog. So this means that calling |
| cerr.tie() and clog.tie() should return 0 (see Table 89 for |
| ios_base::init effects). |
| </p> |
| <p> |
| Neither of the popular standard library implementations |
| that I tried does this, they both tie cerr and clog |
| to &cout. I would think that would be what users expect. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>The standard is clear as written.</p> |
| <p>27.3.1/5 says that "After the object cerr is initialized, cerr.flags() |
| & unitbuf is nonzero. Its state is otherwise the same as required for |
| ios_base::init (27.4.4.1)." Table 89 in 27.4.4.1, which gives the |
| postconditions of basic_ios::init(), says that tie() is 0. (Other issues correct |
| ios_base::init to basic_ios::init().)</p> |
| <hr> |
| <a name="180"><h3>180. Container member iterator arguments constness has unintended consequences</h3></a><p><b>Section:</b> 23 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.containers"> [lib.containers]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 1 Jul 1999</p> |
| <p>It is the constness of the container which should control whether |
| it can be modified through a member function such as erase(), not the |
| constness of the iterators. The iterators only serve to give |
| positioning information.</p> |
| |
| <p>Here's a simple and typical example problem which is currently very |
| difficult or impossible to solve without the change proposed |
| below.</p> |
| |
| <p>Wrap a standard container C in a class W which allows clients to |
| find and read (but not modify) a subrange of (C.begin(), C.end()]. The |
| only modification clients are allowed to make to elements in this |
| subrange is to erase them from C through the use of a member function |
| of W.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p>Change all non-const iterator parameters of standard library |
| container member functions to accept const_iterator parameters. |
| Note that this change applies to all library clauses, including |
| strings.</p> |
| |
| <p>For example, in 21.3.5.5 change:<br> |
| <br> |
| <tt>iterator erase(iterator p);</tt><br> |
| <br> |
| to:<br> |
| <tt>iterator erase(const_iterator p);</tt> |
| </p> |
| <p><b>Rationale:</b></p> |
| <p>The issue was discussed at length. It was generally agreed that 1) |
| There is no major technical argument against the change (although |
| there is a minor argument that some obscure programs may break), and |
| 2) Such a change would not break const correctness. The concerns about |
| making the change were 1) it is user detectable (although only in |
| boundary cases), 2) it changes a large number of signatures, and 3) it |
| seems more of a design issue that an out-and-out defect.</p> |
| |
| <p>The LWG believes that this issue should be considered as part of a |
| general review of const issues for the next revision of the |
| standard. Also see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>.</p> |
| <hr> |
| <a name="188"><h3>188. valarray helpers missing augmented assignment operators</h3></a><p><b>Section:</b> 26.5.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.cassign"> [lib.valarray.cassign]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 15 Aug 1999</p> |
| <p>26.5.2.6 defines augmented assignment operators |
| valarray<T>::op=(const T&), but fails to provide |
| corresponding versions for the helper classes. Thus making the |
| following illegal:</p> |
| <blockquote> |
| <pre>#include <valarray> |
| |
| int main() |
| { |
| std::valarray<double> v(3.14, 1999); |
| |
| v[99] *= 2.0; // Ok |
| |
| std::slice s(0, 50, 2); |
| |
| v[s] *= 2.0; // ERROR |
| }</pre> |
| </blockquote> |
| <p>I can't understand the intent of that omission. It makes the |
| valarray library less intuitive and less useful.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>Although perhaps an unfortunate |
| design decision, the omission is not a defect in the current |
| standard. A future standard may wish to add the missing |
| operators.</p> |
| <hr> |
| <a name="190"><h3>190. min() and max() functions should be std::binary_functions</h3></a><p><b>Section:</b> 25.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.min.max"> [lib.alg.min.max]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Mark Rintoul <b>Date:</b> 26 Aug 1999</p> |
| <p>Both std::min and std::max are defined as template functions. This |
| is very different than the definition of std::plus (and similar |
| structs) which are defined as function objects which inherit |
| std::binary_function.<br> |
| <br> |
| This lack of inheritance leaves std::min and std::max somewhat useless in standard library algorithms which require |
| a function object that inherits std::binary_function.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>Although perhaps an unfortunate design decision, the omission is not a defect |
| in the current standard. A future standard may wish to consider additional |
| function objects.</p> |
| <hr> |
| <a name="191"><h3>191. Unclear complexity for algorithms such as binary search</h3></a><p><b>Section:</b> 25.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.binary.search"> [lib.alg.binary.search]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 10 Oct 1999</p> |
| <p>The complexity of binary_search() is stated as "At most |
| log(last-first) + 2 comparisons", which seems to say that the |
| algorithm has logarithmic complexity. However, this algorithms is |
| defined for forward iterators. And for forward iterators, the need to |
| step element-by-element results into linear complexity. But such a |
| statement is missing in the standard. The same applies to |
| lower_bound(), upper_bound(), and equal_range(). <br> |
| <br> |
| However, strictly speaking the standard contains no bug here. So this |
| might considered to be a clarification or improvement. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>The complexity is expressed in terms of comparisons, and that |
| complexity can be met even if the number of iterators accessed is |
| linear. Paragraph 1 already says exactly what happens to |
| iterators.</p> |
| <hr> |
| <a name="192"><h3>192. a.insert(p,t) is inefficient and overconstrained</h3></a><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Ed Brey <b>Date:</b> 6 Jun 1999</p> |
| <p>As defined in 23.1.2, paragraph 7 (table 69), a.insert(p,t) suffers from |
| several problems:</p> |
| <table border="1" cellpadding="5"> |
| <tbody><tr> |
| <td><b>expression</b></td> |
| <td><b>return type</b></td> |
| <td><b>pre/post-condition</b></td> |
| <td><b>complexity</b></td> |
| </tr> |
| <tr> |
| <td><tt>a.insert(p,t)</tt></td> |
| <td><tt>iterator</tt></td> |
| <td>inserts t if and only if there is no element with key equivalent to the key of |
| t in containers with unique keys; always inserts t in containers with equivalent |
| keys. always returns the iterator pointing to the element with key equivalent to |
| the key of t . iterator p is a hint pointing to where the insert should start to search.</td> |
| <td>logarithmic in general, but amortized constant if t is inserted right after p .</td> |
| </tr> |
| </tbody></table> |
| <p>1. For a container with unique keys, only logarithmic complexity is |
| guaranteed if no element is inserted, even though constant complexity is always |
| possible if p points to an element equivalent to t.</p> |
| <p>2. For a container with equivalent keys, the amortized constant complexity |
| guarantee is only useful if no key equivalent to t exists in the container. |
| Otherwise, the insertion could occur in one of multiple locations, at least one |
| of which would not be right after p.</p> |
| <p>3. By guaranteeing amortized constant complexity only when t is inserted |
| after p, it is impossible to guarantee constant complexity if t is inserted at |
| the beginning of the container. Such a problem would not exist if amortized |
| constant complexity was guaranteed if t is inserted before p, since there is |
| always some p immediately before which an insert can take place.</p> |
| <p>4. For a container with equivalent keys, p does not allow specification of |
| where to insert the element, but rather only acts as a hint for improving |
| performance. This negates the added functionality that p would provide if it |
| specified where within a sequence of equivalent keys the insertion should occur. |
| Specifying the insert location provides more control to the user, while |
| providing no disadvantage to the container implementation.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p>In 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> paragraph 7, replace the row in table 69 |
| for a.insert(p,t) with the following two rows:</p> |
| <table border="1" cellpadding="5"> |
| <tbody><tr> |
| <td><b>expression</b></td> |
| <td><b>return type</b></td> |
| <td><b>pre/post-condition</b></td> |
| <td><b>complexity</b></td> |
| </tr> |
| <tr> |
| <td><tt>a_uniq.insert(p,t)</tt></td> |
| <td><tt>iterator</tt></td> |
| <td>inserts t if and only if there is no element with key equivalent to the |
| key of t. returns the iterator pointing to the element with key equivalent |
| to the key of t.</td> |
| <td>logarithmic in general, but amortized constant if t is inserted right |
| before p or p points to an element with key equivalent to t.</td> |
| </tr> |
| <tr> |
| <td><tt>a_eq.insert(p,t)</tt></td> |
| <td><tt>iterator</tt></td> |
| <td>inserts t and returns the iterator pointing to the newly inserted |
| element. t is inserted right before p if doing so preserves the container |
| ordering.</td> |
| <td>logarithmic in general, but amortized constant if t is inserted right |
| before p.</td> |
| </tr> |
| </tbody></table> |
| |
| <p><b>Rationale:</b></p> |
| <p>Too big a change. Furthermore, implementors report checking |
| both before p and after p, and don't want to change this behavior.</p> |
| <hr> |
| <a name="194"><h3>194. rdbuf() functions poorly specified</h3></a><p><b>Section:</b> 27.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios"> [lib.ios]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Steve Clamage <b>Date:</b> 7 Sep 1999</p> |
| <p>In classic iostreams, base class ios had an rdbuf function that returned a |
| pointer to the associated streambuf. Each derived class had its own rdbuf |
| function that returned a pointer of a type reflecting the actual type derived |
| from streambuf. Because in ARM C++, virtual function overrides had to have the |
| same return type, rdbuf could not be virtual.</p> |
| <p>In standard iostreams, we retain the non-virtual rdbuf function design, and |
| in addition have an overloaded rdbuf function that sets the buffer pointer. |
| There is no need for the second function to be virtual nor to be implemented in |
| derived classes.</p> |
| <p>Minor question: Was there a specific reason not to make the original rdbuf |
| function virtual?</p> |
| <p>Major problem: Friendly compilers warn about functions in derived classes |
| that hide base-class overloads. Any standard implementation of iostreams will |
| result in such a warning on each of the iostream classes, because of the |
| ill-considered decision to overload rdbuf only in a base class.</p> |
| <p>In addition, users of the second rdbuf function must use explicit |
| qualification or a cast to call it from derived classes. An explicit |
| qualification or cast to basic_ios would prevent access to any later overriding |
| version if there was one.</p> |
| <p>What I'd like to do in an implementation is add a using- declaration for the |
| second rdbuf function in each derived class. It would eliminate warnings about |
| hiding functions, and would enable access without using explicit qualification. |
| Such a change I don't think would change the behavior of any valid program, but |
| would allow invalid programs to compile:</p> |
| <blockquote> |
| <pre> filebuf mybuf; |
| fstream f; |
| f.rdbuf(mybuf); // should be an error, no visible rdbuf</pre> |
| </blockquote> |
| <p>I'd like to suggest this problem as a defect, with the proposed resolution to |
| require the equivalent of a using-declaration for the rdbuf function that is not |
| replaced in a later derived class. We could discuss whether replacing the |
| function should be allowed.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>For historical reasons, the standard is correct as written. There is a subtle difference between the base |
| class <tt> rdbuf()</tt> and derived class <tt>rdbuf()</tt>. The derived |
| class <tt> rdbuf()</tt> always returns the original streambuf, whereas the base class |
| <tt> rdbuf()</tt> will return the "current streambuf" if that has been changed by the variant you mention.</p> |
| |
| <p>Permission is not required to add such an extension. See |
| 17.4.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.member.functions"> [lib.member.functions]</a>.</p> |
| <hr> |
| <a name="196"><h3>196. Placement new example has alignment problems</h3></a><p><b>Section:</b> 18.5.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.placement"> [lib.new.delete.placement]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Herb Sutter <b>Date:</b> 15 Dec 1998</p> |
| <p>The example in 18.5.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.placement"> [lib.new.delete.placement]</a> paragraph 4 reads: </p> |
| |
| <blockquote> |
| |
| <p>[Example: This can be useful for constructing an object at a known address:<br> |
| <br> |
| <tt> char place[sizeof(Something)];<br> |
| Something* p = new (place) Something();<br> |
| <br> |
| </tt>end example] </p> |
| |
| </blockquote> |
| |
| <p>This example has potential alignment problems. </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>Duplicate: see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#114">114</a>.</p> |
| <hr> |
| <a name="197"><h3>197. max_size() underspecified</h3></a><p><b>Section:</b> 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.default.con.req"> [lib.default.con.req]</a>, 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 21 Oct 1999</p> |
| <p>Must the value returned by max_size() be unchanged from call to call? </p> |
| |
| <p>Must the value returned from max_size() be meaningful? </p> |
| |
| <p>Possible meanings identified in lib-6827: </p> |
| |
| <p>1) The largest container the implementation can support given "best |
| case" conditions - i.e. assume the run-time platform is "configured to |
| the max", and no overhead from the program itself. This may possibly |
| be determined at the point the library is written, but certainly no |
| later than compile time.<br> |
| <br> |
| 2) The largest container the program could create, given "best case" |
| conditions - i.e. same platform assumptions as (1), but take into |
| account any overhead for executing the program itself. (or, roughly |
| "storage=storage-sizeof(program)"). This does NOT include any resource |
| allocated by the program. This may (or may not) be determinable at |
| compile time.<br> |
| <br> |
| 3) The largest container the current execution of the program could |
| create, given knowledge of the actual run-time platform, but again, |
| not taking into account any currently allocated resource. This is |
| probably best determined at program start-up.<br> |
| <br> |
| 4) The largest container the current execution program could create at |
| the point max_size() is called (or more correctly at the point |
| max_size() returns :-), given it's current environment (i.e. taking |
| into account the actual currently available resources). This, |
| obviously, has to be determined dynamically each time max_size() is |
| called. </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>max_size() isn't useful for very many things, and the existing |
| wording is sufficiently clear for the few cases that max_size() can |
| be used for. None of the attempts to change the existing wording |
| were an improvement.</p> |
| |
| <p>It is clear to the LWG that the value returned by max_size() can't |
| change from call to call.</p> |
| |
| <hr> |
| <a name="203"><h3>203. basic_istream::sentry::sentry() is uninstantiable with ctype<user-defined type></h3></a><p><b>Section:</b> 27.6.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream::sentry"> [lib.istream::sentry]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Matt McClure and Dietmar Kühl <b>Date:</b> 1 Jan 2000</p> |
| <p>27.6.1.1.2 Paragraph 4 states:</p> |
| <blockquote> |
| <p>To decide if the character c is a whitespace character, the constructor |
| performs ''as if'' it executes the following code fragment: </p> |
| <pre>const ctype<charT>& ctype = use_facet<ctype<charT> >(is.getloc()); |
| if (ctype.is(ctype.space,c)!=0) |
| // c is a whitespace character.</pre> |
| </blockquote> |
| |
| <p> But Table 51 in 22.1.1.1.1 only requires an implementation to |
| provide specializations for ctype<char> and |
| ctype<wchar_t>. If sentry's constructor is implemented using |
| ctype, it will be uninstantiable for a user-defined character type |
| charT, unless the implementation has provided non-working (since it |
| would be impossible to define a correct ctype<charT> specialization |
| for an arbitrary charT) definitions of ctype's virtual member |
| functions.</p> |
| |
| <p> |
| It seems the intent the standard is that sentry should behave, in |
| every respect, not just during execution, as if it were implemented |
| using ctype, with the burden of providing a ctype specialization |
| falling on the user. But as it is written, nothing requires the |
| translation of sentry's constructor to behave as if it used the above |
| code, and it would seem therefore, that sentry's constructor should be |
| instantiable for all character types. |
| </p> |
| |
| <p> |
| Note: If I have misinterpreted the intent of the standard with |
| respect to sentry's constructor's instantiability, then a note should |
| be added to the following effect: |
| </p> |
| |
| <blockquote> |
| An implementation is forbidden from using the above code if it renders |
| the constructor uninstantiable for an otherwise valid character |
| type. |
| </blockquote> |
| |
| <p>In any event, some clarification is needed.</p> |
| |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>It is possible but not easy to instantiate on types other than char |
| or wchar_t; many things have to be done first. That is by intention |
| and is not a defect.</p> |
| <hr> |
| <a name="204"><h3>204. distance(first, last) when "last" is before "first"</h3></a><p><b>Section:</b> 24.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.operations"> [lib.iterator.operations]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Rintala Matti <b>Date:</b> 28 Jan 2000</p> |
| <p>Section 24.3.4 describes the function distance(first, last) (where first and |
| last are iterators) which calculates "the number of increments or |
| decrements needed to get from 'first' to 'last'".</p> |
| <p>The function should work for forward, bidirectional and random access |
| iterators, and there is a requirement 24.3.4.5 which states that "'last' |
| must be reachable from 'first'".</p> |
| <p>With random access iterators the function is easy to implement as "last |
| - first".</p> |
| <p>With forward iterators it's clear that 'first' must point to a place before |
| 'last', because otherwise 'last' would not be reachable from 'first'.</p> |
| <p>But what about bidirectional iterators? There 'last' is reachable from |
| 'first' with the -- operator even if 'last' points to an earlier position than |
| 'first'. However, I cannot see how the distance() function could be implemented |
| if the implementation does not know which of the iterators points to an earlier |
| position (you cannot use ++ or -- on either iterator if you don't know which |
| direction is the "safe way to travel").</p> |
| <p>The paragraph 24.3.4.1 states that "for ... bidirectional iterators they |
| use ++ to provide linear time implementations". However, the ++ operator is |
| not mentioned in the reachability requirement. Furthermore 24.3.4.4 explicitly |
| mentions that distance() returns the number of increments _or decrements_, |
| suggesting that it could return a negative number also for bidirectional |
| iterators when 'last' points to a position before 'first'.</p> |
| <p>Is a further requirement is needed to state that for forward and |
| bidirectional iterators "'last' must be reachable from 'first' using the ++ |
| operator". Maybe this requirement might also apply to random access |
| iterators so that distance() would work the same way for every iterator |
| category?</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>"Reachable" is defined in the standard in 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> paragraph 6. |
| The definition is only in terms of operator++(). The LWG sees no defect in |
| the standard.</p> |
| <hr> |
| <a name="205"><h3>205. numeric_limits unclear on how to determine floating point types</h3></a><p><b>Section:</b> 18.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.numeric.limits.members"> [lib.numeric.limits.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Steve Cleary <b>Date:</b> 28 Jan 2000</p> |
| <p>In several places in 18.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.numeric.limits.members"> [lib.numeric.limits.members]</a>, a member is |
| described as "Meaningful for all floating point types." |
| However, no clear method of determining a floating point type is |
| provided.</p> |
| |
| <p>In 18.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.numeric.special"> [lib.numeric.special]</a>, paragraph 1 states ". . . (for |
| example, epsilon() is only meaningful if is_integer is |
| false). . ." which suggests that a type is a floating point type |
| if is_specialized is true and is_integer is false; however, this is |
| unclear.</p> |
| |
| <p>When clarifying this, please keep in mind this need of users: what |
| exactly is the definition of floating point? Would a fixed point or |
| rational representation be considered one? I guess my statement here |
| is that there could also be types that are neither integer or |
| (strictly) floating point.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>It is up to the implementor of a user define type to decide if it is a |
| floating point type.</p> |
| <hr> |
| <a name="207"><h3>207. ctype<char> members return clause incomplete</h3></a><p><b>Section:</b> 22.2.1.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Robert Klarer <b>Date:</b> 2 Nov 1999</p> |
| <p> |
| The <tt>widen</tt> and <tt>narrow</tt> member functions are described |
| in 22.2.1.3.2, paragraphs 9-11. In each case we have two overloaded |
| signatures followed by a <b>Returns</b> clause. The <b>Returns</b> |
| clause only describes one of the overloads. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p>Change the returns clause in 22.2.1.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a> |
| paragraph 10 from:</p> |
| <p> Returns: do_widen(low, high, to).</p> |
| |
| <p>to:</p> |
| <p> Returns: do_widen(c) or do_widen(low, high, to), |
| respectively.</p> |
| |
| <p>Change the returns clause in 22.2.1.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a> paragraph 11 |
| from:</p> |
| <p> Returns: do_narrow(low, high, to).</p> |
| |
| <p>to:</p> |
| <p> Returns: do_narrow(c) or do_narrow(low, high, to), |
| respectively.</p> |
| <p><b>Rationale:</b></p> |
| <p>Subsumed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#153">153</a>, which addresses the same |
| paragraphs.</p> |
| <hr> |
| <a name="213"><h3>213. Math function overloads ambiguous</h3></a><p><b>Section:</b> 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numarray"> [lib.numarray]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Nico Josuttis <b>Date:</b> 26 Feb 2000</p> |
| <p>Due to the additional overloaded versions of numeric functions for |
| float and long double according to Section 26.5, calls such as int x; |
| std::pow (x, 4) are ambiguous now in a standard conforming |
| implementation. Current implementations solve this problem very |
| different (overload for all types, don't overload for float and long |
| double, use preprocessor, follow the standard and get |
| ambiguities).</p> <p>This behavior should be standardized or at least |
| identified as implementation defined.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>These math issues are an |
| understood and accepted consequence of the design. They have |
| been discussed several times in the past. Users must write casts |
| or write floating point expressions as arguments.</p> |
| <hr> |
| <a name="215"><h3>215. Can a map's key_type be const?</h3></a><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 29 Feb 2000</p> |
| <p>A user noticed that this doesn't compile with the Rogue Wave library because |
| the rb_tree class declares a key_allocator, and allocator<const int> is |
| not legal, I think:</p> |
| <blockquote> |
| <pre>map < const int, ... > // legal?</pre> |
| </blockquote> |
| <p>which made me wonder whether it is legal for a map's key_type to be const. In |
| email from Matt Austern he said:</p> |
| <blockquote> |
| <p>I'm not sure whether it's legal to declare a map with a const key type. I |
| hadn't thought about that question until a couple weeks ago. My intuitive |
| feeling is that it ought not to be allowed, and that the standard ought to say |
| so. It does turn out to work in SGI's library, though, and someone in the |
| compiler group even used it. Perhaps this deserves to be written up as an issue |
| too.</p> |
| </blockquote> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>The "key is assignable" requirement from table 69 in |
| 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> already implies the key cannot be const.</p> |
| <hr> |
| <a name="216"><h3>216. setbase manipulator description flawed</h3></a><p><b>Section:</b> 27.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Hyman Rosen <b>Date:</b> 29 Feb 2000</p> |
| <p>27.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a> paragraph 5 says:</p> |
| <blockquote> |
| <pre>smanip setbase(int base);</pre> |
| <p> Returns: An object s of unspecified type such that if out is an |
| (instance of) basic_ostream then the expression out<<s behaves |
| as if f(s) were called, in is an (instance of) basic_istream then the |
| expression in>>s behaves as if f(s) were called. Where f can be |
| defined as:</p> |
| <pre>ios_base& f(ios_base& str, int base) |
| { |
| // set basefield |
| str.setf(n == 8 ? ios_base::oct : |
| n == 10 ? ios_base::dec : |
| n == 16 ? ios_base::hex : |
| ios_base::fmtflags(0), ios_base::basefield); |
| return str; |
| }</pre> |
| </blockquote> |
| <p>There are two problems here. First, f takes two parameters, so the |
| description needs to say that out<<s and in>>s behave as if f(s,base) |
| had been called. Second, f is has a parameter named base, but is written as if |
| the parameter was named n.</p> |
| <p>Actually, there's a third problem. The paragraph has grammatical errors. |
| There needs to be an "and" after the first comma, and the "Where |
| f" sentence fragment needs to be merged into its preceding sentence. You |
| may also want to format the function a little better. The formatting above is |
| more-or-less what the Standard contains.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>The resolution of this defect is subsumed by the proposed resolution for |
| issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#193">193</a>.</p> |
| |
| <p><i>[Tokyo: The LWG agrees that this is a defect and notes that it |
| occurs additional places in the section, all requiring fixes.]</i></p> |
| <hr> |
| <a name="218"><h3>218. Algorithms do not use binary predicate objects for default comparisons</h3></a><p><b>Section:</b> 25.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.sorting"> [lib.alg.sorting]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Pablo Halpern <b>Date:</b> 6 Mar 2000</p> |
| <p>Many of the algorithms take an argument, pred, of template parameter type |
| BinaryPredicate or an argument comp of template parameter type Compare. These |
| algorithms usually have an overloaded version that does not take the predicate |
| argument. In these cases pred is usually replaced by the use of operator== and |
| comp is replaced by the use of operator<.</p> |
| <p>This use of hard-coded operators is inconsistent with other parts of the |
| library, particularly the containers library, where equality is established |
| using equal_to<> and ordering is established using less<>. Worse, |
| the use of operator<, would cause the following innocent-looking code to have |
| undefined behavior:</p> |
| <blockquote> |
| <pre>vector<string*> vec; |
| sort(vec.begin(), vec.end());</pre> |
| </blockquote> |
| <p>The use of operator< is not defined for pointers to unrelated objects. If |
| std::sort used less<> to compare elements, then the above code would be |
| well-defined, since less<> is explicitly specialized to produce a total |
| ordering of pointers.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>This use of operator== and operator< was a very deliberate, conscious, and |
| explicitly made design decision; these operators are often more efficient. The |
| predicate forms are available for users who don't want to rely on operator== and |
| operator<.</p> |
| <hr> |
| <a name="219"><h3>219. find algorithm missing version that takes a binary predicate argument</h3></a><p><b>Section:</b> 25.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.find"> [lib.alg.find]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Pablo Halpern <b>Date:</b> 6 Mar 2000</p> |
| <p>The find function always searches for a value using operator== to compare the |
| value argument to each element in the input iterator range. This is inconsistent |
| with other find-related functions such as find_end and find_first_of, which |
| allow the caller to specify a binary predicate object to be used for determining |
| equality. The fact that this can be accomplished using a combination of find_if |
| and bind_1st or bind_2nd does not negate the desirability of a consistent, |
| simple, alternative interface to find.</p> |
| <p><b>Proposed resolution:</b></p> |
| <blockquote> |
| <p>In section 25.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.find"> [lib.alg.find]</a>, add a second prototype for find |
| (between the existing prototype and the prototype for find_if), as |
| follows:</p> |
| <pre> template<class InputIterator, class T, class BinaryPredicate> |
| InputIterator find(InputIterator first, InputIterator last, |
| const T& value, BinaryPredicate bin_pred);</pre> |
| <p>Change the description of the return from:</p> |
| <blockquote> |
| <p>Returns: The first iterator i in the range [first, last) for which the following corresponding |
| conditions hold: *i == value, pred(*i) != false. Returns last if no such iterator is found.</p> |
| </blockquote> |
| <p> to:</p> |
| <blockquote> |
| <p>Returns: The first iterator i in the range [first, last) for which the following |
| corresponding condition holds: *i == value, bin_pred(*i,value) != false, pred(*) |
| != false. Return last if no such iterator is found.</p> |
| </blockquote> |
| </blockquote> |
| <p><b>Rationale:</b></p> |
| <p>This is request for a pure extension, so it is not a defect in the |
| current standard. As the submitter pointed out, "this can |
| be accomplished using a combination of find_if and bind_1st or |
| bind_2nd".</p> |
| <hr> |
| <a name="236"><h3>236. ctype<char>::is() member modifies facet</h3></a><p><b>Section:</b> 22.2.1.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Dietmar Kühl <b>Date:</b> 24 Apr 2000</p> |
| <p>The description of the <tt>is()</tt> member in paragraph 4 of 22.2.1.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.ctype.char.members"> [lib.facet.ctype.char.members]</a> is broken: According to this description, the |
| second form of the <tt>is()</tt> method modifies the masks in the |
| <tt>ctype</tt> object. The correct semantics if, of course, to obtain |
| an array of masks. The corresponding method in the general case, |
| ie. the <tt>do_is()</tt> method as described in 22.2.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.virtuals"> [lib.locale.ctype.virtuals]</a> paragraph 1 does the right thing.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p>Change paragraph 4 from</p> |
| <blockquote> |
| The second form, for all *p in the range [low, high), assigns |
| vec[p-low] to table()[(unsigned char)*p]. |
| </blockquote> |
| <p>to become</p> |
| <blockquote> |
| The second form, for all *p in the range [low, high), assigns |
| table()[(unsigned char)*p] to vec[p-low]. |
| </blockquote> |
| <p><b>Rationale:</b></p> |
| <p>Duplicate. See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#28">28</a>.</p> |
| <hr> |
| <a name="244"><h3>244. Must <tt>find</tt>'s third argument be CopyConstructible?</h3></a><p><b>Section:</b> 25.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.find"> [lib.alg.find]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 02 May 2000</p> |
| <p>Is the following implementation of <tt>find</tt> acceptable?</p> |
| |
| <pre> template<class Iter, class X> |
| Iter find(Iter begin, Iter end, const X& x) |
| { |
| X x1 = x; // this is the crucial statement |
| while (begin != end && *begin != x1) |
| ++begin; |
| return begin; |
| } |
| </pre> |
| |
| <p>If the answer is yes, then it is implementation-dependent as to |
| whether the following fragment is well formed:</p> |
| |
| <pre> vector<string> v; |
| |
| find(v.begin(), v.end(), "foo"); |
| </pre> |
| |
| <p>At issue is whether there is a requirement that the third argument |
| of find be CopyConstructible. There may be no problem here, but |
| analysis is necessary.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>There is no indication in the standard that find's third argument |
| is required to be Copy Constructible. The LWG believes that no such |
| requirement was intended. As noted above, there are times when a user |
| might reasonably pass an argument that is not Copy Constructible.</p> |
| <hr> |
| <a name="245"><h3>245. Which operations on <tt>istream_iterator</tt> trigger input operations?</h3></a><p><b>Section:</b> 24.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istream.iterator"> [lib.istream.iterator]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 02 May 2000</p> |
| <p>I do not think the standard specifies what operation(s) on istream |
| iterators trigger input operations. So, for example:</p> |
| |
| <pre> istream_iterator<int> i(cin); |
| |
| int n = *i++; |
| </pre> |
| |
| <p>I do not think it is specified how many integers have been read |
| from cin. The number must be at least 1, of course, but can it be 2? |
| More?</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>The standard is clear as written: the stream is read every time |
| operator++ is called, and it is also read either when the iterator is |
| constructed or when operator* is called for the first time. In the |
| example above, exactly two integers are read from cin.</p> |
| |
| <p>There may be a problem with the interaction between istream_iterator |
| and some STL algorithms, such as find. There are no guarantees about |
| how many times find may invoke operator++.</p> |
| <hr> |
| <a name="246"><h3>246. <tt>a.insert(p,t)</tt> is incorrectly specified</h3></a><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Mark Rodgers <b>Date:</b> 19 May 2000</p> |
| <p>Closed issue 192 raised several problems with the specification of |
| this function, but was rejected as Not A Defect because it was too big |
| a change with unacceptable impacts on existing implementations. |
| However, issues remain that could be addressed with a smaller change |
| and with little or no consequent impact.</p> |
| |
| <ol> |
| <li> |
| <p> The specification is inconsistent with the original |
| proposal and with several implementations.</p> |
| |
| <p>The initial implementation by Hewlett Packard only ever looked |
| immediately <i>before</i> p, and I do not believe there was any |
| intention to standardize anything other than this behavior. |
| Consequently, current implementations by several leading |
| implementors also look immediately before p, and will only insert |
| after p in logarithmic time. I am only aware of one implementation |
| that does actually look after p, and it looks before p as well. It |
| is therefore doubtful that existing code would be relying on the |
| behavior defined in the standard, and it would seem that fixing |
| this defect as proposed below would standardize existing |
| practice.</p> |
| </li> |
| |
| <li> |
| <p> |
| The specification is inconsistent with insertion for sequence |
| containers.</p> |
| |
| <p>This is difficult and confusing to teach to newcomers. All |
| insert operations that specify an iterator as an insertion location |
| should have a consistent meaning for the location represented by |
| that iterator.</p> |
| </li> |
| |
| <li> |
| <p> As specified, there is no way to hint that the insertion |
| should occur at the beginning of the container, and the way to hint |
| that it should occur at the end is long winded and unnatural.</p> |
| |
| <p>For a container containing n elements, there are n+1 possible |
| insertion locations and n+1 valid iterators. For there to be a |
| one-to-one mapping between iterators and insertion locations, the |
| iterator must represent an insertion location immediately before |
| the iterator.</p> |
| </li> |
| |
| <li> |
| <p> When appending sorted ranges using insert_iterators, |
| insertions are guaranteed to be sub-optimal.</p> |
| |
| <p>In such a situation, the optimum location for insertion is |
| always immediately after the element previously inserted. The |
| mechanics of the insert iterator guarantee that it will try and |
| insert after the element after that, which will never be correct. |
| However, if the container first tried to insert before the hint, |
| all insertions would be performed in amortized constant |
| time.</p> |
| </li> |
| </ol> |
| <p><b>Proposed resolution:</b></p> |
| <p>In 23.1.2 [lib.associative.reqmts] paragraph 7, table 69, make |
| the following changes in the row for a.insert(p,t):</p> |
| |
| <p><i>assertion/note pre/post condition:</i> |
| <br>Change the last sentence from</p> |
| <blockquote> |
| "iterator p is a hint pointing to where the insert should |
| start to search." |
| </blockquote> |
| <p>to</p> |
| <blockquote> |
| "iterator p is a hint indicating that immediately before p |
| may be a correct location where the insertion could occur." |
| </blockquote> |
| |
| <p><i>complexity:</i><br> |
| Change the words "right after" to "immediately before".</p> |
| <p><b>Rationale:</b></p> |
| <p>Duplicate; see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#233">233</a>.</p> |
| <hr> |
| <a name="249"><h3>249. Return Type of <tt>auto_ptr::operator=</tt> |
| </h3></a><p><b>Section:</b> 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.unary"> [lib.meta.unary]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Joseph Gottman <b>Date:</b> 30 Jun 2000</p> |
| <p>According to section 20.4.5, the function |
| <tt>auto_ptr::operator=()</tt> returns a reference to an auto_ptr. |
| The reason that <tt>operator=()</tt> usually returns a reference is to |
| facilitate code like</p> |
| |
| <pre> int x,y,z; |
| x = y = z = 1; |
| </pre> |
| |
| <p>However, given analogous code for <tt>auto_ptr</tt>s,</p> |
| <pre> auto_ptr<int> x, y, z; |
| z.reset(new int(1)); |
| x = y = z; |
| </pre> |
| |
| <p>the result would be that <tt>z</tt> and <tt>y</tt> would both be set to |
| NULL, instead of all the <tt>auto_ptr</tt>s being set to the same value. |
| This makes such cascading assignments useless and counterintuitive for |
| <tt>auto_ptr</tt>s.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p>Change <tt>auto_ptr::operator=()</tt> to return <tt>void</tt> instead |
| of an <tt>auto_ptr</tt> reference.</p> |
| <p><b>Rationale:</b></p> |
| <p>The return value has uses other than cascaded assignments: a user can |
| call an auto_ptr member function, pass the auto_ptr to a |
| function, etc. Removing the return value could break working user |
| code.</p> |
| <hr> |
| <a name="257"><h3>257. STL functional object and iterator inheritance.</h3></a><p><b>Section:</b> 20.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.tuple.tuple"> [lib.tuple.tuple]</a>, 24.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.basic"> [lib.iterator.basic]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Robert Dick <b>Date:</b> 17 Aug 2000</p> |
| <p> |
| According to the November 1997 Draft Standard, the results of deleting an |
| object of a derived class through a pointer to an object of its base class are |
| undefined if the base class has a non-virtual destructor. Therefore, it is |
| potentially dangerous to publicly inherit from such base classes. |
| </p> |
| |
| <p>Defect: |
| <br> |
| The STL design encourages users to publicly inherit from a number of classes |
| which do nothing but specify interfaces, and which contain non-virtual |
| destructors. |
| </p> |
| |
| <p>Attribution: |
| <br> |
| Wil Evers and William E. Kempf suggested this modification for functional |
| objects. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| When a base class in the standard library is useful only as an interface |
| specifier, i.e., when an object of the class will never be directly |
| instantiated, specify that the class contains a protected destructor. This |
| will prevent deletion through a pointer to the base class without performance, |
| or space penalties (on any implementation I'm aware of). |
| </p> |
| |
| <p> |
| As an example, replace... |
| </p> |
| |
| <pre> template <class Arg, class Result> |
| struct unary_function { |
| typedef Arg argument_type; |
| typedef Result result_type; |
| }; |
| </pre> |
| |
| <p> |
| ... with... |
| </p> |
| |
| <pre> template <class Arg, class Result> |
| struct unary_function { |
| typedef Arg argument_type; |
| typedef Result result_type; |
| protected: |
| ~unary_function() {} |
| }; |
| </pre> |
| |
| <p> |
| Affected definitions: |
| <br> |
| 20.3.1 [lib.function.objects] -- unary_function, binary_function |
| <br> |
| 24.3.2 [lib.iterator.basic] -- iterator |
| </p> |
| <p><b>Rationale:</b></p> |
| <p> |
| The standard is clear as written; this is a request for change, not a |
| defect in the strict sense. The LWG had several different objections |
| to the proposed change. One is that it would prevent users from |
| creating objects of type <tt>unary_function</tt> and |
| <tt>binary_function</tt>. Doing so can sometimes be legitimate, if users |
| want to pass temporaries as traits or tag types in generic code. |
| </p> |
| <hr> |
| <a name="267"><h3>267. interaction of strstreambuf::overflow() and seekoff()</h3></a><p><b>Section:</b> D.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 5 Oct 2000</p> |
| <p> |
| It appears that the interaction of the strstreambuf members overflow() |
| and seekoff() can lead to undefined behavior in cases where defined |
| behavior could reasonably be expected. The following program |
| demonstrates this behavior: |
| </p> |
| |
| <pre> #include <strstream> |
| |
| int main () |
| { |
| std::strstreambuf sb; |
| sb.sputc ('c'); |
| |
| sb.pubseekoff (-1, std::ios::end, std::ios::in); |
| return !('c' == sb.sgetc ()); |
| } |
| </pre> |
| |
| <p> |
| D.7.1.1, p1 initializes strstreambuf with a call to basic_streambuf<>(), |
| which in turn sets all pointers to 0 in 27.5.2.1, p1. |
| </p> |
| |
| <p> |
| 27.5.2.2.5, p1 says that basic_streambuf<>::sputc(c) calls |
| overflow(traits::to_int_type(c)) if a write position isn't available (it |
| isn't due to the above). |
| </p> |
| |
| <p> |
| D.7.1.3, p3 says that strstreambuf::overflow(off, ..., ios::in) makes at |
| least one write position available (i.e., it allows the function to make |
| any positive number of write positions available). |
| </p> |
| |
| <p> |
| D.7.1.3, p13 computes newoff = seekhigh - eback(). In D.7.1, p4 we see |
| seekhigh = epptr() ? epptr() : egptr(), or seekhigh = epptr() in this |
| case. newoff is then epptr() - eback(). |
| </p> |
| |
| <p> |
| D.7.1.4, p14 sets gptr() so that gptr() == eback() + newoff + off, or |
| gptr() == epptr() + off holds. |
| </p> |
| |
| <p> |
| If strstreambuf::overflow() made exactly one write position available |
| then gptr() will be set to just before epptr(), and the program will |
| return 0. Buf if the function made more than one write position |
| available, epptr() and gptr() will both point past pptr() and the |
| behavior of the program is undefined. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| |
| |
| <p>Change the last sentence of D.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.strstreambuf"> [depr.strstreambuf]</a> paragraph 4 from</p> |
| |
| <blockquote> |
| Otherwise, seeklow equals gbeg and seekhigh is either pend, if |
| pend is not a null pointer, or gend. |
| </blockquote> |
| |
| <p>to become</p> |
| |
| <blockquote> |
| Otherwise, seeklow equals gbeg and seekhigh is either gend if |
| 0 == pptr(), or pbase() + max where max is the maximum value of |
| pptr() - pbase() ever reached for this stream. |
| </blockquote> |
| |
| <p><i>[ |
| pre-Copenhagen: Dietmar provided wording for proposed resolution. |
| ]</i></p> |
| |
| <p><i>[ |
| post-Copenhagen: Fixed a typo: proposed resolution said to fix |
| 4.7.1, not D.7.1. |
| ]</i></p> |
| |
| <p><b>Rationale:</b></p> |
| <p>This is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a>: it's not clear what it |
| means to seek beyond the current area. Without resolving issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a> we can't resolve this. As with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#65">65</a>, |
| the library working group does not wish to invest time nailing down |
| corner cases in a deprecated feature.</p> |
| <hr> |
| <a name="269"><h3>269. cstdarg and unnamed parameters</h3></a><p><b>Section:</b> 18.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.exception"> [lib.support.exception]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> J. Stephen Adamczyk <b>Date:</b> 10 Oct 2000</p> |
| <p> |
| One of our customers asks whether this is valid C++: |
| </p> |
| |
| <pre> #include <cstdarg> |
| |
| void bar(const char *, va_list); |
| |
| void |
| foo(const char *file, const char *, ...) |
| { |
| va_list ap; |
| va_start(ap, file); |
| bar(file, ap); |
| va_end(ap); |
| } |
| </pre> |
| |
| <p> |
| The issue being whether it is valid to use cstdarg when the final |
| parameter before the "..." is unnamed. cstdarg is, as far |
| as I can tell, inherited verbatim from the C standard. and the |
| definition there (7.8.1.1 in the ISO C89 standard) refers to "the |
| identifier of the rightmost parameter". What happens when there |
| is no such identifier? |
| </p> |
| |
| <p> |
| My personal opinion is that this should be allowed, but some tweak |
| might be required in the C++ standard. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p> |
| Not a defect, the C and C++ standards are clear. It is impossible to |
| use varargs if the parameter immediately before "..." has no |
| name, because that is the parameter that must be passed to va_start. |
| The example given above is broken, because va_start is being passed |
| the wrong parameter. |
| </p> |
| |
| <p> |
| There is no support for extending varargs to provide additional |
| functionality beyond what's currently there. For reasons of C/C++ |
| compatibility, it is especially important not to make gratuitous |
| changes in this part of the C++ standard. The C committee has already |
| been requested not to touch this part of the C standard unless |
| necessary. |
| </p> |
| <hr> |
| <a name="277"><h3>277. Normative encouragement in allocator requirements unclear</h3></a><p><b>Section:</b> 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.default.con.req"> [lib.default.con.req]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 07 Nov 2000</p> |
| <p> |
| In 20.1.5, paragraph 5, the standard says that "Implementors are |
| encouraged to supply libraries that can accept allocators that |
| encapsulate more general memory models and that support non-equal |
| instances." This is intended as normative encouragement to |
| standard library implementors. However, it is possible to interpret |
| this sentence as applying to nonstandard third-party libraries. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| In 20.1.5, paragraph 5, change "Implementors" to |
| "Implementors of the library described in this International |
| Standard". |
| </p> |
| <p><b>Rationale:</b></p> |
| <p>The LWG believes the normative encouragement is already |
| sufficiently clear, and that there are no important consequences |
| even if it is misunderstood.</p> |
| <hr> |
| <a name="279"><h3>279. const and non-const iterators should have equivalent typedefs</h3></a><p><b>Section:</b> 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Steve Cleary <b>Date:</b> 27 Nov 2000</p> |
| |
| <p> |
| This came from an email from Steve Cleary to Fergus in reference to |
| issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>. The library working group briefly discussed |
| this in Toronto and believes it should be a separate issue. |
| </p> |
| |
| <p> |
| Steve said: "We may want to state that the const/non-const iterators must have |
| the same difference type, size_type, and category." |
| </p> |
| |
| <p> |
| (Comment from Judy) |
| I'm not sure if the above sentence should be true for all |
| const and non-const iterators in a particular container, or if it means |
| the container's iterator can't be compared with the container's |
| const_iterator unless the above it true. I suspect the former. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| In <b>Section:</b> 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>, |
| table 65, in the assertion/note pre/post condition for X::const_iterator, |
| add the following: |
| </p> |
| |
| <blockquote> |
| <p> |
| typeid(X::const_iterator::difference_type) == typeid(X::iterator::difference_type) |
| </p> |
| |
| <p> |
| typeid(X::const_iterator::size_type) == typeid(X::iterator::size_type) |
| </p> |
| |
| <p> |
| typeid(X::const_iterator::category) == typeid(X::iterator::category) |
| </p> |
| </blockquote> |
| <p><b>Rationale:</b></p> |
| <p>Going through the types one by one: Iterators don't have a |
| <tt>size_type</tt>. We already know that the difference types are |
| identical, because the container requirements already say that the |
| difference types of both X::iterator and X::const_iterator are both |
| X::difference_type. The standard does not require that X::iterator |
| and X::const_iterator have the same iterator category, but the LWG |
| does not see this as a defect: it's possible to imagine cases in which |
| it would be useful for the categories to be different.</p> |
| |
| <p>It may be desirable to require X::iterator and X::const_iterator to |
| have the same value type, but that is a new issue. (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#322">322</a>.)</p> |
| |
| <hr> |
| <a name="287"><h3>287. conflicting ios_base fmtflags</h3></a><p><b>Section:</b> 27.4.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fmtflags.state"> [lib.fmtflags.state]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 30 Dec 2000</p> |
| <p> |
| The Effects clause for ios_base::setf(fmtflags fmtfl) says |
| "Sets fmtfl in flags()". What happens if the user first calls |
| ios_base::scientific and then calls ios_base::fixed or vice-versa? |
| This is an issue for all of the conflicting flags, i.e. ios_base::left |
| and ios_base::right or ios_base::dec, ios_base::hex and ios_base::oct. |
| </p> |
| |
| <p> |
| I see three possible solutions: |
| </p> |
| |
| <ol> |
| <li>Set ios_base::failbit whenever the user specifies a conflicting |
| flag with one previously explicitly set. If the constructor is |
| supposed to set ios_base::dec (see discussion below), then |
| the user setting hex or oct format after construction will not |
| set failbit. </li> |
| <li>The last call to setf "wins", i.e. it clears any conflicting |
| previous setting.</li> |
| <li>All the flags that the user specifies are set, but when actually |
| interpreting them, fixed always override scientific, right always |
| overrides left, dec overrides hex which overrides oct.</li> |
| </ol> |
| |
| <p> |
| Most existing implementations that I tried seem to conform to resolution #3, |
| except that when using the iomanip manipulator hex or oct then that always |
| overrides dec, but calling setf(ios_base::hex) doesn't. |
| </p> |
| |
| <p> |
| There is a sort of related issue, which is that although the ios_base |
| constructor says that each ios_base member has an indeterminate value |
| after construction, all the existing implementations I tried explicitly set |
| ios_base::dec. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p> |
| <tt>adjustfield</tt>, <tt>basefield</tt>, and <tt>floatfield</tt> |
| are each multi-bit fields. It is possible to set multiple bits within |
| each of those fields. (For example, <tt>dec</tt> and |
| <tt>oct</tt>). These fields are used by locale facets. The LWG |
| reviewed the way in which each of those three fields is used, and |
| believes that in each case the behavior is well defined for any |
| possible combination of bits. See for example Table 58, in 22.2.2.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a>, noting the requirement in paragraph 6 of that |
| section. |
| </p> |
| <p> |
| Users are advised to use manipulators, or else use the two-argument |
| version of <tt>setf</tt>, to avoid unexpected behavior. |
| </p> |
| <hr> |
| <a name="289"><h3>289. <cmath> requirements missing C float and long double versions</h3></a><p><b>Section:</b> 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numarray"> [lib.numarray]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 30 Dec 2000</p> |
| <p> |
| In ISO/IEC 9899:1990 Programming Languages C we find the following |
| concerning <math.h>: |
| </p> |
| |
| <blockquote> |
| 7.13.4 Mathematics <math.h> |
| <br> |
| The names of all existing functions declared in the <math.h> |
| header, suffixed with f or l, are reserved respectively for |
| corresponding functions with float and long double arguments |
| are return values. |
| </blockquote> |
| |
| <p> |
| For example, <tt>float sinf(float)</tt> |
| is reserved. |
| </p> |
| |
| <p> |
| In the C99 standard, <math.h> must contain declarations |
| for these functions. |
| </p> |
| |
| <p> |
| So, is it acceptable for an implementor to add these prototypes to the |
| C++ versions of the math headers? Are they required? |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Add these Functions to Table 80, section 26.5 and to Table 99, |
| section C.2: |
| </p> |
| |
| <pre> acosf asinf atanf atan2f ceilf cosf coshf |
| expf fabsf floorf fmodf frexpf ldexpf |
| logf log10f modff powf sinf sinhf sqrtf |
| tanf tanhf |
| acosl asinl atanl atan2l ceill cosl coshl |
| expl fabsl floorl fmodl frexpl ldexpl |
| logl log10l modfl powl sinl sinhl sqrtl |
| tanl tanhl |
| </pre> |
| |
| <p> |
| There should probably be a note saying that these functions |
| are optional and, if supplied, should match the description in |
| the 1999 version of the C standard. In the next round |
| of C++ standardization they can then become mandatory. |
| </p> |
| <p><b>Rationale:</b></p> |
| <p>The C90 standard, as amended, already permits (but does not |
| require) these functions, and the C++ standard incorporates the |
| C90 standard by reference. C99 is not an issue, because it is |
| never referred to by the C++ standard.</p> |
| <hr> |
| <a name="293"><h3>293. Order of execution in transform algorithm</h3></a><p><b>Section:</b> 25.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.transform"> [lib.alg.transform]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Angelika Langer <b>Date:</b> 04 Jan 2001</p> |
| <p>This issue is related to issue 242. In case that the resolution |
| proposed for issue 242 is accepted, we have have the following |
| situation: The 4 numeric algorithms (accumulate and consorts) as well |
| as transform would allow a certain category of side effects. The |
| numeric algorithms specify that they invoke the functor "for |
| every iterator i in the range [first, last) in order". transform, |
| in contrast, would not give any guarantee regarding order of |
| invocation of the functor, which means that the functor can be invoked |
| in any arbitrary order. |
| </p> |
| |
| <p>Why would that be a problem? Consider an example: say the |
| transformator that is a simple enumerator ( or more generally |
| speaking, "is order-sensitive" ). Since a standard |
| compliant implementation of transform is free to invoke the enumerator |
| in no definite order, the result could be a garbled enumeration. |
| Strictly speaking this is not a problem, but it is certainly at odds |
| with the prevalent understanding of transform as an algorithms that |
| assigns "a new _corresponding_ value" to the output |
| elements. |
| </p> |
| |
| <p>All implementations that I know of invoke the transformator in |
| definite order, namely starting from first and proceeding to last - |
| 1. Unless there is an optimization conceivable that takes advantage of |
| the indefinite order I would suggest to specify the order, because it |
| eliminate the uncertainty that users would otherwise have regarding |
| the order of execution of their potentially order-sensitive function |
| objects. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p>In section 25.2.3 - Transform [lib.alg.transform] change:</p> |
| <blockquote> |
| -1- Effects: Assigns through every iterator i in the range [result, |
| result + (last1 - first1)) a new corresponding |
| value equal to op(*(first1 + (i - result)) or binary_op(*(first1 + |
| (i - result), *(first2 + (i - result))). |
| </blockquote> |
| <p>to:</p> |
| <blockquote> |
| -1- Effects: Computes values by invoking the operation op or binary_op |
| for every iterator in the range [first1, last1) in order. Assigns through |
| every iterator i in the range [result, result + (last1 - first1)) a new |
| corresponding |
| value equal to op(*(first1 + (i - result)) or binary_op(*(first1 + |
| (i - result), *(first2 + (i - result))). |
| </blockquote> |
| <p><b>Rationale:</b></p> |
| <p>For Input Iterators an order is already guaranteed, because |
| only one order is possible. If a user who passes a Forward |
| Iterator to one of these algorithms really needs a specific |
| order of execution, it's possible to achieve that effect by |
| wrapping it in an Input Iterator adaptor.</p> |
| <hr> |
| <a name="296"><h3>296. Missing descriptions and requirements of pair operators</h3></a><p><b>Section:</b> 20.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.pairs"> [lib.pairs]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 14 Jan 2001</p> |
| <p>The synopsis of the header <tt><utility></tt> in 20.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.utility"> [lib.utility]</a> |
| lists the complete set of equality and relational operators for <tt>pair</tt> |
| but the section describing the template and the operators only describes |
| <tt>operator==()</tt> and <tt>operator<()</tt>, and it fails to mention |
| any requirements on the template arguments. The remaining operators are |
| not mentioned at all. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>20.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.operators"> [lib.operators]</a> paragraph 10 already specifies the semantics. |
| That paragraph says that, if declarations of operator!=, operator>, |
| operator<=, and operator>= appear without definitions, they are |
| defined as specified in 20.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.operators"> [lib.operators]</a>. There should be no user |
| confusion, since that paragraph happens to immediately precede the |
| specification of <tt>pair</tt>.</p> |
| <hr> |
| <a name="302"><h3>302. Need error indication from codecvt<>::do_length</h3></a><p><b>Section:</b> 22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Gregory Bumgardner <b>Date:</b> 25 Jan 2001</p> |
| <p> |
| The effects of <tt>codecvt<>::do_length()</tt> are described in |
| 22.2.1.5.2, paragraph 10. As implied by that paragraph, and clarified |
| in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#75">75</a>, <tt>codecvt<>::do_length()</tt> must |
| process the source data and update the <tt>stateT</tt> argument just |
| as if the data had been processed by <tt>codecvt<>::in()</tt>. |
| However, the standard does not specify how <tt>do_length()</tt> would |
| report a translation failure, should the source sequence contain |
| untranslatable or illegal character sequences. |
| </p> |
| |
| <p> |
| The other conversion methods return an "error" result value |
| to indicate that an untranslatable character has been encountered, but |
| <tt>do_length()</tt> already has a return value (the number of source |
| characters that have been processed by the method). |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| This issue cannot be resolved without modifying the interface. An exception |
| cannot be used, as there would be no way to determine how many characters |
| have been processed and the state object would be left in an indeterminate |
| state. |
| </p> |
| |
| <p> |
| A source compatible solution involves adding a fifth argument to length() |
| and do_length() that could be used to return position of the offending |
| character sequence. This argument would have a default value that would |
| allow it to be ignored: |
| </p> |
| |
| <pre> int length(stateT& state, |
| const externT* from, |
| const externT* from_end, |
| size_t max, |
| const externT** from_next = 0); |
| |
| virtual |
| int do_length(stateT& state, |
| const externT* from, |
| const externT* from_end, |
| size_t max, |
| const externT** from_next); |
| </pre> |
| |
| <p> |
| Then an exception could be used to report any translation errors and |
| the from_next argument, if used, could then be used to retrieve the |
| location of the offending character sequence. |
| </p> |
| <p><b>Rationale:</b></p> |
| <p>The standard is already clear: the return value is the number of |
| "valid complete characters". If it encounters an invalid sequence of |
| external characters, it stops.</p> |
| <hr> |
| <a name="304"><h3>304. Must <tt>*a</tt> return an lvalue when <tt>a</tt> is an input iterator?</h3></a><p><b>Section:</b> 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 5 Feb 2001</p> |
| <p> |
| We all "know" that input iterators are allowed to produce |
| values when dereferenced of which there is no other in-memory copy. |
| </p> |
| |
| <p> |
| But: Table 72, with a careful reading, seems to imply that this can only be |
| the case if the value_type has no members (e.g. is a built-in type). |
| </p> |
| |
| <p>The problem occurs in the following entry:</p> |
| |
| <pre> a->m pre: (*a).m is well-defined |
| Equivalent to (*a).m |
| </pre> |
| |
| <p> |
| <tt>*a.m</tt> can be well-defined if <tt>*a</tt> is not a reference |
| type, but since <tt>operator->()</tt> must return a pointer for |
| <tt>a->m</tt> to be well-formed, it needs something to return a |
| pointer <i>to</i>. This seems to indicate that <tt>*a</tt> must be |
| buffered somewhere to make a legal input iterator. |
| </p> |
| |
| <p>I don't think this was intentional.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>The current standard is clear and consistent. Input iterators that |
| return rvalues are in fact implementable. They may in some cases |
| require extra work, but it is still possible to define an operator-> |
| in such cases: it doesn't have to return a T*, but may return a |
| proxy type. No change to the standard is justified.</p> |
| <hr> |
| <a name="313"><h3>313. set_terminate and set_unexpected question</h3></a><p><b>Section:</b> 18.7.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.terminate"> [lib.terminate]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Judy Ward <b>Date:</b> 3 Apr 2001</p> |
| <p> |
| According to section 18.7.3.3 of the standard, std::terminate() is |
| supposed to call the terminate_handler in effect immediately after |
| evaluating the throw expression. |
| </p> |
| |
| <p> |
| Question: what if the terminate_handler in effect is itself |
| std::terminate? |
| </p> |
| |
| <p>For example:</p> |
| |
| <pre> #include <exception> |
| |
| int main () { |
| std::set_terminate(std::terminate); |
| throw 5; |
| return 0; |
| } |
| </pre> |
| |
| <p> |
| Is the implementation allowed to go into an infinite loop? |
| </p> |
| |
| <p> |
| I think the same issue applies to std::set_unexpected. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>Infinite recursion is to be expected: users who set the terminate |
| handler to <tt>terminate</tt> are explicitly asking for <tt>terminate</tt> |
| to call itself.</p> |
| <hr> |
| <a name="314"><h3>314. Is the stack unwound when terminate() is called?</h3></a><p><b>Section:</b> 18.7.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.terminate"> [lib.terminate]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Detlef Vollmann <b>Date:</b> 11 Apr 2001</p> |
| |
| <p> |
| The standard appears to contradict itself about whether the stack is |
| unwound when the implementation calls terminate(). |
| </p> |
| |
| <p>From 18.7.3.3p2:</p> |
| <blockquote> |
| Calls the terminate_handler function in effect immediately |
| after evaluating the throw-expression (lib.terminate.handler), |
| if called by the implementation [...] |
| </blockquote> |
| |
| <p>So the stack is guaranteed not to be unwound.</p> |
| |
| <p>But from 15.3p9:</p> |
| <blockquote> |
| [...]whether or not the stack is unwound before this call |
| to terminate() is implementation-defined (except.terminate). |
| </blockquote> |
| |
| <p> |
| And 15.5.1 actually defines that in most cases the stack is unwound. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>There is definitely no contradiction between the core and library |
| clauses; nothing in the core clauses says that stack unwinding happens |
| after <tt>terminate</tt> is called. 18.7.3.3p2 does not say anything |
| about when terminate() is called; it merely specifies which |
| <tt>terminate_handler</tt> is used.</p> |
| <hr> |
| <a name="323"><h3>323. abs() overloads in different headers</h3></a><p><b>Section:</b> 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numarray"> [lib.numarray]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 4 June 2001</p> |
| <p>Currently the standard mandates the following overloads of |
| abs():</p> |
| |
| <pre> abs(long), abs(int) in <cstdlib> |
| |
| abs(float), abs(double), abs(long double) in <cmath> |
| |
| template<class T> T abs(const complex<T>&) in <complex> |
| |
| template<class T> valarray<T> abs(const valarray<T>&); in <valarray> |
| </pre> |
| |
| <p> |
| The problem is that having only some overloads visible of a function |
| that works on "implicitly inter-convertible" types is dangerous in |
| practice. The headers that get included at any point in a translation |
| unit can change unpredictably during program |
| development/maintenance. The wrong overload might be unintentionally |
| selected. |
| </p> |
| |
| <p> |
| Currently, there is nothing that mandates the simultaneous visibility |
| of these overloads. Indeed, some vendors have begun fastidiously |
| reducing dependencies among their (public) headers as a QOI issue: it |
| helps people to write portable code by refusing to compile unless all |
| the correct headers are #included. |
| </p> |
| |
| <p>The same issue may exist for other functions in the library.</p> |
| |
| <p>Redmond: PJP reports that C99 adds two new kinds of abs: complex, |
| and int_max_abs.</p> |
| |
| <p>Related issue: <font color="red">343</font>.</p> |
| |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>The programs that could potentially be broken by this situation are |
| already fragile, and somewhat contrived: For example, a user-defined |
| class that has conversion overloads both to <tt>long</tt> and |
| to <tt>float</tt>. If <tt>x</tt> is a value of such a class, then |
| <tt>abs(x)</tt> would give the <tt>long</tt> version if the user |
| included <cstdlib>, the <tt>float</tt> version if the user |
| included <cmath>, and would be diagnosed as ambiguous at |
| compile time if the user included both headers. The LWG couldn't |
| find an example of a program whose meaning would be changed (as |
| opposed to changing it from well-formed to ill-formed) simply by |
| adding another standard header.</p> |
| |
| <p>Since the harm seems minimal, and there don't seem to be any simple |
| and noninvasive solutions, this is being closed as NAD. It is |
| marked as "Future" for two reasons. First, it might be useful to |
| define an <tt><all></tt> header that would include all |
| Standard Library headers. Second, we should at least make sure that |
| future library extensions don't make this problem worse.</p> |
| <hr> |
| <a name="326"><h3>326. Missing typedef in moneypunct_byname</h3></a><p><b>Section:</b> 22.2.6.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.moneypunct.byname"> [lib.locale.moneypunct.byname]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 05 Jul 2001</p> |
| <p>The definition of the moneypunct facet contains the typedefs char_type |
| and string_type. Only one of these names, string_type, is defined in |
| the derived facet, moneypunct_byname.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p>For consistency with the numpunct facet, add a typedef for |
| char_type to the definition of the moneypunct_byname facet in |
| 22.2.6.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.moneypunct.byname"> [lib.locale.moneypunct.byname]</a>.</p> |
| <p><b>Rationale:</b></p> |
| <p>The absence of the typedef is irrelevant. Users can still access |
| the typedef, because it is inherited from the base class.</p> |
| <hr> |
| <a name="330"><h3>330. Misleading "exposition only" value in class locale definition</h3></a><p><b>Section:</b> 22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 15 Jul 2001</p> |
| <p> |
| The "exposition only" value of the std::locale::none constant shown in |
| the definition of class locale is misleading in that it on many |
| systems conflicts with the value assigned to one if the LC_XXX |
| constants (specifically, LC_COLLATE on AIX, LC_ALL on HP-UX, LC_CTYPE |
| on Linux and SunOS). This causes incorrect behavior when such a |
| constant is passed to one of the locale member functions that accept a |
| locale::category argument and interpret it as either the C LC_XXX |
| constant or a bitmap of locale::category values. At least three major |
| implementations adopt the suggested value without a change and |
| consequently suffer from this problem. |
| </p> |
| |
| <p> |
| For instance, the following code will (presumably) incorrectly copy facets |
| belonging to the collate category from the German locale on AIX: |
| </p> |
| |
| <pre> std::locale l (std::locale ("C"), "de_DE", std::locale::none); |
| </pre> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>The LWG agrees that it may be difficult to implement locale member |
| functions in such a way that they can take either <tt>category</tt> |
| arguments or the LC_ constants defined in <cctype>. In light of |
| this requirement (22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a>, paragraph 2), and in light |
| of the requirement in the preceding paragraph that it is possible to |
| combine <tt>category</tt> bitmask elements with bitwise operations, |
| defining the <tt>category</tt> elements is delicate, |
| particularly if an implementor is constrained to work with a |
| preexisting C library. (Just using the existing LC_ constants would |
| not work in general.) There's no set of "exposition only" values that |
| could give library implementors proper guidance in such a delicate |
| matter. The non-normative example we're giving is no worse than |
| any other choice would be.</p> |
| |
| <p>See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#347">347</a>.</p> |
| <hr> |
| <a name="332"><h3>332. Consider adding increment and decrement operators to std::fpos< T > </h3></a><p><b>Section:</b> 27.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos"> [lib.fpos]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> PremAnand M. Rao <b>Date:</b> 27 Aug 2001</p> |
| <p> |
| Increment and decrement operators are missing from |
| Table 88 -- Position type requirements in 27.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos"> [lib.fpos]</a>. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Table 88 (section 27.4.3) -- Position type requirements |
| be updated to include increment and decrement operators. |
| </p> |
| |
| <pre>expression return type operational note |
| |
| ++p fpos& p += O(1) |
| p++ fpos { P tmp = p; |
| ++p; |
| return tmp; } |
| --p fpos& p -= O(1) |
| p-- fpos { P tmp = p; |
| --p; |
| return tmp; } |
| </pre> |
| |
| <p><b>Rationale:</b></p> |
| <p>The LWG believes this is a request for extension, not a defect |
| report. Additionally, nobody saw a clear need for this extension; |
| <tt>fpos</tt> is used only in very limited ways.</p> |
| <hr> |
| <a name="344"><h3>344. grouping + showbase</h3></a><p><b>Section:</b> 22.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.category.numeric"> [lib.category.numeric]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 13 Oct 2001</p> |
| <p> |
| When both grouping and showbase are active and the basefield is octal, |
| does the leading 0 participate in the grouping or not? For example, |
| should one format as: 0,123,456 or 0123,456? |
| </p> |
| <p> |
| An analogy can be drawn with hexadecimal. It appears that 0x123,456 is |
| preferred over 0x,123,456. However, this analogy is not universally |
| accepted to apply to the octal base. The standard is not clear on how |
| to format (or parse) in this manner. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Insert into 22.2.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a> paragraph 3, just before the last |
| sentence: |
| </p> |
| <blockquote> |
| The leading hexadecimal base specifier "0x" does not participate in |
| grouping. The leading '0' octal base specifier may participate in |
| grouping. It is unspecified if the leading '0' participates in |
| formatting octal numbers. In parsing octal numbers, the implementation |
| is encouraged to accept both the leading '0' participating in the |
| grouping, and not participating (e.g. 0123,456 or 0,123,456). |
| </blockquote> |
| <p><b>Rationale:</b></p> |
| <p> |
| The current behavior may be unspecified, but it's not clear that it |
| matters. This is an obscure corner case, since grouping is usually |
| intended for the benefit of humans and oct/hex prefixes are usually |
| intended for the benefit of machines. There is not a strong enough |
| consensus in the LWG for action. |
| </p> |
| <hr> |
| <a name="348"></a><h3><a name="348">348. Minor issue with std::pair operator<</a></h3><p><b>Section:</b> 20.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.pairs"> [lib.pairs]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Andy Sawyer <b>Date:</b> 23 Oct 2001</p> |
| <p> |
| The current wording of 20.2.2 [lib.pairs] p6 precludes the use of |
| operator< on any pair type which contains a pointer. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p>In 20.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.pairs"> [lib.pairs]</a> paragraph 6, replace:</p> |
| <pre> Returns: x.first < y.first || (!(y.first < x.first) && x.second < |
| y.second). |
| </pre> |
| <p>With:</p> |
| <pre> Returns: std::less<T1>()( x.first, y.first ) || |
| (!std::less<T1>()( y.first, x.first) && |
| std::less<T2>()( x.second, y.second ) ) |
| </pre> |
| |
| <p><b>Rationale:</b></p> |
| <p>This is an instance of a much more general problem. If we want |
| operator< to translate to std::less for pairs of pointers, where |
| do we draw the line? The same issue applies to individual |
| pointers, smart pointer wrappers, std::vector<T*>, and so |
| on.</p> |
| |
| <p>Andy Koenig suggests that the real issue here is that we aren't |
| distinguishing adequately between two different orderings, a |
| "useful ordering" and a "canonical ordering" that's used just |
| because we sometimes need <i>some</i> ordering without caring much |
| which ordering it is. Another example of the later is typeinfo's |
| <tt>before</tt>.</p> |
| |
| <hr> |
| <a name="350"><h3>350. allocator<>::address</h3></a><p><b>Section:</b> 20.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.members"> [lib.allocator.members]</a>, 20.1.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.allocator.requirements"> [lib.allocator.requirements]</a>, 17.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.contents"> [lib.contents]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Nathan Myers <b>Date:</b> 25 Oct 2001</p> |
| <p>See c++std-lib-9006 and c++std-lib-9007. This issue is taken |
| verbatim from -9007.</p> |
| |
| <p> |
| The core language feature allowing definition of operator&() applied |
| to any non-builtin type makes that operator often unsafe to use in |
| implementing libraries, including the Standard Library. The result |
| is that many library facilities fail for legal user code, such as |
| the fragment</p> |
| <pre> class A { private: A* operator&(); }; |
| std::vector<A> aa; |
| |
| class B { }; |
| B* operator&(B&) { return 0; } |
| std::vector<B> ba; |
| </pre> |
| |
| <p> |
| In particular, the requirements table for Allocator (Table 32) specifies |
| no semantics at all for member address(), and allocator<>::address is |
| defined in terms of unadorned operator &. |
| </p> |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| In 20.6.1.1, Change the definition of allocator<>::address from:</p> |
| <blockquote> |
| Returns: &x |
| </blockquote> |
| |
| <p>to:</p> |
| |
| <p> |
| Returns: The value that the built in operator&(x) would return if not |
| overloaded. |
| </p> |
| |
| <p> |
| In 20.1.6, Table 32, add to the Notes column of the a.address(r) and |
| a.address(s) lines, respectively: |
| </p> |
| |
| <pre> allocator<T>::address(r) |
| allocator<T>::address(s) |
| </pre> |
| |
| <p>In addition, in clause 17.4.1.1, add a statement:</p> |
| |
| <blockquote> |
| The Standard Library does not apply operator& to any type for which |
| operator& may be overloaded. |
| </blockquote> |
| |
| <p><b>Rationale:</b></p> |
| <p>The LWG believes both examples are ill-formed. The contained type |
| is required to be CopyConstructible (20.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.copyconstructible"> [lib.copyconstructible]</a>), and that |
| includes the requirement that &t return the usual types and |
| values. Since allocators are intended to be used in conjunction with |
| containers, and since the CopyConstructible requirements appear to |
| have been written to deal with the concerns of this issue, the LWG |
| feels it is NAD unless someone can come up with a well-formed example |
| exhibiting a problem.</p> |
| |
| <p>It may well be that the CopyConstructible requirements are too |
| restrictive and that either the container requirements or the |
| CopyConstructive requirements should be relaxed, but that's a far |
| larger issue. Marking this issue as "future" as a pointer to that |
| larger issue.</p> |
| <hr> |
| <a name="351"><h3>351. unary_negate and binary_negate: struct or class?</h3></a><p><b>Section:</b> 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.tuple"> [lib.tuple]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Dale Riley <b>Date:</b> 12 Nov 2001</p> |
| <p> |
| In 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.tuple"> [lib.tuple]</a> the header <functional> synopsis declares |
| the unary_negate and binary_negate function objects as struct. |
| However in <font color="red">20.3.5</font> the unary_negate and binary_negate |
| function objects are defined as class. Given the context, they are |
| not "basic function objects" like negate, so this is either a typo or |
| an editorial oversight. |
| </p> |
| |
| <p><i>[Taken from comp.std.c++]</i></p> |
| <p><b>Proposed resolution:</b></p> |
| <p>Change the synopsis to reflect the useage in <font color="red">20.3.5</font></p> |
| |
| <p><i>[Curaçao: Since the language permits "struct", the LWG |
| views this as NAD. They suggest, however, that the Project Editor |
| might wish to make the change as editorial.]</i></p> |
| |
| <hr> |
| <a name="353"><h3>353. <tt>std::pair</tt> missing template assignment</h3></a><p><b>Section:</b> 20.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.pairs"> [lib.pairs]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 2 Dec 2001</p> |
| <p> |
| The class template <tt>std::pair</tt> defines a template ctor (20.2.2, p4) but |
| no template assignment operator. This may lead to inefficient code since |
| assigning an object of <tt>pair<C, D></tt> to <tt>pair<A, B></tt> |
| where the types <tt>C</tt> and <tt>D</tt> are distinct from but convertible to |
| <tt>A</tt> and <tt>B</tt>, respectively, results in a call to the template copy |
| ctor to construct an unnamed temporary of type <tt>pair<A, B></tt> |
| followed by an ordinary (perhaps implicitly defined) assignment operator, |
| instead of just a straight assignment. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Add the following declaration to the definition of <tt>std::pair</tt>: |
| </p> |
| <pre> template<class U, class V> |
| pair& operator=(const pair<U, V> &p); |
| </pre> |
| <p> |
| And also add a paragraph describing the effects of the function template to the |
| end of 20.2.2: |
| </p> |
| <pre> template<class U, class V> |
| pair& operator=(const pair<U, V> &p); |
| </pre> |
| <p> |
| <b>Effects</b>: <tt>first = p.first;</tt> |
| <tt>second = p.second;</tt> |
| <b>Returns</b>: <tt>*this</tt> |
| </p> |
| |
| <p><i>[Curaçao: There is no indication this is was anything other than |
| a design decision, and thus NAD. May be appropriate for a future |
| standard.]</i></p> |
| |
| <hr> |
| <a name="356"><h3>356. Meaning of ctype_base::mask enumerators</h3></a><p><b>Section:</b> 22.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 23 Jan 2002</p> |
| |
| <p>What should the following program print?</p> |
| |
| <pre> #include <locale> |
| #include <iostream> |
| |
| class my_ctype : public std::ctype<char> |
| { |
| typedef std::ctype<char> base; |
| public: |
| my_ctype(std::size_t refs = 0) : base(my_table, false, refs) |
| { |
| std::copy(base::classic_table(), base::classic_table() + base::table_size, |
| my_table); |
| my_table[(unsigned char) '_'] = (base::mask) (base::print | base::space); |
| } |
| private: |
| mask my_table[base::table_size]; |
| }; |
| |
| int main() |
| { |
| my_ctype ct; |
| std::cout << "isspace: " << ct.is(std::ctype_base::space, '_') << " " |
| << "isalpha: " << ct.is(std::ctype_base::alpha, '_') << std::endl; |
| } |
| </pre> |
| |
| <p>The goal is to create a facet where '_' is treated as whitespace.</p> |
| |
| <p>On gcc 3.0, this program prints "isspace: 1 isalpha: 0". On |
| Microsoft C++ it prints "isspace: 1 isalpha: 1".</p> |
| |
| <p> |
| I believe that both implementations are legal, and the standard does not |
| give enough guidance for users to be able to use std::ctype's |
| protected interface portably.</p> |
| |
| <p> |
| The above program assumes that ctype_base::mask enumerators like |
| <tt>space</tt> and <tt>print</tt> are disjoint, and that the way to |
| say that a character is both a space and a printing character is to or |
| those two enumerators together. This is suggested by the "exposition |
| only" values in 22.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a>, but it is nowhere specified in |
| normative text. An alternative interpretation is that the more |
| specific categories subsume the less specific. The above program |
| gives the results it does on the Microsoft compiler because, on that |
| compiler, <tt>print</tt> has all the bits set for each specific |
| printing character class. |
| </p> |
| |
| <p>From the point of view of std::ctype's public interface, there's no |
| important difference between these two techniques. From the point of |
| view of the protected interface, there is. If I'm defining a facet |
| that inherits from std::ctype<char>, I'm the one who defines the |
| value that table()['a'] returns. I need to know what combination of |
| mask values I should use. This isn't so very esoteric: it's exactly |
| why std::ctype has a protected interface. If we care about users |
| being able to write their own ctype facets, we have to give them a |
| portable way to do it. |
| </p> |
| |
| <p> |
| Related reflector messages: |
| lib-9224, lib-9226, lib-9229, lib-9270, lib-9272, lib-9273, lib-9274, |
| lib-9277, lib-9279. |
| </p> |
| |
| <p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a> is related, but not identical. The |
| proposed resolution if issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#339">339</a> says that |
| ctype_base::mask must be a bitmask type. It does not say that the |
| ctype_base::mask elements are bitmask elements, so it doesn't |
| directly affect this issue.</p> |
| |
| <p>More comments from Benjamin Kosnik, who believes that |
| that C99 compatibility essentially requires what we're |
| calling option 1 below.</p> |
| |
| <blockquote> |
| <pre>I think the C99 standard is clear, that isspace -> !isalpha. |
| -------- |
| |
| #include <locale> |
| #include <iostream> |
| |
| class my_ctype : public std::ctype<char> |
| { |
| private: |
| typedef std::ctype<char> base; |
| mask my_table[base::table_size]; |
| |
| public: |
| my_ctype(std::size_t refs = 0) : base(my_table, false, refs) |
| { |
| std::copy(base::classic_table(), base::classic_table() + base::table_size, |
| my_table); |
| mask both = base::print | base::space; |
| my_table[static_cast<mask>('_')] = both; |
| } |
| }; |
| |
| int main() |
| { |
| using namespace std; |
| my_ctype ct; |
| cout << "isspace: " << ct.is(ctype_base::space, '_') << endl; |
| cout << "isprint: " << ct.is(ctype_base::print, '_') << endl; |
| |
| // ISO C99, isalpha iff upper | lower set, and !space. |
| // 7.5, p 193 |
| // -> looks like g++ behavior is correct. |
| // 356 -> bitmask elements are required for ctype_base |
| // 339 -> bitmask type required for mask |
| cout << "isalpha: " << ct.is(ctype_base::alpha, '_') << endl; |
| } |
| </pre> |
| </blockquote> |
| |
| <p><b>Proposed resolution:</b></p> |
| <p>Informally, we have three choices:</p> |
| <ol> |
| <li>Require that the enumerators are disjoint (except for alnum and |
| graph)</li> |
| <li>Require that the enumerators are not disjoint, and specify which |
| of them subsume which others. (e.g. mandate that lower includes alpha |
| and print)</li> |
| <li>Explicitly leave this unspecified, which the result that the above |
| program is not portable.</li> |
| </ol> |
| |
| <p>Either of the first two options is just as good from the standpoint |
| of portability. Either one will require some implementations to |
| change.</p> |
| <p><b>Rationale:</b></p> |
| <p>The LWG agrees that this is a real ambiguity, and that both |
| interpretations are conforming under the existing standard. However, |
| there's no evidence that it's causing problems for real users. Users |
| who want to define ctype facets portably can test the ctype_base masks |
| to see which interpretation is being used.</p> |
| <hr> |
| <a name="357"><h3>357. <cmath> float functions cannot return HUGE_VAL</h3></a><p><b>Section:</b> 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numarray"> [lib.numarray]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 26 Feb 2002</p> |
| <p> |
| The float versions of the math functions have no meaningful value to return |
| for a range error. The long double versions have a value they can return, |
| but it isn't necessarily the most reasonable value. |
| </p> |
| |
| <p> |
| Section 26.5 [lib.c.math], paragraph 5, says that C++ "adds float and long |
| double overloaded versions of these functions, with the same semantics," |
| referring to the math functions from the C90 standard. |
| </p> |
| |
| <p> |
| The C90 standard, in section 7.5.1, paragraph 3, says that functions return |
| "the value of the macro HUGE_VAL" when they encounter a range error. |
| Section 7.5, paragraph 2, defines HUGE_VAL as a macro that "expands to a |
| positive double expression, not necessarily representable as a float." |
| </p> |
| |
| <p> |
| Therefore, the float versions of the math functions have no way to |
| signal a range error. <i>[Curaçao: The LWG notes that this isn't |
| strictly correct, since errno is set.]</i> The semantics require that they |
| return HUGE_VAL, but they cannot because HUGE_VAL might not be |
| representable as a float. |
| </p> |
| |
| <p> |
| The problem with long double functions is less severe because HUGE_VAL is |
| representable as a long double. On the other hand, it might not be a "huge" |
| long double value, and might fall well within the range of normal return |
| values for a long double function. Therefore, it does not make sense for a |
| long double function to return a double (HUGE_VAL) for a range error. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p>Curaçao: C99 was faced with a similar problem, which they fixed by |
| adding HUGE_VALF and HUGE_VALL in addition to HUGE_VAL.</p> |
| |
| <p>C++ must also fix, but it should be done in the context of the |
| general C99 based changes to C++, not via DR. Thus the LWG in Curaçao |
| felt the resolution should be NAD, FUTURE, but the issue is being held |
| open for one more meeting to ensure LWG members not present during the |
| discussion concur.</p> |
| <p><b>Rationale:</b></p> |
| <p>Will be fixed as part of more general work in the TR.</p> |
| <hr> |
| <a name="361"><h3>361. num_get<>::do_get (..., void*&) checks grouping</h3></a><p><b>Section:</b> 22.2.2.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.put.virtuals"> [lib.facet.num.put.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 12 Mar 2002</p> |
| <p> |
| 22.2.2.2.2, p12 specifies that <tt>thousands_sep</tt> is to be inserted only |
| for integral types (issue 282 suggests that this should be done for |
| all arithmetic types). |
| </p> |
| |
| <p> |
| 22.2.2.1.2, p12 requires that grouping be checked for all extractors |
| including that for <tt>void*</tt>. |
| </p> |
| |
| <p> |
| I don't think that's right. <tt>void*</tt> values should not be checked for |
| grouping, should they? (Although if they should, then <tt>num_put</tt> needs |
| to write them out, otherwise their extraction will fail.) |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change the first sentence of 22.2.2.2.2, p12 from |
| </p> |
| <blockquote> |
| Digit grouping is checked. That is, the positions of discarded |
| separators is examined for consistency with |
| use_facet<numpunct<charT> >(loc).grouping(). |
| If they are not consistent then ios_base::failbit is assigned |
| to err. |
| </blockquote> |
| |
| <p>to</p> |
| <blockquote> |
| Except for conversions to void*, digit grouping is checked... |
| </blockquote> |
| |
| <p><b>Rationale:</b></p> |
| <p>This would be a change: as it stands, the standard clearly |
| specifies that grouping applies to void*. A survey of existing |
| practice shows that most existing implementations do that, as they |
| should.</p> |
| <hr> |
| <a name="366"><h3>366. Excessive const-qualification</h3></a><p><b>Section:</b> 27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Walter Brown, Marc Paterno <b>Date:</b> 10 May 2002</p> |
| <p> |
| The following member functions are declared const, yet return non-const |
| pointers. We believe they are should be changed, because they allow code |
| that may surprise the user. See document N1360 for details and |
| rationale. |
| </p> |
| |
| <p><i>[Santa Cruz: the real issue is that we've got const member |
| functions that return pointers to non-const, and N1360 proposes |
| replacing them by overloaded pairs. There isn't a consensus about |
| whether this is a real issue, since we've never said what our |
| constness policy is for iostreams. N1360 relies on a distinction |
| between physical constness and logical constness; that distinction, or |
| those terms, does not appear in the standard.]</i></p> |
| |
| <p><b>Proposed resolution:</b></p> |
| <p>In 27.4.4 and 27.4.4.2</p> |
| <p>Replace</p> |
| <pre> basic_ostream<charT,traits>* tie() const; |
| </pre> |
| <p>with</p> |
| <pre> basic_ostream<charT,traits>* tie(); |
| const basic_ostream<charT,traits>* tie() const; |
| </pre> |
| |
| <p>and replace</p> |
| <pre> basic_streambuf<charT,traits>* rdbuf() const; |
| </pre> |
| <p>with</p> |
| <pre> basic_streambuf<charT,traits>* rdbuf(); |
| const basic_streambuf<charT,traits>* rdbuf() const; |
| </pre> |
| |
| <p>In 27.5.2 and 27.5.2.3.1</p> |
| <p>Replace</p> |
| <pre> char_type* eback() const; |
| </pre> |
| <p>with</p> |
| <pre> char_type* eback(); |
| const char_type* eback() const; |
| </pre> |
| |
| <p>Replace</p> |
| <pre> char_type gptr() const; |
| </pre> |
| <p>with</p> |
| <pre> char_type* gptr(); |
| const char_type* gptr() const; |
| </pre> |
| |
| <p>Replace</p> |
| <pre> char_type* egptr() const; |
| </pre> |
| <p>with</p> |
| <pre> char_type* egptr(); |
| const char_type* egptr() const; |
| </pre> |
| |
| <p>In 27.5.2 and 27.5.2.3.2</p> |
| <p>Replace</p> |
| <pre> char_type* pbase() const; |
| </pre> |
| <p>with</p> |
| <pre> char_type* pbase(); |
| const char_type* pbase() const; |
| </pre> |
| |
| <p>Replace</p> |
| <pre> char_type* pptr() const; |
| </pre> |
| <p>with</p> |
| <pre> char_type* pptr(); |
| const char_type* pptr() const; |
| </pre> |
| |
| <p>Replace</p> |
| <pre> char_type* epptr() const; |
| </pre> |
| <p>with</p> |
| <pre> char_type* epptr(); |
| const char_type* epptr() const; |
| </pre> |
| |
| <p>In 27.7.2, 27.7.2.2, 27.7.3 27.7.3.2, 27.7.4, and 27.7.6</p> |
| <p>Replace</p> |
| <pre> basic_stringbuf<charT,traits,Allocator>* rdbuf() const; |
| </pre> |
| <p>with</p> |
| <pre> basic_stringbuf<charT,traits,Allocator>* rdbuf(); |
| const basic_stringbuf<charT,traits,Allocator>* rdbuf() const; |
| </pre> |
| |
| <p>In 27.8.1.5, 27.8.1.7, 27.8.1.8, 27.8.1.10, 27.8.1.11, and 27.8.1.13</p> |
| <p>Replace</p> |
| <pre> basic_filebuf<charT,traits>* rdbuf() const; |
| </pre> |
| <p>with</p> |
| <pre> basic_filebuf<charT,traits>* rdbuf(); |
| const basic_filebuf<charT,traits>* rdbuf() const; |
| </pre> |
| <p><b>Rationale:</b></p> |
| <p>The existing specification is a bit sloppy, but there's no |
| particular reason to change this other than tidiness, and there are |
| a number of ways in which streams might have been designed |
| differently if we were starting today. There's no evidence that the |
| existing constness policy is harming users. We might consider |
| a different constness policy as part of a full stream redesign.</p> |
| <hr> |
| <a name="367"><h3>367. remove_copy/remove_copy_if and Input Iterators</h3></a><p><b>Section:</b> 25.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.remove"> [lib.alg.remove]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Anthony Williams <b>Date:</b> 13 May 2002</p> |
| <p> |
| remove_copy and remove_copy_if (25.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.remove"> [lib.alg.remove]</a>) permit their |
| input range to be marked with Input Iterators. However, since two |
| operations are required against the elements to copy (comparison and |
| assigment), when the input range uses Input Iterators, a temporary |
| copy must be taken to avoid dereferencing the iterator twice. This |
| therefore requires the value type of the InputIterator to be |
| CopyConstructible. If the iterators are at least Forward Iterators, |
| then the iterator can be dereferenced twice, or a reference to the |
| result maintained, so the temporary is not required. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Add "If InputIterator does not meet the requirements of forward |
| iterator, then the value type of InputIterator must be copy |
| constructible. Otherwise copy constructible is not required." to |
| 25.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.remove"> [lib.alg.remove]</a> paragraph 6. |
| </p> |
| <p><b>Rationale:</b></p> |
| <p>The assumption is that an input iterator can't be dereferenced |
| twice. There's no basis for that assumption in the Standard.</p> |
| <hr> |
| <a name="368"><h3>368. basic_string::replace has two "Throws" paragraphs</h3></a><p><b>Section:</b> 21.3.5.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::replace"> [lib.string::replace]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Beman Dawes <b>Date:</b> 3 Jun 2002</p> |
| <p> |
| 21.3.5.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::replace"> [lib.string::replace]</a> basic_string::replace, second |
| signature, given in paragraph 1, has two "Throws" paragraphs (3 and |
| 5). |
| </p> |
| |
| <p> |
| In addition, the second "Throws" paragraph (5) includes specification |
| (beginning with "Otherwise, the function replaces ...") that should be |
| part of the "Effects" paragraph. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>This is editorial. Both "throws" statements are true. The bug is |
| just that the second one should be a sentence, part of the "Effects" |
| clause, not a separate "Throws". The project editor has been |
| notified.</p> |
| <hr> |
| <a name="372"><h3>372. Inconsistent description of stdlib exceptions</h3></a><p><b>Section:</b> 17.4.4.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a>, 18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.type.info"> [lib.type.info]</a>, <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Randy Maddox <b>Date:</b> 22 Jul 2002</p> |
| |
| <p>Paragraph 3 under clause 17.4.4.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.exception.handling"> [lib.res.on.exception.handling]</a>, Restrictions on |
| Exception Handling, states that "Any other functions defined in the |
| C++ Standard Library that do not have an exception-specification may |
| throw implementation-defined exceptions unless otherwise specified." |
| This statement is followed by a reference to footnote 178 at the |
| bottom of that page which states, apparently in reference to the C++ |
| Standard Library, that "Library implementations are encouraged (but |
| not required) to report errors by throwing exceptions from (or derived |
| from) the standard exceptions."</p> |
| |
| <p>These statements appear to be in direct contradiction to clause |
| 18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.type.info"> [lib.type.info]</a>, which states "The class exception defines the |
| base class for the types of objects thrown as exceptions by the C++ |
| Standard library components ...".</p> |
| |
| <p>Is this inconsistent?</p> |
| |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>Clause 17 is setting the overall library requirements, and it's |
| clear and consistent. This sentence from Clause 18 is descriptive, |
| not setting a requirement on any other class. |
| </p> |
| <hr> |
| <a name="374"><h3>374. moneypunct::frac_digits returns int not unsigned</h3></a><p><b>Section:</b> 22.2.6.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.moneypunct.members"> [lib.locale.moneypunct.members]</a>, 22.2.6.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.moneypunct.virtuals"> [lib.locale.moneypunct.virtuals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 8 Aug 2002</p> |
| <p> |
| In section 22.2.6.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.moneypunct.members"> [lib.locale.moneypunct.members]</a>, frac_digits() returns type |
| "int". This implies that frac_digits() might return a negative value, |
| but a negative value is nonsensical. It should return "unsigned". |
| </p> |
| |
| <p> |
| Similarly, in section 22.2.6.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.moneypunct.virtuals"> [lib.locale.moneypunct.virtuals]</a>, do_frac_digits() |
| should return "unsigned". |
| </p> |
| |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>Regardless of whether the return value is int or unsigned, it's |
| always conceivable that frac_digits might return a nonsensical |
| value. (Is 4294967295 really any better than -1?) The clients of |
| moneypunct, the get and put facets, can and do perform range |
| checks.</p> |
| <hr> |
| <a name="377"><h3>377. basic_string::insert and length_error</h3></a><p><b>Section:</b> 21.3.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::insert"> [lib.string::insert]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Ray Lischner <b>Date:</b> 16 Aug 2002</p> |
| <p> |
| Section 21.3.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::insert"> [lib.string::insert]</a>, paragraph 4, contains the following, |
| "Then throws length_error if size() >= npos - rlen." |
| </p> |
| |
| <p> |
| Related to DR 83, this sentence should probably be removed. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>This requirement is redundant but correct. No change is |
| needed.</p> |
| <hr> |
| <a name="378"><h3>378. locale immutability and locale::operator=()</h3></a><p><b>Section:</b> 22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 6 Sep 2002</p> |
| <p> |
| I think there is a problem with 22.1.1, p6 which says that |
| </p> |
| <pre> -6- An instance of locale is immutable; once a facet reference |
| is obtained from it, that reference remains usable as long |
| as the locale value itself exists. |
| </pre> |
| <p> |
| and 22.1.1.2, p4: |
| </p> |
| <pre> const locale& operator=(const locale& other) throw(); |
| |
| -4- Effects: Creates a copy of other, replacing the current value. |
| </pre> |
| <p> |
| How can a reference to a facet obtained from a locale object remain |
| valid after an assignment that clearly must replace all the facets |
| in the locale object? Imagine a program such as this |
| </p> |
| <pre> std::locale loc ("de_DE"); |
| const std::ctype<char> &r0 = std::use_facet<std::ctype<char> >(loc); |
| loc = std::locale ("en_US"); |
| const std::ctype<char> &r1 = std::use_facet<std::ctype<char> >(loc); |
| </pre> |
| <p> |
| Is r0 really supposed to be preserved and destroyed only when loc goes |
| out of scope? |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><i>[Summer '04 mid-meeting mailing: Martin and Dietmar believe this |
| is a duplicate of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#31">31</a> and recommend that it be |
| closed. |
| ]</i></p> |
| |
| <hr> |
| <a name="388"><h3>388. Use of complex as a key in associative containers</h3></a><p><b>Section:</b> 26.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.cfenv"> [lib.cfenv]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Gabriel Dos Reis <b>Date:</b> 8 Nov 2002</p> |
| <p> |
| Practice with std::complex<> and the associative containers |
| occasionally reveals artificial and distracting issues with constructs |
| resembling: std::set<std::complex<double> > s; |
| </p> |
| |
| <p> |
| The main reason for the above to fail is the absence of an approriate |
| definition for std::less<std::complex<T> >. That in turn comes from |
| the definition of the primary template std::less<> in terms of |
| operator<. |
| </p> |
| |
| <p> |
| The usual argument goes as follows: Since there is no ordering over |
| the complex field compatible with field operations it makes little |
| sense to define a function operator< operating on the datatype |
| std::complex<T>. That is fine. However, that reasoning does not carry |
| over to std::less<T> which is used, among other things, by associative |
| containers as an ordering useful to meet complexity requirements. |
| </p> |
| |
| <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>.</p> |
| |
| <p><b>Proposed resolution:</b></p> |
| <p>Informally: Add a specialization of std::less for std::complex.</p> |
| <p><b>Rationale:</b></p> |
| <p>Discussed in Santa Cruz. An overwhelming majority of the LWG |
| believes this should not be treated a DR: it's a request for a design |
| change, not a defect in the existing standard. Most people (10-3) |
| believed that we probably don't want this change, period: as with |
| issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#348">348</a>, it's hard to know where to draw the line. |
| The LWG noted that users who want to put objects into an associative |
| container for which <tt>operator<</tt> isn't defined can simply |
| provide their own comparison function object.</p> |
| <hr> |
| <a name="390"><h3>390. CopyConstructible requirements too strict</h3></a><p><b>Section:</b> 20.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.copyconstructible"> [lib.copyconstructible]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Future">Future</a> <b>Submitter:</b> Doug Gregor <b>Date:</b> 24 Oct 2002</p> |
| <p> |
| The CopyConstructible requirements in Table 30 state that for an |
| object t of type T (where T is CopyConstructible), the expression &t |
| returns the address of t (with type T*). This requirement is overly |
| strict, in that it disallows types that overload operator& to not |
| return a value of type T*. This occurs, for instance, in the <a href="http://www.boost.org/libs/lambda">Boost.Lambda</a> library, where |
| operator& is overloaded for a Boost.Lambda function object to return |
| another function object. |
| </p> |
| |
| <p>Example:</p> |
| |
| <pre> std::vector<int> u, v; |
| int x; |
| // ... |
| std::transform(u.begin(), u.end(), std::back_inserter(v), _1 * x); |
| </pre> |
| |
| <p> |
| _1 * x returns an unnamed function object with operator& overloaded to |
| not return T* , therefore rendering the std::transform call ill-formed. |
| However, most standard library implementations will compile this code |
| properly, and the viability of such binder libraries is severely hindered |
| by the unnecessary restriction in the CopyConstructible requirements. |
| </p> |
| |
| <p> |
| For reference, the address of an object can be retrieved without using |
| the address-of operator with the following function template: |
| </p> |
| |
| <pre> template <typename T> T* addressof(T& v) |
| { |
| return reinterpret_cast<T*>( |
| &const_cast<char&>(reinterpret_cast<const volatile char &>(v))); |
| } |
| </pre> |
| |
| <p> |
| Note: this relates directly to library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#350">350</a>, which |
| will need to be reexamined if the CopyConstructible requirements |
| change. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Remove the last two rows of Table 30, eliminating the requirements |
| that &t and &u return the address of t and u, respectively. |
| </p> |
| <p><b>Rationale:</b></p> |
| <p>This was a deliberate design decision. Perhaps it should be |
| reconsidered for C++0x. </p> |
| <hr> |
| <a name="392"><h3>392. 'equivalence' for input iterators</h3></a><p><b>Section:</b> 24.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Corwin Joy <b>Date:</b> 11 Dec 2002</p> |
| |
| <p> |
| In section 24.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a> table 72 - |
| 'Input Iterator Requirements' we have as a postcondition of *a: |
| "If a==b and (a, b) is in the domain of == then *a is equivalent to *b". |
| </p> |
| |
| <p> |
| In section 24.5.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator::equal"> [lib.istreambuf.iterator::equal]</a> it states that |
| "istreambuf_iterator::equal returns true if and only if both iterators |
| are at end-of-stream, or neither is at end-of-stream, <i>regardless of |
| what streambuf object they use</i>." (My emphasis). |
| </p> |
| |
| <p> |
| The defect is that either 'equivalent' needs to be more precisely |
| defined or the conditions for equality in 24.5.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator::equal"> [lib.istreambuf.iterator::equal]</a> |
| are incorrect. (Or both). |
| </p> |
| |
| <p>Consider the following example:</p> |
| <pre> #include <iostream> |
| #include <fstream> |
| #include <iterator> |
| using namespace std; |
| |
| int main() { |
| ifstream file1("file1.txt"), file2("file2.txt"); |
| istreambuf_iterator<char> f1(file1), f2(file2); |
| cout << "f1 == f2 : " << boolalpha << (f1 == f2) << endl; |
| cout << "f1 = " << *f1 << endl; |
| cout << "f2 = " << *f2 << endl; |
| return 0; |
| } |
| </pre> |
| |
| <p>Now assuming that neither f1 or f2 are at the end-of-stream then |
| f1 == f2 by 24.5.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator::equal"> [lib.istreambuf.iterator::equal]</a>.</p> |
| |
| <p>However, it is unlikely that *f1 will give the same value as *f2 except |
| by accident.</p> |
| |
| <p>So what does *f1 'equivalent' to *f2 mean? I think the standard should |
| be clearer on this point, or at least be explicit that this does not |
| mean that *f1 and *f2 are required to have the same value in the case |
| of input iterators.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>The two iterators aer not in the domain of ==</p> |
| <hr> |
| <a name="399"><h3>399. volations of unformatted input function requirements</h3></a><p><b>Section:</b> 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 5 Jan 2003</p> |
| <p> |
| The Effects clauses for the two functions below violate the |
| general requirements on unformatted input functions outlined |
| in 27.6.1.3: they do not begin by constructing a sentry object. |
| Instead, they begin by calling widen ('\n'), which may throw |
| an exception. The exception is then allowed to propagate from |
| the unformatted input function irrespective of the setting of |
| exceptions(). |
| </p> |
| <p> |
| Note that in light of 27.6.1.1, p3 and p4, the fact that the |
| functions allow exceptions thrown from widen() to propagate |
| may not strictly speaking be a defect (but the fact that the |
| functions do not start by constructing a sentry object still |
| is). However, since an exception thrown from ctype<charT> |
| ::widen() during any other input operation (say, from within |
| a call to num_get<charT>::get()) will be caught and cause |
| badbit to be set, these two functions should not be treated |
| differently for the sake of consistency. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p> |
| Not a defect. The standard is consistent, and the behavior required |
| by the standard is unambiguous. Yes, it's theoretically possible for |
| widen to throw. (Not that this will happen for the default ctype |
| facet or for most real-world replacement ctype facets.) Users who |
| define ctype facets that can throw, and who care about this behavior, |
| can use alternative signatures that don't call widen. |
| </p> |
| <hr> |
| <a name="429"><h3>429. typo in basic_ios::clear(iostate)</h3></a><p><b>Section:</b> 27.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostate.flags"> [lib.iostate.flags]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 18 Sep 2003</p> |
| <p> |
| |
| The Effects clause in 27.4.4.3, p5 describing the effects of a call to |
| the ios_base member function clear(iostate state) says that the function |
| only throws if the respective bits are already set prior to the function |
| call. That's obviously not the intent. If it was, a call to clear(badbit) |
| on an object for which (rdstate() == goodbit && exceptions() == badbit) |
| holds would not result in an exception being thrown. |
| |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| |
| The text ought to be changed from |
| <br> |
| |
| "If (rdstate() & exceptions()) == 0, returns. ..." |
| <br> |
| |
| to |
| <br> |
| |
| "If (state & exceptions()) == 0, returns. ..." |
| </p> |
| <p><b>Rationale:</b></p> |
| <p>This is a duplicate of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#412">412</a>.</p> |
| <hr> |
| <a name="433"><h3>433. Contradiction in specification of unexpected()</h3></a><p><b>Section:</b> 18.7.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.unexpected"> [lib.unexpected]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Vyatcheslav Sysoltsev <b>Date:</b> 29 Sep 2003</p> |
| <p> |
| Clause 15.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/except.html#except.unexpected"> [except.unexpected]</a> paragraph 1 says that "void unexpected(); |
| is called (18.7.2) immediately after completing the stack unwinding |
| for the former function", but 18.7.2.4 (Effects) says that "void |
| unexpected(); . . . Calls the unexpected_handler function in effect |
| immediately after evaluating the throwexpression (18.7.2.2),". Isn't |
| here a contradiction: 15.5.2 requires stack have been unwound when in |
| void unexpected() and therefore in unexpected_handler but 18.7.2.4 |
| claims that unexpected_handler is called "in effect immediately" after |
| evaluation of throw expression is finished, so there is no space left |
| for stack to be unwound therefore? I think the phrase "in effect |
| immediately" should be removed from the standard because it brings |
| ambiguity in understanding. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>There is no contradiction. The phrase "in effect immediately" is |
| just to clarify which handler is to be called.</p> |
| <hr> |
| <a name="437"><h3>437. Formatted output of function pointers is confusing</h3></a><p><b>Section:</b> 27.6.2.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.inserters.arithmetic"> [lib.ostream.inserters.arithmetic]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Ivan Godard <b>Date:</b> 24 Oct 2003</p> |
| <p> |
| Given: |
| </p> |
| <pre>void f(int) {} |
| void(*g)(int) = f; |
| cout << g; |
| </pre> |
| |
| <p> |
| (with the expected #include and usings), the value printed is a rather |
| surprising "true". Rather useless too. |
| </p> |
| |
| <p>The standard defines:</p> |
| |
| <pre>ostream& operator<<(ostream&, void*);</pre> |
| |
| <p>which picks up all data pointers and prints their hex value, but does |
| not pick up function pointers because there is no default conversion |
| from function pointer to void*. Absent that, we fall back to legacy |
| conversions from C and the function pointer is converted to bool. |
| </p> |
| |
| <p>There should be an analogous inserter that prints the address of a |
| function pointer.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>This is indeed a wart, but there is no good way to solve it. C |
| doesn't provide a portable way of outputting the address of a |
| function point either.</p> |
| <hr> |
| <a name="439"><h3>439. Should facets be copyable?</h3></a><p><b>Section:</b> 22.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.categories"> [lib.locale.categories]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 2 Nov 2003</p> |
| <p>The following facets classes have no copy constructors described in |
| the standard, which, according to the standard, means that they are |
| supposed to use the compiler-generated defaults. Default copy |
| behavior is probably inappropriate. We should either make these |
| classes uncopyable or else specify exactly what their constructors do.</p> |
| |
| <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#421">421</a>.</p> |
| |
| <pre> ctype_base |
| ctype |
| ctype_byname |
| ctype<char> |
| ctype_byname<char> |
| codecvt_base |
| codecvt |
| codecvt_byname |
| num_get |
| num_put |
| numpunct |
| numpunct_byname |
| collate |
| collate_byname |
| time_base |
| time_get |
| time_get_byname |
| time_put |
| time_put_byname |
| money_get |
| money_put |
| money_base |
| moneypunct |
| moneypunct_byname |
| messages_base |
| messages |
| messages_byname |
| </pre> |
| |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>The copy constructor in the base class is private.</p> |
| <hr> |
| <a name="440"></a><h3><a name="440">440. Should std::complex use unqualified transcendentals?</a></h3><p><b>Section:</b> 26.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.transcendentals"> [lib.complex.transcendentals]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 5 Nov 2003</p> |
| <p> |
| Operations like <tt>pow</tt> and <tt>exp</tt> on |
| <tt>complex<T></tt> are typically implemented in terms of |
| operations like <tt>sin</tt> and <tt>cos</tt> on <tt>T</tt>. |
| Should implementations write this as <tt>std::sin</tt>, or as plain |
| unqualified <tt>sin</tt>? |
| </p> |
| |
| <p>The issue, of course, is whether we want to use |
| argument-dependent lookup in the case where <tt>T</tt> is a |
| user-defined type. This is similar to the issue of valarray |
| transcendentals, as discussed in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a>.</p> |
| |
| <p>This issue differs from valarray transcendentals in two important |
| ways. First, "the effect of instantiating the template |
| <tt>complex</tt> for types other than float, double or long double is |
| unspecified." (26.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a>) Second, the standard does not |
| dictate implementation, so there is no guarantee that a particular |
| real math function is used in the implementation of a particular |
| complex function.</p> |
| |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>If you instantiate std::complex for user-defined types, all bets |
| are off.</p> |
| <hr> |
| <a name="447"><h3>447. Wrong template argument for time facets</h3></a><p><b>Section:</b> 22.1.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.category"> [lib.locale.category]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Pete Becker <b>Date:</b> 26 Dec 2003</p> |
| <p> |
| 22.1.1.1.1/4, table 52, "Required Instantiations", lists, among others: |
| </p> |
| <pre> time_get<char,InputIterator> |
| time_get_byname<char,InputIterator> |
| time_get<wchar_t,OutputIterator> |
| time_get_byname<wchar_t,OutputIterator> |
| </pre> |
| |
| <p> |
| The second argument to the last two should be InputIterator, not |
| OutputIterator. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change the second template argument to InputIterator. |
| </p> |
| <p><b>Rationale:</b></p> |
| Duplicate of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#327">327</a> |
| <hr> |
| <a name="450"><h3>450. set::find is inconsistent with associative container requirements</h3></a><p><b>Section:</b> 23.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.set"> [lib.set]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 30 Jan 2004</p> |
| <p>map/multimap have:</p> |
| |
| <pre> iterator find(const key_type& x) const; |
| const_iterator find(const key_type& x) const; |
| </pre> |
| |
| <p> |
| which is consistent with the table of associative container requirements. |
| But set/multiset have: |
| </p> |
| <pre> iterator find(const key_type&) const; |
| </pre> |
| |
| <p> |
| set/multiset should look like map/multimap, and honor the requirements |
| table, in this regard. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>Duplicate of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#214">214</a>.</p> |
| <hr> |
| <a name="451"><h3>451. Associative erase should return an iterator</h3></a><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, 23.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative"> [lib.associative]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 30 Jan 2004</p> |
| <p>map/multimap/set/multiset have:</p> |
| <pre> void erase(iterator); |
| void erase(iterator, iterator); |
| </pre> |
| |
| <p>But there's no good reason why these can't return an iterator, as for |
| vector/deque/list:</p> |
| <pre> iterator erase(iterator); |
| iterator erase(iterator, iterator); |
| </pre> |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Informally: The table of associative container requirements, and the |
| relevant template classes, should return an iterator designating the |
| first element beyond the erased subrange. |
| </p> |
| <p><b>Rationale:</b></p> |
| <p>Duplicate of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a></p> |
| <hr> |
| <a name="452"><h3>452. locale::combine should be permitted to generate a named locale</h3></a><p><b>Section:</b> 22.1.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.members"> [lib.locale.members]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Bill Plauger <b>Date:</b> 30 Jan 2004</p> |
| <pre>template<class Facet> |
| locale::combine(const locale&) const; |
| </pre> |
| <p> |
| is obliged to create a locale that has no name. This is overspecification |
| and overkill. The resulting locale should follow the usual rules -- it |
| has a name if the locale argument has a name and Facet is one of the |
| standard facets. |
| </p> |
| |
| <p><i>[ |
| Sydney and post-Sydney (see c++std-lib-13439, c++std-lib-13440, |
| c++std-lib-13443): agreed that it's overkill to say that the locale |
| is obligated to be nameless. However, we also can't require it to |
| have a name. At the moment, locale names are based on categories |
| and not on individual facets. If a locale contains two different |
| facets of different names from the same category, then this would |
| not fit into existing naming schemes. We need to give |
| implementations more freedom. Bill will provide wording. |
| ]</i></p> |
| |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>After further discussion the LWG decided to close this as NAD. |
| The fundamental problem is that names right now are per-category, |
| not per-facet. The <tt>combine</tt> member function works at the |
| wrong level of granularity.</p> |
| <hr> |
| <a name="472"><h3>472. Missing "Returns" clause in std::equal_range</h3></a><p><b>Section:</b> 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Prateek R Karandikar <b>Date:</b> 29 Feb 1900</p> |
| <p> |
| There is no "Returns:" clause for std::equal_range, which returns non-void. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>Fixed as part of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270">270</a>.</p> |
| <hr> |
| <a name="476"><h3>476. Forward Iterator implied mutability</h3></a><p><b>Section:</b> 24.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.forward.iterators"> [lib.forward.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 9 Jul 2004</p> |
| |
| <p>24.1/3 says:</p> |
| <blockquote> |
| Forward iterators satisfy all the requirements of the input and |
| output iterators and can be used whenever either kind is specified |
| </blockquote> |
| |
| <p> |
| The problem is that satisfying the requirements of output iterator |
| means that you can always assign *something* into the result of |
| dereferencing it. That makes almost all non-mutable forward |
| iterators non-conforming. I think we need to sever the refinement |
| relationship between forward iterator and output iterator. |
| </p> |
| |
| <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#200">200</a>. But this is not a dup.</p> |
| |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>Yes, 24.1/3 does say that. But it's introductory material. The |
| precise specification is in 24.1.3, and the requrements table there is |
| right. We don't need to fine-tune introductory wording. (Especially |
| since this wording is likely to be changed as part of the iterator |
| overhaul.)</p> |
| <hr> |
| <a name="477"><h3>477. Operator-> for const forward iterators</h3></a><p><b>Section:</b> 24.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.forward.iterators"> [lib.forward.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 11 Jul 2004</p> |
| <p> |
| The Forward Iterator requirements table contains the following: |
| </p> |
| <pre> expression return type operational precondition |
| semantics |
| ========== ================== =========== ========================== |
| a->m U& if X is mutable, (*a).m pre: (*a).m is well-defined. |
| otherwise const U& |
| |
| r->m U& (*r).m pre: (*r).m is well-defined. |
| </pre> |
| |
| <p> |
| The first line is exactly right. The second line is wrong. Basically |
| it implies that the const-ness of the iterator affects the const-ness |
| of referenced members. But Paragraph 11 of [lib.iterator.requirements] says: |
| </p> |
| |
| <blockquote> |
| In the following sections, a and b denote values of type const X, n |
| denotes a value of the difference type Distance, u, tmp, and m |
| denote identifiers, r denotes a value of X&, t denotes a value of |
| value type T, o denotes a value of some type that is writable to |
| the output iterator. |
| </blockquote> |
| |
| <p>AFAICT if we need the second line at all, it should read the same |
| as the first line.</p> |
| |
| <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a></p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>The LWG agrees that this is a real problem. Marked as a DUP |
| because the LWG chose to adopt the solution proposed in |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#478">478</a>. |
| </p> |
| <hr> |
| <a name="480"><h3>480. unary_function and binary_function should have protected nonvirtual destructors</h3></a><p><b>Section:</b> 20.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.tuple.tuple"> [lib.tuple.tuple]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Joe Gottman <b>Date:</b> 19 Aug 2004</p> |
| <p>The classes std::unary_function and std::binary_function are both |
| designed to be inherited from but contain no virtual functions. This |
| makes it too easy for a novice programmer to write code like |
| binary_function<int, int, int> *p = new plus<int>; delete p;</p> |
| |
| <p>There are two common ways to prevent this source of undefined |
| behavior: give the base class a public virtual destructor, or give it |
| a protected nonvirtual destructor. Since unary_function and |
| binary_function have no other virtual functions, (note in particular |
| the absence of an operator()() ), it would cost too much to give them |
| public virtual destructors. Therefore, they should be given protected |
| nonvirtual destructors.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p>Change Paragraph 20.3.1 of the Standard from</p> |
| <pre> template <class Arg, class Result> |
| struct unary_function { |
| typedef Arg argument_type; |
| typedef Result result_type; |
| }; |
| |
| template <class Arg1, class Arg2, class Result> |
| struct binary_function { |
| typedef Arg1 first_argument_type; |
| typedef Arg2 second_argument_type; |
| typedef Result result_type; |
| }; |
| </pre> |
| |
| <p>to</p> |
| <pre> template <class Arg, class Result> |
| struct unary_function { |
| typedef Arg argument_type; |
| typedef Result result_type; |
| protected: |
| ~unary_function() {} |
| }; |
| |
| template <class Arg1, class Arg2, class Result> |
| struct binary_function { |
| typedef Arg1 first_argument_type; |
| typedef Arg2 second_argument_type; |
| typedef Result result_type; |
| protected: |
| ~binary_function() {} |
| }; |
| </pre> |
| <p><b>Rationale:</b></p> |
| <p>The LWG doesn't believe the existing definition causes anybody any |
| concrete harm.</p> |
| <hr> |
| <a name="481"><h3>481. unique's effects on the range [result, last)</h3></a><p><b>Section:</b> 25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Andrew Koenig <b>Date:</b> 30 Aug 2004</p> |
| <p> |
| The standard says that unique(first, last) "eliminates all but the |
| first element from every consecutive group of equal elements" in |
| [first, last) and returns "the end of the resulting range". So a |
| postcondition is that [first, result) is the same as the old [first, |
| last) except that duplicates have been eliminated. |
| </p> |
| |
| <p>What postconditions are there on the range [result, last)? One |
| might argue that the standard says nothing about those values, so |
| they can be anything. One might also argue that the standard |
| doesn't permit those values to be changed, so they must not be. |
| Should the standard say something explicit one way or the other?</p> |
| |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| <p><b>Rationale:</b></p> |
| <p>We don't want to make many guarantees about what's in [result, |
| end). Maybe we aren't being quite explicit enough about not being |
| explicit, but it's hard to think that's a major problem.</p> |
| <hr> |
| <a name="483"><h3>483. Heterogeneous equality and EqualityComparable</h3></a><p><b>Section:</b> 25.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.nonmodifying"> [lib.alg.nonmodifying]</a>, 25.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.modifying.operations"> [lib.alg.modifying.operations]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Peter Dimov <b>Date:</b> 20 Sep 2004</p> |
| <p>c++std-lib-14262</p> |
| |
| <p>[lib.alg.find] requires T to be EqualityComparable:</p> |
| |
| <pre>template <class InputIterator, class T> |
| InputIterator find(InputIterator first, InputIterator last, |
| const T& value); |
| </pre> |
| |
| <p> |
| However the condition being tested, as specified in the Effects |
| clause, is actually *i == value, where i is an InputIterator. |
| </p> |
| |
| <p> |
| The two clauses are in agreement only if the type of *i is T, but this |
| isn't necessarily the case. *i may have a heterogeneous comparison |
| operator that takes a T, or a T may be convertible to the type of *i. |
| </p> |
| |
| <p>Further discussion (c++std-lib-14264): this problem affects a |
| number of algorithsm in clause 25, not just <tt>find</tt>. We |
| should try to resolve this problem everywhere it appears.</p> |
| <p><b>Proposed resolution:</b></p> |
| |
| <p>[lib.alg.find]:</p> |
| <blockquote> |
| Remove [lib.alg.find]/1. |
| </blockquote> |
| |
| <p>[lib.alg.count]:</p> |
| <blockquote> |
| Remove [lib.alg.count]/1. |
| </blockquote> |
| |
| <p>[lib.alg.search]:</p> |
| <blockquote> |
| Remove "Type T is EqualityComparable (20.1.1), " from [lib.alg.search]/4. |
| </blockquote> |
| |
| <p>[lib.alg.replace]:</p> |
| |
| <blockquote> |
| <p> |
| Remove [lib.alg.replace]/1. |
| Replace [lb.alg.replace]/2 with: |
| </p> |
| |
| <blockquote> |
| For every iterator i in the range [first, last) for which *i == value |
| or pred(*i) holds perform *i = new_value. |
| </blockquote> |
| |
| <p> |
| Remove the first sentence of /4. |
| Replace the beginning of /5 with: |
| </p> |
| |
| <blockquote> |
| For every iterator i in the range [result, result + (last - |
| first)), assign to *i either... |
| </blockquote> |
| |
| <p>(Note the defect here, current text says assign to i, not *i).</p> |
| </blockquote> |
| |
| <p>[lib.alg.fill]:</p> |
| |
| <blockquote> |
| <p> |
| Remove "Type T is Assignable (23.1), " from /1. |
| Replace /2 with: |
| </p> |
| |
| <blockquote> |
| For every iterator i in the range [first, last) or [first, first + n), |
| perform *i = value. |
| </blockquote> |
| </blockquote> |
| |
| <p>[lib.alg.remove]:</p> |
| <blockquote> |
| Remove /1. |
| Remove the first sentence of /6. |
| </blockquote> |
| |
| <p><b>Rationale:</b></p> |
| <p>Duplicate of (a subset of) issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#283">283</a>.</p> |
| <hr> |
| <a name="486"><h3>486. min/max CopyConstructible requirement is too strict</h3></a><p><b>Section:</b> 25.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.min.max"> [lib.alg.min.max]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Dave Abrahams <b>Date:</b> 13 Oct 2004</p> |
| <p>A straightforward implementation of these algorithms does not need to |
| copy T.</p> |
| <p><b>Proposed resolution:</b></p> |
| <p>drop the the words "and CopyConstructible" from paragraphs 1 and 4</p> |
| <p><b>Rationale:</b></p> |
| <p>Dup of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#281">281</a>.</p> |
| <hr> |
| <a name="487"><h3>487. Allocator::construct is too limiting</h3></a><p><b>Section:</b> 20.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.default.con.req"> [lib.default.con.req]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Dhruv Matani <b>Date:</b> 17 Oct 2004</p> |
| <p> |
| The standard's version of allocator::construct(pointer, |
| const_reference) severely limits what you can construct using this |
| function. Say you can construct a socket from a file descriptor. Now, |
| using this syntax, I first have to manually construct a socket from |
| the fd, and then pass the constructed socket to the construct() |
| function so it will just to an uninitialized copy of the socket I |
| manually constructed. Now it may not always be possible to copy |
| construct a socket eh! So, I feel that the changes should go in the |
| allocator::construct(), making it: |
| </p> |
| <pre> template<typename T> |
| struct allocator{ |
| template<typename T1> |
| void construct(pointer T1 const& rt1); |
| }; |
| </pre> |
| |
| <p> |
| Now, the ctor of the class T which matches the one that takes a T1 can |
| be called! Doesn't that sound great? |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>NAD. STL uses copying all the time, and making it possible for |
| allocators to construct noncopyable objects is useless in the |
| absence of corresponding container changes. We might consider this |
| as part of a larger redesign of STL.</p> |
| <hr> |
| <a name="489"><h3>489. std::remove / std::remove_if wrongly specified</h3></a><p><b>Section:</b> 25.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.remove"> [lib.alg.remove]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Thomas Mang <b>Date:</b> 12 Dec 2004</p> |
| <p>In Section 25.2.7 [lib.alg.remove], paragraphs 1 to 5 describe the |
| behavior of the mutating sequence operations std::remove and |
| std::remove_if. However, the wording does not reflect the intended |
| behavior [Note: See definition of intended behavior below] of these |
| algorithms, as it is known to the C++ community [1]. |
| </p> |
| |
| |
| |
| <p>1) Analysis of current wording:</p> |
| |
| |
| <p>25.2.7 [lib.alg.remove], paragraph 2:</p> |
| |
| <p>Current wording says: |
| "Effects: Eliminates all the elements referred to by iterator i in the |
| range [first, last) for which the following corresponding conditions |
| hold: *i == value, pred(*i) != false."</p> |
| |
| <p> |
| This sentences expresses specifically that all elements denoted by the |
| (original) range [first, last) for which the corresponding condition |
| hold will be eliminated. Since there is no formal definition of the term |
| "eliminate" provided, the meaning of "eliminate" in everyday language |
| implies that as postcondition, no element in the range denoted by |
| [first, last) will hold the corresponding condition on reiteration over |
| the range [first, last). |
| </p> |
| |
| <p> |
| However, this is neither the intent [Note: See definition of intended |
| behavior below] nor a general possible approach. It can be easily proven |
| that if all elements of the original range[first, last) will hold the |
| condition, it is not possible to substitute them by an element for which |
| the condition will not hold. |
| </p> |
| |
| |
| <p>25.2.7 [lib.alg.remove], paragraph 3:</p> |
| |
| <p> |
| Current wording says: |
| "Returns: The end of the resulting range." |
| </p> |
| |
| <p> |
| The resulting range is not specified. In combination with 25.2.7 |
| [lib.alg.remove], paragraph 2, the only reasonable interpretation of |
| this so-called resulting range is the range [first,last) - thus |
| returning always the ForwardIterator 'last' parameter. |
| </p> |
| |
| |
| <p> |
| 25.2.7 [lib.alg.remove], paragraph 4: |
| </p> |
| |
| <p> |
| Current wording says: |
| "Notes: Stable: the relative order of the elements that are not removed |
| is the same as their relative order in the original range" |
| </p> |
| |
| <p> |
| This sentences makes use of the term "removed", which is neither |
| specified, nor used in a previous paragraph (which uses the term |
| "eliminate"), nor unamgiuously separated from the name of the algorithm. |
| </p> |
| |
| |
| <p>2) Description of intended behavior:</p> |
| |
| <p> |
| For the rest of this Defect Report, it is assumed that the intended |
| behavior was that all elements of the range [first, last) which do not |
| hold the condition *i == value (std::remove) or pred(*i) != false |
| (std::remove_if)], call them s-elements [Note: s...stay], will be placed |
| into a contiguous subrange of [first, last), denoted by the iterators |
| [first, return value). The number of elements in the resulting range |
| [first, return value) shall be equal to the number of s-elements in the |
| original range [first, last). The relative order of the elements in the |
| resulting subrange[first, return value) shall be the same as the |
| relative order of the corresponding elements in the original range. It |
| is undefined whether any elements in the resulting subrange [return |
| value, last) will hold the corresponding condition, or not. |
| </p> |
| |
| <p> |
| All implementations known to the author of this Defect Report comply |
| with this intent. Since the intent of the behavior (contrary to the |
| current wording) is also described in various utility references serving |
| the C++ community [1], it is not expected that fixing the paragraphs |
| will influence current code - unless the code relies on the behavior as |
| it is described by current wording and the implementation indeed |
| reflects the current wording, and not the intent. |
| </p> |
| |
| |
| |
| <p>3) Proposed fixes:</p> |
| |
| |
| <p>Change 25.2.7 [lib.alg.remove], paragraph 2 to:</p> |
| |
| <p> |
| "Effect: Places all the elements referred to by iterator i in the range |
| [first, last) for which the following corresponding conditions hold : |
| !(*i == value), pred(*i) == false into the subrange [first, k) of the |
| original range, where k shall denote a value of type ForwardIterator. It |
| is undefined whether any elements in the resulting subrange [k, last) |
| will hold the corresponding condition, or not." |
| </p> |
| |
| <p>Comments to the new wording:</p> |
| |
| <p> |
| a) "Places" has no special meaning, and the everyday language meaning |
| should fit. |
| b) The corresponding conditions were negated compared to the current |
| wording, becaue the new wording requires it. |
| c) The wording "of the original range" might be redundant, since any |
| subrange starting at 'first' and containing no more elements than the |
| original range is implicitly a subrange of the original range [first, |
| last). |
| d) The iterator k was introduced instead of "return value" in order to |
| avoid a cyclic dependency on 25.2.7/3. The wording ", where k shall |
| denote a value of type ForwardIterator" might be redundant, because it |
| follows implicitly by 25.2.7/3. |
| e) "Places" does, in the author's opinion, explicitly forbid duplicating |
| any element holding the corresponding condition in the original range |
| [first, last) within the resulting range [first, k). If there is doubt |
| this term might be not unambiguous regarding this, it is suggested that |
| k is specified more closely by the following wording: "k shall denote a |
| value of type ForwardIterator [Note: see d)] so that k - first is equal |
| to the number of elements in the original range [first, last) for which |
| the corresponding condition did hold". This could also be expressed as a |
| separate paragraph "Postcondition:" |
| f) The senctence "It is undefined whether any elements in the resulting |
| subrange [k, last) will hold the corresponding condition, or not." was |
| added consciously so the term "Places" does not imply if the original |
| range [first, last) contains n elements holding the corresponding |
| condition, the identical range[first, last) will also contain exactly n |
| elements holding the corresponding condition after application of the |
| algorithm. |
| </p> |
| |
| <p> |
| Change 25.2.7 [lib.alg.remove], paragraph 3 to: |
| |
| "Returns: The iterator k." |
| </p> |
| |
| <p> |
| Change 25.2.7 [lib.alg.remove], paragraph 4 to: |
| |
| "Notes: Stable: the relative order of the elements that are placed into |
| the subrange [first, return value) shall be the same as their relative |
| order was in the original range [first, last) prior to application of |
| the algorithm." |
| </p> |
| |
| <p> |
| Comments to the new wording: |
| </p> |
| |
| <p> |
| a) the wording "was ... prior to application of the algorithm" is used |
| to explicitly distinguish the original range not only by means of |
| iterators, but also by a 'chronological' factor from the resulting range |
| [first, return value). It might be redundant. |
| </p> |
| |
| <p> |
| [1]: |
| The wording of these references is not always unambiguous, and provided |
| examples partially contradict verbal description of the algorithms, |
| because the verbal description resembles the problematic wording of |
| ISO/IEC 14882:2003. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>The LWG believes that the standard is sufficiently clear, and that |
| there is no evidence of any real-world confusion about this point.</p> |
| <hr> |
| <a name="490"><h3>490. std::unique wrongly specified</h3></a><p><b>Section:</b> 25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Thomas Mang <b>Date:</b> 12 Dec 2004</p> |
| <p>In Section 25.2.8 [lib.alg.unique], paragraphs 1 to 3 describe the |
| behavior of the mutating sequence operation std::unique. However, the |
| wording does not reflect the intended behavior [Note: See definition of |
| intended behavior below] of these algorithms, as it is known to the C++ |
| community [1].</p> |
| |
| |
| |
| <p>1) Analysis of current wording:</p> |
| |
| |
| <p>25.2.8 [lib.alg.unique], paragraph 1:</p> |
| |
| <p> |
| Current wording says: |
| "Effects: Eliminates all but the first element from every consecutive |
| group of equal elements referred to by the iterator i in the range |
| [first, last) for which the following corresponding conditions hold: *i |
| == *(i - 1) or pred(*i, *(i -1)) != false" |
| </p> |
| |
| <p> |
| This sentences expresses specifically that all elements denoted by the |
| (original) range [first, last) which are not but the first element from |
| a consecutive group of equal elements (where equality is defined as *i |
| == *(i - 1) or pred(*i, *(i - 1)) ! = false) [Note: See DR 202], call |
| them r-elements [Note: r...remove], will be eliminated. Since there is |
| no formal definition of the term "eliminate" provided, it is undefined |
| how this "elimination" takes place. But the meaning of "eliminate" in |
| everyday language seems to disallow explicitly that after application of |
| the algorithm, any r-element will remain at any position of the range |
| [first, last) [2]. |
| </p> |
| |
| <p> |
| Another defect in the current wording concerns the iterators used to |
| compare two elements for equality: The current wording contains the |
| expression "(i - 1)", which is not covered by 25/9 [Note: See DR |
| submitted by Thomas Mang regarding invalid iterator arithmetic |
| expressions]. |
| </p> |
| |
| |
| <p> |
| 25.2.8 [lib.alg.unique], paragraph 2: |
| </p> |
| <p>Current wording says: |
| "Returns: The end of the resulting range."</p> |
| |
| <p> |
| The resulting range is not specified. In combination with 25.2.8 |
| [lib.alg.unique], paragraph 1, one reasonable interpretation (in the |
| author's opinion even the only possible interpretation) of this |
| so-called resulting range is the range [first, last) - thus returning |
| always the ForwardIterator 'last' parameter. |
| </p> |
| |
| <p>2) Description of intended behavior:</p> |
| |
| <p> |
| For the rest of this Defect Report, it is assumed that the intended |
| behavior was that all elements denoted by the original range [first, |
| last) which are the first element from a consecutive group of elements |
| for which the corresponding conditions: *(i-1) == *i (for the version of |
| unique without a predicate argument) or pred(*(i-1), *i) ! = false (for |
| the version of unique with a predicate argument) [Note: If such a group |
| of elements consists of only a single element, this is also considered |
| the first element] [Note: See resolutions of DR 202], call them |
| s-elements [Note: s...stay], will be placed into a contiguous subrange |
| of [first, last), denoted by the iterators [first, return value). The |
| number of elements in the resulting range [first, return value) shall be |
| equal to the number of s-elements in the original range [first, last). |
| Invalid iterator arithmetic expressions are expected to be resolved as |
| proposed in DR submitted by Thomas Mang regarding invalid iterator |
| arithmetic expressions. It is also assumed by the author that the |
| relative order of the elements in the resulting subrange [first, return |
| value) shall be the same as the relative order of the corresponding |
| elements (the s-elements) in the original range [Note: If this was not |
| intended behavior, the additional proposed paragraph about stable order |
| will certainly become obsolete]. |
| Furthermore, the resolutions of DR 202 are partially considered. |
| </p> |
| |
| <p> |
| All implementations known to the author of this Defect Report comply |
| with this intent [Note: Except possible effects of DR 202]. Since this |
| intent of the behavior (contrary to the current wording) is also |
| described in various utility references serving the C++ community [1], |
| it is not expected that fixing the paragraphs will influence current |
| code [Note: Except possible effects of DR 202] - unless the code relies |
| on the behavior as it is described by current wording and the |
| implementation indeed reflects the current wording, and not the intent. |
| </p> |
| |
| |
| |
| <p>3) Proposed fixes:</p> |
| |
| <p> |
| Change 25.2.8 [lib.alg.unique], paragraph 1 to: |
| </p> |
| |
| <p> |
| "Effect: Places the first element from every consecutive group of |
| elements, referred to by the iterator i in the range [first, last), for |
| which the following conditions hold: *(i-1) == *i (for the version of |
| unique without a predicate argument) or pred(*(i -1), *i) != false (for |
| the version of unique with a predicate argument), into the subrange |
| [first, k) of the original range, where k shall denote a value of type |
| ForwardIterator." |
| </p> |
| |
| <p>Comments to the new wording:</p> |
| |
| <p> |
| a) The new wording was influenced by the resolutions of DR 202. If DR |
| 202 is resolved in another way, the proposed wording need also |
| additional review. |
| b) "Places" has no special meaning, and the everyday language meaning |
| should fit. |
| c) The expression "(i - 1)" was left, but is expected that DR submitted |
| by Thomas Mang regarding invalid iterator arithmetic expressions will |
| take this into account. |
| d) The wording "(for the version of unique without a predicate |
| argument)" and "(for the version of unique with a predicate argument)" |
| was added consciously for clarity and is in resemblence with current |
| 23.2.2.4 [lib.list.ops], paragraph 19. It might be considered redundant. |
| e) The wording "of the original range" might be redundant, since any |
| subrange starting at first and containing no more elements than the |
| original range is implicitly a subrange of the original range [first, |
| last). |
| f) The iterator k was introduced instead of "return value" in order to |
| avoid a cyclic dependency on 25.2.8 [lib.alg.unique], paragraph 2. The |
| wording ", where k shall denote a value of type ForwardIterator" might |
| be redundant, because it follows implicitly by 25.2.8 [lib.alg.unique], |
| paragraph 2. |
| g) "Places" does, in the author's opinion, explicitly forbid duplicating |
| any s-element in the original range [first, last) within the resulting |
| range [first, k). If there is doubt this term might be not unambiguous |
| regarding this, it is suggested that k is specified more closely by the |
| following wording: "k shall denote a value of type ForwardIterator |
| [Note: See f)] so that k - first is equal to the number of elements in |
| the original range [first, last) being the first element from every |
| consecutive group of elements for which the corresponding condition did |
| hold". This could also be expressed as a separate paragraph |
| "Postcondition:". |
| h) If it is considered that the wording is unclear whether it declares |
| the element of a group which consists of only a single element |
| implicitly to be the first element of this group [Note: Such an |
| interpretation could eventually arise especially in case last - first == |
| 1] , the following additional sentence is proposed: "If such a group of |
| elements consists of only a single element, this element is also |
| considered the first element." |
| </p> |
| |
| <p> |
| Change 25.2.8 [lib.alg.unique], paragraph 2 to: |
| "Returns: The iterator k." |
| </p> |
| |
| <p> |
| Add a separate paragraph "Notes:" as 25.2.8 [lib.alg.unique], paragraph |
| 2a or 3a, or a separate paragraph "Postcondition:" before 25.2.8 |
| [lib.alg.unique], paragraph 2 (wording inside {} shall be eliminated if |
| the preceding expressions are used, or the preceding expressions shall |
| be eliminated if wording inside {} is used): |
| </p> |
| |
| <p> |
| "Notes:{Postcondition:} Stable: the relative order of the elements that |
| are placed into the subrange [first, return value {k}) shall be the same |
| as their relative order was in the original range [first, last) prior to |
| application of the algorithm." |
| </p> |
| |
| <p>Comments to the new wording:</p> |
| |
| <p> |
| a) It is assumed by the author that the algorithm was intended to be |
| stable. |
| In case this was not the intent, this paragraph becomes certainly |
| obsolete. |
| b) The wording "was ... prior to application of the algorithm" is used |
| to explicitly distinguish the original range not only by means of |
| iterators, but also by a 'chronological' factor from the resulting range |
| [first, return value). It might be redundant. |
| </p> |
| |
| <p> |
| 25.2.8 [lib.alg.unique], paragraph 3: |
| </p> |
| <p>See DR 239.</p> |
| |
| <p> |
| 4) References to other DRs: |
| </p> |
| |
| <p> |
| See DR 202, but which does not address any of the problems described in |
| this Defect Report [Note: This DR is supposed to complement DR 202]. |
| See DR 239. |
| See DR submitted by Thomas Mang regarding invalid iterator arithmetic |
| expressions. |
| </p> |
| |
| <p> |
| [1]: |
| The wording of these references is not always unambiguous, and provided |
| examples partially contradict verbal description of the algorithms, |
| because the verbal description resembles the problematic wording of |
| ISO/IEC 14882:2003. |
| </p> |
| |
| <p> |
| [2]: |
| Illustration of conforming implementations according to current wording: |
| </p> |
| |
| <p> |
| One way the author of this DR considers how this "elimination" could be |
| achieved by a conforming implementation according to current wording is |
| by substituting each r-element by _any_ s-element [Note: s...stay; any |
| non-r-element], since all r-elements are "eliminated". |
| </p> |
| |
| <p> |
| In case of a sequence consisting of elements being all 'equal' [Note: |
| See DR 202], substituting each r-element by the single s-element is the |
| only possible solution according to current wording. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>The LWG believes the standard is sufficiently clear. No |
| implementers get it wrong, and changing it wouldn't cause any code to |
| change, so there is no real-world harm here.</p> |
| <hr> |
| <a name="491"><h3>491. std::list<>::unique incorrectly specified</h3></a><p><b>Section:</b> 23.2.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.special"> [lib.deque.special]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Thomas Mang <b>Date:</b> 12 Dec 2004</p> |
| <p>In Section 23.2.2.4 [lib.list.ops], paragraphs 19 to 21 describe the |
| behavior of the std::list<T, Allocator>::unique operation. However, the |
| current wording is defective for various reasons.</p> |
| |
| |
| |
| <p> |
| 1) Analysis of current wording: |
| </p> |
| |
| <p>23.2.2.4 [lib.list.ops], paragraph 19:</p> |
| |
| <p> |
| Current wording says: |
| "Effects: Eliminates all but the first element from every consecutive |
| group of equal elements referred to by the iterator i in the range |
| [first + 1, last) for which *i == *(i - 1) (for the version of unique |
| with no argument) or pred(*i, *(i -1)) (for the version of unique with a |
| predicate argument) holds."</p> |
| |
| <p> |
| This sentences makes use of the undefined term "Eliminates". Although it |
| is, to a certain degree, reasonable to consider the term "eliminate" |
| synonymous with "erase", using "Erase" in the first place, as the |
| wording of 23.2.2.4 [lib.list.ops], paragraph 15 does, would be clearer.</p> |
| |
| <p> |
| The range of the elements referred to by iterator i is "[first + 1, |
| last)". However, neither "first" nor "last" is defined.</p> |
| |
| <p> |
| The sentence makes three times use of iterator arithmetic expressions ( |
| "first + 1", "*i == *(i - 1)", "pred(*i, *(i -1))" ) which is not |
| defined for bidirectional iterator [see DR submitted by Thomas Mang |
| regarding invalid iterator arithmetic expressions].</p> |
| |
| <p> |
| The same problems as pointed out in DR 202 (equivalence relation / order |
| of arguments for pred()) apply to this paragraph.</p> |
| |
| <p> |
| 23.2.2.4 [lib.list.ops], paragraph 20: |
| </p> |
| |
| <p> |
| Current wording says: |
| "Throws: Nothing unless an exception in thrown by *i == *(i-1) or |
| pred(*i, *(i - 1))"</p> |
| |
| <p> |
| The sentence makes two times use of invalid iterator arithmetic |
| expressions ( "*i == *(i - 1)", "pred(*i, *(i -1))" ). |
| </p> |
| <p> |
| [Note: Minor typos: "in" / missing dot at end of sentence.] |
| </p> |
| |
| <p> |
| 23.2.2.4 [lib.list.ops], paragraph 21:</p> |
| |
| <p> |
| Current wording says: |
| "Complexity: If the range (last - first) is not empty, exactly (last - |
| first) - 1 applications of the corresponding predicate, otherwise no |
| application of the predicate.</p> |
| |
| <p> |
| See DR 315 regarding "(last - first)" not yielding a range.</p> |
| |
| <p> |
| Invalid iterator arithmetic expression "(last - first) - 1" left .</p> |
| |
| |
| <p>2) Description of intended behavior:</p> |
| |
| <p> |
| For the rest of this Defect Report, it is assumed that "eliminate" is |
| supposed to be synonymous to "erase", that "first" is equivalent to an |
| iterator obtained by a call to begin(), "last" is equivalent to an |
| iterator obtained by a call to end(), and that all invalid iterator |
| arithmetic expressions are resolved as described in DR submitted by |
| Thomas Mang regarding invalid iterator arithmetic expressions.</p> |
| |
| <p> |
| Furthermore, the resolutions of DR 202 are considered regarding |
| equivalence relation and order of arguments for a call to pred.</p> |
| |
| <p> |
| All implementations known to the author of this Defect Report comply |
| with these assumptions, apart from the impact of the alternative |
| resolution of DR 202. Except for the changes implied by the resolutions |
| of DR 202, no impact on current code is expected.</p> |
| |
| <p> |
| 3) Proposed fixes:</p> |
| |
| <p> |
| Change 23.2.2.4 [lib.list.ops], paragraph 19 to:</p> |
| |
| <p> |
| "Effect: Erases all but the first element from every consecutive group |
| of elements, referred to by the iterator i in the range [begin(), |
| end()), for which the following conditions hold: *(i-1) == *i (for the |
| version of unique with no argument) or pred(*(i-1), *i) != false (for |
| the version of unique with a predicate argument)."</p> |
| |
| <p> |
| Comments to the new wording:</p> |
| |
| <p> |
| a) The new wording was influenced by DR 202 and the resolutions |
| presented there. If DR 202 is resolved in another way, the proposed |
| wording need also additional review. |
| b) "Erases" refers in the author's opinion unambiguously to the member |
| function "erase". In case there is doubt this might not be unamgibuous, |
| a direct reference to the member function "erase" is suggested [Note: |
| This would also imply a change of 23.2.2.4 [lib.list.ops], paragraph |
| 15.]. |
| c) The expression "(i - 1)" was left, but is expected that DR submitted |
| by Thomas Mang regarding invalid iterator arithmetic expressions will |
| take this into account. |
| d) The wording "(for the version of unique with no argument)" and "(for |
| the version of unique with a predicate argument)" was kept consciously |
| for clarity. |
| e) "begin()" substitutes "first", and "end()" substitutes "last". The |
| range need adjustment from "[first + 1, last)" to "[begin(), end())" to |
| ensure a valid range in case of an empty list. |
| f) If it is considered that the wording is unclear whether it declares |
| the element of a group which consists of only a single element |
| implicitly to be the first element of this group [Note: Such an |
| interpretation could eventually arise especially in case size() == 1] , |
| the following additional sentence is proposed: "If such a group of |
| elements consists of only a single element, this element is also |
| considered the first element."</p> |
| |
| <p> |
| Change 23.2.2.4 [lib.list.ops], paragraph 20 to:</p> |
| |
| <p> |
| "Throws: Nothing unless an exception is thrown by *(i-1) == *i or |
| pred(*(i-1), *i)."</p> |
| |
| <p> |
| Comments to the new wording:</p> |
| |
| <p> |
| a) The wording regarding the conditions is identical to proposed |
| 23.2.2.4 [lib.list.ops], paragraph 19. If 23.2.2.4 [lib.list.ops], |
| paragraph 19 is resolved in another way, the proposed wording need also |
| additional review. |
| b) The expression "(i - 1)" was left, but is expected that DR submitted |
| by Thomas Mang regarding invalid iterator arithmetic expressions will |
| take this into account. |
| c) Typos fixed.</p> |
| |
| <p> |
| Change 23.2.2.4 [lib.list.ops], paragraph 21 to:</p> |
| |
| <p> |
| "Complexity: If empty() == false, exactly size() - 1 applications of the |
| corresponding predicate, otherwise no applications of the corresponding |
| predicate."</p> |
| |
| <p> |
| Comments to the new wording:</p> |
| |
| <p> |
| a) The new wording is supposed to also replace the proposed resolution |
| of DR 315, which suffers from the problem of undefined "first" / "last". |
| </p> |
| |
| <p> |
| 5) References to other DRs:</p> |
| |
| <p>See DR 202. |
| See DR 239. |
| See DR 315. |
| See DR submitted by Thomas Mang regarding invalid iterator arithmetic |
| expressions.</p> |
| |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>"All implementations known to the author of this Defect Report |
| comply with these assumption", and "no impact on current code is |
| expected", i.e. there is no evidence of real-world confusion or |
| harm.</p> |
| <hr> |
| <a name="493"><h3>493. Undefined Expression in Input Iterator Note Title</h3></a><p><b>Section:</b> 24.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Chris Jefferson <b>Date:</b> 13 Dec 2004</p> |
| <p>1) In 24.1.1/3, the following text is currently present.</p> |
| |
| <p>"Note: For input iterators, a==b does not imply ++a=++b (Equality does |
| not guarantee the substitution property or referential transparency)."</p> |
| |
| <p>However, when in Table 72, part of the definition of ++r is given as:</p> |
| |
| <p>"pre: r is dereferenceable. |
| post: any copies of the previous value of r are no longer required |
| either to be dereferenceable ..."</p> |
| |
| <p>While a==b does not imply that b is a copy of a, this statement should |
| perhaps still be made more clear.</p> |
| |
| <p>2) There are no changes to intended behaviour</p> |
| |
| <p> |
| 3) This Note should be altered to say "Note: For input iterators a==b, |
| when its behaviour is defined ++a==++b may still be false (Equality does |
| not guarantee the substitution property or referential transparency).</p> |
| |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>This is descriptive text, not normative, and the meaning is clear.</p> |
| <hr> |
| <a name="494"><h3>494. Wrong runtime complexity for associative container's insert and delete</h3></a><p><b>Section:</b> 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Hans B os <b>Date:</b> 19 Dec 2004</p> |
| <p>According to [lib.associative.reqmts] table 69, the runtime comlexity |
| of insert(p, t) and erase(q) can be done in amortized constant time.</p> |
| |
| <p>It was my understanding that an associative container could be |
| implemented as a balanced binary tree.</p> |
| |
| <p>For inser(p, t), you 'll have to iterate to p's next node to see if t |
| can be placed next to p. Furthermore, the insertion usually takes |
| place at leaf nodes. An insert next to the root node will be done at |
| the left of the root next node</p> |
| |
| <p>So when p is the root node you 'll have to iterate from the root to |
| its next node, which takes O(log(size)) time in a balanced tree.</p> |
| |
| <p>If you insert all values with insert(root, t) (where root is the |
| root of the tree before insertion) then each insert takes O(log(size)) |
| time. The amortized complexity per insertion will be O(log(size)) |
| also.</p> |
| |
| <p>For erase(q), the normal algorithm for deleting a node that has no |
| empty left or right subtree, is to iterate to the next (or previous), |
| which is a leaf node. Then exchange the node with the next and delete |
| the leaf node. Furthermore according to DR 130, erase should return |
| the next node of the node erased. Thus erasing the root node, |
| requires iterating to the next node.</p> |
| |
| <p>Now if you empty a map by deleting the root node until the map is |
| empty, each operation will take O(log(size)), and the amortized |
| complexity is still O(log(size)).</p> |
| |
| <p>The operations can be done in amortized constant time if iterating |
| to the next node can be done in (non amortized) constant time. This |
| can be done by putting all nodes in a double linked list. This |
| requires two extra links per node. To me this is a bit overkill since |
| you can already efficiently insert or erase ranges with erase(first, |
| last) and insert(first, last).</p> |
| |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p>Only "amortized constant" in special circumstances, and we believe |
| that's implementable. That is: doing this N times will be O(N), not |
| O(log N).</p> |
| <hr> |
| <a name="499"><h3>499. Std. doesn't seem to require stable_sort() to be stable!</h3></a><p><b>Section:</b> 25.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.stable.sort"> [lib.stable.sort]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Prateek Karandikar <b>Date:</b> 12 Apr 2005</p> |
| <blockquote> |
| <p> |
| 17.3.1.1 Summary</p> |
| |
| <p> |
| 1 The Summary provides a synopsis of the category, and introduces the |
| first-level subclauses. Each subclause also provides a summary, listing |
| the headers specified in the subclause and the library entities |
| provided in each header. |
| </p> |
| <p> |
| 2 Paragraphs labelled "Note(s):" or "Example(s):" are informative, |
| other paragraphs are normative. |
| </p> |
| </blockquote> |
| |
| <p>So this means that a "Notes" paragraph wouldn't be normative. </p> |
| |
| <blockquote> |
| <p> |
| 25.3.1.2 stable_sort |
| </p> |
| <pre>template<class RandomAccessIterator> |
| void stable_sort(RandomAccessIterat or first, RandomAccessIterator last); |
| |
| template<class RandomAccessIterator, class Compare> |
| void stable_sort(RandomAccessIterat or first, RandomAccessIterator last, Compare comp); |
| </pre> |
| <p> |
| 1 Effects: Sorts the elements in the range [first, last). |
| </p> |
| <p> |
| 2 Complexity: It does at most N(log N)^2 (where N == last - first) |
| comparisons; if enough extra memory is available, it is N log N. |
| </p> |
| <p> |
| 3 Notes: Stable: the relative order of the equivalent elements is |
| preserved. |
| </p> |
| </blockquote> |
| |
| <p> |
| The Notes para is informative, and nowhere else is stability mentioned above. |
| </p> |
| |
| <p> |
| Also, I just searched for the word "stable" in my copy of the Standard. |
| and the phrase "Notes: Stable: the relative order of the elements..." |
| is repeated several times in the Standard library clauses for |
| describing various functions. How is it that stability is talked about |
| in the informative paragraph? Or am I missing something obvious? |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| <p><b>Rationale:</b></p> |
| <p> |
| This change has already been made. |
| </p> |
| <hr> |
| <a name="500"><h3>500. do_length cannot be implemented correctly</h3></a><p><b>Section:</b> 22.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.codecvt.byname"> [lib.locale.codecvt.byname]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Krzysztof ¯elechowski <b>Date:</b> 24 May 2005</p> |
| <ol> |
| <li>codecvt::do_length is of type int;</li> |
| <li>it is assumed to be sort-of returning from_next - from of type ptrdiff_t;</li> |
| <li>ptrdiff_t cannot be cast to an int without data loss.</li> |
| </ol> |
| <p> |
| Contradiction. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| </p> |
| <hr> |
| <a name="501"><h3>501. Proposal: strengthen guarantees of lib.comparisons</h3></a><p><b>Section:</b> 20.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.base"> [lib.base]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Me <anti_spam_email2003@yahoo.com> <b>Date:</b> 7 Jun 2005</p> |
| <blockquote> |
| "For templates greater, less, greater_equal, and less_equal, |
| the specializations for any pointer type yield a total order, even if |
| the built-in operators <, >, <=, >= do not." |
| </blockquote> |
| |
| <p> |
| The standard should do much better than guarantee that these provide a |
| total order, it should guarantee that it can be used to test if memory |
| overlaps, i.e. write a portable memmove. You can imagine a platform |
| where the built-in operators use a uint32_t comparison (this tests for |
| overlap on this platform) but the less<T*> functor is allowed to be |
| defined to use a int32_t comparison. On this platform, if you use |
| std::less with the intent of making a portable memmove, comparison on |
| an array that straddles the 0x7FFFFFFF/0x8000000 boundary can give |
| incorrect results. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Add a footnote to 20.5.3/8 saying: |
| </p> |
| |
| <blockquote> |
| Given a p1 and p2 such that p1 points to N objects of type T and p2 |
| points to M objects of type T. If [p1,p1+N) does not overlap [p2,p2+M), |
| less returns the same value when comparing all pointers in [p1,p1+N) to |
| all pointers in [p2,p2+M). Otherwise, there is a value Q and a value R |
| such that less returns the same value when comparing all pointers in |
| [p1,p1+Q) to all pointers in [p2,p2+R) and an opposite value when |
| comparing all pointers in [p1+Q,p1+N) to all pointers in [p2+R,p2+M). |
| For the sake of completeness, the null pointer value (4.10) for T is |
| considered to be an array of 1 object that doesn't overlap with any |
| non-null pointer to T. less_equal, greater, greater_equal, equal_to, |
| and not_equal_to give the expected results based on the total ordering |
| semantics of less. For T of void, treat it as having similar semantics |
| as T of char i.e. less<cv T*>(a, b) gives the same results as less<cv |
| void*>(a, b) which gives the same results as less<cv char*>((cv |
| char*)(cv void*)a, (cv char*)(cv void*)b). |
| </blockquote> |
| |
| <p> |
| I'm also thinking there should be a footnote to 20.5.3/1 saying that if |
| A and B are similar types (4.4/4), comp<A>(a,b) returns the same value |
| as comp<B>(a,b) (where comp is less, less_equal, etc.). But this might |
| be problematic if there is some really funky operator overloading going |
| on that does different things based on cv (that should be undefined |
| behavior if somebody does that though). This at least should be |
| guaranteed for all POD types (especially pointers) that use the |
| built-in comparison operators. |
| </p> |
| |
| <p><b>Rationale:</b></p> |
| less is already required to provide a strict weak ordering which is good enough |
| to detect overlapping memory situations. |
| <hr> |
| <a name="504"><h3>504. Integer types in pseudo-random number engine requirements</h3></a><p><b>Section:</b> TR1 5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.req"> [tr.rand.req]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> |
| <p> |
| In [tr.rand.req], Paragraph 2 states that "... s is a value of integral type, |
| g is an ... object returning values of unsigned integral type ..." |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| In 5.1.1 [tr.rand.req], Paragraph 2 replace |
| </p> |
| |
| <blockquote> |
| ... s is a value of integral type, g is an lvalue of a type other than X that |
| defines a zero-argument function object returning values of <del>unsigned integral</del> type |
| <ins><tt>unsigned long int</tt></ins>, |
| ... |
| </blockquote> |
| |
| <p> |
| In 5.1.1 [tr.rand.seq], Table 16, replace in the line for X(s) |
| </p> |
| |
| <blockquote> |
| creates an engine with the initial internal state |
| determined by <ins><tt>static_cast<unsigned long>(</tt></ins><tt><i>s</i></tt><ins><tt>)</tt></ins> |
| </blockquote> |
| |
| <p><i>[ |
| Mont Tremblant: Both s and g should be unsigned long. |
| This should refer to the constructor signatures. Jens provided wording post Mont Tremblant. |
| ]</i></p> |
| |
| <p><i>[ |
| Berlin: N1932 adopts the proposed resolution: see 26.3.1.3/1e and Table 3 row 2. Moved |
| to Ready. |
| ]</i></p> |
| |
| <p><b>Rationale:</b></p> |
| <p> |
| Jens: Just requiring X(unsigned long) still makes it possible |
| for an evil library writer to also supply a X(int) that does something |
| unexpected. The wording above requires that X(s) always performs |
| as if X(unsigned long) would have been called. I believe that is |
| sufficient and implements our intentions from Mont Tremblant. I |
| see no additional use in actually requiring a X(unsigned long) |
| signature. u.seed(s) is covered by its reference to X(s), same |
| arguments. |
| </p> |
| <hr> |
| <a name="506"><h3>506. Requirements of Distribution parameter for variate_generator</h3></a><p><b>Section:</b> TR1 5.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.var"> [tr.rand.var]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> |
| <p> |
| Paragraph 3 requires that template argument U (which corresponds to template |
| parameter Engine) satisfy all uniform random number generator requirements. |
| However, there is no analogous requirement regarding the template argument |
| that corresponds to template parameter Distribution. We believe there should |
| be, and that it should require that this template argument satisfy all random |
| distribution requirements. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Consequence 1: Remove the precondition clauses [tr.rand.var]/16 and /18. |
| </p> |
| <p> |
| Consequence 2: Add max() and min() functions to those distributions that |
| do not already have them. |
| </p> |
| |
| <p><i>[ |
| Mont Tremblant: Jens reccommends NAD, min/max not needed everywhere. |
| Marc supports having min and max to satisfy generic programming interface. |
| ]</i></p> |
| |
| <p><b>Rationale:</b></p> |
| Berlin: N1932 makes this moot: variate_generator has been eliminated. |
| <hr> |
| <a name="509"><h3>509. Uniform_int template parameters</h3></a><p><b>Section:</b> TR1 5.1.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.dist.iunif"> [tr.rand.dist.iunif]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> |
| <p> |
| In [tr.rand.dist.iunif] the uniform_int distribution currently has a single |
| template parameter, IntType, used as the input_type and as the result_type |
| of the distribution. We believe there is no reason to conflate these types |
| in this way. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| We recommend that there be a second template parameter to |
| reflect the distributionÕs input_type, and that the existing first template |
| parameter continue to reflect (solely) the result_type: |
| </p> |
| <blockquote><pre>template< class IntType = int, UIntType = unsigned int > |
| class uniform_int |
| { |
| public: |
| // types |
| typedef UIntType input_type; |
| typedef IntType result_type; |
| </pre></blockquote> |
| |
| <p><i>[ |
| Berlin: Moved to NAD. N1932 makes this moot: the input_type template parameter has been |
| eliminated. |
| ]</i></p> |
| |
| <hr> |
| <a name="510"><h3>510. Input_type for bernoulli_distribution</h3></a><p><b>Section:</b> TR1 5.1.7.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.dist.bern"> [tr.rand.dist.bern]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> |
| <p> |
| In [tr.rand.dist.bern] the distribution currently requires; |
| </p> |
| <blockquote><pre>typedef int input_type; |
| </pre></blockquote> |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| We believe this is an unfortunate choice, and recommend instead: |
| </p> |
| <blockquote><pre>typedef unsigned int input_type; |
| </pre></blockquote> |
| |
| <p><i>[ |
| Berlin: Moved to NAD. N1932 makes this moot: the input_type template parameter has been |
| eliminated. |
| ]</i></p> |
| |
| <hr> |
| <a name="511"><h3>511. Input_type for binomial_distribution</h3></a><p><b>Section:</b> TR1 5.1.7.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.dist.bin"> [tr.rand.dist.bin]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> |
| <p> |
| Unlike all other distributions in TR1, this binomial_distribution has an |
| implementation-defined input_type. We believe this is an unfortunate choice, |
| because it hinders users from writing portable code. It also hinders the |
| writing of compliance tests. We recommend instead: |
| </p> |
| <blockquote><pre>typedef RealType input_type; |
| </pre></blockquote> |
| <p> |
| While this choice is somewhat arbitrary (as it was for some of the other |
| distributions), we make this particular choice because (unlike all other |
| distributions) otherwise this template would not publish its RealType |
| argument and so users could not write generic code that accessed this |
| second template parameter. In this respect, the choice is consistent with |
| the other distributions in TR1. |
| </p> |
| <p> |
| We have two reasons for recommending that a real type be specified instead. |
| One reason is based specifically on characteristics of binomial distribution |
| implementations, while the other is based on mathematical characteristics of |
| probability distribution functions in general. |
| </p> |
| <p> |
| Implementations of binomial distributions commonly use Stirling approximations |
| for values in certain ranges. It is far more natural to use real values to |
| represent these approximations than it would be to use integral values to do |
| so. In other ranges, implementations reply on the Bernoulli distribution to |
| obtain values. While TR1Õs bernoulli_distribution::input_type is specified as |
| int, we believe this would be better specified as double. |
| </p> |
| <p> |
| This brings us to our main point: The notion of a random distribution rests |
| on the notion of a cumulative distribution function, which in turn mathematically |
| depends on a continuous dependent variable. Indeed, such a distribution function |
| would be meaningless if it depended on discrete values such as integersÑand this |
| remains true even if the distribution function were to take discrete steps. |
| </p> |
| <p> |
| Although this note is specifically about binomial_distribution::input_type, |
| we intend to recommend that all of the random distributionsÕ input_types be |
| specified as a real type (either a RealType template parameter, or double, |
| as appropriate). |
| </p> |
| <p> |
| Of the nine distributions in TR1, four already have this characteristic |
| (uniform_real, exponential_distribution, normal_distribution, and |
| gamma_distribution). We have already argued the case for the binomial the |
| remaining four distributions. |
| </p> |
| <p> |
| In the case of uniform_int, we believe that the calculations to produce an |
| integer result in a specified range from an integer in a different specified |
| range is best done using real arithmetic. This is because it involves a |
| product, one of whose terms is the ratio of the extents of the two ranges. |
| Without real arithmetic, the results become less uniform: some numbers become |
| more (or less) probable that they should be. This is, of course, undesireable |
| behavior in a uniform distribution. |
| </p> |
| <p> |
| Finally, we believe that in the case of the bernoulli_distribution (briefly |
| mentioned earlier), as well as the cases of the geometric_distribution and the |
| poisson_distribution, it would be far more natural to have a real input_type. |
| This is because the most natural computation involves the random number |
| delivered and the distributionÕs parameter p (in the case of bernoulli_distribution, |
| for example, the computation is a comparison against p), and p is already specified |
| in each case as having some real type. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <blockquote><pre>typedef RealType input_type; |
| </pre></blockquote> |
| |
| <p><i>[ |
| Berlin: Moved to NAD. N1932 makes this moot: the input_type template parameter has been |
| eliminated. |
| ]</i></p> |
| <hr> |
| <a name="512"><h3>512. Seeding subtract_with_carry_01 from a single unsigned long</h3></a><p><b>Section:</b> TR1 5.1.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.eng.sub1"> [tr.rand.eng.sub1]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> |
| <p> |
| Paragraph 8 specifies the algorithm by which a subtract_with_carry_01 engine |
| is to be seeded given a single unsigned long. This algorithm is seriously |
| flawed in the case where the engine parameter w (also known as word_size) |
| exceeds 31 [bits]. The key part of the paragraph reads: |
| </p> |
| <blockquote> |
| sets x(-r) ... x(-1) to (lcg(1)*2**(-w)) mod 1 |
| </blockquote> |
| <p> |
| and so forth. |
| </p> |
| <p> |
| Since the specified linear congruential engine, lcg, delivers numbers with |
| a maximum of 2147483563 (just a shade under 31 bits), then when w is, for |
| example, 48, each of the x(i) will be less than 2**-17. The consequence |
| is that roughly the first 400 numbers delivered will be conspicuously |
| close to either zero or one. |
| </p> |
| <p> |
| Unfortunately, this is not an innocuous flaw: One of the predefined engines |
| in [tr.rand.predef], namely ranlux64_base_01, has w = 48 and would exhibit |
| this poor behavior, while the original N1378 proposal states that these |
| pre-defined engines are intended to be of "known good properties." |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| In 5.1.4.4 [tr.rand.eng.sub1], replace the "effects" clause for |
| void seed(unsigned long value = 19780503) by |
| </p> |
| |
| <blockquote> |
| <i>Effects:</i> If <tt>value == 0</tt>, sets value to <tt>19780503</tt>. In any |
| case, <del>with a linear congruential generator <tt>lcg</tt>(i) having parameters |
| <tt><i>m<sub>lcg</sub></i> = 2147483563</tt>, <tt><i>a<sub>lcg</sub></i> = 40014</tt>, |
| <tt><i>c<sub>lcg</sub></i> = 0</tt>, and <tt><i>lcg</i>(0) = value</tt>,</del> |
| sets <ins>carry<tt>(-1)</tt> and</ins> <tt>x(-r) … x(-1)</tt> |
| <ins>as if executing</ins> |
| |
| <blockquote><pre><ins> |
| linear_congruential<unsigned long, 40014, 0, 2147483563> lcg(value); |
| seed(lcg); |
| </ins></pre></blockquote> |
| |
| <del>to <tt>(<i>lcg</i>(1) · 2<sup>-<i>w</i></sup>) mod 1 |
| … (<i>lcg</i>(<i>r</i>) · 2<sup>-<i>w</i></sup>) mod 1</tt>, |
| respectively. If <tt><i>x</i>(-1) == 0</tt>, sets carry<tt>(-1) = 2<sup>-<i>w</i></sup></tt>, |
| else sets carry<tt>(-1) = 0</tt>.</del> |
| </blockquote> |
| |
| <p><i>[ |
| Jens provided revised wording post Mont Tremblant. |
| ]</i></p> |
| |
| <p><i>[ |
| Berlin: N1932 adopts the originally-proposed resolution of the issue. |
| Jens's supplied wording is a clearer description of what is |
| intended. Moved to Ready. |
| ]</i></p> |
| |
| <p><b>Rationale:</b></p> |
| <p> |
| Jens: I'm using an explicit type here, because fixing the |
| prose would probably not qualify for the (with issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#504">504</a> even |
| stricter) requirements we have for seed(Gen&). |
| </p> |
| |
| <p><i>[ |
| Portland: Subsumed by N2111. |
| ]</i></p> |
| <hr> |
| <a name="513"><h3>513. Size of state for subtract_with_carry_01</h3></a><p><b>Section:</b> TR1 5.1.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.eng.sub1"> [tr.rand.eng.sub1]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> |
| <p> |
| Paragraph 3 begins: |
| </p> |
| <blockquote> |
| The size of the state is r. |
| </blockquote> |
| <p> |
| However, this is not quite consistent with the remainder of the paragraph |
| which specifies a total of nr+1 items in the textual representation of |
| the state. We recommend the sentence be corrected to match: |
| </p> |
| <blockquote> |
| The size of the state is nr+1. |
| </blockquote> |
| <p> |
| To give meaning to the coefficient n, it may be also desirable to move |
| nÕs definition from later in the paragraph. Either of the following |
| seem reasonable formulations: |
| </p> |
| <blockquote> |
| With n=..., the size of the state is nr+1. |
| </blockquote> |
| <blockquote> |
| The size of the state is nr+1, where n=... . |
| </blockquote> |
| <p> |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><i>[ |
| Jens: I plead for "NAD" on the grounds that "size of state" is only |
| used as an argument for big-O complexity notation, thus |
| constant factors and additions don't count. |
| ]</i></p> |
| |
| <p><i>[ |
| Berlin: N1932 adopts the proposed NAD. |
| ]</i></p> |
| |
| <hr> |
| <a name="514"><h3>514. Size of state for subtract_with_carry</h3></a><p><b>Section:</b> TR1 5.1.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.eng.sub"> [tr.rand.eng.sub]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> |
| <p> |
| Paragraph 2 begins: |
| </p> |
| <blockquote> |
| The size of the state is r. |
| </blockquote> |
| <p> |
| However, the next sentence specifies a total of r+1 items in the textual |
| representation of the state, r specific xÕs as well as a specific carry. |
| This makes a total of r+1 items that constitute the size of the state, |
| rather than r. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| We recommend the sentence be corrected to match: |
| </p> |
| <blockquote> |
| The size of the state is r+1. |
| </blockquote> |
| |
| <p><i>[ |
| Jens: I plead for "NAD" on the grounds that "size of state" is only |
| used as an argument for big-O complexity notation, thus |
| constant factors and additions don't count. |
| ]</i></p> |
| |
| <p><i>[ |
| Berlin: N1932 adopts the proposed NAD. |
| ]</i></p> |
| |
| <hr> |
| <a name="516"><h3>516. Seeding subtract_with_carry_01 using a generator</h3></a><p><b>Section:</b> TR1 5.1.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.eng.sub1"> [tr.rand.eng.sub1]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> |
| <p> |
| Paragraph 6 says: |
| </p> |
| <blockquote> |
| ... obtained by successive invocations of g, ... |
| </blockquote> |
| <p> |
| We recommend instead: |
| </p> |
| <blockquote> |
| ... obtained by taking successive invocations of g mod 2**32, ... |
| </blockquote> |
| <p> |
| as the context seems to require only 32-bit quantities be used here. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Berlin: N1932 adopts the proposed resultion: see 26.3.3.4/7. Moved to Ready. |
| </p> |
| |
| <p><i>[ |
| Portland: Subsumed by N2111. |
| ]</i></p> |
| <hr> |
| <a name="517"><h3>517. Should include name in external representation</h3></a><p><b>Section:</b> TR1 5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.req"> [tr.rand.req]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Walter Brown <b>Date:</b> 3 Jul 2005</p> |
| <p> |
| The last two rows of Table 16 deal with the i/o requirements of an engine, |
| specifying that the textual representation of an engineÕs state, |
| appropriately formatted, constitute the engineÕs external representation. |
| </p> |
| <p> |
| This seems adequate when an engineÕs type is known. However, it seems |
| inadequate in the context of generic code, where it becomes useful and |
| perhaps even necessary to determine an engineÕs type via input. |
| </p> |
| <p> |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| We therefore recommend that, in each of these two rows of Table 16, the |
| text "textual representation" be expanded so as to read "engine name |
| followed by the textual representation." |
| </p> |
| |
| <p><i>[ |
| Berlin: N1932 considers this NAD. This is a QOI issue. |
| ]</i></p> |
| |
| <hr> |
| <a name="544"><h3>544. minor NULL problems in C.2</h3></a><p><b>Section:</b> C.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/diff.html#diff.library"> [diff.library]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Martin Sebor <b>Date:</b> 25 Nov 2005</p> |
| <p> |
| According to C.2.2.3, p1, "the macro NULL, defined in any of <clocale>, |
| <cstddef>, <cstdio>, <cstdlib>, <cstring>, <ctime>, |
| or <cwchar>." This is consistent with the C standard. |
| </p> |
| <p> |
| However, Table 95 in C.2 fails to mention <clocale> and <cstdlib>. |
| </p> |
| <p> |
| In addition, C.2, p2 claims that "The C++ Standard library provides |
| 54 standard macros from the C library, as shown in Table 95." While |
| table 95 does have 54 entries, since a couple of them (including the |
| NULL macro) are listed more than once, the actual number of macros |
| defined by the C++ Standard Library may not be 54. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| I propose we add <clocale> and <cstdlib> to Table 96 and remove the |
| number of macros from C.2, p2 and reword the sentence as follows: |
| </p> |
| <blockquote> |
| The C++ Standard library <del>provides 54 standard macros from</del> |
| <ins>defines a number macros corresponding to those defined by</ins> the C |
| <ins>Standard</ins> library, as shown in Table 96. |
| </blockquote> |
| |
| <p><i>[ |
| Portland: Resolution is considered editorial. It will be incorporated into the WD. |
| ]</i></p> |
| |
| <hr> |
| <a name="549"><h3>549. Undefined variable in binomial_distribution</h3></a><p><b>Section:</b> TR1 5.1.7.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.dist.bin"> [tr.rand.dist.bin]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Matt Austern <b>Date:</b> 10 Jan 2006</p> |
| <p> |
| Paragraph 1 says that "A binomial distributon random distribution produces |
| integer values i>0 with p(i) = (n choose i) * p*i * (1-p)^(t-i), where t and |
| p are the parameters of the distribution. OK, that tells us what t, p, and i |
| are. What's n? |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Berlin: Typo: "n" replaced by "t" in N1932: see 26.3.7.2.2/1. |
| </p> |
| |
| <p><i>[ |
| Portland: Subsumed by N2111. |
| ]</i></p> |
| <hr> |
| <a name="554"><h3>554. Problem with lwg DR 184 numeric_limits<bool></h3></a><p><b>Section:</b> 18.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.numeric.special"> [lib.numeric.special]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Howard Hinnant <b>Date:</b> 29 Jan 2006</p> |
| <p> |
| I believe we have a bug in the resolution of: |
| <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#184">lwg 184</a> |
| (WP status). |
| </p> |
| |
| <p> |
| The resolution spells out each member of <tt>numeric_limits<bool></tt>. |
| The part I'm having a little trouble with is: |
| </p> |
| <blockquote><pre>static const bool traps = false; |
| </pre></blockquote> |
| |
| <p> |
| Should this not be implementation defined? Given: |
| </p> |
| |
| <blockquote><pre>int main() |
| { |
| bool b1 = true; |
| bool b2 = false; |
| bool b3 = b1/b2; |
| } |
| </pre></blockquote> |
| |
| <p> |
| If this causes a trap, shouldn't <tt>numeric_limits<bool>::traps</tt> be |
| <tt>true</tt>? |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change 18.2.1.5p3: |
| </p> |
| |
| <blockquote> |
| -3- The specialization for <tt>bool</tt> shall be provided as follows: |
| <blockquote><pre>namespace std { |
| template <> class numeric_limits<bool> { |
| ... |
| static const bool traps = <del>false</del> <ins><i>implementation-defined</i></ins>; |
| ... |
| }; |
| } |
| </pre></blockquote> |
| </blockquote> |
| |
| <p><i>[ |
| Redmond: NAD because traps refers to values, not operations. There is no bool |
| value that will trap. |
| ]</i></p> |
| |
| <hr> |
| <a name="555"><h3>555. TR1, 8.21/1: typo</h3></a><p><b>Section:</b> TR1 8.21 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.c99.boolh"> [tr.c99.boolh]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> Paolo Carlini <b>Date:</b> 2 Feb 2006</p> |
| <p> |
| This one, if nobody noticed it yet, seems really editorial: |
| s/cstbool/cstdbool/ |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change 8.21p1: |
| </p> |
| <blockquote> |
| -1- The header behaves as if it defines the additional macro defined in |
| <tt><cst<ins>d</ins>bool></tt> by including the header <tt><cstdbool></tt>. |
| </blockquote> |
| |
| <p><i>[ |
| Redmond: Editorial. |
| ]</i></p> |
| |
| <hr> |
| <a name="558"><h3>558. lib.input.iterators Defect</h3></a><p><b>Section:</b> 24.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#NAD">NAD</a> <b>Submitter:</b> David Abrahams <b>Date:</b> 9 Feb 2006</p> |
| <blockquote> |
| <p> |
| 24.1.1 Input iterators [lib.input.iterators] |
| </p> |
| <p> |
| 1 A class or a built-in type X satisfies the requirements of an |
| input iterator for the value type T if the following expressions are |
| valid, where U is the type of any specified member of type T, as |
| shown in Table 73. |
| </p> |
| </blockquote> |
| <p> |
| There is no capital U used in table 73. There is a lowercase u, but |
| that is clearly not meant to denote a member of type T. Also, there's |
| no description in 24.1.1 of what lowercase a means. IMO the above |
| should have been...Hah, a and b are already covered in 24.1/11, so maybe it |
| should have just been: |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p> |
| Change 24.1.1p1: |
| </p> |
| <blockquote> |
| -1- A class or a built-in type <tt>X</tt> satisfies the requirements of an |
| input iterator for the value type <tt>T</tt> if the following expressions |
| are valid<del>, where <tt>U</tt> is the type of any specified member of type |
| <tt>T</tt>,</del> as shown in Table 73. |
| </blockquote> |
| |
| <p><i>[ |
| Portland: Editorial. |
| ]</i></p> |
| |
| <hr> |
| <a name="569"><h3>569. Postcondition for basic_ios::clear(iostate) incorrectly stated</h3></a><p><b>Section:</b> 27.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostate.flags"> [lib.iostate.flags]</a> <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a> <b>Submitter:</b> Seungbeom Kim <b>Date:</b> 10 Mar 2006</p> |
| <p> |
| Section: 27.4.4.3 [lib.iostate.flags] |
| </p> |
| <p> |
| Paragraph 4 says: |
| </p> |
| <blockquote> |
| <blockquote><pre>void clear(iostate <i>state</i> = goodbit); |
| </pre></blockquote> |
| <p> |
| <i>Postcondition:</i> If <tt>rdbuf()!=0</tt> then <tt><i>state</i> == rdstate();</tt> |
| otherwise <tt>rdstate()==<i>state</i>|ios_base::badbit</tt>. |
| </p> |
| </blockquote> |
| |
| <p> |
| The postcondition "rdstate()==state|ios_base::badbit" is parsed as |
| "(rdstate()==state)|ios_base::badbit", which is probably what the |
| committee meant. |
| </p> |
| <p><b>Proposed resolution:</b></p> |
| <p><b>Rationale:</b></p> |
| <p> |
| This is a duplicate of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#272">272</a>. |
| </p> |
| <p>----- End of document -----</p> |
| </body></html> |