libstdc++-v3/docs/html/ext/lwg-defects.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
   2 <html><head><title>C++ Standard Library Defect Report List</title>
   3
   4 <style>ins {background-color:#FFFFA0}
   5 del {background-color:#FFFFA0}</style></head>
   6
   7 <body bgcolor="#ffffff" text="#000000">
   8 <table>
   9 <tbody><tr>
  10 <td align="left">Doc. no.</td>
  11 <td align="left">N2131=06-0201</td>
  12 </tr>
  13 <tr>
  14 <td align="left">Date:</td>
  15 <td align="left">2006-11-03</td>
  16 </tr>
  17 <tr>
  18 <td align="left">Project:</td>
  19 <td align="left">Programming Language C++</td>
  20 </tr>
  21 <tr>
  22 <td align="left">Reply to:</td>
  23 <td align="left">Howard Hinnant &lt;howard.hinnant@gmail.com&gt;</td>
  24 </tr>
  25 </tbody></table>
  26 <h1>C++ Standard Library Defect Report List (Revision R45)</h1>
  27   <p>Reference ISO/IEC IS 14882:1998(E)</p>
  28   <p>Also see:</p>
  29     <ul>
  30       <li>
  31 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-toc.html">Table of Contents</a> for all library issues.</li>
  32       <li>
  33 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html">Index by Section</a> for all library issues.</li>
  34       <li>
  35 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html">Index by Status</a> for all library issues.</li>
  36       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a></li>
  37       <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a></li>
  38     </ul>
  39   <p>This document contains only library issues which have been closed
  40   by the Library Working Group (LWG) after being found to be defects
  41   in the standard.  That is, issues which have a status of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>, or <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#RR">RR</a>. See the
  42   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html">Library Closed Issues List</a> for issues closed as non-defects.  See the
  43   <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html">Library Active Issues List</a> for active issues and more information.  The
  44   introductory material in that document also applies to this
  45   document.</p>
  46 <h2>Revision History</h2>
  47 <ul>
  48 <li>R45:
  49 2006-11-03 post-Portland mailing.
  50 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.
  51 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.
  52 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#569">569</a> to Dup.
  53 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.
  54 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.
  55 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.
  56 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>.
  57 </li>
  58 <li>R44:
  59 2006-09-08 pre-Portland mailing.
  60 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>.
  61 </li>
  62 <li>R43:
  63 2006-06-23 mid-term mailing.
  64 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>.
  65 Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#255">255</a>.
  66 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.
  67 </li>
  68 <li>R42:
  69 2006-04-21 post-Berlin mailing.
  70 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>.
  71 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.
  72 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.
  73 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.
  74 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.
  75 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#534">534</a> to Review.
  76 </li>
  77 <li>R41:
  78 2006-02-24 pre-Berlin mailing.
  79 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>.
  80 Moved <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#342">342</a> from Ready to Open.
  81 Reopened <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309">309</a>.
  82 </li>
  83 <li>R40:
  84 2005-12-16 mid-term mailing.
  85 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>.
  86 </li>
  87 <li>R39:
  88 2005-10-14 post-Mont Tremblant mailing.
  89 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>.
  90 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.
  91 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.
  92 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.
  93 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.
  94 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#500">500</a> from New to NAD.
  95 Moved issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#518">518</a> from New to Review.
  96 </li>
  97 <li>R38:
  98 2005-07-03 pre-Mont Tremblant mailing.
  99 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>.
 100 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>
 101 </li>
 102 <li>R37:
 103 2005-06 mid-term mailing.
 104 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>.
 105 </li>
 106 <li>R36:
 107 2005-04 post-Lillehammer mailing. All issues in "ready" status except
 108 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
 109 previously in "DR" status were moved to "WP".
 110 </li>
 111 <li>R35:
 112 2005-03 pre-Lillehammer mailing.
 113 </li>
 114 <li>R34:
 115 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>.
 116 </li>
 117 <li>R33:
 118 2004-11 post-Redmond mailing. Reflects actions taken in Redmond.
 119 </li>
 120 <li>R32:
 121 2004-09 pre-Redmond mailing: reflects new proposed resolutions and
 122 new issues received after the 2004-07 mailing.  Added
 123 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>.
 124 </li>
 125 <li>R31:
 126 2004-07 mid-term mailing: reflects new proposed resolutions and
 127 new issues received after the post-Sydney mailing.  Added
 128 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>.
 129 </li>
 130 <li>R30:
 131 Post-Sydney mailing: reflects decisions made at the Sydney meeting.
 132 Voted all "Ready" issues from R29 into the working paper.
 133 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>.
 134 </li>
 135 <li>R29:
 136 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>.
 137 </li>
 138 <li>R28:
 139 Post-Kona mailing: reflects decisions made at the Kona meeting.
 140 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>.
 141 </li>
 142 <li>R27:
 143 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>.
 144 </li>
 145 <li>R26:
 146 Post-Oxford mailing: reflects decisions made at the Oxford meeting.
 147 All issues in Ready status were voted into DR status.  All issues in
 148 DR status were voted into WP status.
 149 </li>
 150 <li>R25:
 151 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>.
 152 </li>
 153 <li>R24:
 154 Post-Santa Cruz mailing: reflects decisions made at the Santa Cruz
 155 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
 156 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
 157 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
 158 concerns with <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> involve wording.
 159 </li>
 160 <li>R23:
 161 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>.
 162 Moved issues in the TC to TC status.
 163 </li>
 164 <li>R22:
 165 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>.
 166 </li>
 167 <li>R21:
 168 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>.
 169 </li>
 170 <li>R20:
 171 Post-Redmond mailing; reflects actions taken in Redmond.  Added
 172 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
 173 <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
 174 not discussed at the meeting.
 175
 176 All Ready issues were moved to DR status, with the exception of issues
 177 <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>.
 178
 179 Noteworthy issues discussed at Redmond include
 180 <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>,
 181 <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>.
 182 </li>
 183 <li>R19:
 184 Pre-Redmond mailing.  Added new issues
 185 <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>.
 186 </li>
 187 <li>R18:
 188 Post-Copenhagen mailing; reflects actions taken in Copenhagen.
 189 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
 190 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>.
 191
 192 Changed status of issues
 193 <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>
 194 <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>
 195 <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>
 196 <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>
 197 <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>
 198 <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>
 199 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#268">268</a>
 200 to DR.
 201
 202 Changed status of issues
 203 <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>
 204 <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>
 205 <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>
 206 <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>
 207 <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>
 208 <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>
 209 <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>
 210 <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>
 211 <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>
 212 to Ready.
 213
 214 Closed issues
 215 <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>
 216 <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>
 217 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#314">314</a>
 218 as NAD.
 219
 220 </li>
 221 <li>R17:
 222 Pre-Copenhagen mailing.  Converted issues list to XML.  Added proposed
 223 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>.
 224 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>.
 225 </li>
 226 <li>R16:
 227 post-Toronto mailing; reflects actions taken in Toronto. Added new
 228 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
 229 <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>,
 230 <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>,
 231 <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>,
 232 <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>,
 233 <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>,
 234 <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>,
 235 <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>,
 236 <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>,
 237 <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>,
 238 <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>,
 239 <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>,
 240 <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>,
 241 <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
 242 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
 243 <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
 244 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
 245 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
 246 the bug in enough places.
 247 </li>
 248 <li>R15:
 249 pre-Toronto mailing. Added issues
 250 <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
 251 changes so that we pass Weblint tests.
 252 </li>
 253 <li>R14:
 254 post-Tokyo II mailing; reflects committee actions taken in
 255 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)
 256 </li>
 257 <li>R13:
 258 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>.
 259 </li>
 260 <li>R12:
 261 pre-Tokyo II mailing: Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#199">199</a> to
 262 <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
 263 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#29">29</a>.  Add further rationale to issue
 264 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#178">178</a>.
 265 </li>
 266 <li>R11:
 267 post-Kona mailing: Updated to reflect LWG and full committee actions
 268 in Kona (99-0048/N1224). Note changed resolution of issues
 269 <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>
 270 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
 271 "closed" documents.  Changed the proposed resolution of issue
 272 <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
 273 of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#38">38</a>.
 274 </li>
 275 <li>R10:
 276 pre-Kona updated.  Added proposed resolutions <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>,
 277 <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>,
 278 <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
 279 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#195">195</a>. (99-0033/D1209, 14 Oct 99)
 280 </li>
 281 <li>R9:
 282 pre-Kona mailing.  Added issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a> to
 283 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#189">189</a>. Issues list split into separate "active" and
 284 "closed" documents. (99-0030/N1206, 25 Aug 99)
 285 </li>
 286 <li>R8:
 287 post-Dublin mailing. Updated to reflect LWG and full committee actions
 288 in Dublin. (99-0016/N1193, 21 Apr 99)
 289 </li>
 290 <li>R7:
 291 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>,
 292 <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>,
 293 <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>,
 294 <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)
 295 </li>
 296 <li>R6:
 297 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>,
 298 and <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#129">129</a>.  (99-0007/N1194, 22 Feb 99)
 299 </li>
 300 <li>R5:
 301 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
 302 <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
 303 for making list public. (30 Dec 98)
 304 </li>
 305 <li>R4:
 306 post-Santa Cruz II updated: Issues <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#110">110</a>,
 307 <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
 308 issues corrected. (22 Oct 98)
 309 </li>
 310 <li>R3:
 311 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>
 312 added, many issues updated to reflect LWG consensus (12 Oct 98)
 313 </li>
 314 <li>R2:
 315 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,
 316 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#17">17</a> updated. (29 Sep 98)
 317 </li>
 318 <li>R1:
 319 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
 320 format, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a> title. (17 Sep 98)
 321 </li>
 322 </ul>
 323 <h2>Defect Reports</h2>
 324 <hr>
 325 <a name="1"><h3>1.&nbsp;C library linkage editing oversight</h3></a><p><b>Section:</b>&nbsp;17.4.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.using.linkage"> [lib.using.linkage]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;16 Nov 1997</p>
 326 <p>The change specified in the proposed resolution below did not make
 327 it into the Standard. This change was accepted in principle at the
 328 London meeting, and the exact wording below was accepted at the
 329 Morristown meeting.</p>
 330 <p><b>Proposed resolution:</b></p>
 331 <p>Change 17.4.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.using.linkage"> [lib.using.linkage]</a> paragraph 2
 332 from:</p>
 333
 334 <blockquote>
 335   <p>It is unspecified whether a name from the Standard C library
 336   declared with external linkage has either extern "C" or
 337   extern "C++" linkage.</p>
 338 </blockquote>
 339
 340 <p>to:</p>
 341
 342 <blockquote>
 343   <p>Whether a name from the Standard C library declared with external
 344   linkage has extern "C" or extern "C++" linkage
 345   is implementation defined. It is recommended that an implementation
 346   use extern "C++" linkage for this purpose.</p>
 347 </blockquote>
 348 <hr>
 349 <a name="3"><h3>3.&nbsp;Atexit registration during atexit() call is not described</h3></a><p><b>Section:</b>&nbsp;18.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.cstdint"> [lib.cstdint]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;12 Dec 1997</p>
 350 <p>We appear not to have covered all the possibilities of
 351  exit processing with respect to
 352 atexit registration. <br>
 353 <br>
 354 Example 1: (C and C++)</p>
 355
 356 <pre>    #include &lt;stdlib.h&gt;
 357     void f1() { }
 358     void f2() { atexit(f1); }
 359
 360     int main()
 361     {
 362         atexit(f2); // the only use of f2
 363         return 0; // for C compatibility
 364     }</pre>
 365
 366 <p>At program exit, f2 gets called due to its registration in
 367 main. Running f2 causes f1 to be newly registered during the exit
 368 processing. Is this a valid program? If so, what are its
 369 semantics?</p>
 370
 371 <p>
 372 Interestingly, neither the C standard, nor the C++ draft standard nor
 373 the forthcoming C9X Committee Draft says directly whether you can
 374 register a function with atexit during exit processing.</p>
 375
 376 <p>
 377 All 3 standards say that functions are run in reverse order of their
 378 registration. Since f1 is registered last, it ought to be run first,
 379 but by the time it is registered, it is too late to be first.</p>
 380
 381 <p>If the program is valid, the standards are self-contradictory about
 382 its semantics.</p>
 383
 384 <p>Example 2: (C++ only)</p>
 385
 386 <pre>
 387     void F() { static T t; } // type T has a destructor
 388
 389     int main()
 390     {
 391         atexit(F); // the only use of F
 392     }
 393 </pre>
 394
 395 <p>Function F registered with atexit has a local static variable t,
 396 and F is called for the first time during exit processing. A local
 397 static object is initialized the first time control flow passes
 398 through its definition, and all static objects are destroyed during
 399 exit processing. Is the code valid? If so, what are its semantics?</p>
 400
 401 <p>
 402 Section 18.3 "Start and termination" says that if a function
 403 F is registered with atexit before a static object t is initialized, F
 404 will not be called until after t's destructor completes.</p>
 405
 406 <p>
 407 In example 2, function F is registered with atexit before its local
 408 static object O could possibly be initialized. On that basis, it must
 409 not be called by exit processing until after O's destructor
 410 completes. But the destructor cannot be run until after F is called,
 411 since otherwise the object could not be constructed in the first
 412 place.</p>
 413
 414 <p>If the program is valid, the standard is self-contradictory about
 415 its semantics.</p>
 416
 417 <p>I plan to submit Example 1 as a public comment on the C9X CD, with
 418 a recommendation that the results be undefined. (Alternative: make it
 419 unspecified. I don't think it is worthwhile to specify the case where
 420 f1 itself registers additional functions, each of which registers
 421 still more functions.)</p>
 422
 423 <p>I think we should resolve the situation in the whatever way the C
 424 committee decides. </p>
 425
 426 <p>For Example 2, I recommend we declare the results undefined.</p>
 427
 428 <p><i>[See reflector message lib-6500 for further discussion.]</i></p>
 429
 430 <p><b>Proposed resolution:</b></p>
 431 <p>Change section 18.3/8 from:</p>
 432 <blockquote>
 433   First, objects with static storage duration are destroyed and
 434   functions registered by calling atexit are called. Objects with
 435   static storage duration are destroyed in the reverse order of the
 436   completion of their constructor.  (Automatic objects are not
 437   destroyed as a result of calling exit().) Functions registered with
 438   atexit are called in the reverse order of their registration.  A
 439   function registered with atexit before an object obj1 of static
 440   storage duration is initialized will not be called until obj1's
 441   destruction has completed. A function registered with atexit after
 442   an object obj2 of static storage duration is initialized will be
 443   called before obj2's destruction starts.
 444 </blockquote>
 445 <p>to:</p>
 446 <blockquote>
 447   First, objects with static storage duration are destroyed and
 448   functions registered by calling atexit are called. Non-local objects
 449   with static storage duration are destroyed in the reverse order of
 450   the completion of their constructor. (Automatic objects are not
 451   destroyed as a result of calling exit().) Functions registered with
 452   atexit are called in the reverse order of their registration, except
 453   that a function is called after any previously registered functions
 454   that had already been called at the time it was registered. A
 455   function registered with atexit before a non-local object obj1 of
 456   static storage duration is initialized will not be called until
 457   obj1's destruction has completed. A function registered with atexit
 458   after a non-local object obj2 of static storage duration is
 459   initialized will be called before obj2's destruction starts. A local
 460   static object obj3 is destroyed at the same time it would be if a
 461   function calling the obj3 destructor were registered with atexit at
 462   the completion of the obj3 constructor.
 463 </blockquote>
 464 <p><b>Rationale:</b></p>
 465 <p>See 99-0039/N1215, October 22, 1999, by Stephen D. Clamage for the analysis
 466 supporting to the proposed resolution.</p>
 467 <hr>
 468 <a name="5"><h3>5.&nbsp;String::compare specification questionable</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Jack Reeves&nbsp; <b>Date:</b>&nbsp;11 Dec 1997</p>
 469 <p>At the very end of the basic_string class definition is the signature: int
 470 compare(size_type pos1, size_type n1, const charT* s, size_type n2 = npos) const; In the
 471 following text this is defined as: returns
 472 basic_string&lt;charT,traits,Allocator&gt;(*this,pos1,n1).compare(
 473 basic_string&lt;charT,traits,Allocator&gt;(s,n2); </p>
 474
 475 <p>Since the constructor basic_string(const charT* s, size_type n, const Allocator&amp; a
 476 = Allocator()) clearly requires that s != NULL and n &lt; npos and further states that it
 477 throws length_error if n == npos, it appears the compare() signature above should always
 478 throw length error if invoked like so: str.compare(1, str.size()-1, s); where 's' is some
 479 null terminated character array. </p>
 480
 481 <p>This appears to be a typo since the obvious intent is to allow either the call above or
 482 something like: str.compare(1, str.size()-1, s, strlen(s)-1); </p>
 483
 484 <p>This would imply that what was really intended was two signatures int compare(size_type
 485 pos1, size_type n1, const charT* s) const int compare(size_type pos1, size_type n1, const
 486 charT* s, size_type n2) const; each defined in terms of the corresponding constructor. </p>
 487 <p><b>Proposed resolution:</b></p>
 488 <p>Replace the compare signature in 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>
 489 (at the very end of the basic_string synopsis) which reads:</p>
 490
 491 <blockquote>
 492   <p><tt>int compare(size_type pos1, size_type n1,<br>
 493   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s,
 494   size_type n2 = npos) const;</tt></p>
 495 </blockquote>
 496
 497 <p>with:</p>
 498
 499 <blockquote>
 500   <p><tt>int compare(size_type pos1, size_type n1,<br>
 501   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s) const;<br>
 502   int compare(size_type pos1, size_type n1,<br>
 503   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT* s,
 504   size_type n2) const;</tt></p>
 505 </blockquote>
 506
 507 <p>Replace the portion of 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>
 508 paragraphs 5 and 6 which read:</p>
 509
 510 <blockquote>
 511   <p><tt>int compare(size_type pos, size_type n1,<br>
 512   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; charT * s, size_type n2
 513   = npos) const;<br>
 514   </tt>Returns:<tt><br>
 515   basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
 516   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 517   basic_string&lt;charT,traits,Allocator&gt;( s, n2))</tt></p>
 518 </blockquote>
 519
 520 <p>with:</p>
 521
 522 <blockquote>
 523   <p><tt>int compare(size_type pos, size_type n1,<br>
 524   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT * s) const;<br>
 525   </tt>Returns:<tt><br>
 526   basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
 527   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 528   basic_string&lt;charT,traits,Allocator&gt;( s ))<br>
 529   <br>
 530   int compare(size_type pos, size_type n1,<br>
 531   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; const charT * s,
 532   size_type n2) const;<br>
 533   </tt>Returns:<tt><br>
 534   basic_string&lt;charT,traits,Allocator&gt;(*this, pos, n1).compare(<br>
 535   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 536   basic_string&lt;charT,traits,Allocator&gt;( s, n2))</tt></p>
 537 </blockquote>
 538
 539 <p>Editors please note that in addition to splitting the signature, the third argument
 540 becomes const, matching the existing synopsis.</p>
 541 <p><b>Rationale:</b></p>
 542 <p>While the LWG dislikes adding signatures, this is a clear defect in
 543 the Standard which must be fixed.&nbsp; The same problem was also
 544 identified in issues 7 (item 5) and 87.</p>
 545 <hr>
 546 <a name="7"><h3>7.&nbsp;String clause minor problems</h3></a><p><b>Section:</b>&nbsp;21 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.strings"> [lib.strings]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;15 Dec 1997</p>
 547 <p>(1) In 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>, the description of template
 548 &lt;class InputIterator&gt; insert(iterator, InputIterator,
 549 InputIterator) makes no sense. It refers to a member function that
 550 doesn't exist. It also talks about the return value of a void
 551 function. </p>
 552
 553 <p>(2) Several versions of basic_string::replace don't appear in the
 554 class synopsis. </p>
 555
 556 <p>(3) basic_string::push_back appears in the synopsis, but is never
 557 described elsewhere.  In the synopsis its argument is const charT,
 558 which doesn't makes much sense; it should probably be charT, or
 559 possible const charT&amp;. </p>
 560
 561 <p>(4) basic_string::pop_back is missing. </p>
 562
 563 <p>(5) int compare(size_type pos, size_type n1, charT* s, size_type n2
 564 = npos) make no sense. First, it's const charT* in the synopsis and
 565 charT* in the description. Second, given what it says in RETURNS,
 566 leaving out the final argument will always result in an exception
 567 getting thrown. This is paragraphs 5 and 6 of
 568 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></p>
 569
 570 <p>(6) In table 37, in section 21.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits.require"> [lib.char.traits.require]</a>,
 571 there's a note for X::move(s, p, n). It says "Copies correctly
 572 even where p is in [s, s+n)". This is correct as far as it goes,
 573 but it doesn't go far enough; it should also guarantee that the copy
 574 is correct even where s in in [p, p+n). These are two orthogonal
 575 guarantees, and neither one follows from the other. Both guarantees
 576 are necessary if X::move is supposed to have the same sort of
 577 semantics as memmove (which was clearly the intent), and both
 578 guarantees are necessary if X::move is actually supposed to be
 579 useful. </p>
 580 <p><b>Proposed resolution:</b></p>
 581 <p>ITEM 1: In 21.3.5.4 [lib.string::insert], change paragraph 16 to <br>
 582 <br>
 583 &nbsp;&nbsp;&nbsp; EFFECTS: Equivalent to insert(p - begin(), basic_string(first, last)).<br>
 584 <br>
 585 ITEM 2:&nbsp; Not a defect; the Standard is clear.. There are ten versions of replace() in
 586 the synopsis, and ten versions in 21.3.5.6 [lib.string::replace].<br>
 587 <br>
 588 ITEM 3: Change the declaration of push_back in the string synopsis (21.3,
 589 [lib.basic.string]) from:</p>
 590
 591 <p>&nbsp;&nbsp;&nbsp;&nbsp; void push_back(const charT)<br>
 592 <br>
 593 to<br>
 594 <br>
 595 &nbsp;&nbsp;&nbsp;&nbsp; void push_back(charT)<br>
 596 <br>
 597 Add the following text immediately after 21.3.5.2 [lib.string::append], paragraph 10.<br>
 598 <br>
 599 &nbsp;&nbsp;&nbsp; void basic_string::push_back(charT c);<br>
 600 &nbsp;&nbsp;&nbsp; EFFECTS: Equivalent to append(static_cast&lt;size_type&gt;(1), c);<br>
 601 <br>
 602 ITEM 4: Not a defect. The omission appears to have been deliberate.<br>
 603 <br>
 604 ITEM 5: Duplicate; see issue 5 (and 87).<br>
 605 <br>
 606 ITEM 6: In table 37, Replace:<br>
 607 <br>
 608 &nbsp;&nbsp;&nbsp; "Copies correctly even where p is in [s, s+n)."<br>
 609 <br>
 610 with:<br>
 611 <br>
 612 &nbsp;&nbsp;&nbsp;&nbsp; "Copies correctly even where the ranges [p, p+n) and [s,
 613 s+n) overlap."</p>
 614 <hr>
 615 <a name="8"><h3>8.&nbsp;Locale::global lacks guarantee</h3></a><p><b>Section:</b>&nbsp;22.1.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.statics"> [lib.locale.statics]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;24 Dec 1997</p>
 616 <p>It appears there's an important guarantee missing from clause
 617 22. We're told that invoking locale::global(L) sets the C locale if L
 618 has a name. However, we're not told whether or not invoking
 619 setlocale(s) sets the global C++ locale. </p>
 620
 621 <p>The intent, I think, is that it should not, but I can't find any
 622 such words anywhere. </p>
 623 <p><b>Proposed resolution:</b></p>
 624 <p>Add a sentence at the end of 22.1.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.statics"> [lib.locale.statics]</a>,
 625 paragraph 2:&nbsp; </p>
 626
 627 <blockquote>
 628   <p>No library function other than <tt>locale::global()</tt> shall affect
 629   the value returned by <tt>locale()</tt>. </p>
 630
 631 </blockquote>
 632 <hr>
 633 <a name="9"><h3>9.&nbsp;Operator new(0) calls should not yield the same pointer</h3></a><p><b>Section:</b>&nbsp;18.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete"> [lib.new.delete]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;4 Jan 1998</p>
 634 <p>Scott Meyers, in a comp.std.c++ posting: I just noticed that
 635 section 3.7.3.1 of CD2 seems to allow for the possibility that all
 636 calls to operator new(0) yield the same pointer, an implementation
 637 technique specifically prohibited by ARM 5.3.3.Was this prohibition
 638 really lifted? Does the FDIS agree with CD2 in the regard? [Issues
 639 list maintainer's note: the IS is the same.]</p>
 640 <p><b>Proposed resolution:</b></p>
 641 <p>Change the last paragraph of 3.7.3 from:</p>
 642 <blockquote>
 643   <p>Any allocation and/or deallocation functions defined in a C++ program shall
 644   conform to the semantics specified in 3.7.3.1 and 3.7.3.2.</p>
 645 </blockquote>
 646 <p>to:</p>
 647 <blockquote>
 648   <p>Any allocation and/or deallocation functions defined in a C++ program,
 649   including the default versions in the library, shall conform to the semantics
 650   specified in 3.7.3.1 and 3.7.3.2.</p>
 651 </blockquote>
 652 <p>Change 3.7.3.1/2, next-to-last sentence, from :</p>
 653 <blockquote>
 654   <p>If the size of the space requested is zero, the value returned shall not be
 655   a null pointer value (4.10).</p>
 656 </blockquote>
 657 <p>to:</p>
 658 <blockquote>
 659   <p>Even if the size of the space requested is zero, the request can fail. If
 660   the request succeeds, the value returned shall be a non-null pointer value
 661   (4.10) p0 different from any previously returned value p1, unless that value
 662   p1 was since passed to an operator delete.</p>
 663 </blockquote>
 664 <p>5.3.4/7 currently reads:</p>
 665 <blockquote>
 666   <p>When the value of the expression in a direct-new-declarator is zero, the
 667   allocation function is called to allocate an array with no elements. The
 668   pointer returned by the new-expression is non-null. [Note: If the library
 669   allocation function is called, the pointer returned is distinct from the
 670   pointer to any other object.]</p>
 671 </blockquote>
 672 <p>Retain the first sentence, and delete the remainder.</p>
 673 <p>18.5.1 currently has no text. Add the following:</p>
 674 <blockquote>
 675   <p>Except where otherwise specified, the provisions of 3.7.3 apply to the
 676   library versions of operator new and operator delete.</p>
 677 </blockquote>
 678 <p>To 18.5.1.3, add the following text:</p>
 679 <blockquote>
 680   <p>The provisions of 3.7.3 do not apply to these reserved placement forms of
 681   operator new and operator delete.</p>
 682 </blockquote>
 683 <p><b>Rationale:</b></p>
 684 <p>See 99-0040/N1216, October 22, 1999, by Stephen D. Clamage for the analysis
 685 supporting to the proposed resolution.</p>
 686 <hr>
 687 <a name="11"><h3>11.&nbsp;Bitset minor problems</h3></a><p><b>Section:</b>&nbsp;23.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;22 Jan 1998</p>
 688 <p>(1) bitset&lt;&gt;::operator[] is mentioned in the class synopsis (23.3.5), but it is
 689 not documented in 23.3.5.2. </p>
 690
 691 <p>(2) The class synopsis only gives a single signature for bitset&lt;&gt;::operator[],
 692 reference operator[](size_t pos). This doesn't make much sense. It ought to be overloaded
 693 on const. reference operator[](size_t pos); bool operator[](size_t pos) const. </p>
 694
 695 <p>(3) Bitset's stream input function (23.3.5.3) ought to skip all whitespace before
 696 trying to extract 0s and 1s. The standard doesn't explicitly say that, though. This should
 697 go in the Effects clause.</p>
 698 <p><b>Proposed resolution:</b></p>
 699 <p>ITEMS 1 AND 2:<br>
 700 <br>
 701 In the bitset synopsis (23.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a>),
 702 replace the member function <br>
 703 <br>
 704 <tt>&nbsp;&nbsp;&nbsp; reference operator[](size_t pos);<br>
 705 </tt><br>
 706 with the two member functions<br>
 707 <br>
 708 <tt>&nbsp;&nbsp;&nbsp; bool operator[](size_t pos) const; <br>
 709 &nbsp;&nbsp;&nbsp; reference operator[](size_t pos); <br>
 710 </tt><br>
 711 Add the following text at the end of 23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a>,
 712 immediately after paragraph 45:</p>
 713
 714 <blockquote>
 715   <p><tt>bool operator[](size_t pos) const;</tt><br>
 716   Requires: pos is valid<br>
 717   Throws: nothing<br>
 718   Returns: <tt>test(pos)</tt><br>
 719   <br>
 720   <tt>bitset&lt;N&gt;::reference operator[](size_t pos);</tt> <br>
 721   Requires: pos is valid<br>
 722   Throws: nothing<br>
 723   Returns: An object of type <tt>bitset&lt;N&gt;::reference</tt> such that <tt>(*this)[pos]
 724   == this-&gt;test(pos)</tt>, and such that <tt>(*this)[pos] = val</tt> is equivalent to <tt>this-&gt;set(pos,
 725   val);</tt></p>
 726 </blockquote>
 727 <p><b>Rationale:</b></p>
 728 <p>The LWG believes Item 3 is not a defect. "Formatted
 729 input" implies the desired semantics. See 27.6.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted"> [lib.istream.formatted]</a>.
 730 </p>
 731 <hr>
 732 <a name="13"><h3>13.&nbsp;Eos refuses to die</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;William M. Miller&nbsp; <b>Date:</b>&nbsp;3 Mar 1998</p>
 733 <p>In 27.6.1.2.3, there is a reference to "eos", which is
 734 the only one in the whole draft (at least using Acrobat search), so
 735 it's undefined. </p>
 736 <p><b>Proposed resolution:</b></p>
 737 <p>In 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>, replace "eos" with
 738 "charT()"</p>
 739 <hr>
 740 <a name="14"><h3>14.&nbsp;Locale::combine should be const</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 741 <p>locale::combine is the only member function of locale (other than constructors and
 742 destructor) that is not const. There is no reason for it not to be const, and good reasons
 743 why it should have been const. Furthermore, leaving it non-const conflicts with 22.1.1
 744 paragraph 6: "An instance of a locale is immutable." </p>
 745
 746 <p>History: this member function originally was a constructor. it happened that the
 747 interface it specified had no corresponding language syntax, so it was changed to a member
 748 function. As constructors are never const, there was no "const" in the interface
 749 which was transformed into member "combine". It should have been added at that
 750 time, but the omission was not noticed. </p>
 751 <p><b>Proposed resolution:</b></p>
 752 <p>In 22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a> and also in 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>, add
 753 "const" to the declaration of member combine: </p>
 754 <blockquote>
 755   <pre>template &lt;class Facet&gt; locale combine(const locale&amp; other) const; </pre>
 756 </blockquote>
 757 <hr>
 758 <a name="15"><h3>15.&nbsp;Locale::name requirement inconsistent</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 759 <p>locale::name() is described as returning a string that can be passed to a locale
 760 constructor, but there is no matching constructor. </p>
 761 <p><b>Proposed resolution:</b></p>
 762 <p>In 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>, paragraph 5, replace
 763 "<tt>locale(name())</tt>" with
 764 "<tt>locale(name().c_str())</tt>".
 765 </p>
 766 <hr>
 767 <a name="16"><h3>16.&nbsp;Bad ctype_byname&lt;char&gt; decl</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 768 <p>The new virtual members ctype_byname&lt;char&gt;::do_widen and do_narrow did not get
 769 edited in properly. Instead, the member do_widen appears four times, with wrong argument
 770 lists. </p>
 771 <p><b>Proposed resolution:</b></p>
 772 <p>The correct declarations for the overloaded members
 773 <tt>do_narrow</tt> and <tt>do_widen</tt> should be copied
 774 from 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>
 775 <hr>
 776 <a name="17"><h3>17.&nbsp;Bad bool parsing</h3></a><p><b>Section:</b>&nbsp;22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 777 <p>This section describes the process of parsing a text boolean value from the input
 778 stream. It does not say it recognizes either of the sequences "true" or
 779 "false" and returns the corresponding bool value; instead, it says it recognizes
 780 only one of those sequences, and chooses which according to the received value of a
 781 reference argument intended for returning the result, and reports an error if the other
 782 sequence is found. (!) Furthermore, it claims to get the names from the ctype&lt;&gt;
 783 facet rather than the numpunct&lt;&gt; facet, and it examines the "boolalpha"
 784 flag wrongly; it doesn't define the value "loc"; and finally, it computes
 785 wrongly whether to use numeric or "alpha" parsing.<br>
 786 <br>
 787 I believe the correct algorithm is "as if": </p>
 788
 789 <pre>  // in, err, val, and str are arguments.
 790   err = 0;
 791   const numpunct&lt;charT&gt;&amp; np = use_facet&lt;numpunct&lt;charT&gt; &gt;(str.getloc());
 792   const string_type t = np.truename(), f = np.falsename();
 793   bool tm = true, fm = true;
 794   size_t pos = 0;
 795   while (tm &amp;&amp; pos &lt; t.size() || fm &amp;&amp; pos &lt; f.size()) {
 796     if (in == end) { err = str.eofbit; }
 797     bool matched = false;
 798     if (tm &amp;&amp; pos &lt; t.size()) {
 799       if (!err &amp;&amp; t[pos] == *in) matched = true;
 800       else tm = false;
 801     }
 802     if (fm &amp;&amp; pos &lt; f.size()) {
 803       if (!err &amp;&amp; f[pos] == *in) matched = true;
 804       else fm = false;
 805     }
 806     if (matched) { ++in; ++pos; }
 807     if (pos &gt; t.size()) tm = false;
 808     if (pos &gt; f.size()) fm = false;
 809   }
 810   if (tm == fm || pos == 0) { err |= str.failbit; }
 811   else                      { val = tm; }
 812   return in;</pre>
 813
 814 <p>Notice this works reasonably when the candidate strings are both empty, or equal, or
 815 when one is a substring of the other. The proposed text below captures the logic of the
 816 code above.</p>
 817 <p><b>Proposed resolution:</b></p>
 818 <p>In 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>, in the first line of paragraph 14,
 819 change "&amp;&amp;" to "&amp;".</p>
 820
 821 <p>Then, replace paragraphs 15 and 16 as follows:</p>
 822
 823 <blockquote>
 824
 825   <p>Otherwise target sequences are determined "as if" by
 826   calling the members <tt>falsename()</tt> and
 827   <tt>truename()</tt> of the facet obtained by
 828   <tt>use_facet&lt;numpunct&lt;charT&gt;&nbsp;&gt;(str.getloc())</tt>.
 829   Successive characters in the range <tt>[in,end)</tt> (see
 830   [lib.sequence.reqmts]) are obtained and matched against
 831   corresponding positions in the target sequences only as necessary to
 832   identify a unique match. The input iterator <tt>in</tt> is
 833   compared to <tt>end</tt> only when necessary to obtain a
 834   character. If and only if a target sequence is uniquely matched,
 835   <tt>val</tt> is set to the corresponding value.</p>
 836
 837 </blockquote>
 838
 839 <blockquote>
 840   <p>The <tt>in</tt> iterator is always left pointing one position beyond the last character
 841   successfully matched. If <tt>val</tt> is set, then err is set to <tt>str.goodbit</tt>; or to
 842   <tt>str.eofbit</tt> if, when seeking another character to match, it is found that
 843   <tt>(in==end)</tt>. If <tt>val</tt> is not set, then <i>err</i> is set to <tt>str.failbit</tt>; or to
 844   <tt>(str.failbit|str.eofbit)</tt>if
 845   the reason for the failure was that <tt>(in==end)</tt>. [Example: for targets
 846   <tt>true</tt>:"a" and <tt>false</tt>:"abb", the input sequence "a" yields
 847   <tt>val==true</tt> and <tt>err==str.eofbit</tt>; the input sequence "abc" yields
 848   <tt>err=str.failbit</tt>, with <tt>in</tt> ending at the 'c' element. For targets
 849   <tt>true</tt>:"1"
 850   and <tt>false</tt>:"0", the input sequence "1" yields <tt>val==true</tt>
 851   and <tt>err=str.goodbit</tt>. For empty targets (""), any input sequence yields
 852   <tt>err==str.failbit</tt>. --end example]</p>
 853 </blockquote>
 854 <hr>
 855 <a name="18"><h3>18.&nbsp;Get(...bool&amp;) omitted</h3></a><p><b>Section:</b>&nbsp;22.2.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 856 <p>In the list of num_get&lt;&gt; non-virtual members on page 22-23, the member
 857 that parses bool values was omitted from the list of definitions of non-virtual
 858 members, though it is listed in the class definition and the corresponding
 859 virtual is listed everywhere appropriate. </p>
 860 <p><b>Proposed resolution:</b></p>
 861 <p>Add at the beginning of 22.2.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a>
 862 another get member for bool&amp;, copied from the entry in
 863 22.2.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.num.get"> [lib.locale.num.get]</a>.</p>
 864 <hr>
 865 <a name="19"><h3>19.&nbsp;"Noconv" definition too vague</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 866 <p>
 867 In the definitions of codecvt&lt;&gt;::do_out and do_in, they are
 868 specified to return noconv if "no conversion is
 869 needed". This definition is too vague, and does not say
 870 normatively what is done with the buffers.
 871 </p>
 872 <p><b>Proposed resolution:</b></p>
 873 <p>
 874 Change the entry for noconv in the table under paragraph 4 in section
 875 <font color="red">22.2.1.5.2</font> to read:
 876 </p>
 877 <blockquote>
 878   <p><tt>noconv</tt>: <tt>internT</tt> and <tt>externT</tt> are the same type,
 879   and input sequence is identical to converted sequence.</p>
 880 </blockquote>
 881 <p>Change the Note in paragraph 2 to normative text as follows:</p>
 882 <blockquote>
 883   <p>If returns <tt>noconv</tt>, <tt>internT</tt> and <tt>externT</tt> are the
 884   same type and the converted sequence is identical to the input sequence <tt>[from,from_next)</tt>.
 885   <tt>to_next</tt> is set equal to <tt>to</tt>, the value of <tt>state</tt> is
 886   unchanged, and there are no changes to the values in <tt>[to, to_limit)</tt>.</p>
 887 </blockquote>
 888 <hr>
 889 <a name="20"></a><h3><a name="20">20.&nbsp;Thousands_sep returns wrong type</a></h3><p><b>Section:</b>&nbsp;22.2.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.numpunct.virtuals"> [lib.facet.numpunct.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 890 <p>The synopsis for numpunct&lt;&gt;::do_thousands_sep, and the
 891 definition of numpunct&lt;&gt;::thousands_sep which calls it, specify
 892 that it returns a value of type char_type. Here it is erroneously
 893 described as returning a "string_type". </p>
 894 <p><b>Proposed resolution:</b></p>
 895 <p>In 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>, above paragraph 2, change
 896 "string_type" to "char_type". </p>
 897 <hr>
 898 <a name="21"><h3>21.&nbsp;Codecvt_byname&lt;&gt; instantiations</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 899 <p>In the second table in the section, captioned "Required
 900 instantiations", the instantiations for codecvt_byname&lt;&gt;
 901 have been omitted. These are necessary to allow users to construct a
 902 locale by name from facets. </p>
 903 <p><b>Proposed resolution:</b></p>
 904 <p>Add in 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> to the table captioned
 905 "Required instantiations", in the category "ctype"
 906 the lines </p>
 907
 908 <blockquote>
 909   <pre>codecvt_byname&lt;char,char,mbstate_t&gt;,
 910 codecvt_byname&lt;wchar_t,char,mbstate_t&gt; </pre>
 911 </blockquote>
 912 <hr>
 913 <a name="22"><h3>22.&nbsp;Member open vs. flags</h3></a><p><b>Section:</b>&nbsp;27.8.1.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 914 <p>The description of basic_istream&lt;&gt;::open leaves unanswered questions about how it
 915 responds to or changes flags in the error status for the stream. A strict reading
 916 indicates that it ignores the bits and does not change them, which confuses users who do
 917 not expect eofbit and failbit to remain set after a successful open. There are three
 918 reasonable resolutions: 1) status quo 2) fail if fail(), ignore eofbit 3) clear failbit
 919 and eofbit on call to open(). </p>
 920 <p><b>Proposed resolution:</b></p>
 921 <p>In 27.8.1.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a> paragraph 3, <i>and</i> in 27.8.1.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ofstream.members"> [lib.ofstream.members]</a> paragraph 3, under open() effects, add a footnote:
 922 </p>
 923
 924 <blockquote>
 925   <p>A successful open does not change the error state.</p>
 926 </blockquote>
 927 <p><b>Rationale:</b></p>
 928 <p>This may seem surprising to some users, but it's just an instance
 929 of a general rule: error flags are never cleared by the
 930 implementation. The only way error flags are are ever cleared is if
 931 the user explicitly clears them by hand.</p>
 932
 933 <p>The LWG believed that preserving this general rule was
 934 important enough so that an exception shouldn't be made just for this
 935 one case.  The resolution of this issue clarifies what the LWG
 936 believes to have been the original intent.</p>
 937
 938 <hr>
 939 <a name="24"><h3>24.&nbsp;"do_convert" doesn't exist</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 940 <p>The description of codecvt&lt;&gt;::do_out and do_in mentions a
 941 symbol "do_convert" which is not defined in the
 942 standard. This is a leftover from an edit, and should be "do_in
 943 and do_out". </p>
 944 <p><b>Proposed resolution:</b></p>
 945 <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>, paragraph 3, change
 946 "do_convert" to "do_in or do_out". Also, in <font color="red">22.2.1.5.2</font>, change "do_convert()" to "do_in
 947 or do_out". </p>
 948 <hr>
 949 <a name="25"><h3>25.&nbsp;String operator&lt;&lt; uses width() value wrong</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 950 <p>In the description of operator&lt;&lt; applied to strings, the standard says that uses
 951 the smaller of os.width() and str.size(), to pad "as described in stage 3"
 952 elsewhere; but this is inconsistent, as this allows no possibility of space for padding. </p>
 953 <p><b>Proposed resolution:</b></p>
 954 <p>Change 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>  paragraph 4 from:<br>
 955 <br>
 956 &nbsp;&nbsp;&nbsp; "... where <tt>n</tt> is the smaller of <tt>os.width()</tt> and <tt>str.size()</tt>;
 957 ..."<br>
 958 <br>
 959 to: <br>
 960 <br>
 961 &nbsp;&nbsp;&nbsp; "... where <tt>n</tt> is the larger of <tt>os.width()</tt> and <tt>str.size()</tt>;
 962 ..."</p>
 963 <hr>
 964 <a name="26"><h3>26.&nbsp;Bad sentry example</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 965 <p>In paragraph 6, the code in the example: </p>
 966
 967 <pre>  template &lt;class charT, class traits = char_traits&lt;charT&gt; &gt;
 968   basic_istream&lt;charT,traits&gt;::sentry(
 969            basic_istream&lt;charT,traits&gt;&amp; is, bool noskipws = false) {
 970       ...
 971       int_type c;
 972       typedef ctype&lt;charT&gt; ctype_type;
 973       const ctype_type&amp; ctype = use_facet&lt;ctype_type&gt;(is.getloc());
 974       while ((c = is.rdbuf()-&gt;snextc()) != traits::eof()) {
 975         if (ctype.is(ctype.space,c)==0) {
 976           is.rdbuf()-&gt;sputbackc (c);
 977           break;
 978         }
 979       }
 980       ...
 981    }</pre>
 982
 983 <p>fails to demonstrate correct use of the facilities described. In
 984 particular, it fails to use traits operators, and specifies incorrect
 985 semantics. (E.g. it specifies skipping over the first character in the
 986 sequence without examining it.) </p>
 987 <p><b>Proposed resolution:</b></p>
 988 <p>Remove the example above from 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>
 989 paragraph 6.</p>
 990 <p><b>Rationale:</b></p>
 991 <p>The originally proposed replacement code for the example was not
 992 correct. The LWG tried in Kona and again in Tokyo to correct it
 993 without success. In Tokyo, an implementor reported that actual working
 994 code ran over one page in length and was quite complicated. The LWG
 995 decided that it would be counter-productive to include such a lengthy
 996 example, which might well still contain errors.</p>
 997 <hr>
 998 <a name="27"><h3>27.&nbsp;String::erase(range) yields wrong iterator</h3></a><p><b>Section:</b>&nbsp;21.3.5.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::erase"> [lib.string::erase]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
 999 <p>The string::erase(iterator first, iterator last) is specified to return an element one
1000 place beyond the next element after the last one erased. E.g. for the string
1001 "abcde", erasing the range ['b'..'d') would yield an iterator for element 'e',
1002 while 'd' has not been erased. </p>
1003 <p><b>Proposed resolution:</b></p>
1004 <p>In 21.3.5.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::erase"> [lib.string::erase]</a>, paragraph 10, change: </p>
1005
1006 <blockquote>
1007   <p>Returns: an iterator which points to the element immediately following _last_ prior to
1008   the element being erased. </p>
1009 </blockquote>
1010
1011 <p>to read </p>
1012
1013 <blockquote>
1014   <p>Returns: an iterator which points to the element pointed to by _last_ prior to the
1015   other elements being erased. </p>
1016 </blockquote>
1017 <hr>
1018 <a name="28"><h3>28.&nbsp;Ctype&lt;char&gt;is ambiguous</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1019 <p>The description of the vector form of ctype&lt;char&gt;::is can be interpreted to mean
1020 something very different from what was intended. Paragraph 4 says </p>
1021
1022 <blockquote>
1023   <p>Effects: The second form, for all *p in the range [low, high), assigns vec[p-low] to
1024   table()[(unsigned char)*p]. </p>
1025 </blockquote>
1026
1027 <p>This is intended to copy the value indexed from table()[] into the place identified in
1028 vec[]. </p>
1029 <p><b>Proposed resolution:</b></p>
1030 <p>Change 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 4, to read </p>
1031
1032 <blockquote>
1033   <p>Effects: The second form, for all *p in the range [low, high), assigns into vec[p-low]
1034   the value table()[(unsigned char)*p]. </p>
1035 </blockquote>
1036 <hr>
1037 <a name="29"><h3>29.&nbsp;Ios_base::init doesn't exist</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1038 <p>Sections 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> and 27.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.wide.stream.objects"> [lib.wide.stream.objects]</a> mention
1039 a function ios_base::init, which is not defined. Probably they mean
1040 basic_ios&lt;&gt;::init, defined in 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>,
1041 paragraph 3. </p>
1042 <p><b>Proposed resolution:</b></p>
1043 <p>[R12: modified to include paragraph 5.]</p>
1044
1045 <p>In 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> paragraph 2 and 5, change </p>
1046
1047 <blockquote>
1048   <p>ios_base::init </p>
1049 </blockquote>
1050
1051 <p>to </p>
1052
1053 <blockquote>
1054   <p>basic_ios&lt;char&gt;::init </p>
1055 </blockquote>
1056
1057 <p>Also, make a similar change in 27.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.wide.stream.objects"> [lib.wide.stream.objects]</a> except it
1058 should read </p>
1059
1060 <blockquote>
1061   <p>basic_ios&lt;wchar_t&gt;::init </p>
1062 </blockquote>
1063 <hr>
1064 <a name="30"><h3>30.&nbsp;Wrong header for LC_*</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1065 <p>Paragraph 2 implies that the C macros LC_CTYPE etc. are defined in &lt;cctype&gt;,
1066 where they are in fact defined elsewhere to appear in &lt;clocale&gt;. </p>
1067 <p><b>Proposed resolution:</b></p>
1068 <p>In 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, change
1069 "&lt;cctype&gt;" to read "&lt;clocale&gt;". </p>
1070 <hr>
1071 <a name="31"><h3>31.&nbsp;Immutable locale values</h3></a><p><b>Section:</b>&nbsp;22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1072 <p>Paragraph 6, says "An instance of <tt>locale</tt> is
1073 <i>immutable</i>; once a facet reference is obtained from it,
1074 ...". This has caused some confusion, because locale variables
1075 are manifestly assignable. </p>
1076 <p><b>Proposed resolution:</b></p>
1077 <p>In 22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a> replace paragraph 6</p>
1078
1079 <blockquote>
1080   <p>An instance of <tt>locale</tt> is immutable; once a facet
1081   reference is obtained from it, that reference remains usable as long
1082   as the locale value itself exists.</p>
1083 </blockquote>
1084
1085 <p>with</p>
1086
1087 <blockquote>
1088   <p>Once a facet reference is obtained from a locale object by
1089   calling use_facet&lt;&gt;, that reference remains usable, and the
1090   results from member functions of it may be cached and re-used, as
1091   long as some locale object refers to that facet.</p>
1092 </blockquote>
1093 <hr>
1094 <a name="32"><h3>32.&nbsp;Pbackfail description inconsistent</h3></a><p><b>Section:</b>&nbsp;27.5.2.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.pback"> [lib.streambuf.virt.pback]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1095 <p>The description of the required state before calling virtual member
1096 basic_streambuf&lt;&gt;::pbackfail requirements is inconsistent with the conditions
1097 described in 27.5.2.2.4 [lib.streambuf.pub.pback] where member sputbackc calls it.
1098 Specifically, the latter says it calls pbackfail if: </p>
1099
1100 <p>&nbsp;&nbsp;&nbsp; traits::eq(c,gptr()[-1]) is false </p>
1101
1102 <p>where pbackfail claims to require: </p>
1103
1104 <p>&nbsp;&nbsp;&nbsp; traits::eq(*gptr(),traits::to_char_type(c)) returns false </p>
1105
1106 <p>It appears that the pbackfail description is wrong. </p>
1107 <p><b>Proposed resolution:</b></p>
1108 <p>In 27.5.2.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.pback"> [lib.streambuf.virt.pback]</a>, paragraph 1, change:</p>
1109
1110 <blockquote>
1111   <p>"<tt>traits::eq(*gptr(),traits::to_char_type( c))</tt>"</p>
1112 </blockquote>
1113
1114 <p>to </p>
1115
1116 <blockquote>
1117   <p>"<tt>traits::eq(traits::to_char_type(c),gptr()[-1])</tt>"
1118   </p>
1119 </blockquote>
1120 <p><b>Rationale:</b></p>
1121 <p>Note deliberate reordering of arguments for clarity in addition to the correction of
1122 the argument value.</p>
1123 <hr>
1124 <a name="33"><h3>33.&nbsp;Codecvt&lt;&gt; mentions from_type</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1125 <p>In the table defining the results from do_out and do_in, the specification for the
1126 result <i>error</i> says </p>
1127
1128 <blockquote>
1129   <p>encountered a from_type character it could not convert </p>
1130 </blockquote>
1131
1132 <p>but from_type is not defined. This clearly is intended to be an externT for do_in, or
1133 an internT for do_out. </p>
1134 <p><b>Proposed resolution:</b></p>
1135 <p>In <font color="red">22.2.1.5.2</font> paragraph 4, replace the definition
1136 in the table for the case of _error_ with </p>
1137
1138 <blockquote>
1139   <p>encountered a character in <tt>[from,from_end)</tt> that it could not convert. </p>
1140 </blockquote>
1141 <hr>
1142 <a name="34"><h3>34.&nbsp;True/falsename() not in ctype&lt;&gt;</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1143 <p>In paragraph 19, Effects:, members truename() and falsename are used from facet
1144 ctype&lt;charT&gt;, but it has no such members. Note that this is also a problem in
1145 22.2.2.1.2, addressed in (4). </p>
1146 <p><b>Proposed resolution:</b></p>
1147 <p>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>, paragraph 19, in the Effects:
1148 clause for member put(...., bool), replace the initialization of the
1149 string_type value s as follows: </p>
1150
1151 <blockquote>
1152   <pre>const numpunct&amp; np = use_facet&lt;numpunct&lt;charT&gt; &gt;(loc);
1153 string_type s = val ? np.truename() : np.falsename(); </pre>
1154 </blockquote>
1155 <hr>
1156 <a name="35"><h3>35.&nbsp;No manipulator unitbuf in synopsis</h3></a><p><b>Section:</b>&nbsp;27.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostreams.base"> [lib.iostreams.base]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1157 <p>In 27.4.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fmtflags.manip"> [lib.fmtflags.manip]</a>, we have a definition for a manipulator
1158 named "unitbuf". Unlike other manipulators, it's not listed
1159 in synopsis. Similarly for "nounitbuf". </p>
1160 <p><b>Proposed resolution:</b></p>
1161 <p>Add to the synopsis for &lt;ios&gt; in 27.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostreams.base"> [lib.iostreams.base]</a>, after
1162 the entry for "nouppercase", the prototypes: </p>
1163
1164 <blockquote>
1165   <pre>ios_base&amp; unitbuf(ios_base&amp; str);
1166 ios_base&amp; nounitbuf(ios_base&amp; str); </pre>
1167 </blockquote>
1168 <hr>
1169 <a name="36"><h3>36.&nbsp;Iword &amp; pword storage lifetime omitted</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1170 <p>In the definitions for ios_base::iword and pword, the lifetime of the storage is
1171 specified badly, so that an implementation which only keeps the last value stored appears
1172 to conform. In particular, it says: </p>
1173
1174 <p>The reference returned may become invalid after another call to the object's iword
1175 member with a different index ... </p>
1176
1177 <p>This is not idle speculation; at least one implementation was done this way. </p>
1178 <p><b>Proposed resolution:</b></p>
1179 <p>Add in 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>, in both paragraph 2 and also in
1180 paragraph 4, replace the sentence: </p>
1181
1182 <blockquote>
1183   <p>The reference returned may become invalid after another call to the object's iword
1184   [pword] member with a different index, after a call to its copyfmt member, or when the
1185   object is destroyed. </p>
1186 </blockquote>
1187
1188 <p>with: </p>
1189
1190 <blockquote>
1191   <p>The reference returned is invalid after any other operations on the object. However,
1192   the value of the storage referred to is retained, so that until the next call to copyfmt,
1193   calling iword [pword] with the same index yields another reference to the same value. </p>
1194 </blockquote>
1195
1196 <p>substituting "iword" or "pword" as appropriate. </p>
1197 <hr>
1198 <a name="37"><h3>37.&nbsp;Leftover "global" reference</h3></a><p><b>Section:</b>&nbsp;22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1199 <p>In the overview of locale semantics, paragraph 4, is the sentence </p>
1200
1201 <blockquote>
1202   <p>If Facet is not present in a locale (or, failing that, in the global locale), it throws
1203   the standard exception bad_cast. </p>
1204 </blockquote>
1205
1206 <p>This is not supported by the definition of use_facet&lt;&gt;, and represents semantics
1207 from an old draft. </p>
1208 <p><b>Proposed resolution:</b></p>
1209 <p>In 22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a>, paragraph 4, delete the parenthesized
1210 expression </p>
1211
1212 <blockquote>
1213   <p>(or, failing that, in the global locale) </p>
1214 </blockquote>
1215 <hr>
1216 <a name="38"><h3>38.&nbsp;Facet definition incomplete</h3></a><p><b>Section:</b>&nbsp;22.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.global.templates"> [lib.locale.global.templates]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1217 <p>It has been noticed by Esa Pulkkinen that the definition of
1218 "facet" is incomplete. In particular, a class derived from
1219 another facet, but which does not define a member <i>id</i>, cannot
1220 safely serve as the argument <i>F</i> to use_facet&lt;F&gt;(loc),
1221 because there is no guarantee that a reference to the facet instance
1222 stored in <i>loc</i> is safely convertible to <i>F</i>. </p>
1223 <p><b>Proposed resolution:</b></p>
1224 <p>In the definition of std::use_facet&lt;&gt;(), replace the text in paragraph 1 which
1225 reads: </p>
1226
1227 <blockquote>
1228   <p>Get a reference to a facet of a locale. </p>
1229 </blockquote>
1230
1231 <p>with: </p>
1232
1233 <blockquote>
1234   <p>Requires: <tt>Facet</tt> is a facet class whose definition
1235   contains the public static member <tt>id</tt> as defined in 22.1.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.facet"> [lib.locale.facet]</a>. </p>
1236 </blockquote>
1237
1238 <p><i>[
1239 Kona: strike as overspecification the text "(not inherits)"
1240 from the original resolution, which read "... whose definition
1241 contains (not inherits) the public static member
1242 <tt>id</tt>..."
1243 ]</i></p>
1244
1245 <hr>
1246 <a name="39"><h3>39.&nbsp;istreambuf_iterator&lt;&gt;::operator++(int) definition garbled</h3></a><p><b>Section:</b>&nbsp;24.5.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator::op++"> [lib.istreambuf.iterator::op++]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1247 <p>Following the definition of istreambuf_iterator&lt;&gt;::operator++(int) in paragraph
1248 3, the standard contains three lines of garbage text left over from a previous edit. </p>
1249
1250 <blockquote>
1251   <pre>istreambuf_iterator&lt;charT,traits&gt; tmp = *this;
1252 sbuf_-&gt;sbumpc();
1253 return(tmp); </pre>
1254 </blockquote>
1255 <p><b>Proposed resolution:</b></p>
1256 <p>In 24.5.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator::op++"> [lib.istreambuf.iterator::op++]</a>, delete the three lines of code at the
1257 end of paragraph 3. </p>
1258 <hr>
1259 <a name="40"><h3>40.&nbsp;Meaningless normative paragraph in examples</h3></a><p><b>Section:</b>&nbsp;22.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1260 <p>Paragraph 3 of the locale examples is a description of part of an
1261 implementation technique that has lost its referent, and doesn't mean
1262 anything. </p>
1263 <p><b>Proposed resolution:</b></p>
1264 <p>Delete 22.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> paragraph 3 which begins "This
1265 initialization/identification system depends...", or (at the
1266 editor's option) replace it with a place-holder to keep the paragraph
1267 numbering the same. </p>
1268 <hr>
1269 <a name="41"><h3>41.&nbsp;Ios_base needs clear(), exceptions()</h3></a><p><b>Section:</b>&nbsp;27.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1270 <p>The description of ios_base::iword() and pword() in 27.4.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>, say that if they fail, they "set badbit,
1271 which may throw an exception". However, ios_base offers no
1272 interface to set or to test badbit; those interfaces are defined in
1273 basic_ios&lt;&gt;. </p>
1274 <p><b>Proposed resolution:</b></p>
1275 <p>Change the description in 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> in
1276 paragraph 2, and also in paragraph 4, as follows. Replace</p>
1277
1278 <blockquote>
1279   <p>If the function fails it sets badbit, which may throw an exception.</p>
1280 </blockquote>
1281
1282 <p>with</p>
1283
1284 <blockquote>
1285   <p>If the function fails, and <tt>*this</tt> is a base sub-object of
1286   a <tt>basic_ios&lt;&gt;</tt> object or sub-object, the effect is
1287   equivalent to calling <tt>basic_ios&lt;&gt;::setstate(badbit)</tt>
1288   on the derived object (which may throw <tt>failure</tt>).</p>
1289 </blockquote>
1290
1291 <p><i>[Kona: LWG reviewed wording; setstate(failbit) changed to
1292 setstate(badbit).]</i></p>
1293
1294 <hr>
1295 <a name="42"><h3>42.&nbsp;String ctors specify wrong default allocator</h3></a><p><b>Section:</b>&nbsp;21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1296 <p>The basic_string&lt;&gt; copy constructor: </p>
1297
1298 <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
1299              size_type n = npos, const Allocator&amp; a = Allocator()); </pre>
1300
1301 <p>specifies an Allocator argument default value that is
1302 counter-intuitive. The natural choice for a the allocator to copy from
1303 is str.get_allocator(). Though this cannot be expressed in
1304 default-argument notation, overloading suffices. </p>
1305
1306 <p>Alternatively, the other containers in Clause 23 (deque, list,
1307 vector) do not have this form of constructor, so it is inconsistent,
1308 and an evident source of confusion, for basic_string&lt;&gt; to have
1309 it, so it might better be removed. </p>
1310 <p><b>Proposed resolution:</b></p>
1311 <p> In 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>, replace the declaration of the copy
1312 constructor as follows: </p>
1313
1314 <blockquote>
1315   <pre>basic_string(const basic_string&amp; str);
1316 basic_string(const basic_string&amp; str, size_type pos, size_type n = npos,
1317              const Allocator&amp; a = Allocator());</pre>
1318 </blockquote>
1319
1320 <p>In 21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, replace the copy constructor declaration
1321 as above. Add to paragraph 5, Effects:</p>
1322
1323 <blockquote>
1324   <p>In the first form, the Allocator value used is copied from
1325   <tt>str.get_allocator()</tt>.</p>
1326 </blockquote>
1327 <p><b>Rationale:</b></p>
1328 <p>The LWG believes the constructor is actually broken, rather than
1329 just an unfortunate design choice.</p>
1330
1331 <p>The LWG considered two other possible resolutions:</p>
1332
1333 <p>A. In 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>, replace the declaration of the copy
1334 constructor as follows:</p>
1335
1336 <blockquote>
1337   <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
1338              size_type n = npos);
1339 basic_string(const basic_string&amp; str, size_type pos,
1340              size_type n, const Allocator&amp; a); </pre>
1341 </blockquote>
1342
1343 <p>In 21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, replace the copy constructor declaration
1344 as above. Add to paragraph 5, Effects: </p>
1345
1346 <blockquote>
1347   <p>When no <tt>Allocator</tt> argument is provided, the string is constructed using the
1348   value <tt>str.get_allocator()</tt>. </p>
1349 </blockquote>
1350
1351 <p>B. In 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>, and also in 21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, replace
1352 the declaration of the copy constructor as follows: </p>
1353
1354 <blockquote>
1355   <pre>basic_string(const basic_string&amp; str, size_type pos = 0,
1356              size_type n = npos); </pre>
1357 </blockquote>
1358
1359 <p>The proposed resolution reflects the original intent of the LWG. It
1360 was also noted by Pete Becker that this fix "will cause
1361 a small amount of existing code to now work correctly."</p>
1362
1363 <p><i>[
1364 Kona: issue editing snafu fixed - the proposed resolution now correctly
1365 reflects the LWG consensus.
1366 ]</i></p>
1367 <hr>
1368 <a name="44"><h3>44.&nbsp;Iostreams use operator== on int_type values</h3></a><p><b>Section:</b>&nbsp;27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
1369 <p>Many of the specifications for iostreams specify that character
1370 values or their int_type equivalents are compared using operators ==
1371 or !=, though in other places traits::eq() or traits::eq_int_type is
1372 specified to be used throughout. This is an inconsistency; we should
1373 change uses of == and != to use the traits members instead. </p>
1374 <p><b>Proposed resolution:</b></p>
1375
1376 <p><i>[Pre-Kona: Dietmar supplied wording]</i></p>
1377
1378 <p>List of changes to clause 27:</p>
1379 <ol>
1380 <li>
1381    In lib.basic.ios.members paragraph 13 (postcondition clause for
1382    'fill(cT)') change
1383
1384 <blockquote>
1385      fillch == fill()
1386 </blockquote>
1387
1388    to
1389
1390 <blockquote>
1391      traits::eq(fillch, fill())
1392 </blockquote>
1393
1394
1395 </li>
1396 <li>
1397    In lib.istream.unformatted paragraph 7 (effects clause for
1398    'get(cT,streamsize,cT)'), third bullet, change
1399
1400 <blockquote>
1401      c == delim for the next available input character c
1402 </blockquote>
1403
1404    to
1405
1406 <blockquote>
1407      traits::eq(c, delim) for the next available input character c
1408   </blockquote>
1409
1410 </li>
1411 <li>
1412    In lib.istream.unformatted paragraph 12 (effects clause for
1413    'get(basic_streambuf&lt;cT,Tr&gt;&amp;,cT)'), third bullet, change
1414
1415 <blockquote>
1416      c == delim for the next available input character c
1417 </blockquote>
1418
1419    to
1420
1421 <blockquote>
1422      traits::eq(c, delim) for the next available input character c
1423 </blockquote>
1424
1425 </li>
1426 <li>
1427    In lib.istream.unformatted paragraph 17 (effects clause for
1428    'getline(cT,streamsize,cT)'), second bullet, change
1429
1430 <blockquote>
1431      c == delim for the next available input character c
1432 </blockquote>
1433
1434    to
1435
1436 <blockquote>
1437      traits::eq(c, delim) for the next available input character c
1438   </blockquote>
1439
1440 </li>
1441 <li>
1442    In lib.istream.unformatted paragraph 24 (effects clause for
1443    'ignore(int,int_type)'), second bullet, change
1444
1445 <blockquote>
1446      c == delim for the next available input character c
1447 </blockquote>
1448
1449    to
1450
1451 <blockquote>
1452      traits::eq_int_type(c, delim) for the next available input
1453      character c
1454 </blockquote>
1455
1456 </li>
1457 <li>
1458    In lib.istream.unformatted paragraph 25 (notes clause for
1459    'ignore(int,int_type)'), second bullet, change
1460
1461 <blockquote>
1462      The last condition will never occur if delim == traits::eof()
1463 </blockquote>
1464
1465    to
1466
1467 <blockquote>
1468      The last condition will never occur if
1469      traits::eq_int_type(delim, traits::eof()).
1470 </blockquote>
1471
1472 </li>
1473 <li>
1474    In lib.istream.sentry paragraph 6 (example implementation for the
1475    sentry constructor) change
1476
1477 <blockquote>
1478      while ((c = is.rdbuf()-&gt;snextc()) != traits::eof()) {
1479 </blockquote>
1480
1481    to
1482
1483 <blockquote>
1484      while (!traits::eq_int_type(c = is.rdbuf()-&gt;snextc(), traits::eof())) {
1485 </blockquote>
1486
1487 </li>
1488 </ol>
1489
1490 <p>List of changes to Chapter 21:</p>
1491
1492 <ol>
1493 <li>
1494    In lib.string::find paragraph 1 (effects clause for find()),
1495    second bullet, change
1496
1497 <blockquote>
1498      at(xpos+I) == str.at(I) for all elements ...
1499 </blockquote>
1500
1501    to
1502
1503 <blockquote>
1504      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1505 </blockquote>
1506
1507 </li>
1508 <li>
1509    In lib.string::rfind paragraph 1 (effects clause for rfind()),
1510    second bullet, change
1511
1512 <blockquote>
1513      at(xpos+I) == str.at(I) for all elements ...
1514 </blockquote>
1515
1516    to
1517
1518 <blockquote>
1519      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1520 </blockquote>
1521
1522 </li>
1523 <li>
1524    In lib.string::find.first.of paragraph 1 (effects clause for
1525    find_first_of()), second bullet, change
1526
1527 <blockquote>
1528      at(xpos+I) == str.at(I) for all elements ...
1529 </blockquote>
1530
1531    to
1532
1533 <blockquote>
1534      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1535 </blockquote>
1536
1537 </li>
1538 <li>
1539    In lib.string::find.last.of paragraph 1 (effects clause for
1540    find_last_of()), second bullet, change
1541
1542 <blockquote>
1543      at(xpos+I) == str.at(I) for all elements ...
1544 </blockquote>
1545
1546    to
1547
1548 <blockquote>
1549      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1550 </blockquote>
1551
1552 </li>
1553 <li>
1554    In lib.string::find.first.not.of paragraph 1 (effects clause for
1555    find_first_not_of()), second bullet, change
1556
1557 <blockquote>
1558      at(xpos+I) == str.at(I) for all elements ...
1559 </blockquote>
1560
1561    to
1562
1563 <blockquote>
1564      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1565 </blockquote>
1566 </li>
1567
1568 <li>
1569    In lib.string::find.last.not.of paragraph 1 (effects clause for
1570    find_last_not_of()), second bullet, change
1571
1572 <blockquote>
1573      at(xpos+I) == str.at(I) for all elements ...
1574 </blockquote>
1575
1576    to
1577
1578 <blockquote>
1579      traits::eq(at(xpos+I), str.at(I)) for all elements ...
1580 </blockquote>
1581 </li>
1582
1583 <li>
1584    In lib.string.ios paragraph 5 (effects clause for getline()),
1585    second bullet, change
1586
1587 <blockquote>
1588      c == delim for the next available input character c
1589 </blockquote>
1590
1591    to
1592
1593 <blockquote>
1594      traits::eq(c, delim) for the next available input character c
1595 </blockquote>
1596 </li>
1597
1598 </ol>
1599
1600 <p>Notes:</p>
1601 <ul>
1602 <li>
1603   Fixing this issue highlights another sloppyness in
1604   lib.istream.unformatted paragraph 24: this clause mentions a "character"
1605   which is then compared to an 'int_type' (see item 5. in the list
1606   below). It is not clear whether this requires explicit words and
1607   if so what these words are supposed to be. A similar issue exists,
1608   BTW, for operator*() of istreambuf_iterator which returns the result
1609   of sgetc() as a character type (see lib.istreambuf.iterator::op*
1610   paragraph 1), and for operator++() of istreambuf_iterator which
1611   passes the result of sbumpc() to a constructor taking a char_type
1612   (see lib.istreambuf.iterator::operator++ paragraph 3). Similarily, the
1613   assignment operator ostreambuf_iterator passes a char_type to a function
1614   taking an int_type (see lib.ostreambuf.iter.ops paragraph 1).
1615 </li>
1616 <li>
1617   It is inconsistent to use comparisons using the traits functions in
1618   Chapter 27 while not using them in Chapter 21, especially as some
1619   of the inconsistent uses actually involve streams (eg. getline() on
1620   streams). To avoid leaving this issue open still longer due to this
1621   inconsistency (it is open since 1998), a list of changes to Chapter
1622   21 is below.
1623 </li>
1624 <li>
1625   In Chapter 24 there are several places with statements like "the end
1626   of stream is reached (streambuf_type::sgetc() returns traits::eof())"
1627   (lib.istreambuf.iterator paragraph 1, lib.ostreambuf.iter.ops
1628   paragraph 5). It is unclear whether these should be clarified to use
1629   traits::eq_int_type() for detecting traits::eof().
1630 </li>
1631 </ul>
1632
1633 <hr>
1634 <a name="46"><h3>46.&nbsp;Minor Annex D errors</h3></a><p><b>Section:</b>&nbsp;D.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.str.strstreams"> [depr.str.strstreams]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Brendan Kehoe&nbsp; <b>Date:</b>&nbsp; 1 Jun 1998</p>
1635 <p>See lib-6522 and edit-814.</p>
1636 <p><b>Proposed resolution:</b></p>
1637 <p>Change D.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.strstreambuf"> [depr.strstreambuf]</a> (since streambuf is a typedef of
1638 basic_streambuf&lt;char&gt;) from:</p>
1639
1640 <pre>         virtual streambuf&lt;char&gt;* setbuf(char* s, streamsize n);</pre>
1641
1642 <p>to:</p>
1643
1644 <pre>         virtual streambuf* setbuf(char* s, streamsize n);</pre>
1645
1646 <p>In D.7.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.strstream"> [depr.strstream]</a> insert the semicolon now missing after
1647 int_type:</p>
1648
1649 <pre>     namespace std {
1650        class strstream
1651          : public basic_iostream&lt;char&gt; {
1652        public:
1653          // Types
1654          typedef char                                char_type;
1655          typedef typename char_traits&lt;char&gt;::int_type int_type
1656          typedef typename char_traits&lt;char&gt;::pos_type pos_type;</pre>
1657 <hr>
1658 <a name="47"><h3>47.&nbsp;Imbue() and getloc() Returns clauses swapped</h3></a><p><b>Section:</b>&nbsp;27.4.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;21 Jun 1998</p>
1659 <p>Section 27.4.2.3 specifies how imbue() and getloc() work. That
1660 section has two RETURNS clauses, and they make no sense as
1661 stated. They make perfect sense, though, if you swap them. Am I
1662 correct in thinking that paragraphs 2 and 4 just got mixed up by
1663 accident?</p>
1664 <p><b>Proposed resolution:</b></p>
1665 <p>In 27.4.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> swap paragraphs 2 and 4.</p>
1666 <hr>
1667 <a name="48"><h3>48.&nbsp;Use of non-existent exception constructor</h3></a><p><b>Section:</b>&nbsp;27.4.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;21 Jun 1998</p>
1668 <p>27.4.2.1.1, paragraph 2, says that class failure initializes the
1669 base class, exception, with exception(msg). Class exception (see
1670 18.6.1) has no such constructor.</p>
1671 <p><b>Proposed resolution:</b></p>
1672 <p>Replace 27.4.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a>, paragraph 2, with</p>
1673
1674 <blockquote>
1675   <p>EFFECTS: Constructs an object of class <tt>failure</tt>.</p>
1676 </blockquote>
1677 <hr>
1678 <a name="49"><h3>49.&nbsp;Underspecification of ios_base::sync_with_stdio</h3></a><p><b>Section:</b>&nbsp;27.4.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;21 Jun 1998</p>
1679 <p>Two problems</p>
1680
1681 <p>(1) 27.4.2.4 doesn't say what ios_base::sync_with_stdio(f)
1682 returns. Does it return f, or does it return the previous
1683 synchronization state? My guess is the latter, but the standard
1684 doesn't say so.</p>
1685
1686 <p>(2) 27.4.2.4 doesn't say what it means for streams to be
1687 synchronized with stdio.  Again, of course, I can make some
1688 guesses. (And I'm unhappy about the performance implications of those
1689 guesses, but that's another matter.)</p>
1690 <p><b>Proposed resolution:</b></p>
1691 <p>Change the following sentence in 27.4.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>
1692 returns clause from:</p>
1693
1694 <blockquote>
1695   <p><tt>true</tt> if the standard iostream objects (27.3) are
1696   synchronized and otherwise returns <tt>false</tt>.</p>
1697 </blockquote>
1698
1699 <p>to:</p>
1700
1701 <blockquote>
1702   <p><tt>true</tt> if the previous state of the standard iostream
1703   objects (27.3) was synchronized and otherwise returns
1704   <tt>false</tt>.</p>
1705 </blockquote>
1706
1707 <p>Add the following immediately after 27.4.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.members.static"> [lib.ios.members.static]</a>,
1708 paragraph 2:</p>
1709
1710 <blockquote>
1711 <p>When a standard iostream object str is <i>synchronized</i> with a
1712 standard stdio stream f, the effect of inserting a character c by</p>
1713 <pre>  fputc(f, c);
1714 </pre>
1715
1716 <p>is the same as the effect of</p>
1717 <pre>  str.rdbuf()-&gt;sputc(c);
1718 </pre>
1719
1720 <p>for any sequence of characters; the effect of extracting a
1721 character c by</p>
1722 <pre>  c = fgetc(f);
1723 </pre>
1724
1725 <p>is the same as the effect of:</p>
1726 <pre>  c = str.rdbuf()-&gt;sbumpc(c);
1727 </pre>
1728
1729 <p>for any sequences of characters; and the effect of pushing
1730 back a character c by</p>
1731 <pre>  ungetc(c, f);
1732 </pre>
1733
1734 <p>is the same as the effect of</p>
1735 <pre>  str.rdbuf()-&gt;sputbackc(c);
1736 </pre>
1737
1738 <p>for any sequence of characters.  [<i>Footnote</i>: This implies
1739 that operations on a standard iostream object can be mixed arbitrarily
1740 with operations on the corresponding stdio stream.  In practical
1741 terms, synchronization usually means that a standard iostream object
1742 and a standard stdio object share a buffer. <i>--End Footnote</i>]</p>
1743 </blockquote>
1744
1745 <p><i>[pre-Copenhagen: PJP and Matt contributed the definition
1746 of "synchronization"]</i></p>
1747
1748 <p><i>[post-Copenhagen: proposed resolution was revised slightly:
1749 text was added in the non-normative footnote to say that operations
1750 on the two streams can be mixed arbitrarily.]</i></p>
1751 <hr>
1752 <a name="50"><h3>50.&nbsp;Copy constructor and assignment operator of ios_base</h3></a><p><b>Section:</b>&nbsp;27.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;21 Jun 1998</p>
1753 <p>As written, ios_base has a copy constructor and an assignment
1754 operator. (Nothing in the standard says it doesn't have one, and all
1755 classes have copy constructors and assignment operators unless you
1756 take specific steps to avoid them.) However, nothing in 27.4.2 says
1757 what the copy constructor and assignment operator do. </p>
1758
1759 <p>My guess is that this was an oversight, that ios_base is, like
1760 basic_ios, not supposed to have a copy constructor or an assignment
1761 operator.</p>
1762
1763 <p>
1764 Jerry Schwarz comments: Yes, its an oversight, but in the opposite
1765 sense to what you're suggesting. At one point there was a definite
1766 intention that you could copy ios_base. It's an easy way to save the
1767 entire state of a stream for future use. As you note, to carry out
1768 that intention would have required a explicit description of the
1769 semantics (e.g. what happens to the iarray and parray stuff).
1770 </p>
1771 <p><b>Proposed resolution:</b></p>
1772 <p>In 27.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a>, class ios_base, specify the copy
1773 constructor and operator= members as being private.</p>
1774 <p><b>Rationale:</b></p>
1775 <p>The LWG believes the difficulty of specifying correct semantics
1776 outweighs any benefit of allowing ios_base objects to be copyable.</p>
1777 <hr>
1778 <a name="51"><h3>51.&nbsp;Requirement to not invalidate iterators missing</h3></a><p><b>Section:</b>&nbsp;23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;David Vandevoorde&nbsp; <b>Date:</b>&nbsp;23 Jun 1998</p>
1779 <p>The std::sort algorithm can in general only sort a given sequence
1780 by moving around values. The list&lt;&gt;::sort() member on the other
1781 hand could move around values or just update internal pointers. Either
1782 method can leave iterators into the list&lt;&gt; dereferencable, but
1783 they would point to different things. </p>
1784
1785 <p>Does the FDIS mandate anywhere which method should be used for
1786 list&lt;&gt;::sort()?</p>
1787
1788 <p>Matt Austern comments:</p>
1789
1790 <p>I think you've found an omission in the standard. </p>
1791
1792 <p>The library working group discussed this point, and there was
1793 supposed to be a general requirement saying that list, set, map,
1794 multiset, and multimap may not invalidate iterators, or change the
1795 values that iterators point to, except when an operation does it
1796 explicitly. So, for example, insert() doesn't invalidate any iterators
1797 and erase() and remove() only invalidate iterators pointing to the
1798 elements that are being erased. </p>
1799
1800 <p>I looked for that general requirement in the FDIS, and, while I
1801 found a limited form of it for the sorted associative containers, I
1802 didn't find it for list. It looks like it just got omitted. </p>
1803
1804 <p>The intention, though, is that list&lt;&gt;::sort does not
1805 invalidate any iterators and does not change the values that any
1806 iterator points to. There would be no reason to have the member
1807 function otherwise.</p>
1808 <p><b>Proposed resolution:</b></p>
1809 <p>Add a new paragraph at the end of 23.1:</p>
1810
1811 <blockquote>
1812   <p>Unless otherwise specified (either explicitly or by defining a function in terms of
1813   other functions), invoking a container member function or passing a container as an
1814   argument to a library function shall not invalidate iterators to, or change the values of,
1815   objects within that container. </p>
1816 </blockquote>
1817 <p><b>Rationale:</b></p>
1818 <p>This was US issue CD2-23-011; it was accepted in London but the
1819 change was not made due to an editing oversight. The wording in the
1820 proposed resolution below is somewhat updated from CD2-23-011,
1821 particularly the addition of the phrase "or change the values
1822 of"</p>
1823 <hr>
1824 <a name="52"><h3>52.&nbsp;Small I/O problems</h3></a><p><b>Section:</b>&nbsp;27.4.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos.operations"> [lib.fpos.operations]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;23 Jun 1998</p>
1825 <p>First, 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>, table 89. This is pretty obvious:
1826 it should be titled "basic_ios&lt;&gt;() effects", not
1827 "ios_base() effects". </p>
1828
1829 <p>[The second item is a duplicate; see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#6">6</a> for
1830 resolution.]</p>
1831
1832 <p>Second, 27.4.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos.operations"> [lib.fpos.operations]</a> table 88 . There are a couple
1833 different things wrong with it, some of which I've already discussed
1834 with Jerry, but the most obvious mechanical sort of error is that it
1835 uses expressions like P(i) and p(i), without ever defining what sort
1836 of thing "i" is.
1837 </p>
1838
1839 <p>(The other problem is that it requires support for streampos
1840 arithmetic. This is impossible on some systems, i.e. ones where file
1841 position is a complicated structure rather than just a number. Jerry
1842 tells me that the intention was to require syntactic support for
1843 streampos arithmetic, but that it wasn't actually supposed to do
1844 anything meaningful except on platforms, like Unix, where genuine
1845 arithmetic is possible.) </p>
1846 <p><b>Proposed resolution:</b></p>
1847 <p>Change 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> table 89 title from
1848 "ios_base() effects" to "basic_ios&lt;&gt;()
1849 effects". </p>
1850 <hr>
1851 <a name="53"><h3>53.&nbsp;Basic_ios destructor unspecified</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;23 Jun 1998</p>
1852 <p>There's nothing in 27.4.4 saying what basic_ios's destructor does.
1853 The important question is whether basic_ios::~basic_ios() destroys
1854 rdbuf().</p>
1855 <p><b>Proposed resolution:</b></p>
1856 <p>Add after 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> paragraph 2:</p>
1857
1858 <blockquote>
1859   <p><tt>virtual ~basic_ios();</tt></p>
1860   <p><b>Notes</b>: The destructor does not destroy <tt>rdbuf()</tt>.</p>
1861 </blockquote>
1862 <p><b>Rationale:</b></p>
1863 <p>The LWG reviewed the additional question of whether or not
1864 <tt>rdbuf(0)</tt> may set <tt>badbit</tt>.  The answer is
1865 clearly yes; it may be set via <tt>clear()</tt>.  See 27.4.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.basic.ios.members"> [lib.basic.ios.members]</a>, paragraph 6.  This issue was reviewed at length
1866 by the LWG, which removed from the original proposed resolution a
1867 footnote which incorrectly said "<tt>rdbuf(0)</tt> does not set
1868 <tt>badbit</tt>".</p>
1869 <hr>
1870 <a name="54"><h3>54.&nbsp;Basic_streambuf's destructor</h3></a><p><b>Section:</b>&nbsp;27.5.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.cons"> [lib.streambuf.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;25 Jun 1998</p>
1871 <p>The class synopsis for basic_streambuf shows a (virtual)
1872 destructor, but the standard doesn't say what that destructor does. My
1873 assumption is that it does nothing, but the standard should say so
1874 explicitly. </p>
1875 <p><b>Proposed resolution:</b></p>
1876 <p>Add after 27.5.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.cons"> [lib.streambuf.cons]</a> paragraph 2:</p>
1877
1878 <blockquote>
1879   <p><tt>virtual&nbsp; ~basic_streambuf();</tt></p>
1880   <p><b>Effects</b>: None.</p>
1881 </blockquote>
1882 <hr>
1883 <a name="55"><h3>55.&nbsp;Invalid stream position is undefined</h3></a><p><b>Section:</b>&nbsp;27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;26 Jun 1998</p>
1884 <p>Several member functions in clause 27 are defined in certain
1885 circumstances to return an "invalid stream position", a term
1886 that is defined nowhere in the standard. Two places (27.5.2.4.2,
1887 paragraph 4, and 27.8.1.4, paragraph 15) contain a cross-reference to
1888 a definition in _lib.iostreams.definitions_, a nonexistent
1889 section. </p>
1890
1891 <p>I suspect that the invalid stream position is just supposed to be
1892 pos_type(-1).  Probably best to say explicitly in (for example)
1893 27.5.2.4.2 that the return value is pos_type(-1), rather than to use
1894 the term "invalid stream position", define that term
1895 somewhere, and then put in a cross-reference. </p>
1896
1897 <p>The phrase "invalid stream position" appears ten times in
1898 the C++ Standard.  In seven places it refers to a return value, and it
1899 should be changed. In three places it refers to an argument, and it
1900 should not be changed. Here are the three places where "invalid
1901 stream position" should not be changed:</p>
1902
1903 <blockquote>
1904   <p>27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>, paragraph 14<br>
1905   27.8.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 14<br>
1906   D.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 17
1907   </p>
1908 </blockquote>
1909 <p><b>Proposed resolution:</b></p>
1910 <p>In 27.5.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a>, paragraph 4, change "Returns an
1911 object of class pos_type that stores an invalid stream position
1912 (_lib.iostreams.definitions_)" to "Returns
1913 <tt>pos_type(off_type(-1))</tt>".
1914 </p>
1915
1916 <p>In 27.5.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a>, paragraph 6, change "Returns
1917 an object of class pos_type that stores an invalid stream
1918 position" to "Returns <tt>pos_type(off_type(-1))</tt>".</p>
1919
1920 <p>In 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>, paragraph 13, change "the object
1921 stores an invalid stream position" to "the return value is
1922 <tt>pos_type(off_type(-1))</tt>". </p>
1923
1924 <p>In 27.8.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 13, change "returns an
1925 invalid stream position (27.4.3)" to "returns
1926 <tt>pos_type(off_type(-1))</tt>" </p>
1927
1928 <p>In 27.8.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 15, change "Otherwise
1929 returns an invalid stream position (_lib.iostreams.definitions_)"
1930 to "Otherwise returns <tt>pos_type(off_type(-1))</tt>"
1931 </p>
1932
1933 <p>In D.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 15, change "the object
1934 stores an invalid stream position" to "the return value is
1935 <tt>pos_type(off_type(-1))</tt>" </p>
1936
1937 <p>In D.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 18, change "the object
1938 stores an invalid stream position" to "the return value is
1939 <tt>pos_type(off_type(-1))</tt>"</p>
1940 <hr>
1941 <a name="56"><h3>56.&nbsp;Showmanyc's return type</h3></a><p><b>Section:</b>&nbsp;27.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;29 Jun 1998</p>
1942 <p>The class summary for basic_streambuf&lt;&gt;, in 27.5.2, says that
1943 showmanyc has return type int. However, 27.5.2.4.3 says that its
1944 return type is streamsize. </p>
1945 <p><b>Proposed resolution:</b></p>
1946 <p>Change <tt>showmanyc</tt>'s return type in the
1947 27.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> class summary to <tt>streamsize</tt>.</p>
1948 <hr>
1949 <a name="57"><h3>57.&nbsp;Mistake in char_traits</h3></a><p><b>Section:</b>&nbsp;21.1.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits.specializations.wchar.t"> [lib.char.traits.specializations.wchar.t]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;1 Jul 1998</p>
1950 <p>21.1.3.2, paragraph 3, says "The types streampos and
1951 wstreampos may be different if the implementation supports no shift
1952 encoding in narrow-oriented iostreams but supports one or more shift
1953 encodings in wide-oriented streams". </p>
1954
1955 <p>That's wrong: the two are the same type. The &lt;iosfwd&gt; summary
1956 in 27.2 says that streampos and wstreampos are, respectively, synonyms
1957 for fpos&lt;char_traits&lt;char&gt;::state_type&gt; and
1958 fpos&lt;char_traits&lt;wchar_t&gt;::state_type&gt;, and, flipping back
1959 to clause 21, we see in 21.1.3.1 and 21.1.3.2 that
1960 char_traits&lt;char&gt;::state_type and
1961 char_traits&lt;wchar_t&gt;::state_type must both be mbstate_t. </p>
1962 <p><b>Proposed resolution:</b></p>
1963 <p>Remove the sentence in 21.1.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits.specializations.wchar.t"> [lib.char.traits.specializations.wchar.t]</a> paragraph 3 which
1964 begins "The types streampos and wstreampos may be
1965 different..." . </p>
1966 <hr>
1967 <a name="59"><h3>59.&nbsp;Ambiguity in specification of gbump</h3></a><p><b>Section:</b>&nbsp;27.5.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.get.area"> [lib.streambuf.get.area]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;28 Jul 1998</p>
1968 <p>27.5.2.3.1 says that basic_streambuf::gbump() "Advances the
1969 next pointer for the input sequence by n." </p>
1970
1971 <p>The straightforward interpretation is that it is just gptr() +=
1972 n. An alternative interpretation, though, is that it behaves as if it
1973 calls sbumpc n times. (The issue, of course, is whether it might ever
1974 call underflow.) There is a similar ambiguity in the case of
1975 pbump. </p>
1976
1977 <p>(The "classic" AT&amp;T implementation used the
1978 former interpretation.)</p>
1979 <p><b>Proposed resolution:</b></p>
1980 <p>Change 27.5.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.get.area"> [lib.streambuf.get.area]</a> paragraph 4 gbump effects from:</p>
1981
1982 <blockquote>
1983   <p>Effects: Advances the next pointer for the input sequence by n.</p>
1984 </blockquote>
1985
1986 <p>to:</p>
1987
1988 <blockquote>
1989   <p>Effects: Adds <tt>n</tt> to the next pointer for the input sequence.</p>
1990 </blockquote>
1991
1992 <p>Make the same change to 27.5.2.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.put.area"> [lib.streambuf.put.area]</a> paragraph 4 pbump
1993 effects.</p>
1994 <hr>
1995 <a name="60"><h3>60.&nbsp;What is a formatted input function?</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;3 Aug 1998</p>
1996 <p>Paragraph 1 of 27.6.1.2.1 contains general requirements for all
1997 formatted input functions. Some of the functions defined in section
1998 27.6.1.2 explicitly say that those requirements apply ("Behaves
1999 like a formatted input member (as described in 27.6.1.2.1)"), but
2000 others don't. The question: is 27.6.1.2.1 supposed to apply to
2001 everything in 27.6.1.2, or only to those member functions that
2002 explicitly say "behaves like a formatted input member"? Or
2003 to put it differently: are we to assume that everything that appears
2004 in a section called "Formatted input functions" really is a
2005 formatted input function? I assume that 27.6.1.2.1 is intended to
2006 apply to the arithmetic extractors (27.6.1.2.2), but I assume that it
2007 is not intended to apply to extractors like </p>
2008
2009 <pre>    basic_istream&amp; operator&gt;&gt;(basic_istream&amp; (*pf)(basic_istream&amp;));</pre>
2010
2011 <p>and </p>
2012
2013 <pre>    basic_istream&amp; operator&gt;&gt;(basic_streammbuf*);</pre>
2014
2015 <p>There is a similar ambiguity for unformatted input, formatted output, and unformatted
2016 output. </p>
2017
2018 <p>Comments from Judy Ward: It seems like the problem is that the
2019 basic_istream and basic_ostream operator &lt;&lt;()'s that are used
2020 for the manipulators and streambuf* are in the wrong section and
2021 should have their own separate section or be modified to make it clear
2022 that the "Common requirements" listed in section 27.6.1.2.1
2023 (for basic_istream) and section 27.6.2.5.1 (for basic_ostream) do not
2024 apply to them. </p>
2025
2026 <p>Additional comments from Dietmar Kühl: It appears to be somewhat
2027 nonsensical to consider the functions defined in 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> paragraphs 1 to 5 to be "Formatted input
2028 function" but since these functions are defined in a section
2029 labeled "Formatted input functions" it is unclear to me
2030 whether these operators are considered formatted input functions which
2031 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
2032 just <tt>ws</tt>, would skip whitespace unless <tt>noskipws</tt> is
2033 set (... but setting <tt>noskipws</tt> using the manipulator syntax
2034 would also skip whitespace :-)</p> <p>It is not clear which functions
2035 are to be considered unformatted input functions. As written, it seems
2036 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
2037 functions. However, it does not really make much sense to construct a
2038 sentry object for <tt>gcount()</tt>, <tt>sync()</tt>, ... Also it is
2039 unclear what happens to the <tt>gcount()</tt> if
2040 eg. <tt>gcount()</tt>, <tt>putback()</tt>, <tt>unget()</tt>, or
2041 <tt>sync()</tt> is called: These functions don't extract characters,
2042 some of them even "unextract" a character. Should this still
2043 be reflected in <tt>gcount()</tt>? Of course, it could be read as if
2044 after a call to <tt>gcount()</tt> <tt>gcount()</tt> return <tt>0</tt>
2045 (the last unformatted input function, <tt>gcount()</tt>, didn't
2046 extract any character) and after a call to <tt>putback()</tt>
2047 <tt>gcount()</tt> returns <tt>-1</tt> (the last unformatted input
2048 function <tt>putback()</tt> did "extract" back into the
2049 stream). Correspondingly for <tt>unget()</tt>. Is this what is
2050 intended?  If so, this should be clarified. Otherwise, a corresponding
2051 clarification should be used.</p>
2052 <p><b>Proposed resolution:</b></p>
2053 <p>
2054 In 27.6.1.2.2 [lib.istream.formatted.arithmetic], paragraph 1.
2055 Change the beginning of the second sentence from "The conversion
2056 occurs" to "These extractors behave as formatted input functions (as
2057 described in 27.6.1.2.1).  After a sentry object is constructed,
2058 the conversion occurs"
2059 </p>
2060
2061 <p>
2062 In 27.6.1.2.3, [lib.istream::extractors], before paragraph 1.
2063 Add an effects clause.  "Effects: None.  This extractor does
2064 not behave as a formatted input function (as described in
2065 27.6.1.2.1).
2066 </p>
2067
2068 <p>
2069 In 27.6.1.2.3, [lib.istream::extractors], paragraph 2.  Change the
2070 effects clause to "Effects: Calls pf(*this).  This extractor does not
2071 behave as a formatted input function (as described in 27.6.1.2.1).
2072 </p>
2073
2074 <p>
2075 In 27.6.1.2.3, [lib.istream::extractors], paragraph 4.  Change the
2076 effects clause to "Effects: Calls pf(*this).  This extractor does not
2077 behave as a formatted input function (as described in 27.6.1.2.1).
2078 </p>
2079
2080 <p>
2081 In 27.6.1.2.3, [lib.istream::extractors], paragraph 12.  Change the
2082 first two sentences from "If sb is null, calls setstate(failbit),
2083 which may throw ios_base::failure (27.4.4.3).  Extracts characters
2084 from *this..." to "Behaves as a formatted input function (as described
2085 in 27.6.1.2.1).  If sb is null, calls setstate(failbit), which may
2086 throw ios_base::failure (27.4.4.3).  After a sentry object is
2087 constructed, extracts characters from *this...".
2088 </p>
2089
2090 <p>
2091 In 27.6.1.3, [lib.istream.unformatted], before paragraph 2.  Add an
2092 effects clause.  "Effects: none. This member function does not behave
2093 as an unformatted input function (as described in 27.6.1.3, paragraph 1)."
2094 </p>
2095
2096 <p>
2097 In 27.6.1.3, [lib.istream.unformatted], paragraph 3.  Change the
2098 beginning of the first sentence of the effects clause from "Extracts a
2099 character" to "Behaves as an unformatted input function (as described
2100 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts a
2101 character"
2102 </p>
2103
2104 <p>
2105 In 27.6.1.3, [lib.istream.unformatted], paragraph 5.  Change the
2106 beginning of the first sentence of the effects clause from "Extracts a
2107 character" to "Behaves as an unformatted input function (as described
2108 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts a
2109 character"
2110 </p>
2111
2112 <p>
2113 In 27.6.1.3, [lib.istream.unformatted], paragraph 7.  Change the
2114 beginning of the first sentence of the effects clause from "Extracts
2115 characters" to "Behaves as an unformatted input function (as described
2116 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2117 characters"
2118 </p>
2119
2120 <p>
2121 [No change needed in paragraph 10, because it refers to paragraph 7.]
2122 </p>
2123
2124 <p>
2125 In 27.6.1.3, [lib.istream.unformatted], paragraph 12.  Change the
2126 beginning of the first sentence of the effects clause from "Extracts
2127 characters" to "Behaves as an unformatted input function (as described
2128 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2129 characters"
2130 </p>
2131
2132 <p>
2133 [No change needed in paragraph 15.]
2134 </p>
2135
2136 <p>
2137 In 27.6.1.3, [lib.istream.unformatted], paragraph 17.  Change the
2138 beginning of the first sentence of the effects clause from "Extracts
2139 characters" to "Behaves as an unformatted input function (as described
2140 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2141 characters"
2142 </p>
2143
2144 <p>
2145 [No change needed in paragraph 23.]
2146 </p>
2147
2148 <p>
2149 In 27.6.1.3, [lib.istream.unformatted], paragraph 24.  Change the
2150 beginning of the first sentence of the effects clause from "Extracts
2151 characters" to "Behaves as an unformatted input function (as described
2152 in 27.6.1.3, paragraph 1).  After constructing a sentry object, extracts
2153 characters"
2154 </p>
2155
2156 <p>
2157 In 27.6.1.3, [lib.istream.unformatted], before paragraph 27.  Add an
2158 Effects clause: "Effects: Behaves as an unformatted input function (as
2159 described in 27.6.1.3, paragraph 1).  After constructing a sentry
2160 object, reads but does not extract the current input character."
2161 </p>
2162
2163 <p>
2164 In 27.6.1.3, [lib.istream.unformatted], paragraph 28.  Change the
2165 first sentence of the Effects clause from "If !good() calls" to
2166 Behaves as an unformatted input function (as described in 27.6.1.3,
2167 paragraph 1).  After constructing a sentry object, if !good() calls"
2168 </p>
2169
2170 <p>
2171 In 27.6.1.3, [lib.istream.unformatted], paragraph 30.  Change the
2172 first sentence of the Effects clause from "If !good() calls" to
2173 "Behaves as an unformatted input function (as described in 27.6.1.3,
2174 paragraph 1).  After constructing a sentry object, if !good() calls"
2175 </p>
2176
2177 <p>
2178 In 27.6.1.3, [lib.istream.unformatted], paragraph 32.  Change the
2179 first sentence of the Effects clause from "If !good() calls..." to
2180 "Behaves as an unformatted input function (as described in 27.6.1.3,
2181 paragraph 1).  After constructing a sentry object, if !good()
2182 calls..."  Add a new sentence to the end of the Effects clause:
2183 "[Note: this function extracts no characters, so the value returned
2184 by the next call to gcount() is 0.]"
2185 </p>
2186
2187 <p>
2188 In 27.6.1.3, [lib.istream.unformatted], paragraph 34.  Change the
2189 first sentence of the Effects clause from "If !good() calls" to
2190 "Behaves as an unformatted input function (as described in 27.6.1.3,
2191 paragraph 1).  After constructing a sentry object, if !good() calls".
2192 Add a new sentence to the end of the Effects clause: "[Note: this
2193 function extracts no characters, so the value returned by the next
2194 call to gcount() is 0.]"
2195 </p>
2196
2197 <p>
2198 In 27.6.1.3, [lib.istream.unformatted], paragraph 36.  Change the
2199 first sentence of the Effects clause from "If !rdbuf() is" to "Behaves
2200 as an unformatted input function (as described in 27.6.1.3, paragraph
2201 1), except that it does not count the number of characters extracted
2202 and does not affect the value returned by subsequent calls to
2203 gcount().  After constructing a sentry object, if rdbuf() is"
2204 </p>
2205
2206 <p>
2207 In 27.6.1.3, [lib.istream.unformatted], before paragraph 37.  Add an
2208 Effects clause: "Effects: Behaves as an unformatted input function (as
2209 described in 27.6.1.3, paragraph 1), except that it does not count the
2210 number of characters extracted and does not affect the value returned
2211 by subsequent calls to gcount()."  Change the first sentence of
2212 paragraph 37 from "if fail()" to "after constructing a sentry object,
2213 if fail()".
2214 </p>
2215
2216 <p>
2217 In 27.6.1.3, [lib.istream.unformatted], paragraph 38.  Change the
2218 first sentence of the Effects clause from "If fail()" to "Behaves
2219 as an unformatted input function (as described in 27.6.1.3, paragraph
2220 1), except that it does not count the number of characters extracted
2221 and does not affect the value returned by subsequent calls to
2222 gcount().  After constructing a sentry object, if fail()
2223 </p>
2224
2225 <p>
2226 In 27.6.1.3, [lib.istream.unformatted], paragraph 40.  Change the
2227 first sentence of the Effects clause from "If fail()" to "Behaves
2228 as an unformatted input function (as described in 27.6.1.3, paragraph
2229 1), except that it does not count the number of characters extracted
2230 and does not affect the value returned by subsequent calls to
2231 gcount().  After constructing a sentry object, if fail()
2232 </p>
2233
2234 <p>
2235 In 27.6.2.5.2 [lib.ostream.inserters.arithmetic], paragraph 1.  Change
2236 the beginning of the third sentence from "The formatting conversion"
2237 to "These extractors behave as formatted output functions (as
2238 described in 27.6.2.5.1).  After the sentry object is constructed, the
2239 conversion occurs".
2240 </p>
2241
2242 <p>
2243 In 27.6.2.5.3 [lib.ostream.inserters], before paragraph 1.  Add an
2244 effects clause: "Effects: None. Does not behave as a formatted output
2245 function (as described in 27.6.2.5.1).".
2246 </p>
2247
2248 <p>
2249 In 27.6.2.5.3 [lib.ostream.inserters], paragraph 2.  Change the
2250 effects clause to "Effects: calls pf(*this).  This extractor does not
2251 behave as a formatted output function (as described in 27.6.2.5.1).".
2252 </p>
2253
2254 <p>
2255 In 27.6.2.5.3 [lib.ostream.inserters], paragraph 4.  Change the
2256 effects clause to "Effects: calls pf(*this).  This extractor does not
2257 behave as a formatted output function (as described in 27.6.2.5.1).".
2258 </p>
2259
2260 <p>
2261 In 27.6.2.5.3 [lib.ostream.inserters], paragraph 6.  Change the first
2262 sentence from "If sb" to "Behaves as a formatted output function (as
2263 described in 27.6.2.5.1).  After the sentry object is constructed, if
2264 sb".
2265 </p>
2266
2267 <p>
2268 In 27.6.2.6 [lib.ostream.unformatted], paragraph 2.  Change the first
2269 sentence from "Inserts the character" to "Behaves as an unformatted
2270 output function (as described in 27.6.2.6, paragraph 1).  After
2271 constructing a sentry object, inserts the character".
2272 </p>
2273
2274 <p>
2275 In 27.6.2.6 [lib.ostream.unformatted], paragraph 5.  Change the first
2276 sentence from "Obtains characters" to "Behaves as an unformatted
2277 output function (as described in 27.6.2.6, paragraph 1).  After
2278 constructing a sentry object, obtains characters".
2279 </p>
2280
2281 <p>
2282 In 27.6.2.6 [lib.ostream.unformatted], paragraph 7.  Add a new
2283 sentence at the end of the paragraph: "Does not behave as an
2284 unformatted output function (as described in 27.6.2.6, paragraph 1)."
2285 </p>
2286 <p><b>Rationale:</b></p>
2287 <p>See J16/99-0043==WG21/N1219, Proposed Resolution to Library Issue 60,
2288 by Judy Ward and Matt Austern.  This proposed resolution is section
2289 VI of that paper.</p>
2290 <hr>
2291 <a name="61"><h3>61.&nbsp;Ambiguity in iostreams exception policy</h3></a><p><b>Section:</b>&nbsp;27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
2292 <p>The introduction to the section on unformatted input (27.6.1.3)
2293 says that every unformatted input function catches all exceptions that
2294 were thrown during input, sets badbit, and then conditionally rethrows
2295 the exception. That seems clear enough. Several of the specific
2296 functions, however, such as get() and read(), are documented in some
2297 circumstances as setting eofbit and/or failbit. (The standard notes,
2298 correctly, that setting eofbit or failbit can sometimes result in an
2299 exception being thrown.) The question: if one of these functions
2300 throws an exception triggered by setting failbit, is this an exception
2301 "thrown during input" and hence covered by 27.6.1.3, or does
2302 27.6.1.3 only refer to a limited class of exceptions? Just to make
2303 this concrete, suppose you have the following snippet. </p>
2304
2305 <pre>
2306   char buffer[N];
2307   istream is;
2308   ...
2309   is.exceptions(istream::failbit); // Throw on failbit but not on badbit.
2310   is.read(buffer, N);</pre>
2311
2312 <p>Now suppose we reach EOF before we've read N characters. What
2313 iostate bits can we expect to be set, and what exception (if any) will
2314 be thrown? </p>
2315 <p><b>Proposed resolution:</b></p>
2316 <p>
2317 In 27.6.1.3, paragraph 1, after the sentence that begins
2318 "If an exception is thrown...", add the following
2319 parenthetical comment: "(Exceptions thrown from
2320 <tt>basic_ios&lt;&gt;::clear()</tt> are not caught or rethrown.)"
2321 </p>
2322 <p><b>Rationale:</b></p>
2323 <p>The LWG looked to two alternative wordings, and choose the proposed
2324 resolution as better standardese.</p>
2325 <hr>
2326 <a name="62"><h3>62.&nbsp;<tt>Sync</tt>'s return value</h3></a><p><b>Section:</b>&nbsp;27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;6 Aug 1998</p>
2327 <p>The Effects clause for sync() (27.6.1.3, paragraph 36) says that it
2328 "calls rdbuf()-&gt;pubsync() and, if that function returns -1
2329 ... returns traits::eof()." </p>
2330
2331 <p>That looks suspicious, because traits::eof() is of type
2332 traits::int_type while the return type of sync() is int. </p>
2333 <p><b>Proposed resolution:</b></p>
2334 <p>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>, paragraph 36, change "returns
2335 <tt>traits::eof()</tt>" to "returns <tt>-1</tt>".
2336 </p>
2337 <hr>
2338 <a name="63"><h3>63.&nbsp;Exception-handling policy for unformatted output</h3></a><p><b>Section:</b>&nbsp;27.6.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;11 Aug 1998</p>
2339 <p>Clause 27 details an exception-handling policy for formatted input,
2340 unformatted input, and formatted output. It says nothing for
2341 unformatted output (27.6.2.6). 27.6.2.6 should either include the same
2342 kind of exception-handling policy as in the other three places, or
2343 else it should have a footnote saying that the omission is
2344 deliberate. </p>
2345 <p><b>Proposed resolution:</b></p>
2346 <p>
2347 In 27.6.2.6, paragraph 1, replace the last sentence ("In any
2348 case, the unformatted output function ends by destroying the sentry
2349 object, then returning the value specified for the formatted output
2350 function.") with the following text:
2351 </p>
2352 <blockquote>
2353 If an exception is thrown during output, then <tt>ios::badbit</tt> is
2354 turned on [Footnote: without causing an <tt>ios::failure</tt> to be
2355 thrown.] in <tt>*this</tt>'s error state. If <tt>(exceptions() &amp;
2356 badbit) != 0</tt> then the exception is rethrown.  In any case, the
2357 unformatted output function ends by destroying the sentry object,
2358 then, if no exception was thrown, returning the value specified for
2359 the formatted output function.
2360 </blockquote>
2361 <p><b>Rationale:</b></p>
2362 <p>
2363 This exception-handling policy is consistent with that of formatted
2364 input, unformatted input, and formatted output.
2365 </p>
2366 <hr>
2367 <a name="64"><h3>64.&nbsp;Exception handling in <tt>basic_istream::operator&gt;&gt;(basic_streambuf*)</tt>
2368 </h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;11 Aug 1998 </p>
2369 <p>27.6.1.2.3, paragraph 13, is ambiguous. It can be interpreted two
2370 different ways, depending on whether the second sentence is read as an
2371 elaboration of the first. </p>
2372 <p><b>Proposed resolution:</b></p>
2373 <p>Replace 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>, paragraph 13, which begins
2374 "If the function inserts no characters ..." with:</p>
2375
2376 <blockquote>
2377   <p>If the function inserts no characters, it calls
2378   <tt>setstate(failbit)</tt>, which may throw
2379   <tt>ios_base::failure</tt> (27.4.4.3). If it inserted no characters
2380   because it caught an exception thrown while extracting characters
2381   from <tt>sb</tt> and <tt>failbit</tt> is on in <tt>exceptions()</tt>
2382   (27.4.4.3), then the caught exception is rethrown. </p>
2383 </blockquote>
2384 <hr>
2385 <a name="66"><h3>66.&nbsp;Strstreambuf::setbuf</h3></a><p><b>Section:</b>&nbsp;D.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;18 Aug 1998</p>
2386 <p>D.7.1.3, paragraph 19, says that strstreambuf::setbuf
2387 "Performs an operation that is defined separately for each class
2388 derived from strstreambuf". This is obviously an incorrect
2389 cut-and-paste from basic_streambuf. There are no classes derived from
2390 strstreambuf. </p>
2391 <p><b>Proposed resolution:</b></p>
2392 <p>D.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.strstreambuf.virtuals"> [depr.strstreambuf.virtuals]</a>, paragraph 19, replace the setbuf effects
2393 clause which currently says "Performs an operation that is
2394 defined separately for each class derived from strstreambuf"
2395 with:</p>
2396
2397 <blockquote>
2398   <p><b>Effects</b>: implementation defined, except that
2399   <tt>setbuf(0,0)</tt> has no effect.</p>
2400 </blockquote>
2401 <hr>
2402 <a name="68"><h3>68.&nbsp;Extractors for char* should store null at end</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;14 Jul 1998</p>
2403 <p>Extractors for char* (27.6.1.2.3) do not store a null character
2404 after the extracted character sequence whereas the unformatted
2405 functions like get() do. Why is this?</p>
2406
2407 <p>Comment from Jerry Schwarz: There is apparently an editing
2408 glitch. You'll notice that the last item of the list of what stops
2409 extraction doesn't make any sense. It was supposed to be the line that
2410 said a null is stored.</p>
2411 <p><b>Proposed resolution:</b></p>
2412 <p>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>, paragraph 7, change the last list
2413 item from:</p>
2414
2415 <blockquote>
2416   A null byte (<tt>charT()</tt>) in the next position, which may be
2417   the first position if no characters were extracted.
2418 </blockquote>
2419
2420 <p>to become a new paragraph which reads:</p>
2421
2422 <blockquote>
2423   Operator&gt;&gt; then stores a null byte (<tt>charT()</tt>) in the
2424   next position, which may be the first position if no characters were
2425   extracted.
2426 </blockquote>
2427 <hr>
2428 <a name="69"><h3>69.&nbsp;Must elements of a vector be contiguous?</h3></a><p><b>Section:</b>&nbsp;23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.adaptors"> [lib.container.adaptors]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;29 Jul 1998</p>
2429 <p>The issue is this: Must the elements of a vector be in contiguous memory?</p>
2430
2431 <p>(Please note that this is entirely separate from the question of
2432 whether a vector iterator is required to be a pointer; the answer to
2433 that question is clearly "no," as it would rule out
2434 debugging implementations)</p>
2435 <p><b>Proposed resolution:</b></p>
2436 <p>Add the following text to the end of 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.adaptors"> [lib.container.adaptors]</a>,
2437 paragraph 1. </p>
2438
2439 <blockquote>
2440   <p>The elements of a vector are stored contiguously, meaning that if
2441   v is a <tt>vector&lt;T, Allocator&gt;</tt> where T is some type
2442   other than <tt>bool</tt>, then it obeys the identity <tt>&amp;v[n]
2443   == &amp;v[0] + n</tt> for all <tt>0 &lt;= n &lt; v.size()</tt>.</p>
2444 </blockquote>
2445 <p><b>Rationale:</b></p>
2446 <p>The LWG feels that as a practical matter the answer is clearly
2447 "yes".  There was considerable discussion as to the best way
2448 to express the concept of "contiguous", which is not
2449 directly defined in the standard.  Discussion included:</p>
2450
2451 <ul>
2452   <li>An operational definition similar to the above proposed resolution is
2453     already used for valarray (<font color="red">26.3.2.3</font>).</li>
2454   <li>There is no need to explicitly consider a user-defined operator&amp;
2455     because elements must be copyconstructible (23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> para 3)
2456     and copyconstructible (20.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.copyconstructible"> [lib.copyconstructible]</a>) specifies
2457     requirements for operator&amp;.</li>
2458   <li>There is no issue of one-past-the-end because of language rules.</li>
2459 </ul>
2460 <hr>
2461 <a name="70"><h3>70.&nbsp;Uncaught_exception() missing throw() specification</h3></a><p><b>Section:</b>&nbsp;18.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.exception"> [lib.support.exception]</a>, 18.7.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.uncaught"> [lib.uncaught]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;Unknown</p>
2462 <p>In article 3E04@pratique.fr, Valentin Bonnard writes: </p>
2463
2464 <p>uncaught_exception() doesn't have a throw specification.</p>
2465
2466 <p>It is intentional ? Does it means that one should be prepared to
2467 handle exceptions thrown from uncaught_exception() ?</p>
2468
2469 <p>uncaught_exception() is called in exception handling contexts where
2470 exception safety is very important.</p>
2471 <p><b>Proposed resolution:</b></p>
2472 <p>In 15.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/except.html#except.uncaught"> [except.uncaught]</a>, paragraph 1, 18.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.exception"> [lib.support.exception]</a>, and 18.7.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.uncaught"> [lib.uncaught]</a>, add "throw()" to uncaught_exception().</p>
2473 <hr>
2474 <a name="71"><h3>71.&nbsp;Do_get_monthname synopsis missing argument</h3></a><p><b>Section:</b>&nbsp;22.2.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.get"> [lib.locale.time.get]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;13 Aug 1998</p>
2475 <p>The locale facet member <tt>time_get&lt;&gt;::do_get_monthname</tt>
2476 is described in 22.2.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.get.virtuals"> [lib.locale.time.get.virtuals]</a> with five arguments,
2477 consistent with do_get_weekday and with its specified use by member
2478 get_monthname. However, in the synopsis, it is specified instead with
2479 four arguments. The missing argument is the "end" iterator
2480 value.</p>
2481 <p><b>Proposed resolution:</b></p>
2482 <p>In 22.2.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.get"> [lib.locale.time.get]</a>, add an "end" argument to
2483 the declaration of member do_monthname as follows:</p>
2484
2485 <pre>  virtual iter_type do_get_monthname(iter_type s, iter_type end, ios_base&amp;,
2486                                      ios_base::iostate&amp; err, tm* t) const;</pre>
2487 <hr>
2488 <a name="74"><h3>74.&nbsp;Garbled text for <tt>codecvt::do_max_length</tt>
2489 </h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;8 Sep 1998</p>
2490 <p>The text of <tt>codecvt::do_max_length</tt>'s "Returns"
2491 clause (22.2.1.5.2, paragraph 11) is garbled. It has unbalanced
2492 parentheses and a spurious <b>n</b>.</p>
2493 <p><b>Proposed resolution:</b></p>
2494 <p>Replace <font color="red">22.2.1.5.2</font> paragraph 11 with the
2495 following:</p>
2496
2497 <blockquote>
2498   <b>Returns</b>: The maximum value that
2499   <tt>do_length(state, from, from_end, 1)</tt> can return for any
2500   valid range <tt>[from, from_end)</tt> and <tt>stateT</tt> value
2501   <tt>state</tt>. The specialization <tt>codecvt&lt;char, char,
2502   mbstate_t&gt;::do_max_length()</tt> returns 1.
2503 </blockquote>
2504 <hr>
2505 <a name="75"><h3>75.&nbsp;Contradiction in <tt>codecvt::length</tt>'s argument types</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp; Matt
2506 Austern&nbsp; <b>Date:</b>&nbsp; 18 Sep 1998</p>
2507 <p>The class synopses for classes <tt>codecvt&lt;&gt;</tt> (22.2.1.5)
2508 and <tt>codecvt_byname&lt;&gt;</tt> (22.2.1.6) say that the first
2509 parameter of the member functions <tt>length</tt> and
2510 <tt>do_length</tt> is of type <tt>const stateT&amp;</tt>. The member
2511 function descriptions, however (22.2.1.5.1, paragraph 6; 22.2.1.5.2,
2512 paragraph 9) say that the type is <tt>stateT&amp;</tt>.  Either the
2513 synopsis or the summary must be changed. </p>
2514
2515 <p>If (as I believe) the member function descriptions are correct,
2516 then we must also add text saying how <tt>do_length</tt> changes its
2517 <tt>stateT</tt> argument. </p>
2518 <p><b>Proposed resolution:</b></p>
2519 <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>, and also in <font color="red">22.2.1.6</font>,
2520 change the <tt>stateT</tt> argument type on both member
2521 <tt>length()</tt> and member <tt>do_length()</tt> from </p>
2522
2523 <blockquote>
2524   <p><tt>const stateT&amp;</tt></p>
2525 </blockquote>
2526
2527 <p>to</p>
2528
2529 <blockquote>
2530   <p><tt>stateT&amp;</tt></p>
2531 </blockquote>
2532
2533 <p>In <font color="red">22.2.1.5.2</font>, add to the definition for member
2534 <tt>do_length</tt> a paragraph:</p>
2535
2536 <blockquote>
2537   <p>Effects: The effect on the <tt>state</tt> argument is ``as if''
2538   it called <tt>do_in(state, from, from_end, from, to, to+max,
2539   to)</tt> for <tt>to</tt> pointing to a buffer of at least
2540   <tt>max</tt> elements.</p>
2541 </blockquote>
2542 <hr>
2543 <a name="76"><h3>76.&nbsp;Can a <tt>codecvt</tt> facet always convert one internal character at a time?</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;25 Sep 1998</p>
2544 <p>This issue concerns the requirements on classes derived from
2545 <tt>codecvt</tt>, including user-defined classes. What are the
2546 restrictions on the conversion from external characters
2547 (e.g. <tt>char</tt>) to internal characters (e.g. <tt>wchar_t</tt>)?
2548 Or, alternatively, what assumptions about <tt>codecvt</tt> facets can
2549 the I/O library make? </p>
2550
2551 <p>The question is whether it's possible to convert from internal
2552 characters to external characters one internal character at a time,
2553 and whether, given a valid sequence of external characters, it's
2554 possible to pick off internal characters one at a time. Or, to put it
2555 differently: given a sequence of external characters and the
2556 corresponding sequence of internal characters, does a position in the
2557 internal sequence correspond to some position in the external
2558 sequence? </p>
2559
2560 <p>To make this concrete, suppose that <tt>[first, last)</tt> is a
2561 sequence of <i>M</i> external characters and that <tt>[ifirst,
2562 ilast)</tt> is the corresponding sequence of <i>N</i> internal
2563 characters, where <i>N &gt; 1</i>. That is, <tt>my_encoding.in()</tt>,
2564 applied to <tt>[first, last)</tt>, yields <tt>[ifirst,
2565 ilast)</tt>. Now the question: does there necessarily exist a
2566 subsequence of external characters, <tt>[first, last_1)</tt>, such
2567 that the corresponding sequence of internal characters is the single
2568 character <tt>*ifirst</tt>?
2569 </p>
2570
2571 <p>(What a "no" answer would mean is that
2572 <tt>my_encoding</tt> translates sequences only as blocks. There's a
2573 sequence of <i>M</i> external characters that maps to a sequence of
2574 <i>N</i> internal characters, but that external sequence has no
2575 subsequence that maps to <i>N-1</i> internal characters.) </p>
2576
2577 <p>Some of the wording in the standard, such as the description of
2578 <tt>codecvt::do_max_length</tt> (<font color="red">22.2.1.5.2</font>,
2579 paragraph 11) and <tt>basic_filebuf::underflow</tt> (27.8.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>, paragraph 3) suggests that it must always be
2580 possible to pick off internal characters one at a time from a sequence
2581 of external characters. However, this is never explicitly stated one
2582 way or the other. </p>
2583
2584 <p>This issue seems (and is) quite technical, but it is important if
2585 we expect users to provide their own encoding facets. This is an area
2586 where the standard library calls user-supplied code, so a well-defined
2587 set of requirements for the user-supplied code is crucial. Users must
2588 be aware of the assumptions that the library makes. This issue affects
2589 positioning operations on <tt>basic_filebuf</tt>, unbuffered input,
2590 and several of <tt>codecvt</tt>'s member functions. </p>
2591 <p><b>Proposed resolution:</b></p>
2592 <p>Add the following text as a new paragraph, following <font color="red">22.2.1.5.2</font> paragraph 2:</p>
2593
2594 <blockquote>
2595 <p>A <tt>codecvt</tt> facet that is used by <tt>basic_filebuf</tt>
2596 (27.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a>) must have the property that if</p>
2597 <pre>    do_out(state, from, from_end, from_next, to, to_lim, to_next)
2598 </pre>
2599 would return <tt>ok</tt>, where <tt>from != from_end</tt>, then
2600 <pre>    do_out(state, from, from + 1, from_next, to, to_end, to_next)
2601 </pre>
2602 must also return <tt>ok</tt>, and that if
2603 <pre>    do_in(state, from, from_end, from_next, to, to_lim, to_next)
2604 </pre>
2605 would return <tt>ok</tt>, where <tt>to != to_lim</tt>, then
2606 <pre>    do_in(state, from, from_end, from_next, to, to + 1, to_next)
2607 </pre>
2608 <p>must also return <tt>ok</tt>.  [<i>Footnote:</i> Informally, this
2609 means that <tt>basic_filebuf</tt> assumes that the mapping from
2610 internal to external characters is 1 to N: a <tt>codecvt</tt> that is
2611 used by <tt>basic_filebuf</tt> must be able to translate characters
2612 one internal character at a time.  <i>--End Footnote</i>]</p>
2613 </blockquote>
2614
2615 <p><i>[Redmond: Minor change in proposed resolution.  Original
2616 proposed resolution talked about "success", with a parenthetical
2617 comment that success meant returning <tt>ok</tt>.  New wording
2618 removes all talk about "success", and just talks about the
2619 return value.]</i></p>
2620
2621 <p><b>Rationale:</b></p>
2622
2623   <p>The proposed resoluion says that conversions can be performed one
2624   internal character at a time.  This rules out some encodings that
2625   would otherwise be legal.  The alternative answer would mean there
2626   would be some internal positions that do not correspond to any
2627   external file position.</p>
2628   <p>
2629   An example of an encoding that this rules out is one where the
2630   <tt>internT</tt> and <tt>externT</tt> are of the same type, and
2631   where the internal sequence <tt>c1 c2</tt> corresponds to the
2632   external sequence <tt>c2 c1</tt>.
2633   </p>
2634   <p>It was generally agreed that <tt>basic_filebuf</tt> relies
2635   on this property: it was designed under the assumption that
2636   the external-to-internal mapping is N-to-1, and it is not clear
2637   that <tt>basic_filebuf</tt> is implementable without that
2638   restriction.
2639   </p>
2640   <p>
2641   The proposed resolution is expressed as a restriction on
2642   <tt>codecvt</tt> when used by <tt>basic_filebuf</tt>, rather
2643   than a blanket restriction on all <tt>codecvt</tt> facets,
2644   because <tt>basic_filebuf</tt> is the only other part of the
2645   library that uses <tt>codecvt</tt>.  If a user wants to define
2646   a <tt>codecvt</tt> facet that implements a more general N-to-M
2647   mapping, there is no reason to prohibit it, so long as the user
2648   does not expect <tt>basic_filebuf</tt> to be able to use it.
2649   </p>
2650 <hr>
2651 <a name="78"><h3>78.&nbsp;Typo: event_call_back</h3></a><p><b>Section:</b>&nbsp;27.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2652 <p>typo: event_call_back should be event_callback &nbsp; </p>
2653 <p><b>Proposed resolution:</b></p>
2654 <p>In the 27.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> synopsis change
2655 "event_call_back" to "event_callback". </p>
2656 <hr>
2657 <a name="79"><h3>79.&nbsp;Inconsistent declaration of polar()</h3></a><p><b>Section:</b>&nbsp;26.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2658 <p>In 26.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a> polar is declared as follows:</p>
2659 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp;, const T&amp;); </pre>
2660
2661 <p>In 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> it is declared as follows:</p>
2662 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = 0); </pre>
2663
2664 <p>Thus whether the second parameter is optional is not clear. </p>
2665 <p><b>Proposed resolution:</b></p>
2666 <p>In 26.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.synopsis"> [lib.complex.synopsis]</a> change:</p>
2667 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp;, const T&amp;);</pre>
2668
2669 <p>to:</p>
2670 <pre>   template&lt;class T&gt; complex&lt;T&gt; polar(const T&amp; rho, const T&amp; theta = 0); </pre>
2671 <hr>
2672 <a name="80"><h3>80.&nbsp;Global Operators of complex declared twice</h3></a><p><b>Section:</b>&nbsp;26.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.cfenv.syn"> [lib.cfenv.syn]</a>, 26.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.fenv"> [lib.fenv]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2673 <p>Both 26.2.1 and 26.2.2 contain declarations of global operators for
2674 class complex. This redundancy should be removed.</p>
2675 <p><b>Proposed resolution:</b></p>
2676 <p>Reduce redundancy according to the general style of the standard. </p>
2677 <hr>
2678 <a name="83"><h3>83.&nbsp;String::npos vs. string::max_size()</h3></a><p><b>Section:</b>&nbsp;21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2679 <p>Many string member functions throw if size is getting or exceeding
2680 npos. However, I wonder why they don't throw if size is getting or
2681 exceeding max_size() instead of npos.  May be npos is known at compile
2682 time, while max_size() is known at runtime. However, what happens if
2683 size exceeds max_size() but not npos, then? It seems the standard
2684 lacks some clarifications here.</p>
2685 <p><b>Proposed resolution:</b></p>
2686 <p>After 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> paragraph 4 ("The functions
2687 described in this clause...") add a new paragraph:</p>
2688
2689 <blockquote>
2690   <p>For any string operation, if as a result of the operation, <tt> size()</tt> would exceed
2691   <tt> max_size()</tt> then
2692   the operation throws <tt>length_error</tt>.</p>
2693 </blockquote>
2694 <p><b>Rationale:</b></p>
2695 <p>The LWG believes length_error is the correct exception to throw.</p>
2696 <hr>
2697 <a name="86"><h3>86.&nbsp;String constructors don't describe exceptions</h3></a><p><b>Section:</b>&nbsp;21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2698 <p>The constructor from a range:</p>
2699
2700 <pre>template&lt;class InputIterator&gt;
2701          basic_string(InputIterator begin, InputIterator end,
2702                       const Allocator&amp; a = Allocator());</pre>
2703
2704 <p>lacks a throws clause. However, I would expect that it throws
2705 according to the other constructors if the numbers of characters in
2706 the range equals npos (or exceeds max_size(), see above). </p>
2707 <p><b>Proposed resolution:</b></p>
2708 <p>In 21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a>, Strike throws paragraphs for
2709 constructors which say "Throws: length_error if n ==
2710 npos."</p>
2711 <p><b>Rationale:</b></p>
2712 <p>Throws clauses for length_error if n == npos are no longer needed
2713 because they are subsumed by the general wording added by the
2714 resolution for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#83">83</a>.</p>
2715 <hr>
2716 <a name="90"><h3>90.&nbsp;Incorrect description of operator &gt;&gt; for strings</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2717 <p>The effect of operator &gt;&gt; for strings contain the following item:</p>
2718
2719 <p>&nbsp;&nbsp;&nbsp; <tt>isspace(c,getloc())</tt> is true for the next available input
2720 character c.</p>
2721
2722 <p>Here <tt>getloc()</tt> has to be replaced by <tt>is.getloc()</tt>. </p>
2723 <p><b>Proposed resolution:</b></p>
2724 <p>In 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> paragraph 1 Effects clause replace:</p>
2725
2726 <blockquote>
2727   <p><tt>isspace(c,getloc())</tt> is true for the next available input character c.</p>
2728 </blockquote>
2729
2730 <p>with:</p>
2731
2732 <blockquote>
2733   <p><tt>isspace(c,is.getloc())</tt> is true for the next available input character c.</p>
2734 </blockquote>
2735 <hr>
2736 <a name="91"><h3>91.&nbsp;Description of operator&gt;&gt; and getline() for string&lt;&gt; might cause endless loop</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2737 <p>Operator &gt;&gt; and getline() for strings read until eof()
2738 in the input stream is true. However, this might never happen, if the
2739 stream can't read anymore without reaching EOF. So shouldn't it be
2740 changed into that it reads until !good() ? </p>
2741 <p><b>Proposed resolution:</b></p>
2742 <p>In 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>, paragraph 1, replace:</p>
2743 <blockquote>
2744 Effects: Begins by constructing a sentry object k as if k were
2745 constructed by typename basic_istream&lt;charT,traits&gt;::sentry k( is). If
2746 bool( k) is true, it calls str.erase() and then extracts characters
2747 from is and appends them to str as if by calling str.append(1, c). If
2748 is.width() is greater than zero, the maximum number n of characters
2749 appended is is.width(); otherwise n is str.max_size(). Characters are
2750 extracted and appended until any of the following occurs:
2751 </blockquote>
2752 <p>with:</p>
2753 <blockquote>
2754 Effects: Behaves as a formatted input function (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>).  After constructing a sentry object, if the
2755 sentry converts to true, calls str.erase() and then extracts
2756 characters from is and appends them to str as if by calling
2757 str.append(1,c). If is.width() is greater than zero, the maximum
2758 number n of characters appended is is.width(); otherwise n is
2759 str.max_size(). Characters are extracted and appended until any of the
2760 following occurs:
2761 </blockquote>
2762
2763 <p>In 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>, paragraph 6, replace</p>
2764 <blockquote>
2765 Effects: Begins by constructing a sentry object k as if by typename
2766 basic_istream&lt;charT,traits&gt;::sentry k( is, true). If bool( k) is true,
2767 it calls str.erase() and then extracts characters from is and appends
2768 them to str as if by calling str.append(1, c) until any of the
2769 following occurs:
2770 </blockquote>
2771 <p>with:</p>
2772 <blockquote>
2773 Effects: Behaves as an unformatted input function (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>), except that it does not affect the value returned
2774 by subsequent calls to basic_istream&lt;&gt;::gcount().  After
2775 constructing a sentry object, if the sentry converts to true, calls
2776 str.erase() and then extracts characters from is and appends them to
2777 str as if by calling str.append(1,c) until any of the following
2778 occurs:
2779 </blockquote>
2780
2781 <p><i>[Redmond: Made changes in proposed resolution.  <tt>operator&gt;&gt;</tt>
2782 should be a formatted input function, not an unformatted input function.
2783 <tt>getline</tt> should not be required to set <tt>gcount</tt>, since
2784 there is no mechanism for <tt>gcount</tt> to be set except by one of
2785 <tt>basic_istream</tt>'s member functions.]</i></p>
2786
2787 <p><i>[Curaçao: Nico agrees with proposed resolution.]</i></p>
2788
2789 <p><b>Rationale:</b></p>
2790 <p>The real issue here is whether or not these string input functions
2791 get their characters from a streambuf, rather than by calling an
2792 istream's member functions, a streambuf signals failure either by
2793 returning eof or by throwing an exception; there are no other
2794 possibilities.  The proposed resolution makes it clear that these two
2795 functions do get characters from a streambuf.</p>
2796 <hr>
2797 <a name="92"><h3>92.&nbsp;Incomplete Algorithm Requirements</h3></a><p><b>Section:</b>&nbsp;25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;29 Sep 1998</p>
2798 <p>The standard does not state, how often a function object is copied,
2799 called, or the order of calls inside an algorithm. This may lead to
2800 surprising/buggy behavior. Consider the following example: </p>
2801
2802 <pre>class Nth {    // function object that returns true for the nth element
2803   private:
2804     int nth;     // element to return true for
2805     int count;   // element counter
2806   public:
2807     Nth (int n) : nth(n), count(0) {
2808     }
2809     bool operator() (int) {
2810         return ++count == nth;
2811     }
2812 };
2813 ....
2814 // remove third element
2815     list&lt;int&gt;::iterator pos;
2816     pos = remove_if(coll.begin(),coll.end(),  // range
2817                     Nth(3)),                  // remove criterion
2818     coll.erase(pos,coll.end()); </pre>
2819
2820 <p>This call, in fact removes the 3rd <b>AND the 6th</b> element. This
2821 happens because the usual implementation of the algorithm copies the
2822 function object internally: </p>
2823
2824 <pre>template &lt;class ForwIter, class Predicate&gt;
2825 ForwIter std::remove_if(ForwIter beg, ForwIter end, Predicate op)
2826 {
2827     beg = find_if(beg, end, op);
2828     if (beg == end) {
2829         return beg;
2830     }
2831     else {
2832         ForwIter next = beg;
2833         return remove_copy_if(++next, end, beg, op);
2834     }
2835 } </pre>
2836
2837 <p>The algorithm uses find_if() to find the first element that should
2838 be removed. However, it then uses a copy of the passed function object
2839 to process the resulting elements (if any). Here, Nth is used again
2840 and removes also the sixth element. This behavior compromises the
2841 advantage of function objects being able to have a state. Without any
2842 cost it could be avoided (just implement it directly instead of
2843 calling find_if()). </p>
2844 <p><b>Proposed resolution:</b></p>
2845
2846 <p>Add a new paragraph following 25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> paragraph 8:</p>
2847 <blockquote>
2848 [Note: Unless otherwise specified, algorithms that take function
2849 objects as arguments are permitted to copy those function objects
2850 freely.  Programmers for whom object identity is important should
2851 consider using a wrapper class that points to a noncopied
2852 implementation object, or some equivalent solution.]
2853 </blockquote>
2854
2855 <p><i>[Dublin: Pete Becker felt that this may not be a defect,
2856 but rather something that programmers need to be educated about.
2857 There was discussion of adding wording to the effect that the number
2858 and order of calls to function objects, including predicates, not
2859 affect the behavior of the function object.]</i></p>
2860
2861 <p><i>[Pre-Kona: Nico comments: It seems the problem is that we don't
2862 have a clear statement of "predicate" in the
2863 standard. People including me seemed to think "a function
2864 returning a Boolean value and being able to be called by an STL
2865 algorithm or be used as sorting criterion or ... is a
2866 predicate". But a predicate has more requirements: It should
2867 never change its behavior due to a call or being copied. IMHO we have
2868 to state this in the standard. If you like, see section 8.1.4 of my
2869 library book for a detailed discussion.]</i></p>
2870
2871 <p><i>[Kona: Nico will provide wording to the effect that "unless
2872 otherwise specified, the number of copies of and calls to function
2873 objects by algorithms is unspecified".&nbsp; Consider placing in
2874 25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> after paragraph 9.]</i></p>
2875
2876 <p><i>[Santa Cruz: The standard doesn't currently guarantee that
2877   functions object won't be copied, and what isn't forbidden is
2878   allowed.  It is believed (especially since implementations that were
2879   written in concert with the standard do make copies of function
2880   objects) that this was intentional.  Thus, no normative change is
2881   needed.  What we should put in is a non-normative note suggesting to
2882   programmers that if they want to guarantee the lack of copying they
2883   should use something like the <tt>ref</tt> wrapper.]</i></p>
2884
2885 <p><i>[Oxford: Matt provided wording.]</i></p>
2886
2887
2888 <hr>
2889 <a name="98"><h3>98.&nbsp;Input iterator requirements are badly written</h3></a><p><b>Section:</b>&nbsp;24.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
2890 <p>Table 72 in 24.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a> specifies semantics for
2891 <tt>*r++</tt> of:</p>
2892
2893 <p>&nbsp;&nbsp; <tt>{ T tmp = *r; ++r; return tmp; }</tt></p>
2894
2895 <p>There are two problems with this.  First, the return type is
2896 specified to be "T", as opposed to something like "convertible to T".
2897 This is too specific: we want to allow *r++ to return an lvalue.</p>
2898
2899 <p>Second, writing the semantics in terms of code misleadingly
2900 suggests that the effects *r++ should precisely replicate the behavior
2901 of this code, including side effects.  (Does this mean that *r++
2902 should invoke the copy constructor exactly as many times as the sample
2903 code above would?) See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#334">334</a> for a similar
2904 problem.</p>
2905
2906 <p><b>Proposed resolution:</b></p>
2907 In Table 72 in 24.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.input.iterators"> [lib.input.iterators]</a>, change the return type
2908 for <tt>*r++</tt> from <tt>T</tt> to "convertible to T".
2909 <p><b>Rationale:</b></p>
2910 <p>This issue has two parts: the return type, and the number of times
2911   the copy constructor is invoked.</p>
2912
2913 <p>The LWG believes the the first part is a real issue.  It's
2914   inappropriate for the return type to be specified so much more
2915   precisely for *r++ than it is for *r.  In particular, if r is of
2916   (say) type <tt>int*</tt>, then *r++ isn't <tt>int</tt>,
2917   but <tt>int&amp;</tt>.</p>
2918
2919 <p>The LWG does not believe that the number of times the copy
2920   constructor is invoked is a real issue.  This can vary in any case,
2921   because of language rules on copy constructor elision.  That's too
2922   much to read into these semantics clauses.</p>
2923
2924 <p>Additionally, as Dave Abrahams pointed out (c++std-lib-13703): since
2925    we're told (24.1/3) that forward iterators satisfy all the requirements
2926    of input iterators, we can't impose any requirements in the Input
2927    Iterator requirements table that forward iterators don't satisfy.</p>
2928 <hr>
2929 <a name="103"><h3>103.&nbsp;set::iterator is required to be modifiable, but this allows modification of keys</h3></a><p><b>Section:</b>&nbsp;23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
2930 <p>Set::iterator is described as implementation-defined with a
2931 reference to the container requirement; the container requirement says
2932 that const_iterator is an iterator pointing to const T and iterator an
2933 iterator pointing to T.</p>
2934
2935 <p>23.1.2 paragraph 2 implies that the keys should not be modified to
2936 break the ordering of elements. But that is not clearly
2937 specified. Especially considering that the current standard requires
2938 that iterator for associative containers be different from
2939 const_iterator. Set, for example, has the following: </p>
2940
2941 <p><tt>typedef implementation defined iterator;<br>
2942 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // See _lib.container.requirements_</tt></p>
2943
2944 <p>23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> actually requires that iterator type pointing
2945 to T (table 65). Disallowing user modification of keys by changing the
2946 standard to require an iterator for associative container to be the
2947 same as const_iterator would be overkill since that will unnecessarily
2948 significantly restrict the usage of associative container. A class to
2949 be used as elements of set, for example, can no longer be modified
2950 easily without either redesigning the class (using mutable on fields
2951 that have nothing to do with ordering), or using const_cast, which
2952 defeats requiring iterator to be const_iterator. The proposed solution
2953 goes in line with trusting user knows what he is doing. </p>
2954
2955 <p><b>Other Options Evaluated:</b> </p>
2956
2957 <p>Option A.&nbsp;&nbsp; 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 2, after
2958 first sentence, and before "In addition,...", add one line:
2959 </p>
2960
2961 <blockquote>
2962   <p>Modification of keys shall not change their strict weak ordering. </p>
2963 </blockquote>
2964
2965 <p>Option B.&nbsp;Add three new sentences to 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>:</p>
2966
2967 <blockquote>
2968   <p>At the end of paragraph 5: "Keys in an associative container
2969   are immutable." At the end of paragraph 6: "For
2970   associative containers where the value type is the same as the key
2971   type, both <tt>iterator</tt> and <tt>const_iterator</tt> are
2972   constant iterators. It is unspecified whether or not
2973   <tt>iterator</tt> and <tt>const_iterator</tt> are the same
2974   type."</p>
2975 </blockquote>
2976
2977 <p>Option C.&nbsp;To 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 3, which
2978 currently reads:</p>
2979
2980 <blockquote>
2981   <p>The phrase ``equivalence of keys'' means the equivalence relation imposed by the
2982   comparison and not the operator== on keys. That is, two keys k1 and k2 in the same
2983   container are considered to be equivalent if for the comparison object comp, comp(k1, k2)
2984   == false &amp;&amp; comp(k2, k1) == false.</p>
2985 </blockquote>
2986
2987 <p>&nbsp; add the following:</p>
2988
2989 <blockquote>
2990   <p>For any two keys k1 and k2 in the same container, comp(k1, k2) shall return the same
2991   value whenever it is evaluated. [Note: If k2 is removed from the container and later
2992   reinserted, comp(k1, k2) must still return a consistent value but this value may be
2993   different than it was the first time k1 and k2 were in the same container. This is
2994   intended to allow usage like a string key that contains a filename, where comp compares
2995   file contents; if k2 is removed, the file is changed, and the same k2 (filename) is
2996   reinserted, comp(k1, k2) must again return a consistent value but this value may be
2997   different than it was the previous time k2 was in the container.]</p>
2998 </blockquote>
2999 <p><b>Proposed resolution:</b></p>
3000 <p>Add the following to 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> at
3001 the indicated location:</p>
3002
3003 <blockquote>
3004   <p>At the end of paragraph 3: "For any two keys k1 and k2 in the same container,
3005   calling comp(k1, k2) shall always return the same
3006   value."</p>
3007   <p>At the end of paragraph 5: "Keys in an associative container are immutable."</p>
3008   <p>At the end of paragraph 6: "For associative containers where the value type is the
3009   same as the key type, both <tt>iterator</tt> and <tt>const_iterator</tt> are constant
3010   iterators. It is unspecified whether or not <tt>iterator</tt> and <tt>const_iterator</tt>
3011   are the same type."</p>
3012 </blockquote>
3013 <p><b>Rationale:</b></p>
3014 <p>Several arguments were advanced for and against allowing set elements to be
3015 mutable as long as the ordering was not effected. The argument which swayed the
3016 LWG was one of safety; if elements were mutable, there would be no compile-time
3017 way to detect of a simple user oversight which caused ordering to be
3018 modified.  There was a report that this had actually happened in practice,
3019 and had been painful to diagnose.  If users need to modify elements,
3020 it is possible to use mutable members or const_cast.</p>
3021
3022 <p>Simply requiring that keys be immutable is not sufficient, because the comparison
3023 object may indirectly (via pointers) operate on values outside of the keys.</p>
3024
3025 <p>
3026 The types <tt>iterator</tt> and <tt>const_iterator</tt> are permitted
3027 to be different types to allow for potential future work in which some
3028 member functions might be overloaded between the two types.  No such
3029 member functions exist now, and the LWG believes that user functionality
3030 will not be impaired by permitting the two types to be the same.  A
3031 function that operates on both iterator types can be defined for
3032 <tt>const_iterator</tt> alone, and can rely on the automatic
3033 conversion from <tt>iterator</tt> to <tt>const_iterator</tt>.
3034 </p>
3035
3036 <p><i>[Tokyo: The LWG crafted the proposed resolution and rationale.]</i></p>
3037 <hr>
3038 <a name="106"><h3>106.&nbsp;Numeric library private members are implementation defined</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
3039 <p>This is the only place in the whole standard where the implementation has to document
3040 something private.</p>
3041 <p><b>Proposed resolution:</b></p>
3042 <p>
3043 Remove the comment which says "// remainder implementation defined" from:
3044 </p>
3045
3046 <ul>
3047   <li>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>
3048 </li>
3049   <li>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>
3050 </li>
3051   <li>26.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.transcendentals"> [lib.complex.transcendentals]</a>
3052 </li>
3053   <li>26.3.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.cmplx.over"> [lib.cmplx.over]</a>
3054 </li>
3055 </ul>
3056 <hr>
3057 <a name="108"><h3>108.&nbsp;Lifetime of exception::what() return unspecified</h3></a><p><b>Section:</b>&nbsp;18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.type.info"> [lib.type.info]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;AFNOR&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
3058 <p>In 18.6.1, paragraphs 8-9, the lifetime of the return value of
3059 exception::what() is left unspecified. This issue has implications
3060 with exception safety of exception handling: some exceptions should
3061 not throw bad_alloc.</p>
3062 <p><b>Proposed resolution:</b></p>
3063 <p>Add to 18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.type.info"> [lib.type.info]</a> paragraph 9 (exception::what notes
3064 clause) the sentence:</p>
3065
3066 <blockquote>
3067   <p>The return value remains valid until the exception object from which it is obtained is
3068   destroyed or a non-const member function of the exception object is called.</p>
3069 </blockquote>
3070 <p><b>Rationale:</b></p>
3071 <p>If an exception object has non-const members, they may be used
3072 to set internal state that should affect the contents of the string
3073 returned by <tt>what()</tt>.
3074 </p>
3075 <hr>
3076 <a name="109"><h3>109.&nbsp;Missing binders for non-const sequence elements</h3></a><p><b>Section:</b>&nbsp;20.5.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.arithmetic.operations"> [lib.arithmetic.operations]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Bjarne Stroustrup&nbsp; <b>Date:</b>&nbsp;7 Oct 1998</p>
3077
3078 <p>There are no versions of binders that apply to non-const elements
3079 of a sequence. This makes examples like for_each() using bind2nd() on
3080 page 521 of "The C++ Programming Language (3rd)"
3081 non-conforming. Suitable versions of the binders need to be added.</p>
3082
3083 <p>Further discussion from Nico:</p>
3084
3085 <p>What is probably meant here is shown in the following example:</p>
3086
3087 <pre>class Elem {
3088   public:
3089     void print (int i) const { }
3090     void modify (int i) { }
3091 }; </pre>
3092 <pre>int main()
3093 {
3094     vector&lt;Elem&gt; coll(2);
3095     for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&amp;Elem::print),42));    // OK
3096     for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&amp;Elem::modify),42));   // ERROR
3097 }</pre>
3098
3099 <p>The error results from the fact that bind2nd() passes its first
3100 argument (the argument of the sequence) as constant reference. See the
3101 following typical implementation:</p>
3102
3103 <blockquote>
3104   <pre>template &lt;class Operation&gt;
3105 class binder2nd
3106   : public unary_function&lt;typename Operation::first_argument_type,
3107                           typename Operation::result_type&gt; {
3108 protected:
3109   Operation op;
3110   typename Operation::second_argument_type value;
3111 public:
3112   binder2nd(const Operation&amp; o,
3113             const typename Operation::second_argument_type&amp; v)
3114       : op(o), value(v) {} </pre>
3115   <pre> typename Operation::result_type
3116   operator()(const typename Operation::first_argument_type&amp; x) const {
3117     return op(x, value);
3118   }
3119 };</pre>
3120 </blockquote>
3121
3122 <p>The solution is to overload operator () of bind2nd for non-constant arguments:</p>
3123
3124 <blockquote>
3125   <pre>template &lt;class Operation&gt;
3126 class binder2nd
3127   : public unary_function&lt;typename Operation::first_argument_type,
3128                           typename Operation::result_type&gt; {
3129 protected:
3130   Operation op;
3131   typename Operation::second_argument_type value;
3132 public:
3133   binder2nd(const Operation&amp; o,
3134             const typename Operation::second_argument_type&amp; v)
3135       : op(o), value(v) {} </pre>
3136   <pre> typename Operation::result_type
3137   operator()(const typename Operation::first_argument_type&amp; x) const {
3138     return op(x, value);
3139   }
3140   typename Operation::result_type
3141   operator()(typename Operation::first_argument_type&amp; x) const {
3142     return op(x, value);
3143   }
3144 };</pre>
3145 </blockquote>
3146 <p><b>Proposed resolution:</b></p>
3147
3148 <p><b>Howard believes there is a flaw</b> in this resolution.
3149 See c++std-lib-9127.  We may need to reopen this issue.</p>
3150
3151 <p>In <font color="red">20.5.6.1</font> in the declaration of binder1st after:</p>
3152 <blockquote>
3153   <p><tt>typename Operation::result_type<br>
3154   &nbsp;operator()(const typename Operation::second_argument_type&amp; x) const;</tt></p>
3155 </blockquote>
3156 <p>insert:</p>
3157 <blockquote>
3158   <p><tt>typename Operation::result_type<br>
3159   &nbsp;operator()(typename Operation::second_argument_type&amp; x) const;</tt></p>
3160 </blockquote>
3161 <p>In <font color="red">20.5.6.3</font> in the declaration of binder2nd after:</p>
3162 <blockquote>
3163   <p><tt>typename Operation::result_type<br>
3164   &nbsp;operator()(const typename Operation::first_argument_type&amp; x) const;</tt></p>
3165 </blockquote>
3166 <p>insert:</p>
3167 <blockquote>
3168   <p><tt>typename Operation::result_type<br>
3169   &nbsp;operator()(typename Operation::first_argument_type&amp; x) const;</tt></p>
3170 </blockquote>
3171
3172 <p><i>[Kona: The LWG discussed this at some length.It was agreed that
3173 this is a mistake in the design, but there was no consensus on whether
3174 it was a defect in the Standard.  Straw vote: NAD - 5.  Accept
3175 proposed resolution - 3.  Leave open - 6.]</i></p>
3176
3177 <p><i>[Copenhagen: It was generally agreed that this was a defect.
3178 Strap poll: NAD - 0.  Accept proposed resolution - 10.
3179 Leave open - 1.]</i></p>
3180
3181 <hr>
3182 <a name="110"><h3>110.&nbsp;istreambuf_iterator::equal not const</h3></a><p><b>Section:</b>&nbsp;24.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator"> [lib.istreambuf.iterator]</a>, 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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;15 Oct 1998</p>
3183 <p>Member istreambuf_iterator&lt;&gt;::equal is not declared
3184 "const", yet 24.5.3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator::op=="> [lib.istreambuf.iterator::op==]</a> says that operator==,
3185 which is const, calls it. This is contradictory. </p>
3186 <p><b>Proposed resolution:</b></p>
3187 <p>In 24.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator"> [lib.istreambuf.iterator]</a> and also 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>,
3188 replace:</p>
3189
3190 <blockquote>
3191   <pre>bool equal(istreambuf_iterator&amp; b);</pre>
3192 </blockquote>
3193
3194 <p>with:</p>
3195
3196 <blockquote>
3197   <pre>bool equal(const istreambuf_iterator&amp; b) const;</pre>
3198 </blockquote>
3199 <hr>
3200 <a name="112"><h3>112.&nbsp;Minor typo in <tt>ostreambuf_iterator</tt> constructor</h3></a><p><b>Section:</b>&nbsp;24.5.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.ostreambuf.iter.cons"> [lib.ostreambuf.iter.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;20 Oct 1998</p>
3201 <p>The <b>requires</b> clause for <tt>ostreambuf_iterator</tt>'s
3202 constructor from an <tt>ostream_type</tt> (24.5.4.1, paragraph 1)
3203 reads "<i>s</i> is not null". However, <i>s</i> is a
3204 reference, and references can't be null. </p>
3205 <p><b>Proposed resolution:</b></p>
3206 <p>In 24.5.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.ostreambuf.iter.cons"> [lib.ostreambuf.iter.cons]</a>:</p>
3207
3208 <p>Move the current paragraph 1, which reads "Requires: s is not
3209 null.", from the first constructor to the second constructor.</p>
3210
3211 <p>Insert a new paragraph 1 Requires clause for the first constructor
3212 reading:</p>
3213
3214 <blockquote>
3215   <p><b>Requires</b>: <tt>s.rdbuf()</tt> is not null.</p>
3216 </blockquote>
3217 <hr>
3218 <a name="114"><h3>114.&nbsp;Placement forms example in error twice</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;28 Oct 1998</p>
3219 <p>Section 18.5.1.3 contains the following example: </p>
3220
3221 <pre>[Example: This can be useful for constructing an object at a known address:
3222         char place[sizeof(Something)];
3223         Something* p = new (place) Something();
3224  -end example]</pre>
3225
3226 <p>First code line: "place" need not have any special alignment, and the
3227 following constructor could fail due to misaligned data.</p>
3228
3229 <p>Second code line: Aren't the parens on Something() incorrect?&nbsp; [Dublin: the LWG
3230 believes the () are correct.]</p>
3231
3232 <p>Examples are not normative, but nevertheless should not show code that is invalid or
3233 likely to fail.</p>
3234 <p><b>Proposed resolution:</b></p>
3235 <p>Replace the <u> first line of code</u> in the example in
3236 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> with:
3237 </p>
3238
3239 <blockquote>
3240   <pre>void* place = operator new(sizeof(Something));</pre>
3241 </blockquote>
3242 <hr>
3243 <a name="115"><h3>115.&nbsp;Typo in strstream constructors</h3></a><p><b>Section:</b>&nbsp;D.7.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.strstream.cons"> [depr.strstream.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;2 Nov 1998</p>
3244 <p>D.7.4.1 strstream constructors paragraph 2 says: </p>
3245
3246 <blockquote>
3247   <p>Effects: Constructs an object of class strstream, initializing the base class with
3248   iostream(&amp; sb) and initializing sb with one of the two constructors: </p>
3249   <p>- If mode&amp;app==0, then s shall designate the first element of an array of n
3250   elements. The constructor is strstreambuf(s, n, s). </p>
3251   <p>- If mode&amp;app==0, then s shall designate the first element of an array of n
3252   elements that contains an NTBS whose first element is designated by s. The constructor is
3253   strstreambuf(s, n, s+std::strlen(s)).</p>
3254 </blockquote>
3255
3256 <p>Notice the second condition is the same as the first. I think the second condition
3257 should be "If mode&amp;app==app", or "mode&amp;app!=0", meaning that
3258 the append bit is set.</p>
3259 <p><b>Proposed resolution:</b></p>
3260 <p>In D.7.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.ostrstream.cons"> [depr.ostrstream.cons]</a> paragraph 2 and D.7.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.strstream.cons"> [depr.strstream.cons]</a>
3261 paragraph 2, change the first condition to <tt>(mode&amp;app)==0</tt>
3262 and the second condition to <tt>(mode&amp;app)!=0</tt>.</p>
3263 <hr>
3264 <a name="117"><h3>117.&nbsp;<tt>basic_ostream</tt> uses nonexistent <tt>num_put</tt> member functions</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;20 Nov 1998</p>
3265 <p>The <b>effects</b> clause for numeric inserters says that
3266 insertion of a value <tt>x</tt>, whose type is either <tt>bool</tt>,
3267 <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
3268 int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>,
3269 <tt>double</tt>, <tt>long double</tt>, or <tt>const void*</tt>, is
3270 delegated to <tt>num_put</tt>, and that insertion is performed as if
3271 through the following code fragment: </p>
3272
3273 <pre>bool failed = use_facet&lt;
3274    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3275    &gt;(getloc()).put(*this, *this, fill(), val). failed();</pre>
3276
3277 <p>This doesn't work, because <tt>num_put&lt;&gt;</tt>::put is only
3278 overloaded for the types <tt>bool</tt>, <tt>long</tt>, <tt>unsigned
3279 long</tt>, <tt>double</tt>, <tt>long double</tt>, and <tt>const
3280 void*</tt>. That is, the code fragment in the standard is incorrect
3281 (it is diagnosed as ambiguous at compile time) for the types
3282 <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>, <tt>unsigned
3283 int</tt>, and <tt>float</tt>. </p>
3284
3285 <p>We must either add new member functions to <tt>num_put</tt>, or
3286 else change the description in <tt>ostream</tt> so that it only calls
3287 functions that are actually there. I prefer the latter. </p>
3288 <p><b>Proposed resolution:</b></p>
3289 <p>Replace 27.6.2.5.2, paragraph 1 with the following: </p>
3290
3291 <blockquote>
3292 <p>
3293 The classes num_get&lt;&gt; and num_put&lt;&gt; handle localedependent numeric
3294 formatting and parsing.  These inserter functions use the imbued
3295 locale value to perform numeric formatting.  When val is of type bool,
3296 long, unsigned long, double, long double, or const void*, the
3297 formatting conversion occurs as if it performed the following code
3298 fragment:
3299 </p>
3300
3301 <pre>bool failed = use_facet&lt;
3302    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3303    &gt;(getloc()).put(*this, *this, fill(), val). failed();
3304 </pre>
3305
3306 <p>
3307 When val is of type short the formatting conversion occurs as if it
3308 performed the following code fragment:
3309 </p>
3310
3311 <pre>ios_base::fmtflags baseflags = ios_base::flags() &amp; ios_base::basefield;
3312 bool failed = use_facet&lt;
3313    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3314    &gt;(getloc()).put(*this, *this, fill(),
3315       baseflags == ios_base::oct || baseflags == ios_base::hex
3316          ? static_cast&lt;long&gt;(static_cast&lt;unsigned short&gt;(val))
3317          : static_cast&lt;long&gt;(val)). failed();
3318 </pre>
3319
3320 <p>
3321 When val is of type int the formatting conversion occurs as if it performed
3322 the following code fragment:
3323 </p>
3324
3325 <pre>ios_base::fmtflags baseflags = ios_base::flags() &amp; ios_base::basefield;
3326 bool failed = use_facet&lt;
3327    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3328    &gt;(getloc()).put(*this, *this, fill(),
3329       baseflags == ios_base::oct || baseflags == ios_base::hex
3330          ? static_cast&lt;long&gt;(static_cast&lt;unsigned int&gt;(val))
3331          : static_cast&lt;long&gt;(val)). failed();
3332 </pre>
3333
3334 <p>
3335 When val is of type unsigned short or unsigned int the formatting conversion
3336 occurs as if it performed the following code fragment:
3337 </p>
3338
3339 <pre>bool failed = use_facet&lt;
3340    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3341    &gt;(getloc()).put(*this, *this, fill(), static_cast&lt;unsigned long&gt;(val)).
3342 failed();
3343 </pre>
3344
3345 <p>
3346 When val is of type float the formatting conversion occurs as if it
3347 performed the following code fragment:
3348 </p>
3349
3350 <pre>bool failed = use_facet&lt;
3351    num_put&lt;charT,ostreambuf_iterator&lt;charT,traits&gt; &gt;
3352    &gt;(getloc()).put(*this, *this, fill(), static_cast&lt;double&gt;(val)).
3353 failed();
3354 </pre>
3355
3356 </blockquote>
3357
3358 <p><i>[post-Toronto: This differs from the previous proposed
3359 resolution; PJP provided the new wording.  The differences are in
3360 signed short and int output.]</i></p>
3361 <p><b>Rationale:</b></p>
3362 <p>The original proposed resolution was to cast int and short to long,
3363 unsigned int and unsigned short to unsigned long, and float to double,
3364 thus ensuring that we don't try to use nonexistent num_put&lt;&gt;
3365 member functions.  The current proposed resolution is more
3366 complicated, but gives more expected results for hex and octal output
3367 of signed short and signed int.  (On a system with 16-bit short, for
3368 example, printing short(-1) in hex format should yield 0xffff.)</p>
3369 <hr>
3370 <a name="118"><h3>118.&nbsp;<tt>basic_istream</tt> uses nonexistent <tt>num_get</tt> member functions</h3></a><p><b>Section:</b>&nbsp;27.6.1.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;20 Nov 1998</p>
3371 <p>Formatted input is defined for the types <tt>short</tt>, <tt>unsigned short</tt>, <tt>int</tt>,
3372 <tt>unsigned int</tt>, <tt>long</tt>, <tt>unsigned long</tt>, <tt>float</tt>, <tt>double</tt>,
3373 <tt>long double</tt>, <tt>bool</tt>, and <tt>void*</tt>. According to section 27.6.1.2.2,
3374 formatted input of a value <tt>x</tt> is done as if by the following code fragment: </p>
3375
3376 <pre>typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
3377 iostate err = 0;
3378 use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, val);
3379 setstate(err);</pre>
3380
3381 <p>According to section 22.2.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a>, however,
3382 <tt>num_get&lt;&gt;::get()</tt> is only overloaded for the types
3383 <tt>bool</tt>, <tt>long</tt>, <tt>unsigned short</tt>, <tt>unsigned
3384 int</tt>, <tt>unsigned long</tt>, <tt>unsigned long</tt>,
3385 <tt>float</tt>, <tt>double</tt>, <tt>long double</tt>, and
3386 <tt>void*</tt>. Comparing the lists from the two sections, we find
3387 that 27.6.1.2.2 is using a nonexistent function for types
3388 <tt>short</tt> and <tt>int</tt>. </p>
3389 <p><b>Proposed resolution:</b></p>
3390 <p>In 27.6.1.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a> Arithmetic Extractors, remove the
3391 two lines (1st and 3rd) which read:</p>
3392 <blockquote>
3393   <pre>operator&gt;&gt;(short&amp; val);
3394 ...
3395 operator&gt;&gt;(int&amp; val);</pre>
3396 </blockquote>
3397
3398 <p>And add the following at the end of that section (27.6.1.2.2) :</p>
3399
3400 <blockquote>
3401   <pre>operator&gt;&gt;(short&amp; val);</pre>
3402   <p>The conversion occurs as if performed by the following code fragment (using
3403   the same notation as for the preceding code fragment):</p>
3404   <pre>  typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
3405   iostate err = 0;
3406   long lval;
3407   use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, lval);
3408         if (err == 0
3409                 &amp;&amp; (lval &lt; numeric_limits&lt;short&gt;::min() || numeric_limits&lt;short&gt;::max() &lt; lval))
3410                 err = ios_base::failbit;
3411   setstate(err);</pre>
3412   <pre>operator&gt;&gt;(int&amp; val);</pre>
3413   <p>The conversion occurs as if performed by the following code fragment (using
3414   the same notation as for the preceding code fragment):</p>
3415   <pre>  typedef num_get&lt; charT,istreambuf_iterator&lt;charT,traits&gt; &gt; numget;
3416   iostate err = 0;
3417   long lval;
3418   use_facet&lt; numget &gt;(loc).get(*this, 0, *this, err, lval);
3419         if (err == 0
3420                 &amp;&amp; (lval &lt; numeric_limits&lt;int&gt;::min() || numeric_limits&lt;int&gt;::max() &lt; lval))
3421                 err = ios_base::failbit;
3422   setstate(err);</pre>
3423 </blockquote>
3424
3425 <p><i>[Post-Tokyo: PJP provided the above wording.]</i></p>
3426 <hr>
3427 <a name="119"><h3>119.&nbsp;Should virtual functions be allowed to strengthen the exception specification?</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
3428 <p>Section 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> states: </p>
3429
3430 <p>"An implementation may strengthen the exception-specification
3431 for a function by removing listed exceptions." </p>
3432
3433 <p>The problem is that if an implementation is allowed to do this for
3434 virtual functions, then a library user cannot write a class that
3435 portably derives from that class. </p>
3436
3437 <p>For example, this would not compile if ios_base::failure::~failure
3438 had an empty exception specification: </p>
3439
3440 <pre>#include &lt;ios&gt;
3441 #include &lt;string&gt;
3442
3443 class D : public std::ios_base::failure {
3444 public:
3445         D(const std::string&amp;);
3446         ~D(); // error - exception specification must be compatible with
3447               // overridden virtual function ios_base::failure::~failure()
3448 };</pre>
3449 <p><b>Proposed resolution:</b></p>
3450 <p>Change Section 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> from:</p>
3451
3452 <p>&nbsp;&nbsp;&nbsp;&nbsp; "may strengthen the
3453 exception-specification for a function"</p>
3454
3455 <p>to:</p>
3456
3457 <p>&nbsp;&nbsp;&nbsp;&nbsp; "may strengthen the
3458 exception-specification for a non-virtual function". </p>
3459 <hr>
3460 <a name="120"><h3>120.&nbsp;Can an implementor add specializations?</h3></a><p><b>Section:</b>&nbsp;17.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
3461
3462 <p>The original issue asked whether a library implementor could
3463 specialize standard library templates for built-in types.  (This was
3464 an issue because users are permitted to explicitly instantiate
3465 standard library templates.)</p>
3466
3467 <p>Specializations are no longer a problem, because of the resolution
3468 to core issue 259.  Under the proposed resolution, it will be legal
3469 for a translation unit to contain both a specialization and an
3470 explicit instantiation of the same template, provided that the
3471 specialization comes first.  In such a case, the explicit
3472 instantiation will be ignored.  Further discussion of library issue
3473 120 assumes that the core 259 resolution will be adopted.</p>
3474
3475 <p>However, as noted in lib-7047, one piece of this issue still
3476 remains: what happens if a standard library implementor explicitly
3477 instantiates a standard library templates?  It's illegal for a program
3478 to contain two different explicit instantiations of the same template
3479 for the same type in two different translation units (ODR violation),
3480 and the core working group doesn't believe it is practical to relax
3481 that restriction.</p>
3482
3483 <p>The issue, then, is: are users allowed to explicitly instantiate
3484 standard library templates for non-user defined types?  The status quo
3485 answer is 'yes'.  Changing it to 'no' would give library implementors
3486 more freedom.</p>
3487
3488 <p>This is an issue because, for performance reasons, library
3489 implementors often need to explicitly instantiate standard library
3490 templates.  (for example, std::basic_string&lt;char&gt;)  Does giving
3491 users freedom to explicitly instantiate standard library templates for
3492 non-user defined types make it impossible or painfully difficult for
3493 library implementors to do this?</p>
3494
3495 <p>John Spicer suggests, in lib-8957, that library implementors have a
3496 mechanism they can use for explicit instantiations that doesn't
3497 prevent users from performing their own explicit instantiations: put
3498 each explicit instantiation in its own object file.  (Different
3499 solutions might be necessary for Unix DSOs or MS-Windows DLLs.)  On
3500 some platforms, library implementors might not need to do anything
3501 special: the "undefined behavior" that results from having two
3502 different explicit instantiations might be harmless.</p>
3503
3504 <p><b>Proposed resolution:</b></p>
3505   <p>Append to 17.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a> paragraph 1: </p>
3506   <blockquote>
3507     A program may explicitly instantiate any templates in the standard
3508     library only if the declaration depends on the name of a user-defined
3509     type of external linkage and the instantiation meets the standard library
3510     requirements for the original template.
3511   </blockquote>
3512
3513 <p><i>[Kona: changed the wording from "a user-defined name" to "the name of
3514   a user-defined type"]</i></p>
3515
3516 <p><b>Rationale:</b></p>
3517 <p>The LWG considered another possible resolution:</p>
3518 <blockquote>
3519   <p>In light of the resolution to core issue 259, no normative changes
3520   in the library clauses are necessary.  Add the following non-normative
3521   note to the end of 17.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a> paragraph 1:</p>
3522   <blockquote>
3523     [<i>Note:</i> A program may explicitly instantiate standard library
3524     templates, even when an explicit instantiation does not depend on
3525     a user-defined name. <i>--end note</i>]
3526   </blockquote>
3527 </blockquote>
3528
3529 <p>The LWG rejected this because it was believed that it would make
3530   it unnecessarily difficult for library implementors to write
3531   high-quality implementations.  A program may not include an
3532   explicit instantiation of the same template, for the same template
3533   arguments, in two different translation units.  If users are
3534   allowed to provide explicit instantiations of Standard Library
3535   templates for built-in types, then library implementors aren't,
3536   at least not without nonportable tricks.</p>
3537
3538 <p>The most serious problem is a class template that has writeable
3539   static member variables.  Unfortunately, such class templates are
3540   important and, in existing Standard Library implementations, are
3541   often explicitly specialized by library implementors: locale facets,
3542   which have a writeable static member variable <tt>id</tt>.  If a
3543   user's explicit instantiation collided with the implementations
3544   explicit instantiation, iostream initialization could cause locales
3545   to be constructed in an inconsistent state.</p>
3546
3547 <p>One proposed implementation technique was for Standard Library
3548   implementors to provide explicit instantiations in separate object
3549   files, so that they would not be picked up by the linker when the
3550   user also provides an explicit instantiation.  However, this
3551   technique only applies for Standard Library implementations that
3552   are packaged as static archives.  Most Standard Library
3553   implementations nowadays are packaged as dynamic libraries, so this
3554   technique would not apply.</p>
3555
3556 <p>The Committee is now considering standardization of dynamic
3557   linking.  If there are such changes in the future, it may be
3558   appropriate to revisit this issue later.</p>
3559 <hr>
3560 <a name="122"><h3>122.&nbsp;streambuf/wstreambuf description should not say they are specializations</h3></a><p><b>Section:</b>&nbsp;27.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
3561 <p>Section 27.5.2 describes the streambuf classes this way: </p>
3562
3563 <blockquote>
3564
3565 <p>The class streambuf is a specialization of the template class basic_streambuf
3566 specialized for the type char. </p>
3567
3568 <p>The class wstreambuf is a specialization of the template class basic_streambuf
3569 specialized for the type wchar_t. </p>
3570
3571 </blockquote>
3572
3573 <p>This implies that these classes must be template specializations, not typedefs. </p>
3574
3575 <p>It doesn't seem this was intended, since Section 27.5 has them declared as typedefs. </p>
3576 <p><b>Proposed resolution:</b></p>
3577 <p>Remove 27.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf"> [lib.streambuf]</a> paragraphs 2 and 3 (the above two
3578 sentences). </p>
3579 <p><b>Rationale:</b></p>
3580 <p>The <tt>streambuf</tt>  synopsis already has a declaration for the
3581 typedefs and that is sufficient. </p>
3582 <hr>
3583 <a name="123"><h3>123.&nbsp;Should valarray helper arrays fill functions be const?</h3></a><p><b>Section:</b>&nbsp;26.5.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.slice.arr.fill"> [lib.slice.arr.fill]</a>, 26.5.7.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.gslice.array.fill"> [lib.gslice.array.fill]</a>, 26.5.8.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.mask.array.fill"> [lib.mask.array.fill]</a>, 26.5.9.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.indirect.array.fill"> [lib.indirect.array.fill]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998 </p>
3584 <p>One of the operator= in the valarray helper arrays is const and one
3585 is not. For example, look at slice_array. This operator= in Section
3586 26.5.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a> is const: </p>
3587
3588 <p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const valarray&lt;T&gt;&amp;) const;</tt> </p>
3589
3590 <p>but this one in Section 26.5.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.slice.arr.fill"> [lib.slice.arr.fill]</a> is not: </p>
3591
3592 <p>&nbsp;&nbsp;&nbsp; <tt>void operator=(const T&amp;); </tt></p>
3593
3594 <p>The description of the semantics for these two functions is similar. </p>
3595 <p><b>Proposed resolution:</b></p>
3596
3597 <p>26.5.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a> Template class slice_array</p>
3598 <blockquote>
3599
3600    <p>In the class template definition for slice_array, replace the member
3601    function declaration</p>
3602     <pre>      void operator=(const T&amp;);
3603     </pre>
3604    <p>with</p>
3605     <pre>      void operator=(const T&amp;) const;
3606     </pre>
3607 </blockquote>
3608
3609 <p>26.5.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.slice.arr.fill"> [lib.slice.arr.fill]</a> slice_array fill function</p>
3610 <blockquote>
3611
3612    <p>Change the function declaration</p>
3613     <pre>      void operator=(const T&amp;);
3614     </pre>
3615    <p>to</p>
3616     <pre>      void operator=(const T&amp;) const;
3617     </pre>
3618 </blockquote>
3619
3620 <p>26.5.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a> Template class gslice_array</p>
3621 <blockquote>
3622
3623    <p>In the class template definition for gslice_array, replace the member
3624    function declaration</p>
3625     <pre>      void operator=(const T&amp;);
3626     </pre>
3627    <p>with</p>
3628     <pre>      void operator=(const T&amp;) const;
3629     </pre>
3630 </blockquote>
3631
3632 <p>26.5.7.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.gslice.array.fill"> [lib.gslice.array.fill]</a> gslice_array fill function</p>
3633 <blockquote>
3634
3635    <p>Change the function declaration</p>
3636     <pre>      void operator=(const T&amp;);
3637     </pre>
3638    <p>to</p>
3639     <pre>      void operator=(const T&amp;) const;
3640     </pre>
3641 </blockquote>
3642
3643 <p>26.5.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a> Template class mask_array</p>
3644 <blockquote>
3645
3646    <p>In the class template definition for mask_array, replace the member
3647    function declaration</p>
3648     <pre>      void operator=(const T&amp;);
3649     </pre>
3650    <p>with</p>
3651     <pre>      void operator=(const T&amp;) const;
3652     </pre>
3653 </blockquote>
3654
3655 <p>26.5.8.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.mask.array.fill"> [lib.mask.array.fill]</a> mask_array fill function</p>
3656 <blockquote>
3657
3658    <p>Change the function declaration</p>
3659     <pre>      void operator=(const T&amp;);
3660     </pre>
3661    <p>to</p>
3662     <pre>      void operator=(const T&amp;) const;
3663     </pre>
3664 </blockquote>
3665
3666 <p>26.5.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a> Template class indirect_array</p>
3667 <blockquote>
3668
3669    <p>In the class template definition for indirect_array, replace the member
3670    function declaration</p>
3671     <pre>      void operator=(const T&amp;);
3672     </pre>
3673    <p>with</p>
3674     <pre>      void operator=(const T&amp;) const;
3675     </pre>
3676 </blockquote>
3677
3678 <p>26.5.9.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.indirect.array.fill"> [lib.indirect.array.fill]</a> indirect_array fill function</p>
3679 <blockquote>
3680
3681    <p>Change the function declaration</p>
3682     <pre>      void operator=(const T&amp;);
3683     </pre>
3684    <p>to</p>
3685     <pre>      void operator=(const T&amp;) const;
3686     </pre>
3687 </blockquote>
3688
3689
3690 <p><i>[Redmond: Robert provided wording.]</i></p>
3691
3692 <p><b>Rationale:</b></p>
3693 <p>There's no good reason for one version of operator= being const and
3694 another one not.  Because of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253">253</a>, this now
3695 matters: these functions are now callable in more circumstances.  In
3696 many existing implementations, both versions are already const.</p>
3697 <hr>
3698 <a name="124"><h3>124.&nbsp;ctype_byname&lt;charT&gt;::do_scan_is &amp; do_scan_not return type should be const charT*</h3></a><p><b>Section:</b>&nbsp;22.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
3699 <p>In Section 22.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a>
3700 ctype_byname&lt;charT&gt;::do_scan_is() and do_scan_not() are declared
3701 to return a const char* not a const charT*. </p>
3702 <p><b>Proposed resolution:</b></p>
3703 <p>Change Section 22.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a> <tt>do_scan_is()</tt> and
3704 <tt>do_scan_not()</tt> to return a <tt> const
3705 charT*</tt>. </p>
3706 <hr>
3707 <a name="125"><h3>125.&nbsp;valarray&lt;T&gt;::operator!() return type is inconsistent</h3></a><p><b>Section:</b>&nbsp;26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex"> [lib.complex]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
3708 <p>In Section 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex"> [lib.complex]</a> valarray&lt;T&gt;::operator!() is
3709 declared to return a valarray&lt;T&gt;, but in Section <font color="red">26.3.2.5</font> it is declared to return a valarray&lt;bool&gt;. The
3710 latter appears to be correct. </p>
3711 <p><b>Proposed resolution:</b></p>
3712 <p>Change in Section 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex"> [lib.complex]</a> the declaration of
3713 <tt>operator!()</tt> so that the return type is
3714 <tt>valarray&lt;bool&gt;</tt>. </p>
3715 <hr>
3716 <a name="126"><h3>126.&nbsp;typos in Effects clause of ctype::do_narrow()</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;15 Dec 1998</p>
3717 <p>Typos in 22.2.1.1.2 need to be fixed.</p>
3718 <p><b>Proposed resolution:</b></p>
3719 <p>In Section 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> change: </p>
3720
3721 <pre>   do_widen(do_narrow(c),0) == c</pre>
3722
3723 <p>to:</p>
3724
3725 <pre>   do_widen(do_narrow(c,0)) == c</pre>
3726
3727 <p>and change:</p>
3728
3729 <pre>   (is(M,c) || !ctc.is(M, do_narrow(c),dfault) )</pre>
3730
3731 <p>to:</p>
3732
3733 <pre>   (is(M,c) || !ctc.is(M, do_narrow(c,dfault)) )</pre>
3734 <hr>
3735 <a name="127"><h3>127.&nbsp;auto_ptr&lt;&gt; conversion issues</h3></a><p><b>Section:</b>&nbsp;20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.unary"> [lib.meta.unary]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Greg Colvin&nbsp; <b>Date:</b>&nbsp;17 Feb 1999</p>
3736 <p>There are two problems with the current <tt>auto_ptr</tt> wording
3737 in the standard: </p>
3738
3739 <p>First, the <tt>auto_ptr_ref</tt> definition cannot be nested
3740 because <tt>auto_ptr&lt;Derived&gt;::auto_ptr_ref</tt> is unrelated to
3741 <tt>auto_ptr&lt;Base&gt;::auto_ptr_ref</tt>.  <i>Also submitted by
3742 Nathan Myers, with the same proposed resolution.</i></p>
3743
3744 <p>Second, there is no <tt>auto_ptr</tt> assignment operator taking an
3745 <tt>auto_ptr_ref</tt> argument. </p>
3746
3747 <p>I have discussed these problems with my proposal coauthor, Bill
3748 Gibbons, and with some compiler and library implementors, and we
3749 believe that these problems are not desired or desirable implications
3750 of the standard. </p>
3751
3752 <p>25 Aug 1999: The proposed resolution now reflects changes suggested
3753 by Dave Abrahams, with Greg Colvin's concurrence; 1) changed
3754 "assignment operator" to "public assignment
3755 operator", 2) changed effects to specify use of release(), 3)
3756 made the conversion to auto_ptr_ref const. </p>
3757
3758 <p>2 Feb 2000: Lisa Lippincott comments: [The resolution of] this issue
3759 states that the conversion from auto_ptr to auto_ptr_ref should
3760 be const.  This is not acceptable, because it would allow
3761 initialization and assignment from _any_ const auto_ptr!  It also
3762 introduces an implementation difficulty in writing this conversion
3763 function -- namely, somewhere along the line, a const_cast will be
3764 necessary to remove that const so that release() may be called.  This
3765 may result in undefined behavior [7.1.5.1/4]. The conversion
3766 operator does not have to be const, because a non-const implicit
3767 object parameter may be bound to an rvalue [13.3.3.1.4/3]
3768 [13.3.1/5]. </p>
3769
3770   <p>Tokyo: The LWG removed the following from the proposed resolution:</p>
3771
3772   <p>In 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.unary"> [lib.meta.unary]</a>, paragraph 2, and 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>,
3773   paragraph 2, make the conversion to auto_ptr_ref const:</p>
3774   <blockquote>
3775     <pre>template&lt;class Y&gt; operator auto_ptr_ref&lt;Y&gt;() const throw();</pre>
3776   </blockquote>
3777 <p><b>Proposed resolution:</b></p>
3778 <p>In 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.unary"> [lib.meta.unary]</a>, paragraph 2, move
3779 the <tt>auto_ptr_ref</tt> definition to namespace scope.</p>
3780
3781 <p>In 20.4.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.unary"> [lib.meta.unary]</a>, paragraph 2, add
3782 a public assignment operator to the <tt>auto_ptr</tt> definition: </p>
3783
3784 <blockquote>
3785   <pre>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw();</pre>
3786 </blockquote>
3787
3788 <p>Also add the assignment operator to 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>: </p>
3789
3790 <blockquote>
3791   <pre>auto_ptr&amp; operator=(auto_ptr_ref&lt;X&gt; r) throw()</pre>
3792
3793   <b>Effects:</b> Calls <tt>reset(p.release())</tt> for the <tt>auto_ptr
3794   p</tt> that <tt>r</tt> holds a reference to.<br>
3795   <b>Returns: </b><tt>*this</tt>.
3796
3797 </blockquote>
3798 <hr>
3799 <a name="129"><h3>129.&nbsp;Need error indication from seekp() and seekg()</h3></a><p><b>Section:</b>&nbsp;27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>, 27.6.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.seeks"> [lib.ostream.seeks]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;22 Feb 1999</p>
3800 <p>Currently, the standard does not specify how seekg() and seekp()
3801 indicate failure. They are not required to set failbit, and they can't
3802 return an error indication because they must return *this, i.e. the
3803 stream. Hence, it is undefined what happens if they fail. And they
3804 <i>can</i> fail, for instance, when a file stream is disconnected from the
3805 underlying file (is_open()==false) or when a wide character file
3806 stream must perform a state-dependent code conversion, etc. </p>
3807
3808 <p>The stream functions seekg() and seekp() should set failbit in the
3809 stream state in case of failure.</p>
3810 <p><b>Proposed resolution:</b></p>
3811 <p>Add to the Effects: clause of&nbsp; seekg() in
3812 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> and to the Effects: clause of seekp() in
3813 27.6.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.seeks"> [lib.ostream.seeks]</a>: </p>
3814
3815 <blockquote>
3816   <p>In case of failure, the function calls <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
3817   </p>
3818 </blockquote>
3819 <p><b>Rationale:</b></p>
3820 <p>Setting failbit is the usual error reporting mechanism for streams</p>
3821 <hr>
3822 <a name="130"><h3>130.&nbsp;Return type of container::erase(iterator) differs for associative containers</h3></a><p><b>Section:</b>&nbsp;23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>, 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;2 Mar 1999</p>
3823 <p>Table 67 (23.1.1) says that container::erase(iterator) returns an
3824 iterator. Table 69 (23.1.2) says that in addition to this requirement,
3825 associative containers also say that container::erase(iterator)
3826 returns void.  That's not an addition; it's a change to the
3827 requirements, which has the effect of making associative containers
3828 fail to meet the requirements for containers.</p>
3829 <p><b>Proposed resolution:</b></p>
3830
3831 <p>
3832 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>, in Table 69 Associative container
3833 requirements, change the return type of <tt>a.erase(q)</tt> from
3834 <tt>void</tt> to <tt>iterator</tt>.  Change the
3835 assertion/not/pre/post-condition from "erases the element pointed to
3836 by <tt>q</tt>" to "erases the element pointed to by <tt>q</tt>.
3837 Returns an iterator pointing to the element immediately following q
3838 prior to the element being erased. If no such element exists, a.end()
3839 is returned."
3840 </p>
3841
3842 <p>
3843 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>, in Table 69 Associative container
3844 requirements, change the return type of <tt>a.erase(q1, q2)</tt>
3845 from <tt>void</tt> to <tt>iterator</tt>.  Change the
3846 assertion/not/pre/post-condition from "erases the elements in the
3847 range <tt>[q1, q2)</tt>" to "erases the elements in the range <tt>[q1,
3848 q2)</tt>.  Returns q2."
3849 </p>
3850
3851 <p>
3852 In 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a>, in the <tt>map</tt> class synopsis; and
3853 in 23.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.multimap"> [lib.multimap]</a>, in the <tt>multimap</tt> class synopsis; and
3854 in 23.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.set"> [lib.set]</a>, in the <tt>set</tt> class synopsis; and
3855 in 23.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.multiset"> [lib.multiset]</a>, in the <tt>multiset</tt> class synopsis:
3856 change the signature of the first <tt>erase</tt> overload to
3857 </p>
3858 <pre>   iterator erase(iterator position);
3859 </pre>
3860 <p>and change the signature of the third <tt>erase</tt> overload to</p>
3861 <pre>  iterator erase(iterator first, iterator last);
3862 </pre>
3863
3864
3865 <p><i>[Pre-Kona: reopened at the request of Howard Hinnant]</i></p>
3866
3867 <p><i>[Post-Kona: the LWG agrees the return type should be
3868 <tt>iterator</tt>, not <tt>void</tt>.  (Alex Stepanov agrees too.)
3869 Matt provided wording.]</i></p>
3870
3871 <p><i>[
3872  Sydney: the proposed wording went in the right direction, but it
3873  wasn't good enough. We want to return an iterator from the range form
3874  of erase as well as the single-iterator form. Also, the wording is
3875  slightly different from the wording we have for sequences; there's no
3876  good reason for having a difference.  Matt provided new wording,
3877  which we will review at the next meeting.
3878 ]</i></p>
3879
3880 <hr>
3881 <a name="132"><h3>132.&nbsp;list::resize description uses random access iterators</h3></a><p><b>Section:</b>&nbsp;23.2.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.capacity"> [lib.deque.capacity]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;6 Mar 1999</p>
3882 <p>The description reads:</p>
3883
3884 <p>-1- Effects:</p>
3885
3886 <pre>         if (sz &gt; size())
3887            insert(end(), sz-size(), c);
3888          else if (sz &lt; size())
3889            erase(begin()+sz, end());
3890          else
3891            ;                           //  do nothing</pre>
3892
3893 <p>Obviously list::resize should not be specified in terms of random access iterators.</p>
3894 <p><b>Proposed resolution:</b></p>
3895 <p>Change 23.2.2.2 paragraph 1 to:</p>
3896
3897 <p>Effects:</p>
3898
3899 <pre>         if (sz &gt; size())
3900            insert(end(), sz-size(), c);
3901          else if (sz &lt; size())
3902          {
3903            iterator i = begin();
3904            advance(i, sz);
3905            erase(i, end());
3906          }</pre>
3907
3908 <p><i>[Dublin: The LWG asked Howard to discuss exception safety offline
3909 with David Abrahams. They had a discussion and believe there is
3910 no issue of exception safety with the proposed resolution.]</i></p>
3911 <hr>
3912 <a name="133"><h3>133.&nbsp;map missing get_allocator()</h3></a><p><b>Section:</b>&nbsp;23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;6 Mar 1999</p>
3913 <p>The title says it all.</p>
3914 <p><b>Proposed resolution:</b></p>
3915 <p>Insert in 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a>, paragraph 2,
3916 after operator= in the map declaration:</p>
3917
3918 <pre>    allocator_type get_allocator() const;</pre>
3919 <hr>
3920 <a name="134"><h3>134.&nbsp;vector constructors over specified</h3></a><p><b>Section:</b>&nbsp;23.2.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.queue"> [lib.queue]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;6 Mar 1999</p>
3921 <p>The complexity description says: "It does at most 2N calls to the copy constructor
3922 of T and logN reallocations if they are just input iterators ...".</p>
3923
3924 <p>This appears to be overly restrictive, dictating the precise memory/performance
3925 tradeoff for the implementor.</p>
3926 <p><b>Proposed resolution:</b></p>
3927 <p>Change 23.2.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.queue"> [lib.queue]</a>, paragraph 1 to:</p>
3928
3929 <p>-1- Complexity: The constructor template &lt;class
3930 InputIterator&gt; vector(InputIterator first, InputIterator last)
3931 makes only N calls to the copy constructor of T (where N is the
3932 distance between first and last) and no reallocations if iterators
3933 first and last are of forward, bidirectional, or random access
3934 categories. It makes order N calls to the copy constructor of T and
3935 order logN reallocations if they are just input iterators.
3936 </p>
3937 <p><b>Rationale:</b></p>
3938 <p>"at most 2N calls" is correct only if the growth factor
3939 is greater than or equal to 2.
3940 </p>
3941 <hr>
3942 <a name="136"><h3>136.&nbsp;seekp, seekg setting wrong streams?</h3></a><p><b>Section:</b>&nbsp;27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;6 Mar 1999</p>
3943 <p>I may be misunderstanding the intent, but should not seekg set only
3944 the input stream and seekp set only the output stream? The description
3945 seems to say that each should set both input and output streams. If
3946 that's really the intent, I withdraw this proposal.</p>
3947 <p><b>Proposed resolution:</b></p>
3948 <p>In section 27.6.1.3 change:</p>
3949
3950 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(pos_type pos);
3951 Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos). </pre>
3952
3953 <p>To:</p>
3954
3955 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(pos_type pos);
3956 Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos, ios_base::in). </pre>
3957
3958 <p>In section 27.6.1.3 change:</p>
3959
3960 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type&amp; off, ios_base::seekdir dir);
3961 Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir). </pre>
3962
3963 <p>To:</p>
3964
3965 <pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type&amp; off, ios_base::seekdir dir);
3966 Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir, ios_base::in). </pre>
3967
3968 <p>In section 27.6.2.4, paragraph 2 change:</p>
3969
3970 <pre>-2- Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos). </pre>
3971
3972 <p>To:</p>
3973
3974 <pre>-2- Effects: If fail() != true, executes rdbuf()-&gt;pubseekpos(pos, ios_base::out). </pre>
3975
3976 <p>In section 27.6.2.4, paragraph 4 change:</p>
3977
3978 <pre>-4- Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir). </pre>
3979
3980 <p>To:</p>
3981
3982 <pre>-4- Effects: If fail() != true, executes rdbuf()-&gt;pubseekoff(off, dir, ios_base::out). </pre>
3983
3984 <p><i>[Dublin: Dietmar Kühl thinks this is probably correct, but would
3985 like the opinion of more iostream experts before taking action.]</i></p>
3986
3987 <p><i>[Tokyo: Reviewed by the LWG. PJP noted that although his docs are
3988 incorrect, his implementation already implements the Proposed
3989 Resolution.]</i></p>
3990
3991 <p><i>[Post-Tokyo: Matt Austern comments:<br>
3992 Is it a problem with basic_istream and basic_ostream, or is it a problem
3993 with basic_stringbuf?
3994 We could resolve the issue either by changing basic_istream and
3995 basic_ostream, or by changing basic_stringbuf. I prefer the latter
3996 change (or maybe both changes): I don't see any reason for the standard to
3997 require that std::stringbuf s(std::string("foo"), std::ios_base::in);
3998 s.pubseekoff(0, std::ios_base::beg); must fail.<br>
3999 This requirement is a bit weird. There's no similar requirement
4000 for basic_streambuf&lt;&gt;::seekpos, or for basic_filebuf&lt;&gt;::seekoff or
4001 basic_filebuf&lt;&gt;::seekpos.]</i></p>
4002 <hr>
4003 <a name="137"><h3>137.&nbsp;Do use_facet and has_facet look in the global locale?</h3></a><p><b>Section:</b>&nbsp;22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;17 Mar 1999</p>
4004 <p>Section 22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a> says:</p>
4005
4006 <p>-4- In the call to use_facet&lt;Facet&gt;(loc), the type argument
4007 chooses a facet, making available all members of the named type. If
4008 Facet is not present in a locale (or, failing that, in the global
4009 locale), it throws the standard exception bad_cast. A C++ program can
4010 check if a locale implements a particular facet with the template
4011 function has_facet&lt;Facet&gt;(). </p>
4012
4013 <p>This contradicts the specification given in section
4014 22.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.global.templates"> [lib.locale.global.templates]</a>:
4015 <br><br>
4016 template &lt;class&nbsp; Facet&gt; const&nbsp; Facet&amp; use_facet(const
4017 locale&amp;&nbsp; loc); <br>
4018 <br>
4019 -1- Get a reference to a facet of a locale. <br>
4020 -2- Returns: a reference to the corresponding facet of loc, if present. <br>
4021 -3- Throws: bad_cast if has_facet&lt;Facet&gt;(loc) is false. <br>
4022 -4- Notes: The reference returned remains valid at least as long as any copy of loc exists
4023 </p>
4024 <p><b>Proposed resolution:</b></p>
4025 <p>Remove the phrase "(or, failing that, in the global locale)"
4026 from section 22.1.1. </p>
4027 <p><b>Rationale:</b></p>
4028 <p>Needed for consistency with the way locales are handled elsewhere
4029 in the standard.</p>
4030 <hr>
4031 <a name="139"><h3>139.&nbsp;Optional sequence operation table description unclear</h3></a><p><b>Section:</b>&nbsp;23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;30 Mar 1999</p>
4032 <p>The sentence introducing the Optional sequence operation table
4033 (23.1.1 paragraph 12) has two problems:</p>
4034
4035 <p>A. It says ``The operations in table 68 are provided only for the containers for which
4036 they take constant time.''<br>
4037 <br>
4038 That could be interpreted in two ways, one of them being ``Even though table 68 shows
4039 particular operations as being provided, implementations are free to omit them if they
4040 cannot implement them in constant time.''<br>
4041 <br>
4042 B. That paragraph says nothing about amortized constant time, and it should.&nbsp;</p>
4043 <p><b>Proposed resolution:</b></p>
4044 <p>Replace the wording in 23.1.1 paragraph 12&nbsp; which begins ``The operations in table 68 are provided only..."
4045 with:</p>
4046
4047 <blockquote>
4048   <p>Table 68 lists sequence operations that are provided for some types of sequential
4049   containers but not others. An implementation shall provide these operations for all
4050   container types shown in the ``container'' column, and shall implement them so as to take
4051   amortized constant time.</p>
4052 </blockquote>
4053 <hr>
4054 <a name="141"><h3>141.&nbsp;basic_string::find_last_of, find_last_not_of say pos instead of xpos</h3></a><p><b>Section:</b>&nbsp;21.3.6.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::find.last.of"> [lib.string::find.last.of]</a>, 21.3.6.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::find.last.not.of"> [lib.string::find.last.not.of]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Arch Robison&nbsp; <b>Date:</b>&nbsp;28 Apr 1999</p>
4055 <p>Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1 surely have misprints where they
4056 say:<br>
4057 <br>
4058 &#8212; <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();</tt></p>
4059
4060 <p>Surely the document meant to say ``<tt>xpos &lt; size()</tt>'' in both places.</p>
4061
4062 <p><i>[Judy Ward also sent in this issue for 21.3.6.4 with the same
4063 proposed resolution.]</i></p>
4064 <p><b>Proposed resolution:</b></p>
4065 <p>Change Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1, the line which says:<br>
4066 <br>
4067 &#8212; <tt>xpos &lt;= pos</tt> and <tt>pos &lt; size();<br>
4068 <br>
4069 </tt>to:<br>
4070 <tt><br>
4071 </tt>&#8212; <tt>xpos &lt;= pos</tt> and <tt>xpos &lt; size();</tt></p>
4072 <hr>
4073 <a name="142"><h3>142.&nbsp;lexicographical_compare complexity wrong</h3></a><p><b>Section:</b>&nbsp;25.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.lex.comparison"> [lib.alg.lex.comparison]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;20 Jun 1999</p>
4074 <p>The lexicographical_compare complexity is specified as:<br>
4075 <br>
4076 &nbsp;&nbsp;&nbsp;&nbsp; "At most min((last1 - first1), (last2 - first2))
4077 applications of the corresponding comparison."<br>
4078 <br>
4079 The best I can do is twice that expensive.</p>
4080
4081 <p>Nicolai Josuttis comments in lib-6862: You mean, to check for
4082 equality you have to check both &lt; and &gt;? Yes, IMO you are
4083 right! (and Matt states this complexity in his book)</p>
4084
4085 <p><b>Proposed resolution:</b></p>
4086 <p>Change 25.3.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.lex.comparison"> [lib.alg.lex.comparison]</a> complexity to:</p>
4087     <blockquote>
4088     At most <tt>2*min((last1 - first1), (last2 - first2))</tt>
4089     applications of the corresponding comparison.
4090     </blockquote>
4091
4092 <p>Change the example at the end of paragraph 3 to read:</p>
4093     <blockquote>
4094     [Example:<br>
4095     <br>
4096     &nbsp;&nbsp;&nbsp; for ( ; first1 != last1 &amp;&amp; first2 != last2 ;
4097     ++first1, ++first2) {<br>
4098     &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (*first1 &lt; *first2) return true;<br>
4099     &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (*first2 &lt; *first1) return false;<br>
4100     &nbsp;&nbsp;&nbsp; }<br>
4101     &nbsp;&nbsp;&nbsp; return first1 == last1 &amp;&amp; first2 != last2;<br>
4102     &nbsp;&nbsp;&nbsp;<br>
4103     --end example]
4104     </blockquote>
4105 <hr>
4106 <a name="144"><h3>144.&nbsp;Deque constructor complexity wrong </h3></a><p><b>Section:</b>&nbsp;23.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.array.cons"> [lib.array.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Herb Sutter&nbsp; <b>Date:</b>&nbsp;9 May 1999</p>
4107 <p>In 23.2.1.1 paragraph 6, the deque ctor that takes an iterator range appears
4108 to have complexity requirements which are incorrect, and which contradict the
4109 complexity requirements for insert(). I suspect that the text in question,
4110 below, was taken from vector:</p>
4111 <blockquote>
4112   <p>Complexity: If the iterators first and last are forward iterators,
4113   bidirectional iterators, or random access iterators the constructor makes only
4114   N calls to the copy constructor, and performs no reallocations, where N is
4115   last - first.</p>
4116 </blockquote>
4117 <p>The word "reallocations" does not really apply to deque. Further,
4118 all of the following appears to be spurious:</p>
4119 <blockquote>
4120   <p>It makes at most 2N calls to the copy constructor of T and log N
4121   reallocations if they are input iterators.1)</p>
4122   <p>1) The complexity is greater in the case of input iterators because each
4123   element must be added individually: it is impossible to determine the distance
4124   between first abd last before doing the copying.</p>
4125 </blockquote>
4126 <p>This makes perfect sense for vector, but not for deque. Why should deque gain
4127 an efficiency advantage from knowing in advance the number of elements to
4128 insert?</p>
4129 <p><b>Proposed resolution:</b></p>
4130 <p>In 23.2.1.1 paragraph 6, replace the Complexity description, including the
4131 footnote, with the following text (which also corrects the "abd"
4132 typo):</p>
4133 <blockquote>
4134   <p>Complexity: Makes last - first calls to the copy constructor of T.</p>
4135 </blockquote>
4136 <hr>
4137 <a name="146"><h3>146.&nbsp;complex&lt;T&gt; Inserter and Extractor need sentries</h3></a><p><b>Section:</b>&nbsp;26.3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.ops"> [lib.complex.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;12 May 1999</p>
4138 <p>The <u> extractor</u> for complex numbers is specified as:&nbsp;</p>
4139
4140 <blockquote>
4141
4142 <p>     template&lt;class T, class charT, class traits&gt;&nbsp;<br>
4143      basic_istream&lt;charT, traits&gt;&amp;&nbsp;<br>
4144      operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp;  is, complex&lt;T&gt;&amp;  x);<br>
4145 &nbsp;<br>
4146 Effects: Extracts a complex number x of the form: u, (u), or (u,v),
4147 where u is the real part and v is the imaginary part
4148 (lib.istream.formatted).&nbsp;<br>
4149 Requires: The input values be convertible to T. If bad input is
4150 encountered, calls is.setstate(ios::failbit) (which may throw
4151 ios::failure (lib.iostate.flags).&nbsp;<br>
4152 Returns: is .</p>
4153
4154 </blockquote>
4155 <p>Is it intended that the extractor for complex numbers does not skip
4156 whitespace, unlike all other extractors in the standard library do?
4157 Shouldn't a sentry be used?&nbsp;<br>
4158 <br>
4159 The <u>inserter</u> for complex numbers is specified as:</p>
4160
4161 <blockquote>
4162
4163 <p>     template&lt;class T, class charT, class traits&gt;&nbsp;<br>
4164      basic_ostream&lt;charT, traits&gt;&amp;&nbsp;<br>
4165      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;  o, const complex&lt;T&gt;&amp;  x);<br>
4166 <br>
4167 Effects: inserts the complex number x onto the stream o as if it were implemented as follows:<br>
4168 <br>
4169      template&lt;class T, class charT, class traits&gt;&nbsp;<br>
4170      basic_ostream&lt;charT, traits&gt;&amp;&nbsp;<br>
4171      operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; o, const complex&lt;T&gt;&amp; x)&nbsp;<br>
4172      {&nbsp;<br>
4173              basic_ostringstream&lt;charT, traits&gt; s;&nbsp;<br>
4174              s.flags(o.flags());&nbsp;<br>
4175              s.imbue(o.getloc());&nbsp;<br>
4176              s.precision(o.precision());&nbsp;<br>
4177              s &lt;&lt; '(' &lt;&lt; x.real() &lt;&lt; "," &lt;&lt; x.imag() &lt;&lt; ')';&nbsp;<br>
4178              return o &lt;&lt; s.str();&nbsp;<br>
4179      }</p>
4180
4181 </blockquote>
4182
4183 <p>Is it intended that the inserter for complex numbers ignores the
4184 field width and does not do any padding? If, with the suggested
4185 implementation above, the field width were set in the stream then the
4186 opening parentheses would be adjusted, but the rest not, because the
4187 field width is reset to zero after each insertion.</p>
4188
4189 <p>I think that both operations should use sentries, for sake of
4190 consistency with the other inserters and extractors in the
4191 library. Regarding the issue of padding in the inserter, I don't know
4192 what the intent was.&nbsp;</p>
4193 <p><b>Proposed resolution:</b></p>
4194 <p>After 26.3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex.ops"> [lib.complex.ops]</a> paragraph 14 (operator&gt;&gt;), add a
4195 Notes clause:</p>
4196
4197 <blockquote>
4198
4199 <p>Notes: This extraction is performed as a series of simpler
4200 extractions. Therefore, the skipping of whitespace is specified to be the
4201 same for each of the simpler extractions.</p>
4202
4203 </blockquote>
4204 <p><b>Rationale:</b></p>
4205 <p>For extractors, the note is added to make it clear that skipping whitespace
4206 follows an "all-or-none" rule.</p>
4207
4208 <p>For inserters, the LWG believes there is no defect; the standard is correct
4209 as written.</p>
4210 <hr>
4211 <a name="147"><h3>147.&nbsp;Library Intro refers to global functions that aren't global</h3></a><p><b>Section:</b>&nbsp;17.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.global.functions"> [lib.global.functions]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Lois Goldthwaite&nbsp; <b>Date:</b>&nbsp;4 Jun 1999</p>
4212 <p>The library had many global functions until 17.4.1.1 [lib.contents]
4213 paragraph 2 was added: </p>
4214
4215 <blockquote>
4216
4217 <p>All library entities except macros, operator new and operator
4218 delete are defined within the namespace std or namespaces nested
4219 within namespace std. </p>
4220
4221 </blockquote>
4222
4223 <p>It appears "global function" was never updated in the following: </p>
4224
4225 <blockquote>
4226
4227 <p>17.4.4.3 - Global functions [lib.global.functions]<br>
4228 <br>
4229 -1- It is unspecified whether any global functions in the C++ Standard
4230 Library are defined as inline (dcl.fct.spec).<br>
4231 <br>
4232 -2- A call to a global function signature described in Clauses
4233 lib.language.support through lib.input.output behaves the same as if
4234 the implementation declares no additional global function
4235 signatures.*<br>
4236 <br>
4237     [Footnote: A valid C++ program always calls the expected library
4238     global function. An implementation may also define additional
4239     global functions that would otherwise not be called by a valid C++
4240     program. --- end footnote]<br>
4241 <br>
4242 -3- A global function cannot be declared by the implementation as
4243 taking additional default arguments.&nbsp;<br>
4244 <br>
4245 17.4.4.4 - Member functions [lib.member.functions]<br>
4246 <br>
4247 -2- An implementation can declare additional non-virtual member
4248 function signatures within a class: </p>
4249
4250   <blockquote>
4251
4252 <p>-- by adding arguments with default values to a member function
4253 signature; The same latitude does not extend to the implementation of
4254 virtual or global functions, however. </p>
4255
4256   </blockquote>
4257 </blockquote>
4258 <p><b>Proposed resolution:</b></p>
4259 <p>     Change "global" to "global or non-member" in:</p>
4260 <blockquote>
4261   <p>17.4.4.3 [lib.global.functions] section title,<br>
4262   17.4.4.3 [lib.global.functions] para 1,<br>
4263   17.4.4.3 [lib.global.functions] para 2 in 2 places plus 2
4264            places in the footnote,<br>
4265   17.4.4.3 [lib.global.functions] para 3,<br>
4266   17.4.4.4 [lib.member.functions] para 2</p>
4267 </blockquote>
4268 <p><b>Rationale:</b></p>
4269 <p>
4270 Because operator new and delete are global, the proposed resolution
4271 was changed from "non-member" to "global or non-member.
4272 </p>
4273 <hr>
4274 <a name="148"><h3>148.&nbsp;Functions in the example facet BoolNames should be const</h3></a><p><b>Section:</b>&nbsp;22.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Jeremy Siek&nbsp; <b>Date:</b>&nbsp;3 Jun 1999</p>
4275 <p>In 22.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> paragraph 13, the do_truename() and
4276 do_falsename() functions in the example facet BoolNames should be
4277 const. The functions they are overriding in
4278 numpunct_byname&lt;char&gt; are const. </p>
4279 <p><b>Proposed resolution:</b></p>
4280 <p>In 22.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a> paragraph 13, insert "const" in
4281 two places:</p>
4282 <blockquote>
4283   <p><tt>string do_truename() const { return "Oui Oui!"; }<br>
4284   string do_falsename() const { return "Mais Non!"; }</tt></p>
4285 </blockquote>
4286 <hr>
4287 <a name="150"><h3>150.&nbsp;Find_first_of says integer instead of iterator </h3></a><p><b>Section:</b>&nbsp;25.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.find.first.of"> [lib.alg.find.first.of]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt McClure&nbsp; <b>Date:</b>&nbsp;30 Jun 1999</p>
4288 <p><b>Proposed resolution:</b></p>
4289 <p>Change 25.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.find.first.of"> [lib.alg.find.first.of]</a> paragraph 2 from:</p>
4290
4291 <blockquote>
4292 <p>Returns: The first iterator i in the range [first1, last1) such
4293 that for some <u>integer</u> j in the range [first2, last2) ...</p>
4294 </blockquote>
4295
4296 <p>to:</p>
4297
4298 <blockquote>
4299 <p>Returns: The first iterator i in the range [first1, last1) such
4300 that for some iterator j in the range [first2, last2) ...</p>
4301 </blockquote>
4302 <hr>
4303 <a name="151"><h3>151.&nbsp;Can't currently clear() empty container</h3></a><p><b>Section:</b>&nbsp;23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Ed Brey&nbsp; <b>Date:</b>&nbsp;21 Jun 1999</p>
4304 <p>For both sequences and associative containers, a.clear() has the
4305 semantics of erase(a.begin(),a.end()), which is undefined for an empty
4306 container since erase(q1,q2) requires that q1 be dereferenceable
4307 (23.1.1,3 and 23.1.2,7).  When the container is empty, a.begin() is
4308 not dereferenceable.<br>
4309 <br>
4310 The requirement that q1 be unconditionally dereferenceable causes many
4311 operations to be intuitively undefined, of which clearing an empty
4312 container is probably the most dire.<br>
4313 <br>
4314 Since q1 and q2 are only referenced in the range [q1, q2), and [q1,
4315 q2) is required to be a valid range, stating that q1 and q2 must be
4316 iterators or certain kinds of iterators is unnecessary.
4317 </p>
4318 <p><b>Proposed resolution:</b></p>
4319 <p>In 23.1.1, paragraph 3, change:</p>
4320 <blockquote>
4321   <p>p and q2 denote valid iterators to a, q <u> and q1</u> denote valid dereferenceable iterators to a, [q1, q2) denotes a valid range</p>
4322 </blockquote>
4323 <p>to:</p>
4324 <blockquote>
4325   <p>p denotes a valid iterator to a, q denotes a valid dereferenceable iterator to a, [q1, q2) denotes a valid range<u>
4326   in a</u></p>
4327 </blockquote>
4328 <p>In 23.1.2, paragraph 7, change:</p>
4329 <blockquote>
4330   <p>p and q2 are valid iterators to a, q <u> and q1</u> are valid dereferenceable
4331   iterators to a, [q1, q2) is a valid range</p>
4332 </blockquote>
4333 <p>to</p>
4334 <blockquote>
4335   <p>p is a valid iterator to a, q is a valid dereferenceable iterator to a, [q1, q2) is a valid range
4336   <u>into a</u></p>
4337 </blockquote>
4338 <hr>
4339 <a name="152"><h3>152.&nbsp;Typo in <tt>scan_is()</tt> semantics</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4340 <p>The semantics of <tt>scan_is()</tt> (paragraphs 4 and 6) is not exactly described
4341 because there is no function <tt>is()</tt> which only takes a character as
4342 argument. Also, in the effects clause (paragraph 3), the semantic is also kept
4343 vague.</p>
4344 <p><b>Proposed resolution:</b></p>
4345 <p>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> paragraphs 4 and 6, change the returns
4346 clause from:</p>
4347 <blockquote>
4348   <p>"... such that <tt>is(*p)</tt>
4349 would..."</p>
4350 </blockquote>
4351 <p>to:&nbsp; "... such that <tt>is(m, *p)</tt>
4352  would...."</p>
4353 <hr>
4354 <a name="153"><h3>153.&nbsp;Typo in <tt>narrow()</tt> semantics</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4355 <p>The description of the array version of <tt>narrow()</tt> (in
4356 paragraph 11) is flawed: There is no member <tt>do_narrow()</tt> which
4357 takes only three arguments because in addition to the range a default
4358 character is needed.</p>
4359
4360 <p>Additionally, for both <tt>widen</tt> and <tt>narrow</tt> we have
4361 two signatures followed by a <b>Returns</b> clause that only addresses
4362 one of them.</p>
4363
4364 <p><b>Proposed resolution:</b></p>
4365 <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>
4366 paragraph 10 from:</p>
4367 <p>&nbsp;&nbsp;&nbsp; Returns: do_widen(low, high, to).</p>
4368
4369 <p>to:</p>
4370 <p>&nbsp;&nbsp;&nbsp; Returns: do_widen(c) or do_widen(low, high, to),
4371 respectively.</p>
4372
4373 <p>Change 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 and 11 from:</p>
4374 <pre>        char        narrow(char c, char /*dfault*/) const;
4375         const char* narrow(const char* low, const char* high,
4376                            char /*dfault*/, char* to) const;</pre>
4377 <pre>        Returns: do_narrow(low, high, to).</pre>
4378 <p>to:</p>
4379 <pre>        char        narrow(char c, char dfault) const;
4380         const char* narrow(const char* low, const char* high,
4381                            char dfault, char* to) const;</pre>
4382 <pre>        Returns: do_narrow(c, dfault) or
4383                  do_narrow(low, high, dfault, to), respectively.</pre>
4384
4385 <p><i>[Kona: 1) the problem occurs in additional places, 2) a user
4386 defined version could be different.]</i></p>
4387
4388 <p><i>[Post-Tokyo: Dietmar provided the above wording at the request of
4389 the LWG. He could find no other places the problem occurred. He
4390 asks for clarification of the Kona "a user defined
4391 version..." comment above.  Perhaps it was a circuitous way of
4392 saying "dfault" needed to be uncommented?]</i></p>
4393
4394 <p><i>[Post-Toronto: the issues list maintainer has merged in the
4395 proposed resolution from issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#207">207</a>, which addresses the
4396 same paragraphs.]</i></p>
4397 <hr>
4398 <a name="154"><h3>154.&nbsp;Missing <tt>double</tt> specifier for <tt>do_get()</tt>
4399 </h3></a><p><b>Section:</b>&nbsp;22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4400 <p>The table in paragraph 7 for the length modifier does not list the length
4401 modifier <tt>l</tt> to be applied if the type is <tt>double</tt>. Thus, the
4402 standard asks the implementation to do undefined things when using <tt>scanf()</tt>
4403 (the missing length modifier for <tt>scanf()</tt> when scanning <tt>double</tt>s
4404 is actually a problem I found quite often in production code, too).</p>
4405 <p><b>Proposed resolution:</b></p>
4406 <p>In 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>, paragraph 7, add a row in the Length
4407 Modifier table to say that for <tt>double</tt> a length modifier
4408 <tt>l</tt> is to be used.</p>
4409 <p><b>Rationale:</b></p>
4410 <p>The standard makes an embarrassing beginner's mistake.</p>
4411 <hr>
4412 <a name="155"><h3>155.&nbsp;Typo in naming the class defining the class <tt>Init</tt>
4413 </h3></a><p><b>Section:</b>&nbsp;27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4414 <p>There are conflicting statements about where the class
4415 <tt>Init</tt> is defined. According to 27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> paragraph 2
4416 it is defined as <tt>basic_ios::Init</tt>, according to 27.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> it is defined as <tt>ios_base::Init</tt>.</p>
4417 <p><b>Proposed resolution:</b></p>
4418 <p>Change 27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a> paragraph 2 from
4419 "<tt>basic_ios::Init"</tt> to
4420 "<tt>ios_base::Init"</tt>.</p>
4421 <p><b>Rationale:</b></p>
4422 <p>Although not strictly wrong, the standard was misleading enough to warrant
4423 the change.</p>
4424 <hr>
4425 <a name="156"><h3>156.&nbsp;Typo in <tt>imbue()</tt> description</h3></a><p><b>Section:</b>&nbsp;27.4.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4426 <p>There is a small discrepancy between the declarations of
4427 <tt>imbue()</tt>: in 27.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base"> [lib.ios.base]</a> the argument is passed as
4428 <tt>locale const&amp;</tt> (correct), in 27.4.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> it
4429 is passed as <tt>locale const</tt> (wrong).</p>
4430 <p><b>Proposed resolution:</b></p>
4431 <p>In 27.4.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.locales"> [lib.ios.base.locales]</a> change the <tt>imbue</tt> argument
4432 from "<tt>locale const" to "locale
4433 const&amp;".</tt></p>
4434 <hr>
4435 <a name="158"><h3>158.&nbsp;Underspecified semantics for <tt>setbuf()</tt>
4436 </h3></a><p><b>Section:</b>&nbsp;27.5.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4437 <p>The default behavior of <tt>setbuf()</tt> is described only for the
4438 situation that <tt>gptr() != 0 &amp;&amp; gptr() != egptr()</tt>:
4439 namely to do nothing.  What has to be done in other situations&nbsp;
4440 is not described although there is actually only one reasonable
4441 approach, namely to do nothing, too.</p>
4442
4443 <p>Since changing the buffer would almost certainly mess up most
4444 buffer management of derived classes unless these classes do it
4445 themselves, the default behavior of <tt>setbuf()</tt> should always be
4446 to do nothing.</p>
4447 <p><b>Proposed resolution:</b></p>
4448 <p>Change 27.5.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a>, paragraph 3, Default behavior,
4449 to: "Default behavior: Does nothing. Returns this."</p>
4450 <hr>
4451 <a name="159"><h3>159.&nbsp;Strange use of <tt>underflow()</tt>
4452 </h3></a><p><b>Section:</b>&nbsp;27.5.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.get"> [lib.streambuf.virt.get]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4453 <p>The description of the meaning of the result of
4454 <tt>showmanyc()</tt> seems to be rather strange: It uses calls to
4455 <tt>underflow()</tt>. Using <tt>underflow()</tt> is strange because
4456 this function only reads the current character but does not extract
4457 it, <tt>uflow()</tt> would extract the current character. This should
4458 be fixed to use <tt>sbumpc()</tt> instead.</p>
4459 <p><b>Proposed resolution:</b></p>
4460 <p>Change 27.5.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.get"> [lib.streambuf.virt.get]</a> paragraph 1,
4461 <tt>showmanyc()</tt>returns clause, by replacing the word
4462 "supplied" with the words "extracted from the
4463 stream".</p>
4464 <hr>
4465 <a name="160"><h3>160.&nbsp;Typo: Use of non-existing function <tt>exception()</tt>
4466 </h3></a><p><b>Section:</b>&nbsp;27.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream"> [lib.istream]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4467 <p>The paragraph 4 refers to the function <tt>exception()</tt> which
4468 is not defined. Probably, the referred function is
4469 <tt>basic_ios&lt;&gt;::exceptions()</tt>.</p>
4470 <p><b>Proposed resolution:</b></p>
4471 <p>In 27.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream"> [lib.istream]</a>, 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>, paragraph 1,
4472 27.6.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream"> [lib.ostream]</a>, paragraph 3, and 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>,
4473 paragraph 1, change "<tt>exception()" to
4474 "exceptions()"</tt>.</p>
4475
4476 <p><i>[Note to Editor: "exceptions" with an "s"
4477 is the correct spelling.]</i></p>
4478 <hr>
4479 <a name="161"><h3>161.&nbsp;Typo: <tt>istream_iterator</tt> vs. <tt>istreambuf_iterator</tt>
4480 </h3></a><p><b>Section:</b>&nbsp;27.6.1.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4481 <p>The note in the second paragraph pretends that the first argument
4482 is an object of type <tt>istream_iterator</tt>. This is wrong: It is
4483 an object of type <tt>istreambuf_iterator</tt>.</p>
4484 <p><b>Proposed resolution:</b></p>
4485 <p>Change 27.6.1.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.arithmetic"> [lib.istream.formatted.arithmetic]</a> from:</p>
4486 <blockquote>
4487   <p>The first argument provides an object of the istream_iterator class...</p>
4488 </blockquote>
4489 <p>to</p>
4490 <blockquote>
4491   <p>The first argument provides an object of the istreambuf_iterator class...</p>
4492 </blockquote>
4493 <hr>
4494 <a name="164"><h3>164.&nbsp;do_put() has apparently unused fill argument</h3></a><p><b>Section:</b>&nbsp;22.2.5.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.put.virtuals"> [lib.locale.time.put.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
4495 <p>In 22.2.5.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.put.virtuals"> [lib.locale.time.put.virtuals]</a> the do_put() function is specified
4496 as taking a fill character as an argument, but the description of the
4497 function does not say whether the character is used at all and, if so,
4498 in which way. The same holds for any format control parameters that
4499 are accessible through the ios_base&amp; argument, such as the
4500 adjustment or the field width. Is strftime() supposed to use the fill
4501 character in any way? In any case, the specification of
4502 time_put.do_put() looks inconsistent to me.<br> <br> Is the
4503 signature of do_put() wrong, or is the effects clause incomplete?</p>
4504 <p><b>Proposed resolution:</b></p>
4505 <p>Add the following note after 22.2.5.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.put.virtuals"> [lib.locale.time.put.virtuals]</a>
4506 paragraph 2:</p>
4507 <blockquote>
4508   <p>  [Note: the <tt>fill</tt> argument may be used in the implementation-defined  formats, or by derivations.  A space character is a reasonable default
4509   for this argument. --end Note]</p>
4510 </blockquote>
4511 <p><b>Rationale:</b></p>
4512 <p>The LWG felt that while the normative text was correct,
4513 users need some guidance on what to pass for the <tt>fill</tt>
4514 argument since the standard doesn't say how it's used.</p>
4515 <hr>
4516 <a name="165"><h3>165.&nbsp;<tt>xsputn()</tt>, <tt>pubsync()</tt> never called by <tt>basic_ostream</tt> members?</h3></a><p><b>Section:</b>&nbsp;27.6.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream"> [lib.ostream]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4517 <p>Paragraph 2 explicitly states that none of the <tt>basic_ostream</tt>
4518 functions falling into one of the groups "formatted output functions"
4519 and "unformatted output functions" calls any stream buffer function
4520 which might call a virtual function other than <tt>overflow()</tt>. Basically
4521 this is fine but this implies that <tt>sputn()</tt> (this function would call
4522 the virtual function <tt>xsputn()</tt>) is never called by any of the standard
4523 output functions. Is this really intended? At minimum it would be convenient to
4524 call <tt>xsputn()</tt> for strings... Also, the statement that <tt>overflow()</tt>
4525 is the only virtual member of <tt>basic_streambuf</tt> called is in conflict
4526 with the definition of <tt>flush()</tt> which calls <tt>rdbuf()-&gt;pubsync()</tt>
4527 and thereby the virtual function <tt>sync()</tt> (<tt>flush()</tt> is listed
4528 under "unformatted output functions").</p>
4529 <p>In addition, I guess that the sentence starting with "They may use other
4530 public members of <tt>basic_ostream</tt> ..." probably was intended to
4531 start with "They may use other public members of <tt>basic_streamuf</tt>..."
4532 although the problem with the virtual members exists in both cases.</p>
4533 <p>I see two obvious resolutions:</p>
4534 <ol>
4535   <li>state in a footnote that this means that <tt>xsputn()</tt> will never be
4536     called by any ostream member and that this is intended.</li>
4537   <li>relax the restriction and allow calling <tt>overflow()</tt> and <tt>xsputn()</tt>.
4538     Of course, the problem with <tt>flush()</tt> has to be resolved in some way.</li>
4539 </ol>
4540 <p><b>Proposed resolution:</b></p>
4541 <p>Change the last sentence of 27.6.2.1 (lib.ostream) paragraph 2 from:</p>
4542 <blockquote>
4543   <p>They may use other public members of basic_ostream except that they do not
4544   invoke any virtual members of rdbuf() except overflow().</p>
4545 </blockquote>
4546 <p>to:</p>
4547 <blockquote>
4548   <p>They may use other public members of basic_ostream except that they shall
4549   not invoke any virtual members of rdbuf() except overflow(), xsputn(), and
4550   sync().</p>
4551 </blockquote>
4552
4553 <p><i>[Kona: the LWG believes this is a problem. Wish to ask Jerry or
4554 PJP why the standard is written this way.]</i></p>
4555
4556 <p><i>[Post-Tokyo: Dietmar supplied wording at the request of the
4557 LWG. He comments: The rules can be made a little bit more specific if
4558 necessary be explicitly spelling out what virtuals are allowed to be
4559 called from what functions and eg to state specifically that flush()
4560 is allowed to call sync() while other functions are not.]</i></p>
4561 <hr>
4562 <a name="167"><h3>167.&nbsp;Improper use of <tt>traits_type::length()</tt>
4563 </h3></a><p><b>Section:</b>&nbsp;27.6.2.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4564 <p>Paragraph 4 states that the length is determined using
4565 <tt>traits::length(s)</tt>.  Unfortunately, this function is not
4566 defined for example if the character type is <tt>wchar_t</tt> and the
4567 type of <tt>s</tt> is <tt>char const*</tt>. Similar problems exist if
4568 the character type is <tt>char</tt> and the type of <tt>s</tt> is
4569 either <tt>signed char const*</tt> or <tt>unsigned char
4570 const*</tt>.</p>
4571 <p><b>Proposed resolution:</b></p>
4572 <p>Change 27.6.2.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a> paragraph 4 from:</p>
4573 <blockquote>
4574   <p>Effects: Behaves like an formatted inserter (as described in
4575   lib.ostream.formatted.reqmts) of out. After a sentry object is
4576   constructed it inserts characters. The number of characters starting
4577   at s to be inserted is traits::length(s). Padding is determined as
4578   described in lib.facet.num.put.virtuals. The traits::length(s)
4579   characters starting at s are widened using out.widen
4580   (lib.basic.ios.members). The widened characters and any required
4581   padding are inserted into out. Calls width(0).</p>
4582 </blockquote>
4583 <p>to:</p>
4584 <blockquote>
4585   <p>Effects: Behaves like a formatted inserter (as described in
4586   lib.ostream.formatted.reqmts) of out. After a sentry object is
4587   constructed it inserts <i>n</i> characters starting at <i>s</i>,
4588   where <i>n</i> is the number that would be computed as if by:</p>
4589   <ul>
4590   <li>traits::length(s) for the overload where the first argument is of
4591     type basic_ostream&lt;charT, traits&gt;&amp; and the second is
4592     of type const charT*, and also for the overload where the first
4593     argument is of type basic_ostream&lt;char, traits&gt;&amp; and
4594     the second is of type const char*.</li>
4595   <li>std::char_traits&lt;char&gt;::length(s)
4596     for the overload where the first argument is of type
4597     basic_ostream&lt;charT, traits&gt;&amp; and the second is of type
4598     const char*.</li>
4599   <li>traits::length(reinterpret_cast&lt;const char*&gt;(s))
4600     for the other two overloads.</li>
4601   </ul>
4602   <p>Padding is determined as described in
4603   lib.facet.num.put.virtuals. The <i>n</i> characters starting at
4604   <i>s</i> are widened using out.widen (lib.basic.ios.members).  The
4605   widened characters and any required padding are inserted into
4606   out. Calls width(0).</p>
4607 </blockquote>
4608
4609 <p><i>[Santa Cruz: Matt supplied new wording]</i></p>
4610
4611 <p><i>[Kona: changed "where <i>n</i> is" to " where <i>n</i> is the
4612   number that would be computed as if by"]</i></p>
4613
4614 <p><b>Rationale:</b></p>
4615 <p>We have five separate cases.  In two of them we can use the
4616 user-supplied traits class without any fuss.  In the other three we
4617 try to use something as close to that user-supplied class as possible.
4618 In two cases we've got a traits class that's appropriate for
4619 char and what we've got is a const signed char* or a const
4620 unsigned char*; that's close enough so we can just use a reinterpret
4621 cast, and continue to use the user-supplied traits class.  Finally,
4622 there's one case where we just have to give up: where we've got a
4623 traits class for some arbitrary charT type, and we somehow have to
4624 deal with a const char*.  There's nothing better to do but fall back
4625 to char_traits&lt;char&gt;</p>
4626 <hr>
4627 <a name="168"><h3>168.&nbsp;Typo: formatted vs. unformatted</h3></a><p><b>Section:</b>&nbsp;27.6.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4628 <p>The first paragraph begins with a descriptions what has to be done
4629 in <i>formatted</i> output functions. Probably this is a typo and the
4630 paragraph really want to describe unformatted output functions...</p>
4631 <p><b>Proposed resolution:</b></p>
4632 <p>In 27.6.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.unformatted"> [lib.ostream.unformatted]</a> paragraph 1, the first and last
4633 sentences, change the word "formatted" to
4634 "unformatted":</p>
4635 <blockquote>
4636   <p>"Each <b>unformatted </b> output function begins ..."<br>
4637   "... value specified for the <b>unformatted </b>  output
4638   function."</p>
4639 </blockquote>
4640 <hr>
4641 <a name="169"><h3>169.&nbsp;Bad efficiency of <tt>overflow()</tt> mandated</h3></a><p><b>Section:</b>&nbsp;27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4642 <p>Paragraph 8, Notes, of this section seems to mandate an extremely
4643 inefficient way of buffer handling for <tt>basic_stringbuf</tt>,
4644 especially in view of the restriction that <tt>basic_ostream</tt>
4645 member functions are not allowed to use <tt>xsputn()</tt> (see 27.6.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream"> [lib.ostream]</a>): For each character to be inserted, a new buffer
4646 is to be created.</p>
4647 <p>Of course, the resolution below requires some handling of
4648 simultaneous input and output since it is no longer possible to update
4649 <tt>egptr()</tt> whenever <tt>epptr()</tt> is changed. A possible
4650 solution is to handle this in <tt>underflow()</tt>.</p>
4651 <p><b>Proposed resolution:</b></p>
4652 <p>In 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a> paragraph 8, Notes, insert the words
4653 "at least" as in the following:</p>
4654 <blockquote>
4655   <p>To make a write position available, the function reallocates (or initially
4656   allocates) an array object with a sufficient number of elements to hold the
4657   current array object (if any), plus <b>at least</b> one additional write
4658   position.</p>
4659 </blockquote>
4660 <hr>
4661 <a name="170"><h3>170.&nbsp;Inconsistent definition of <tt>traits_type</tt>
4662 </h3></a><p><b>Section:</b>&nbsp;27.7.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4663 <p>The classes <tt>basic_stringstream</tt> (27.7.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a>),
4664 <tt>basic_istringstream</tt> (27.7.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istringstream"> [lib.istringstream]</a>), and
4665 <tt>basic_ostringstream</tt> (27.7.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostringstream"> [lib.ostringstream]</a>) are inconsistent
4666 in their definition of the type <tt>traits_type</tt>: For
4667 <tt>istringstream</tt>, this type is defined, for the other two it is
4668 not. This should be consistent.</p>
4669 <p><b>Proposed resolution:</b></p>
4670 <p><b>Proposed resolution:</b></p> <p>To the declarations of
4671 <tt>basic_ostringstream</tt> (27.7.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostringstream"> [lib.ostringstream]</a>) and
4672 <tt>basic_stringstream</tt> (27.7.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringstream"> [lib.stringstream]</a>) add:</p>
4673 <blockquote>
4674 <pre>typedef traits traits_type;</pre>
4675 </blockquote>
4676 <hr>
4677 <a name="171"><h3>171.&nbsp;Strange <tt>seekpos()</tt> semantics due to joint position</h3></a><p><b>Section:</b>&nbsp;27.8.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Jul 1999</p>
4678 <p>Overridden virtual functions, seekpos()</p> <p>In 27.8.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf"> [lib.filebuf]</a> paragraph 3, it is stated that a joint input and
4679 output position is maintained by <tt>basic_filebuf</tt>. Still, the
4680 description of <tt>seekpos()</tt> seems to talk about different file
4681 positions. In particular, it is unclear (at least to me) what is
4682 supposed to happen to the output buffer (if there is one) if only the
4683 input position is changed. The standard seems to mandate that the
4684 output buffer is kept and processed as if there was no positioning of
4685 the output position (by changing the input position). Of course, this
4686 can be exactly what you want if the flag <tt>ios_base::ate</tt> is
4687 set. However, I think, the standard should say something like
4688 this:</p>
4689 <ul>
4690   <li>If <tt>(which &amp; mode) == 0</tt> neither read nor write position is
4691     changed and the call fails. Otherwise, the joint read and write position is
4692     altered to correspond to <tt>sp</tt>.</li>
4693   <li>If there is an output buffer, the output sequences is updated and any
4694     unshift sequence is written before the position is altered.</li>
4695   <li>If there is an input buffer, the input sequence is updated after the
4696     position is altered.</li>
4697 </ul>
4698 <p>Plus the appropriate error handling, that is...</p>
4699 <p><b>Proposed resolution:</b></p>
4700 <p>Change the unnumbered paragraph in 27.8.1.4 (lib.filebuf.virtuals) before
4701 paragraph 14 from:</p>
4702 <blockquote>
4703   <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
4704   ios_base::out);</p>
4705   <p>Alters the file position, if possible, to correspond to the position stored
4706   in sp (as described below).</p>
4707   <p>- if (which&amp;ios_base::in)!=0, set the file position to sp, then update
4708   the input sequence</p>
4709   <p>- if (which&amp;ios_base::out)!=0, then update the output sequence, write
4710   any unshift sequence, and set the file position to sp.</p>
4711 </blockquote>
4712 <p>to:</p>
4713 <blockquote>
4714   <p>pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in |
4715   ios_base::out);</p>
4716   <p>Alters the file position, if possible, to correspond to the position stored
4717   in sp (as described below). Altering the file position performs as follows:</p>
4718   <p>1. if (om &amp; ios_base::out)!=0, then update the output sequence and
4719   write any unshift sequence;</p>
4720   <p>2. set the file position to sp;</p>
4721   <p>3. if (om &amp; ios_base::in)!=0, then update the input sequence;</p>
4722   <p>where om is the open mode passed to the last call to open(). The operation
4723   fails if is_open() returns false.</p>
4724 </blockquote>
4725
4726 <p><i>[Kona: Dietmar is working on a proposed resolution.]</i></p>
4727 <p><i>[Post-Tokyo: Dietmar supplied the above wording.]</i></p>
4728 <hr>
4729 <a name="172"><h3>172.&nbsp;Inconsistent types for <tt>basic_istream::ignore()</tt>
4730 </h3></a><p><b>Section:</b>&nbsp;27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Greg Comeau, Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
4731 <p>In 27.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream"> [lib.istream]</a> the function
4732 <tt>ignore()</tt> gets an object of type <tt>streamsize</tt> as first
4733 argument. However, in 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>
4734 paragraph 23 the first argument is of type <tt>int.</tt></p>
4735
4736 <p>As far as I can see this is not really a contradiction because
4737 everything is consistent if <tt>streamsize</tt> is typedef to be
4738 <tt>int</tt>. However, this is almost certainly not what was
4739 intended. The same thing happened to <tt>basic_filebuf::setbuf()</tt>,
4740 as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#173">173</a>.</p>
4741
4742 <p>Darin Adler also
4743 submitted this issue, commenting: Either 27.6.1.1 should be modified
4744 to show a first parameter of type int, or 27.6.1.3 should be modified
4745 to show a first parameter of type streamsize and use
4746 numeric_limits&lt;streamsize&gt;::max.</p>
4747 <p><b>Proposed resolution:</b></p>
4748 <p>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> paragraph 23 and 24, change both uses
4749 of <tt>int</tt> in the description of <tt>ignore()</tt> to
4750 <tt>streamsize</tt>.</p>
4751 <hr>
4752 <a name="173"><h3>173.&nbsp;Inconsistent types for <tt>basic_filebuf::setbuf()</tt>
4753 </h3></a><p><b>Section:</b>&nbsp;27.8.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Greg Comeau, Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
4754
4755 <p>
4756 In 27.8.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf"> [lib.filebuf]</a> the function <tt>setbuf()</tt> gets an
4757 object of type <tt>streamsize</tt> as second argument. However, in
4758 27.8.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a> paragraph 9 the second argument is of type
4759 <tt>int</tt>.
4760 </p>
4761
4762 <p>
4763 As far as I can see this is not really a contradiction because
4764 everything is consistent if <tt>streamsize</tt> is typedef to be
4765 <tt>int</tt>. However, this is almost certainly not what was
4766 intended. The same thing happened to <tt>basic_istream::ignore()</tt>,
4767 as described in issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#172">172</a>.
4768 </p>
4769
4770 <p><b>Proposed resolution:</b></p>
4771 <p>In 27.8.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.virtuals"> [lib.filebuf.virtuals]</a> paragraph 9, change all uses of
4772 <tt>int</tt> in the description of <tt>setbuf()</tt> to
4773 <tt>streamsize</tt>.</p>
4774 <hr>
4775 <a name="174"><h3>174.&nbsp;Typo: <tt>OFF_T</tt> vs. <tt>POS_T</tt>
4776 </h3></a><p><b>Section:</b>&nbsp;D.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.ios.members"> [depr.ios.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
4777 <p>According to paragraph 1 of this section, <tt>streampos</tt> is the
4778 type <tt>OFF_T</tt>, the same type as <tt>streamoff</tt>. However, in
4779 paragraph 6 the <tt>streampos</tt> gets the type <tt>POS_T</tt></p>
4780 <p><b>Proposed resolution:</b></p>
4781 <p>Change D.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.ios.members"> [depr.ios.members]</a> paragraph 1 from "<tt>typedef
4782 OFF_T streampos;</tt>" to "<tt>typedef POS_T
4783 streampos;</tt>"</p>
4784 <hr>
4785 <a name="175"><h3>175.&nbsp;Ambiguity for <tt>basic_streambuf::pubseekpos()</tt> and a few other functions.</h3></a><p><b>Section:</b>&nbsp;D.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.ios.members"> [depr.ios.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
4786 <p>According to paragraph 8 of this section, the methods
4787 <tt>basic_streambuf::pubseekpos()</tt>,
4788 <tt>basic_ifstream::open()</tt>, and <tt>basic_ofstream::open</tt>
4789 "may" be overloaded by a version of this function taking the
4790 type <tt>ios_base::open_mode</tt> as last argument argument instead of
4791 <tt>ios_base::openmode</tt> (<tt>ios_base::open_mode</tt> is defined
4792 in this section to be an alias for one of the integral types). The
4793 clause specifies, that the last argument has a default argument in
4794 three cases.  However, this generates an ambiguity with the overloaded
4795 version because now the arguments are absolutely identical if the last
4796 argument is not specified.</p>
4797 <p><b>Proposed resolution:</b></p>
4798 <p>In D.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.ios.members"> [depr.ios.members]</a> paragraph 8, remove the default arguments for
4799 <tt>basic_streambuf::pubseekpos()</tt>,
4800 <tt>basic_ifstream::open()</tt>, and
4801 <tt>basic_ofstream::open().</tt></p>
4802 <hr>
4803 <a name="176"><h3>176.&nbsp;<tt>exceptions()</tt> in <tt>ios_base</tt>...?</h3></a><p><b>Section:</b>&nbsp;D.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.ios.members"> [depr.ios.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;23 Jul 1999</p>
4804 <p>The "overload" for the function <tt>exceptions()</tt> in
4805 paragraph 8 gives the impression that there is another function of
4806 this function defined in class <tt>ios_base</tt>. However, this is not
4807 the case. Thus, it is hard to tell how the semantics (paragraph 9) can
4808 be implemented: "Call the corresponding member function specified
4809 in clause 27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a>."</p>
4810 <p><b>Proposed resolution:</b></p>
4811 <p>In D.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.ios.members"> [depr.ios.members]</a> paragraph 8, move the declaration of the
4812 function <tt>exceptions()</tt>into class <tt>basic_ios</tt>.</p>
4813 <hr>
4814 <a name="179"><h3>179.&nbsp;Comparison of const_iterators to iterators doesn't work</h3></a><p><b>Section:</b>&nbsp;23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;2 Jul 1998</p>
4815 <p>Currently the following will not compile on two well-known standard
4816 library implementations:</p>
4817
4818 <blockquote>
4819   <pre>#include &lt;set&gt;
4820 using namespace std;
4821
4822 void f(const set&lt;int&gt; &amp;s)
4823 {
4824   set&lt;int&gt;::iterator i;
4825   if (i==s.end()); // s.end() returns a const_iterator
4826 }</pre>
4827 </blockquote>
4828
4829 <p>
4830 The reason this doesn't compile is because operator== was implemented
4831 as a member function of the nested classes set:iterator and
4832 set::const_iterator, and there is no conversion from const_iterator to
4833 iterator. Surprisingly, (s.end() == i) does work, though, because of
4834 the conversion from iterator to const_iterator.
4835 </p>
4836
4837 <p>
4838 I don't see a requirement anywhere in the standard that this must
4839 work. Should there be one?  If so, I think the requirement would need
4840 to be added to the tables in section 24.1.1. I'm not sure about the
4841 wording.  If this requirement existed in the standard, I would think
4842 that implementors would have to make the comparison operators
4843 non-member functions.</p>
4844
4845 <p>This issues was also raised on comp.std.c++ by Darin
4846 Adler.&nbsp; The example given was:</p>
4847
4848 <blockquote>
4849   <pre>bool check_equal(std::deque&lt;int&gt;::iterator i,
4850 std::deque&lt;int&gt;::const_iterator ci)
4851 {
4852 return i == ci;
4853 }</pre>
4854 </blockquote>
4855
4856 <p>Comment from John Potter:</p>
4857 <blockquote>
4858     <p>
4859     In case nobody has noticed, accepting it will break reverse_iterator.
4860     </p>
4861
4862     <p>
4863     The fix is to make the comparison operators templated on two types.
4864     </p>
4865
4866     <pre>    template &lt;class Iterator1, class Iterator2&gt;
4867     bool operator== (reverse_iterator&lt;Iterator1&gt; const&amp; x,
4868                      reverse_iterator&lt;Iterator2&gt; const&amp; y);
4869     </pre>
4870
4871     <p>
4872     Obviously:  return x.base() == y.base();
4873     </p>
4874
4875     <p>
4876     Currently, no reverse_iterator to const_reverse_iterator compares are
4877     valid.
4878     </p>
4879
4880     <p>
4881     BTW, I think the issue is in support of bad code.  Compares should be
4882     between two iterators of the same type.  All std::algorithms require
4883     the begin and end iterators to be of the same type.
4884     </p>
4885 </blockquote>
4886 <p><b>Proposed resolution:</b></p>
4887 <p>Insert this paragraph after 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> paragraph 7:</p>
4888 <blockquote>
4889   <p>In the expressions</p>
4890   <pre>    i == j
4891     i != j
4892     i &lt; j
4893     i &lt;= j
4894     i &gt;= j
4895     i &gt; j
4896     i - j
4897   </pre>
4898   <p>Where i and j denote objects of a container's iterator type,
4899   either or both may be replaced by an object of the container's
4900   const_iterator type referring to the same element with no
4901   change in semantics.</p>
4902 </blockquote>
4903
4904 <p><i>[post-Toronto: Judy supplied a proposed resolution saying that
4905 <tt>iterator</tt> and <tt>const_iterator</tt> could be freely mixed in
4906 iterator comparison and difference operations.]</i></p>
4907
4908 <p><i>[Redmond: Dave and Howard supplied a new proposed resolution which
4909 explicitly listed expressions; there was concern that the previous
4910 proposed resolution was too informal.]</i></p>
4911 <p><b>Rationale:</b></p>
4912 <p>
4913 The LWG believes it is clear that the above wording applies only to
4914 the nested types <tt>X::iterator</tt> and <tt>X::const_iterator</tt>,
4915 where <tt>X</tt> is a container.  There is no requirement that
4916 <tt>X::reverse_iterator</tt> and <tt>X::const_reverse_iterator</tt>
4917 can be mixed.  If mixing them is considered important, that's a
4918 separate issue.  (Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#280">280</a>.)
4919 </p>
4920 <hr>
4921 <a name="181"><h3>181.&nbsp;make_pair() unintended behavior</h3></a><p><b>Section:</b>&nbsp;20.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.pairs"> [lib.pairs]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;3 Aug 1999</p>
4922 <p>The claim has surfaced in Usenet that expressions such as<br>
4923 <br>
4924 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>make_pair("abc", 3)</tt><br>
4925 <br>
4926 are illegal, notwithstanding their use in examples, because template instantiation tries to bind the first template
4927 parameter to <tt> const char (&amp;)[4]</tt>, which type is uncopyable.<br>
4928 <br>
4929 I doubt anyone intended that behavior...
4930 </p>
4931 <p><b>Proposed resolution:</b></p>
4932 <p>In 20.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.utility"> [lib.utility]</a>, paragraph 1 change the following
4933 declaration of make_pair():</p>
4934 <blockquote>
4935   <pre>template &lt;class T1, class T2&gt; pair&lt;T1,T2&gt; make_pair(const T1&amp;, const T2&amp;);</pre>
4936 </blockquote>
4937 <p>to:</p>
4938 <blockquote>
4939   <pre>template &lt;class T1, class T2&gt; pair&lt;T1,T2&gt; make_pair(T1, T2);</pre>
4940 </blockquote>
4941 <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 7 and the line before, change:</p>
4942 <blockquote>
4943 <pre>template &lt;class T1, class T2&gt;
4944 pair&lt;T1, T2&gt; make_pair(const T1&amp; x, const T2&amp; y);</pre>
4945 </blockquote>
4946 <p>to:</p>
4947 <blockquote>
4948 <pre>template &lt;class T1, class T2&gt;
4949 pair&lt;T1, T2&gt; make_pair(T1 x, T2 y);</pre>
4950 </blockquote>
4951 <p>and add the following footnote to the effects clause:</p>
4952 <blockquote>
4953   <p> According to 12.8 [class.copy], an implementation is permitted
4954   to not perform a copy of an argument, thus avoiding unnecessary
4955   copies.</p>
4956 </blockquote>
4957 <p><b>Rationale:</b></p>
4958 <p>Two potential fixes were suggested by Matt Austern and Dietmar
4959 Kühl, respectively, 1) overloading with array arguments, and 2) use of
4960 a reference_traits class with a specialization for arrays.  Andy
4961 Koenig suggested changing to pass by value. In discussion, it appeared
4962 that this was a much smaller change to the standard that the other two
4963 suggestions, and any efficiency concerns were more than offset by the
4964 advantages of the solution. Two implementors reported that the
4965 proposed resolution passed their test suites.</p>
4966 <hr>
4967 <a name="182"><h3>182.&nbsp;Ambiguous references to size_t</h3></a><p><b>Section:</b>&nbsp;17 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.library"> [lib.library]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Al Stevens&nbsp; <b>Date:</b>&nbsp;15 Aug 1999</p>
4968 <p>Many references to <tt> size_t</tt> throughout the document
4969 omit the <tt> std::</tt> namespace qualification.</p> <p>For
4970 example, 17.4.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a> paragraph 2:</p>
4971 <blockquote>
4972 <pre>&#8212; operator new(size_t)
4973 &#8212; operator new(size_t, const std::nothrow_t&amp;)
4974 &#8212; operator new[](size_t)
4975 &#8212; operator new[](size_t, const std::nothrow_t&amp;)</pre>
4976 </blockquote>
4977 <p><b>Proposed resolution:</b></p>
4978 <p>   In 17.4.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a> paragraph 2: replace:</p>
4979 <blockquote>
4980 <p><tt>     - operator new(size_t)<br>
4981      - operator new(size_t, const std::nothrow_t&amp;)<br>
4982      - operator new[](size_t)<br>
4983      - operator new[](size_t, const std::nothrow_t&amp;)</tt></p>
4984 </blockquote>
4985 <p>    by:</p>
4986 <blockquote>
4987 <pre>- operator new(std::size_t)
4988 - operator new(std::size_t, const std::nothrow_t&amp;)
4989 - operator new[](std::size_t)
4990 - operator new[](std::size_t, const std::nothrow_t&amp;)</pre>
4991 </blockquote>
4992 <p>In [lib.allocator.requirements] 20.1.5, paragraph 4: replace:</p>
4993 <blockquote>
4994   <p>The typedef members pointer, const_pointer, size_type, and difference_type
4995   are required to be T*, T const*, size_t, and ptrdiff_t, respectively.</p>
4996 </blockquote>
4997 <p>&nbsp;by:</p>
4998 <blockquote>
4999   <p>The typedef members pointer, const_pointer, size_type, and difference_type
5000   are required to be T*, T const*, std::size_t, and std::ptrdiff_t,
5001   respectively.</p>
5002 </blockquote>
5003 <p>In [lib.allocator.members] 20.4.1.1, paragraphs 3 and 6: replace:</p>
5004 <blockquote>
5005   <p>3 Notes: Uses ::operator new(size_t) (18.4.1).</p>
5006   <p>6 Note: the storage is obtained by calling ::operator new(size_t), but it
5007   is unspecified when or how often this function is called. The use of hint is
5008   unspecified, but intended as an aid to locality if an implementation so
5009   desires.</p>
5010 </blockquote>
5011 <p>by:</p>
5012 <blockquote>
5013   <p>3 Notes: Uses ::operator new(std::size_t) (18.4.1).</p>
5014   <p>6 Note: the storage is obtained by calling ::operator new(std::size_t), but
5015   it is unspecified when or how often this function is called. The use of hint
5016   is unspecified, but intended as an aid to locality if an implementation so
5017   desires.</p>
5018 </blockquote>
5019 <p>In [lib.char.traits.require] 21.1.1, paragraph 1: replace:</p>
5020 <blockquote>
5021   <p>In Table 37, X denotes a Traits class defining types and functions for the
5022   character container type CharT; c and d denote values of type CharT; p and q
5023   denote values of type const CharT*; s denotes a value of type CharT*; n, i and
5024   j denote values of type size_t; e and f denote values of type X::int_type; pos
5025   denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
5026 </blockquote>
5027 <p>by:</p>
5028 <blockquote>
5029   <p>In Table 37, X denotes a Traits class defining types and functions for the
5030   character container type CharT; c and d denote values of type CharT; p and q
5031   denote values of type const CharT*; s denotes a value of type CharT*; n, i and
5032   j denote values of type std::size_t; e and f denote values of type X::int_type;
5033   pos denotes a value of type X::pos_type; and state denotes a value of type X::state_type.</p>
5034 </blockquote>
5035 <p>In [lib.char.traits.require] 21.1.1, table 37: replace the return type of
5036 X::length(p): "size_t" by "std::size_t".</p>
5037 <p>   In [lib.std.iterator.tags] 24.3.3, paragraph 2:    replace:<br>
5038 &nbsp;&nbsp;&nbsp; typedef ptrdiff_t difference_type;<br>
5039     by:<br>
5040 &nbsp;&nbsp;&nbsp; typedef std::ptrdiff_t difference_type;</p>
5041 <p> In [lib.locale.ctype] 22.2.1.1 put namespace std { ...} around the
5042 declaration of template &lt;class charT&gt; class ctype.<br>
5043 <br>
5044    In [lib.iterator.traits] 24.3.1, paragraph 2    put namespace std { ...} around the declaration of:<br>
5045 <br>
5046 &nbsp;&nbsp;&nbsp; template&lt;class Iterator&gt; struct iterator_traits<br>
5047 &nbsp;&nbsp;&nbsp; template&lt;class T&gt; struct iterator_traits&lt;T*&gt;<br>
5048 &nbsp;&nbsp;&nbsp; template&lt;class T&gt; struct iterator_traits&lt;const T*&gt;</p>
5049 <p><b>Rationale:</b></p>
5050 <p>The LWG believes correcting names like <tt>size_t</tt> and
5051 <tt>ptrdiff_t</tt> to <tt>std::size_t</tt> and <tt>std::ptrdiff_t</tt>
5052 to be essentially editorial.  There there can't be another size_t or
5053 ptrdiff_t meant anyway because, according to 17.4.3.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.extern.types"> [lib.extern.types]</a>,</p>
5054
5055 <blockquote>
5056 For each type T from the Standard C library, the types ::T and std::T
5057 are reserved to the implementation and, when defined, ::T shall be
5058 identical to std::T.
5059 </blockquote>
5060
5061 <p>The issue is treated as a Defect Report to make explicit the Project
5062 Editor's authority to make this change.</p>
5063
5064 <p><i>[Post-Tokyo: Nico Josuttis provided the above wording at the
5065 request of the LWG.]</i></p>
5066
5067 <p><i>[Toronto: This is tangentially related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>, but only tangentially: the intent of this issue is to
5068 address use of the name <tt>size_t</tt> in contexts outside of
5069 namespace std, such as in the description of <tt>::operator new</tt>.
5070 The proposed changes should be reviewed to make sure they are
5071 correct.]</i></p>
5072
5073 <p><i>[pre-Copenhagen: Nico has reviewed the changes and believes
5074 them to be correct.]</i></p>
5075
5076 <hr>
5077 <a name="183"><h3>183.&nbsp;I/O stream manipulators don't work for wide character streams</h3></a><p><b>Section:</b>&nbsp;27.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;7 Jul 1999</p>
5078 <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 3 says (clause numbering added for
5079 exposition):</p>
5080 <blockquote>
5081 <p>Returns: An object s of unspecified type such that if [1] out is an (instance
5082 of) basic_ostream then the expression out&lt;&lt;s behaves as if f(s) were
5083 called, and if [2] in is an (instance of) basic_istream then the expression
5084 in&gt;&gt;s behaves as if f(s) were called. Where f can be defined as: ios_base&amp;
5085 f(ios_base&amp; str, ios_base::fmtflags mask) { // reset specified flags
5086 str.setf(ios_base::fmtflags(0), mask); return str; } [3] The expression
5087 out&lt;&lt;s has type ostream&amp; and value out. [4] The expression in&gt;&gt;s
5088 has type istream&amp; and value in.</p>
5089 </blockquote>
5090 <p>Given the definitions [1] and [2] for out and in, surely [3] should read:
5091 "The expression out &lt;&lt; s has type basic_ostream&amp; ..." and
5092 [4] should read: "The expression in &gt;&gt; s has type basic_istream&amp;
5093 ..."</p>
5094 <p>If the wording in the standard is correct, I can see no way of implementing
5095 any of the manipulators so that they will work with wide character streams.</p>
5096 <p>e.g. wcout &lt;&lt; setbase( 16 );</p>
5097 <p>Must have value 'wcout' (which makes sense) and type 'ostream&amp;' (which
5098 doesn't).</p>
5099 <p>The same "cut'n'paste" type also seems to occur in Paras 4,5,7 and
5100 8. In addition, Para 6 [setfill] has a similar error, but relates only to
5101 ostreams.</p>
5102 <p>I'd be happier if there was a better way of saying this, to make it clear
5103 that the value of the expression is "the same specialization of
5104 basic_ostream as out"&amp;</p>
5105 <p><b>Proposed resolution:</b></p>
5106 <p>Replace section 27.6.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.std.manip"> [lib.std.manip]</a> except paragraph 1 with the
5107 following:</p>
5108 <blockquote>
5109 <p>2- The type designated smanip in each of the following function
5110 descriptions is implementation-specified and may be different for each
5111 function.<br>
5112 <br>
5113 <tt>smanip resetiosflags(ios_base::fmtflags mask);</tt><br>
5114 <br>
5115 -3- Returns: An object s of unspecified type such that if out is an
5116 instance of basic_ostream&lt;charT,traits&gt; then the expression
5117 out&lt;&lt;s behaves
5118 as if f(s, mask) were called, or if in is an instance of
5119 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
5120 behaves as if
5121 f(s, mask) were called. The function f can be defined as:*<br>
5122 <br>
5123 [Footnote: The expression cin &gt;&gt; resetiosflags(ios_base::skipws)
5124 clears ios_base::skipws in the format flags stored in the
5125 basic_istream&lt;charT,traits&gt; object cin (the same as cin &gt;&gt;
5126 noskipws), and the expression cout &lt;&lt;
5127 resetiosflags(ios_base::showbase) clears
5128 ios_base::showbase in the format flags stored in the
5129 basic_ostream&lt;charT,traits&gt; object cout (the same as cout
5130 &lt;&lt;
5131 noshowbase). --- end footnote]<br>
5132 <br>
5133 &nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, ios_base::fmtflags mask)<br>
5134 &nbsp;&nbsp; {<br>
5135 &nbsp;&nbsp; //  reset specified flags<br>
5136 &nbsp;&nbsp; str.setf(ios_base::fmtflags(0), mask);<br>
5137 &nbsp;&nbsp; return str;<br>
5138 &nbsp;&nbsp; }<br>
5139 </tt><br>
5140 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
5141 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
5142 <br>
5143 &nbsp;<tt>smanip setiosflags(ios_base::fmtflags mask);</tt><br>
5144 <br>
5145 -4- Returns: An object s of unspecified type such that if out is an
5146 instance of basic_ostream&lt;charT,traits&gt; then the expression
5147 out&lt;&lt;s behaves
5148 as if f(s, mask) were called, or if in is an instance of
5149 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
5150 behaves as if f(s,
5151 mask) were called. The function f can be defined as:<br>
5152 <br>
5153 &nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, ios_base::fmtflags mask)<br>
5154 &nbsp;&nbsp; {<br>
5155 &nbsp;&nbsp; //  set specified flags<br>
5156 &nbsp;&nbsp; str.setf(mask);<br>
5157 &nbsp;&nbsp; return str;<br>
5158 &nbsp;&nbsp; }<br>
5159 </tt><br>
5160 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
5161 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
5162 <br>
5163 <tt>smanip setbase(int base);</tt><br>
5164 <br>
5165 -5- Returns: An object s of unspecified type such that if out is an
5166 instance of basic_ostream&lt;charT,traits&gt; then the expression
5167 out&lt;&lt;s behaves
5168 as if f(s, base) were called, or if in is an instance of
5169 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
5170 behaves as if f(s,
5171 base) were called. The function f can be defined as:<br>
5172 <br>
5173 &nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int base)<br>
5174 &nbsp;&nbsp; {<br>
5175 &nbsp;&nbsp; //  set  basefield<br>
5176 &nbsp;&nbsp; str.setf(base ==  8 ? ios_base::oct :<br>
5177 &nbsp;&nbsp; base == 10 ? ios_base::dec :<br>
5178 &nbsp;&nbsp; base == 16 ? ios_base::hex :<br>
5179 &nbsp;&nbsp; ios_base::fmtflags(0), ios_base::basefield);<br>
5180 &nbsp;&nbsp; return str;<br>
5181 &nbsp;&nbsp; }<br>
5182 </tt><br>
5183 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
5184 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in.<br>
5185 <br>
5186 <tt>smanip setfill(char_type c);<br>
5187 </tt><br>
5188 -6- Returns: An object s of unspecified type such that if out is (or is
5189 derived from) basic_ostream&lt;charT,traits&gt; and c has type charT
5190 then the
5191 expression out&lt;&lt;s behaves as if f(s, c) were called. The function
5192 f can be
5193 defined as:<br>
5194 <br>
5195 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>template&lt;class charT, class traits&gt;<br>
5196 &nbsp;&nbsp; basic_ios&lt;charT,traits&gt;&amp; f(basic_ios&lt;charT,traits&gt;&amp; str, charT c)<br>
5197 &nbsp;&nbsp; {<br>
5198 &nbsp;&nbsp; //  set fill character<br>
5199 &nbsp;&nbsp; str.fill(c);<br>
5200 &nbsp;&nbsp; return str;<br>
5201 &nbsp;&nbsp; }<br>
5202 </tt><br>
5203 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.<br>
5204 <br>
5205 <tt>smanip setprecision(int n);</tt><br>
5206 <br>
5207 -7- Returns: An object s of unspecified type such that if out is an
5208 instance of basic_ostream&lt;charT,traits&gt; then the expression
5209 out&lt;&lt;s behaves
5210 as if f(s, n) were called, or if in is an instance of
5211 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
5212 behaves as if f(s, n)
5213 were called. The function f can be defined as:<br>
5214 <br>
5215 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int n)<br>
5216 &nbsp;&nbsp; {<br>
5217 &nbsp;&nbsp; //  set precision<br>
5218 &nbsp;&nbsp; str.precision(n);<br>
5219 &nbsp;&nbsp; return str;<br>
5220 &nbsp;&nbsp; }<br>
5221 </tt><br>
5222 The expression out&lt;&lt;s has type basic_ostream&lt;charT,traits&gt;&amp; and value out.
5223 The expression in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value in<br>
5224 .<br>
5225 <tt>smanip setw(int n);<br>
5226 </tt><br>
5227 -8- Returns: An object s of unspecified type such that if out is an
5228 instance of basic_ostream&lt;charT,traits&gt; then the expression
5229 out&lt;&lt;s behaves
5230 as if f(s, n) were called, or if in is an instance of
5231 basic_istream&lt;charT,traits&gt; then the expression in&gt;&gt;s
5232 behaves as if f(s, n)
5233 were called. The function f can be defined as:<br>
5234 <br>
5235 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <tt>ios_base&amp; f(ios_base&amp; str, int n)<br>
5236 &nbsp;&nbsp; {<br>
5237 &nbsp;&nbsp; //  set width<br>
5238 &nbsp;&nbsp; str.width(n);<br>
5239 &nbsp;&nbsp; return str;<br>
5240 &nbsp;&nbsp; }<br>
5241 </tt><br>
5242 The expression out&lt;&lt;s has type
5243 basic_ostream&lt;charT,traits&gt;&amp; and value out.  The expression
5244 in&gt;&gt;s has type basic_istream&lt;charT,traits&gt;&amp; and value
5245 in.
5246 </p>
5247 </blockquote>
5248
5249 <p><i>[Kona: Andy Sawyer and Beman Dawes will work to improve the wording of
5250 the proposed resolution.]</i></p>
5251
5252 <p><i>[Tokyo - The LWG noted that issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#216">216</a> involves
5253 the same paragraphs.]</i></p>
5254
5255 <p><i>[Post-Tokyo: The issues list maintainer combined the proposed
5256 resolution of this issue with the proposed resolution for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#216">216</a> as they both involved the same paragraphs, and were so
5257 intertwined that dealing with them separately appear fraught with
5258 error.  The full text was supplied by Bill Plauger; it was cross
5259 checked against changes supplied by Andy Sawyer. It should be further
5260 checked by the LWG.]</i></p>
5261 <hr>
5262 <a name="184"><h3>184.&nbsp;numeric_limits&lt;bool&gt; wording problems</h3></a><p><b>Section:</b>&nbsp;18.2.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.numeric.special"> [lib.numeric.special]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Gabriel Dos Reis&nbsp; <b>Date:</b>&nbsp;21 Jul 1999</p>
5263 <p>bools are defined by the standard to be of integer types, as per
5264 3.9.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/basic.html#basic.fundamental"> [basic.fundamental]</a> paragraph 7.  However "integer types"
5265 seems to have a special meaning for the author of 18.2. The net effect
5266 is an unclear and confusing specification for
5267 numeric_limits&lt;bool&gt; as evidenced below.</p>
5268
5269 <p>18.2.1.2/7 says numeric_limits&lt;&gt;::digits is, for built-in integer
5270 types, the number of non-sign bits in the representation.</p>
5271
5272 <p>4.5/4 states that a bool promotes to int ; whereas 4.12/1 says any non zero
5273 arithmetical value converts to true.</p>
5274
5275 <p>I don't think it makes sense at all to require
5276 numeric_limits&lt;bool&gt;::digits and numeric_limits&lt;bool&gt;::digits10 to
5277 be meaningful.</p>
5278
5279 <p>The standard defines what constitutes a signed (resp. unsigned) integer
5280 types. It doesn't categorize bool as being signed or unsigned. And the set of
5281 values of bool type has only two elements.</p>
5282
5283 <p>I don't think it makes sense to require numeric_limits&lt;bool&gt;::is_signed
5284 to be meaningful.</p>
5285
5286 <p>18.2.1.2/18 for numeric_limits&lt;integer_type&gt;::radix&nbsp; says:</p>
5287 <blockquote>
5288   <p>For integer types, specifies the base of the representation.186)</p>
5289 </blockquote>
5290
5291 <p>This disposition is at best misleading and confusing for the standard
5292 requires a "pure binary numeration system" for integer types as per
5293 3.9.1/7</p>
5294
5295 <p>The footnote 186) says: "Distinguishes types with base other than 2 (e.g
5296 BCD)."&nbsp; This also erroneous as the standard never defines any integer
5297 types with base representation other than 2.</p>
5298
5299 <p>Furthermore, numeric_limits&lt;bool&gt;::is_modulo and
5300 numeric_limits&lt;bool&gt;::is_signed have similar problems.</p>
5301 <p><b>Proposed resolution:</b></p>
5302 <p>Append to the end of 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>:</p>
5303 <blockquote>
5304   <p>The specialization for bool shall be provided as follows:</p>
5305   <pre>    namespace std {
5306        template&lt;&gt; class numeric_limits&lt;bool&gt; {
5307        public:
5308          static const bool is_specialized = true;
5309          static bool min() throw() { return false; }
5310          static bool max() throw() { return true; }
5311
5312          static const int  digits = 1;
5313          static const int  digits10 = 0;
5314          static const bool is_signed = false;
5315          static const bool is_integer = true;
5316          static const bool is_exact = true;
5317          static const int  radix = 2;
5318          static bool epsilon() throw() { return 0; }
5319          static bool round_error() throw() { return 0; }
5320
5321          static const int  min_exponent = 0;
5322          static const int  min_exponent10 = 0;
5323          static const int  max_exponent = 0;
5324          static const int  max_exponent10 = 0;
5325
5326          static const bool has_infinity = false;
5327          static const bool has_quiet_NaN = false;
5328          static const bool has_signaling_NaN = false;
5329          static const float_denorm_style has_denorm = denorm_absent;
5330          static const bool has_denorm_loss = false;
5331          static bool infinity() throw() { return 0; }
5332          static bool quiet_NaN() throw() { return 0; }
5333          static bool signaling_NaN() throw() { return 0; }
5334          static bool denorm_min() throw() { return 0; }
5335
5336          static const bool is_iec559 = false;
5337          static const bool is_bounded = true;
5338          static const bool is_modulo = false;
5339
5340          static const bool traps = false;
5341          static const bool tinyness_before = false;
5342          static const float_round_style round_style = round_toward_zero;
5343        };
5344      }</pre>
5345 </blockquote>
5346
5347 <p><i>[Tokyo:&nbsp; The LWG desires wording that specifies exact values
5348 rather than more general wording in the original proposed
5349 resolution.]</i></p>
5350
5351 <p><i>[Post-Tokyo:&nbsp; At the request of the LWG in Tokyo, Nico
5352 Josuttis provided the above wording.]</i></p>
5353 <hr>
5354 <a name="185"><h3>185.&nbsp;Questionable use of term "inline"</h3></a><p><b>Section:</b>&nbsp;20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.tuple"> [lib.tuple]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;UK Panel&nbsp; <b>Date:</b>&nbsp;26 Jul 1999</p>
5355 <p>Paragraph 4 of 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.tuple"> [lib.tuple]</a> says:</p>
5356 <blockquote>
5357   <p>&nbsp;[Example: To negate every element of a: transform(a.begin(), a.end(),
5358   a.begin(), negate&lt;double&gt;()); The corresponding functions will inline
5359   the addition and the negation. end example]</p>
5360 </blockquote>
5361 <p>(Note: The "addition" referred to in the above is in para 3) we can
5362 find no other wording, except this (non-normative) example which suggests that
5363 any "inlining" will take place in this case.</p>
5364 <p>Indeed both:</p>
5365 <blockquote>
5366   <p>17.4.4.3 Global Functions [lib.global.functions] 1 It is
5367   unspecified whether any global functions in the C++ Standard Library
5368   are defined as inline (7.1.2).</p>
5369 </blockquote>
5370 <p>and</p>
5371 <blockquote>
5372   <p>17.4.4.4 Member Functions [lib.member.functions] 1 It is
5373   unspecified whether any member functions in the C++ Standard Library
5374   are defined as inline (7.1.2).</p>
5375 </blockquote>
5376 <p>take care to state that this may indeed NOT be the case.</p>
5377 <p>Thus the example "mandates" behavior that is explicitly
5378 not required elsewhere.</p>
5379 <p><b>Proposed resolution:</b></p>
5380 <p>In 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.tuple"> [lib.tuple]</a> paragraph 1, remove the sentence:</p>
5381 <blockquote>
5382 <p>They are important for the effective use of the library.</p>
5383 </blockquote>
5384 <p>Remove 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.tuple"> [lib.tuple]</a> paragraph 2, which reads:</p>
5385 <blockquote>
5386   <p> Using function objects together with function templates
5387   increases the expressive power of the library as well as making the
5388   resulting code much more efficient.</p>
5389 </blockquote>
5390 <p>In 20.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.tuple"> [lib.tuple]</a> paragraph 4, remove the sentence:</p>
5391 <blockquote>
5392   <p>The corresponding functions will inline the addition and the
5393   negation.</p>
5394 </blockquote>
5395
5396 <p><i>[Kona: The LWG agreed there was a defect.]</i></p>
5397 <p><i>[Tokyo: The LWG crafted the proposed resolution.]</i></p>
5398 <hr>
5399 <a name="186"><h3>186.&nbsp;bitset::set() second parameter should be bool</h3></a><p><b>Section:</b>&nbsp;23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Darin Adler&nbsp; <b>Date:</b>&nbsp;13 Aug 1999</p>
5400 <p>In section 23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a>, paragraph 13 defines the
5401 bitset::set operation to take a second parameter of type int. The
5402 function tests whether this value is non-zero to determine whether to
5403 set the bit to true or false. The type of this second parameter should
5404 be bool. For one thing, the intent is to specify a Boolean value. For
5405 another, the result type from test() is bool. In addition, it's
5406 possible to slice an integer that's larger than an int. This can't
5407 happen with bool, since conversion to bool has the semantic of
5408 translating 0 to false and any non-zero value to true.</p>
5409 <p><b>Proposed resolution:</b></p>
5410 <p>In 23.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a> Para 1 Replace:</p>
5411 <blockquote>
5412 <pre>bitset&lt;N&gt;&amp; set(size_t pos, int val = true ); </pre>
5413 </blockquote>
5414 <p>With:</p>
5415 <blockquote>
5416   <pre>bitset&lt;N&gt;&amp; set(size_t pos, bool val = true );</pre>
5417 </blockquote>
5418 <p>In 23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a> Para 12(.5) Replace:</p>
5419 <blockquote>
5420   <pre>bitset&lt;N&gt;&amp; set(size_t pos, int val = 1 );</pre>
5421 </blockquote>
5422 <p>With:</p>
5423 <blockquote>
5424   <pre>bitset&lt;N&gt;&amp; set(size_t pos, bool val = true );</pre>
5425 </blockquote>
5426
5427 <p><i>[Kona: The LWG agrees with the description.&nbsp; Andy Sawyer will work
5428 on better P/R wording.]</i></p>
5429 <p><i>[Post-Tokyo: Andy provided the above wording.]</i></p>
5430 <p><b>Rationale:</b></p>
5431 <p><tt>bool</tt> is a better choice.  It is believed that binary
5432 compatibility is not an issue, because this member function is
5433 usually implemented as <tt>inline</tt>, and because it is already
5434 the case that users cannot rely on the type of a pointer to a
5435 nonvirtual member of a standard library class.</p>
5436 <hr>
5437 <a name="187"><h3>187.&nbsp;iter_swap underspecified</h3></a><p><b>Section:</b>&nbsp;25.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.swap"> [lib.alg.swap]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;14 Aug 1999</p>
5438 <p>The description of iter_swap in 25.2.2 paragraph 7,says that it
5439 ``exchanges the values'' of the objects to which two iterators
5440 refer.<br> <br> What it doesn't say is whether it does so using swap
5441 or using the assignment operator and copy constructor.<br> <br> This
5442 question is an important one to answer, because swap is specialized to
5443 work efficiently for standard containers.<br> For example:</p>
5444 <blockquote>
5445 <pre>vector&lt;int&gt; v1, v2;
5446 iter_swap(&amp;v1, &amp;v2);</pre>
5447 </blockquote>
5448 <p>Is this call to iter_swap equivalent to calling swap(v1, v2)?&nbsp;
5449 Or is it equivalent to</p>
5450 <blockquote>
5451 <pre>{
5452 vector&lt;int&gt; temp = v1;
5453 v1 = v2;
5454 v2 = temp;
5455 }</pre>
5456 </blockquote>
5457 <p>The first alternative is O(1); the second is O(n).</p>
5458 <p>A LWG member, Dave Abrahams, comments:</p>
5459 <blockquote>
5460 <p>Not an objection necessarily, but I want to point out the cost of
5461 that requirement:</p>
5462   <blockquote>
5463 <p><tt>iter_swap(list&lt;T&gt;::iterator, list&lt;T&gt;::iterator)</tt></p>
5464   </blockquote>
5465 <p>can currently be specialized to be more efficient than
5466 iter_swap(T*,T*) for many T (by using splicing). Your proposal would
5467 make that optimization illegal.&nbsp;</p>
5468 </blockquote>
5469
5470 <p><i>[Kona: The LWG notes the original need for iter_swap was proxy iterators
5471 which are no longer permitted.]</i></p>
5472 <p><b>Proposed resolution:</b></p>
5473 <p>Change the effect clause of iter_swap in 25.2.2 paragraph 7 from:</p>
5474 <blockquote>
5475 <p>Exchanges the values pointed to by the two iterators a and b.</p>
5476 </blockquote>
5477 <p>to</p>
5478 <blockquote>
5479 <p><tt>swap(*a, *b)</tt>.</p>
5480 </blockquote>
5481
5482 <p><b>Rationale:</b></p>
5483 <p>It's useful to say just what <tt>iter_swap</tt> does.  There may be
5484   some iterators for which we want to specialize <tt>iter_swap</tt>,
5485   but the fully general version should have a general specification.</p>
5486
5487 <p>Note that in the specific case of <tt>list&lt;T&gt;::iterator</tt>,
5488 iter_swap should not be specialized as suggested above.  That would do
5489 much more than exchanging the two iterators' values: it would change
5490 predecessor/successor relationships, possibly moving the iterator from
5491 one list to another.  That would surely be inappropriate.</p>
5492 <hr>
5493 <a name="189"><h3>189.&nbsp;setprecision() not specified correctly</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;25 Aug 1999</p>
5494 <p>27.4.2.2 paragraph 9 claims that setprecision() sets the precision,
5495 and includes a parenthetical note saying that it is the number of
5496 digits after the decimal point.<br>
5497 <br>
5498 This claim is not strictly correct.  For example, in the default
5499 floating-point output format, setprecision sets the number of
5500 significant digits printed, not the number of digits after the decimal
5501 point.<br>
5502 <br>
5503 I would like the committee to look at the definition carefully and
5504 correct the statement in 27.4.2.2</p>
5505 <p><b>Proposed resolution:</b></p>
5506 <p>Remove from 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>, paragraph 9, the text
5507 "(number of digits after the decimal point)".</p>
5508 <hr>
5509 <a name="193"><h3>193.&nbsp;Heap operations description incorrect</h3></a><p><b>Section:</b>&nbsp;25.3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.heap.operations"> [lib.alg.heap.operations]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Markus Mauhart&nbsp; <b>Date:</b>&nbsp;24 Sep 1999</p>
5510 <p>25.3.6 [lib.alg.heap.operations] states two key properties of a heap [a,b), the first of them
5511 is<br>
5512 <br>
5513 &nbsp;&nbsp;&nbsp; `"(1) *a is the largest element"<br>
5514 <br>
5515 I think this is incorrect and should be changed to the wording in the proposed
5516 resolution.</p>
5517 <p>Actually there are two independent changes:</p>
5518 <blockquote>
5519   <p>A-"part of largest equivalence class" instead of "largest", cause 25.3
5520   [lib.alg.sorting] asserts "strict weak ordering" for all its sub clauses.</p>
5521   <p>B-Take
5522 'an oldest' from that equivalence class, otherwise the heap functions
5523 could not be used for a priority queue as explained in 23.2.3.2.2
5524 [lib.priqueue.members] (where I assume that a "priority queue" respects
5525 priority AND time).</p>
5526 </blockquote>
5527 <p><b>Proposed resolution:</b></p>
5528 <p>Change 25.3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.heap.operations"> [lib.alg.heap.operations]</a> property (1) from:</p>
5529 <blockquote>
5530   <p>(1) *a is the largest element</p>
5531 </blockquote>
5532 <p>to:</p>
5533 <blockquote>
5534   <p>(1) There is no element greater than <tt>*a</tt></p>
5535 </blockquote>
5536 <hr>
5537 <a name="195"><h3>195.&nbsp;Should <tt>basic_istream::sentry</tt>'s constructor ever set eofbit?</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;13 Oct 1999</p>
5538 <p>Suppose that <tt>is.flags() &amp; ios_base::skipws</tt> is nonzero.
5539 What should <tt>basic_istream&lt;&gt;::sentry</tt>'s constructor do if it
5540 reaches eof while skipping whitespace?  27.6.1.1.2/5 suggests it
5541 should set failbit. Should it set eofbit as well?  The standard
5542 doesn't seem to answer that question.</p>
5543
5544 <p>On the one hand, nothing in 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> says that
5545 <tt>basic_istream&lt;&gt;::sentry</tt> should ever set eofbit.  On the
5546 other hand, 27.6.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream"> [lib.istream]</a> paragraph 4 says that if
5547 extraction from a <tt>streambuf</tt> "returns
5548 <tt>traits::eof()</tt>, then the input function, except as explicitly
5549 noted otherwise, completes its actions and does
5550 <tt>setstate(eofbit)"</tt>.  So the question comes down to
5551 whether <tt>basic_istream&lt;&gt;::sentry</tt>'s constructor is an
5552 input function.</p>
5553
5554 <p>Comments from Jerry Schwarz:</p>
5555 <blockquote>
5556 <p>It was always my intention that eofbit should be set any time that a
5557 virtual returned something to indicate eof, no matter what reason
5558 iostream code had for calling the virtual.</p>
5559 <p>
5560 The motivation for this is that I did not want to require streambufs
5561 to behave consistently if their virtuals are called after they have
5562 signaled eof.</p>
5563 <p>
5564 The classic case is a streambuf reading from a UNIX file.  EOF isn't
5565 really a state for UNIX file descriptors.  The convention is that a
5566 read on UNIX returns 0 bytes to indicate "EOF", but the file
5567 descriptor isn't shut down in any way and future reads do not
5568 necessarily also return 0 bytes.  In particular, you can read from
5569 tty's on UNIX even after they have signaled "EOF".  (It
5570 isn't always understood that a ^D on UNIX is not an EOF indicator, but
5571 an EOL indicator.  By typing a "line" consisting solely of
5572 ^D you cause a read to return 0 bytes, and by convention this is
5573 interpreted as end of file.)</p>
5574 </blockquote>
5575 <p><b>Proposed resolution:</b></p>
5576 <p>Add a sentence to the end of 27.6.1.1.2 paragraph 2:</p>
5577 <blockquote>
5578 <p>If <tt>is.rdbuf()-&gt;sbumpc()</tt> or <tt>is.rdbuf()-&gt;sgetc()</tt>
5579 returns <tt>traits::eof()</tt>, the function calls
5580 <tt>setstate(failbit | eofbit)</tt> (which may throw
5581 <tt>ios_base::failure</tt>).
5582 </p>
5583 </blockquote>
5584 <hr>
5585 <a name="198"><h3>198.&nbsp;Validity of pointers and references unspecified after iterator destruction</h3></a><p><b>Section:</b>&nbsp;24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;3 Nov 1999</p>
5586 <p>
5587 Is a pointer or reference obtained from an iterator still valid after
5588 destruction of the iterator?
5589 </p>
5590 <p>
5591 Is a pointer or reference obtained from an iterator still valid after the value
5592 of the iterator changes?
5593 </p>
5594 <blockquote>
5595 <pre>#include &lt;iostream&gt;
5596 #include &lt;vector&gt;
5597 #include &lt;iterator&gt;
5598
5599 int main()
5600 {
5601     typedef std::vector&lt;int&gt; vec_t;
5602     vec_t v;
5603     v.push_back( 1 );
5604
5605     // Is a pointer or reference obtained from an iterator still
5606     // valid after destruction of the iterator?
5607     int * p = &amp;*v.begin();
5608     std::cout &lt;&lt; *p &lt;&lt; '\n';  // OK?
5609
5610     // Is a pointer or reference obtained from an iterator still
5611     // valid after the value of the iterator changes?
5612     vec_t::iterator iter( v.begin() );
5613     p = &amp;*iter++;
5614     std::cout &lt;&lt; *p &lt;&lt; '\n';  // OK?
5615
5616     return 0;
5617 }
5618 </pre>
5619 </blockquote>
5620
5621 <p>The standard doesn't appear to directly address these
5622 questions. The standard needs to be clarified. At least two real-world
5623 cases have been reported where library implementors wasted
5624 considerable effort because of the lack of clarity in the
5625 standard. The question is important because requiring pointers and
5626 references to remain valid has the effect for practical purposes of
5627 prohibiting iterators from pointing to cached rather than actual
5628 elements of containers.</p>
5629
5630 <p>The standard itself assumes that pointers and references obtained
5631 from an iterator are still valid after iterator destruction or
5632 change. The definition of reverse_iterator::operator*(), 24.4.1.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.conv"> [lib.reverse.iter.conv]</a>, which returns a reference, defines
5633 effects:</p>
5634
5635 <blockquote>
5636   <pre>Iterator tmp = current;
5637 return *--tmp;</pre>
5638 </blockquote>
5639 <p>The definition of reverse_iterator::operator-&gt;(), 24.4.1.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.op.star"> [lib.reverse.iter.op.star]</a>, which returns a pointer, defines effects:</p>
5640 <blockquote>
5641   <pre>return &amp;(operator*());</pre>
5642 </blockquote>
5643
5644 <p>Because the standard itself assumes pointers and references remain
5645 valid after iterator destruction or change, the standard should say so
5646 explicitly. This will also reduce the chance of user code breaking
5647 unexpectedly when porting to a different standard library
5648 implementation.</p>
5649 <p><b>Proposed resolution:</b></p>
5650 <p>Add a new paragraph to 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>:</p>
5651 <blockquote>
5652 Destruction of an iterator may invalidate pointers and references
5653 previously obtained from that iterator.
5654 </blockquote>
5655
5656 <p>Replace paragraph 1 of 24.4.1.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.conv"> [lib.reverse.iter.conv]</a> with:</p>
5657
5658 <blockquote>
5659 <p><b>Effects:</b></p>
5660 <pre>  this-&gt;tmp = current;
5661   --this-&gt;tmp;
5662   return *this-&gt;tmp;
5663 </pre>
5664
5665 <p>
5666 [<i>Note:</i> This operation must use an auxiliary member variable,
5667 rather than a temporary variable, to avoid returning a reference that
5668 persists beyond the lifetime of its associated iterator.  (See
5669 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>.)  The name of this member variable is shown for
5670 exposition only.  <i>--end note</i>]
5671 </p>
5672 </blockquote>
5673
5674 <p><i>[Post-Tokyo: The issue has been reformulated purely
5675 in terms of iterators.]</i></p>
5676
5677 <p><i>[Pre-Toronto: Steve Cleary pointed out the no-invalidation
5678 assumption by reverse_iterator. The issue and proposed resolution was
5679 reformulated yet again to reflect this reality.]</i></p>
5680
5681 <p><i>[Copenhagen: Steve Cleary pointed out that reverse_iterator
5682 assumes its underlying iterator has persistent pointers and
5683 references.  Andy Koenig pointed out that it is possible to rewrite
5684 reverse_iterator so that it no longer makes such an assupmption.
5685 However, this issue is related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a>.  If we
5686 decide it is intentional that <tt>p[n]</tt> may return by value
5687 instead of reference when <tt>p</tt> is a Random Access Iterator,
5688 other changes in reverse_iterator will be necessary.]</i></p>
5689 <p><b>Rationale:</b></p>
5690 <p>This issue has been discussed extensively.  Note that it is
5691 <i>not</i> an issue about the behavior of predefined iterators.  It is
5692 asking whether or not user-defined iterators are permitted to have
5693 transient pointers and references.  Several people presented examples
5694 of useful user-defined iterators that have such a property; examples
5695 include a B-tree iterator, and an "iota iterator" that doesn't point
5696 to memory.  Library implementors already seem to be able to cope with
5697 such iterators: they take pains to avoid forming references to memory
5698 that gets iterated past.  The only place where this is a problem is
5699 <tt>reverse_iterator</tt>, so this issue changes
5700 <tt>reverse_iterator</tt> to make it work.</p>
5701
5702 <p>This resolution does not weaken any guarantees provided by
5703 predefined iterators like <tt>list&lt;int&gt;::iterator</tt>.
5704 Clause 23 should be reviewed to make sure that guarantees for
5705 predefined iterators are as strong as users expect.</p>
5706
5707 <hr>
5708 <a name="199"><h3>199.&nbsp;What does <tt>allocate(0)</tt> return?</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;19 Nov 1999</p>
5709 <p>
5710 Suppose that <tt>A</tt> is a class that conforms to the
5711 Allocator requirements of Table 32, and <tt>a</tt> is an
5712 object of class <tt>A</tt>  What should be the return
5713 value of <tt>a.allocate(0)</tt>?  Three reasonable
5714 possibilities: forbid the argument <tt>0</tt>, return
5715 a null pointer, or require that the return value be a
5716 unique non-null pointer.
5717 </p>
5718 <p><b>Proposed resolution:</b></p>
5719 <p>
5720 Add a note to the <tt>allocate</tt> row of Table 32:
5721 "[<i>Note:</i> If <tt>n == 0</tt>, the return value is unspecified. <i>--end note</i>]"</p>
5722 <p><b>Rationale:</b></p>
5723 <p>A key to understanding this issue is that the ultimate use of
5724 allocate() is to construct an iterator, and that iterator for zero
5725 length sequences must be the container's past-the-end
5726 representation.  Since this already implies special case code, it
5727 would be over-specification to mandate the return value.
5728 </p>
5729 <hr>
5730 <a name="200"><h3>200.&nbsp;Forward iterator requirements don't allow constant iterators</h3></a><p><b>Section:</b>&nbsp;24.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.forward.iterators"> [lib.forward.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;19 Nov 1999</p>
5731 <p>
5732 In table 74, the return type of the expression <tt>*a</tt> is given
5733 as <tt>T&amp;</tt>, where <tt>T</tt> is the iterator's value type.
5734 For constant iterators, however, this is wrong.  ("Value type"
5735 is never defined very precisely, but it is clear that the value type
5736 of, say, <tt>std::list&lt;int&gt;::const_iterator</tt> is supposed to be
5737 <tt>int</tt>, not <tt>const int</tt>.)
5738 </p>
5739 <p><b>Proposed resolution:</b></p>
5740 <p>
5741 In table 74, in the <tt>*a</tt> and <tt>*r++</tt> rows, change the
5742 return type from "<tt>T&amp;</tt>" to "<tt>T&amp;</tt>
5743 if <tt>X</tt> is mutable, otherwise <tt>const T&amp;</tt>".
5744 In the <tt>a-&gt;m</tt> row, change the return type from
5745 "<tt>U&amp;</tt>" to "<tt>U&amp;</tt> if <tt>X</tt> is mutable,
5746 otherwise <tt>const U&amp;</tt>".
5747 </p>
5748
5749 <p><i>[Tokyo: The LWG believes this is the tip of a larger iceberg;
5750 there are multiple const problems with the STL portion of the library
5751 and that these should be addressed as a single package.&nbsp; Note
5752 that issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#180">180</a> has already been declared NAD Future for
5753 that very reason.]</i></p>
5754
5755 <p><i>[Redmond: the LWG thinks this is separable from other constness
5756 issues.  This issue is just cleanup; it clarifies language that was
5757 written before we had iterator_traits.  Proposed resolution was
5758 modified: the original version only discussed *a.  It was pointed out
5759 that we also need to worry about *r++ and a-&gt;m.]</i></p>
5760
5761 <hr>
5762 <a name="202"><h3>202.&nbsp;unique() effects unclear when predicate not an equivalence relation</h3></a><p><b>Section:</b>&nbsp;25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Koenig&nbsp; <b>Date:</b>&nbsp;13 Jan 2000</p>
5763 <p>
5764 What should unique() do if you give it a predicate that is not an
5765 equivalence relation?  There are at least two plausible answers:
5766 </p>
5767
5768 <blockquote>
5769
5770 <p>
5771    1. You can't, because 25.2.8 says that it it "eliminates all but
5772    the first element from every consecutive group of equal
5773    elements..." and it wouldn't make sense to interpret "equal" as
5774    meaning anything but an equivalence relation.  [It also doesn't
5775    make sense to interpret "equal" as meaning ==, because then there
5776    would never be any sense in giving a predicate as an argument at
5777    all.]
5778 </p>
5779
5780 <p>
5781    2. The word "equal" should be interpreted to mean whatever the
5782    predicate says, even if it is not an equivalence relation
5783    (and in particular, even if it is not transitive).
5784 </p>
5785
5786 </blockquote>
5787
5788 <p>
5789 The example that raised this question is from Usenet:
5790 </p>
5791
5792 <blockquote>
5793
5794 <pre>int f[] = { 1, 3, 7, 1, 2 };
5795 int* z = unique(f, f+5, greater&lt;int&gt;());</pre>
5796
5797 </blockquote>
5798
5799 <p>
5800 If one blindly applies the definition using the predicate
5801 greater&lt;int&gt;, and ignore the word "equal", you get:
5802 </p>
5803
5804 <blockquote>
5805
5806 <p>
5807     Eliminates all but the first element from every consecutive group
5808     of elements referred to by the iterator i in the range [first, last)
5809     for which *i &gt; *(i - 1).
5810 </p>
5811
5812 </blockquote>
5813
5814 <p>
5815 The first surprise is the order of the comparison.  If we wanted to
5816 allow for the predicate not being an equivalence relation, then we
5817 should surely compare elements the other way: pred(*(i - 1), *i).  If
5818 we do that, then the description would seem to say: "Break the
5819 sequence into subsequences whose elements are in strictly increasing
5820 order, and keep only the first element of each subsequence".  So the
5821 result would be 1, 1, 2.  If we take the description at its word, it
5822 would seem to call for strictly DEcreasing order, in which case the
5823 result should be 1, 3, 7, 2.<br>
5824 <br>
5825 In fact, the SGI implementation of unique() does neither: It yields 1,
5826 3, 7.
5827 </p>
5828 <p><b>Proposed resolution:</b></p>
5829 <p>Change 25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> paragraph 1 to:</p>
5830 <blockquote>
5831 For a nonempty range, eliminates all but the first element from every
5832 consecutive group of equivalent elements referred to by the iterator
5833 <tt>i</tt> in the range [first+1, last) for which the following
5834 conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
5835 false</tt>.
5836 </blockquote>
5837
5838 <p>
5839 Also insert a new paragraph, paragraph 2a, that reads: "Requires: The
5840 comparison function must be an equivalence relation."
5841 </p>
5842
5843 <p><i>[Redmond: discussed arguments for and against requiring the
5844 comparison function to be an equivalence relation.  Straw poll:
5845 14-2-5.  First number is to require that it be an equivalence
5846 relation, second number is to explicitly not require that it be an
5847 equivalence relation, third number is people who believe they need
5848 more time to consider the issue.  A separate issue: Andy Sawyer
5849 pointed out that "i-1" is incorrect, since "i" can refer to the first
5850 iterator in the range.  Matt provided wording to address this
5851 problem.]</i></p>
5852
5853 <p><i>[Curaçao: The LWG changed "... the range (first,
5854 last)..." to "...  the range [first+1, last)..." for
5855 clarity. They considered this change close enough to editorial to not
5856 require another round of review.]</i></p>
5857
5858 <p><b>Rationale:</b></p>
5859 <p>The LWG also considered an alternative resolution: change
5860 25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> paragraph 1 to:</p>
5861
5862 <blockquote>
5863 For a nonempty range, eliminates all but the first element from every
5864 consecutive group of elements referred to by the iterator
5865 <tt>i</tt> in the range (first, last) for which the following
5866 conditions hold: <tt>*(i-1) == *i</tt> or <tt>pred(*(i-1), *i) !=
5867 false</tt>.
5868 </blockquote>
5869
5870 <p>
5871 Also insert a new paragraph, paragraph 1a, that reads: "Notes: The
5872 comparison function need not be an equivalence relation."
5873 </p>
5874
5875
5876 <p>Informally: the proposed resolution imposes an explicit requirement
5877 that the comparison function be an equivalence relation.  The
5878 alternative resolution does not, and it gives enough information so
5879 that the behavior of unique() for a non-equivalence relation is
5880 specified.  Both resolutions are consistent with the behavior of
5881 existing implementations.</p>
5882 <hr>
5883 <a name="208"><h3>208.&nbsp;Unnecessary restriction on past-the-end iterators</h3></a><p><b>Section:</b>&nbsp;24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Stephen Cleary&nbsp; <b>Date:</b>&nbsp;02 Feb 2000</p>
5884 <p>In 24.1 paragraph 5, it is stated ". . . Dereferenceable and
5885 past-the-end values are always non-singular."</p>
5886 <p>This places an unnecessary restriction on past-the-end iterators for
5887 containers with forward iterators (for example, a singly-linked list). If the
5888 past-the-end value on such a container was a well-known singular value, it would
5889 still satisfy all forward iterator requirements.</p>
5890 <p>Removing this restriction would allow, for example, a singly-linked list
5891 without a "footer" node.</p>
5892 <p>This would have an impact on existing code that expects past-the-end
5893 iterators obtained from different (generic) containers being not equal.</p>
5894 <p><b>Proposed resolution:</b></p>
5895 <p>Change 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> paragraph 5, the last sentence, from:</p>
5896 <blockquote>
5897 <p>Dereferenceable and past-the-end values are always non-singular.</p>
5898 </blockquote>
5899 <p>to:</p>
5900 <blockquote>
5901 <p>Dereferenceable values are always non-singular.&nbsp;</p>
5902 </blockquote>
5903 <p><b>Rationale:</b></p>
5904 <p>For some kinds of containers, including singly linked lists and
5905 zero-length vectors, null pointers are perfectly reasonable past-the-end
5906 iterators.  Null pointers are singular.
5907 </p>
5908 <hr>
5909 <a name="209"><h3>209.&nbsp;basic_string declarations inconsistent</h3></a><p><b>Section:</b>&nbsp;21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Igor Stauder&nbsp; <b>Date:</b>&nbsp;11 Feb 2000</p>
5910 <p>In Section 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> the basic_string member function
5911 declarations use a consistent style except for the following functions:</p>
5912 <blockquote>
5913   <pre>void push_back(const charT);
5914 basic_string&amp; assign(const basic_string&amp;);
5915 void swap(basic_string&lt;charT,traits,Allocator&gt;&amp;);</pre>
5916 </blockquote>
5917 <p>- push_back, assign, swap: missing argument name&nbsp;<br>
5918 - push_back: use of const with charT (i.e. POD type passed by value
5919 not by reference - should be charT or const charT&amp; )<br>
5920 - swap: redundant use of template parameters in argument
5921 basic_string&lt;charT,traits,Allocator&gt;&amp;</p>
5922 <p><b>Proposed resolution:</b></p>
5923 <p>In Section 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> change the basic_string member
5924 function declarations push_back, assign, and swap to:</p>
5925 <blockquote>
5926   <pre>void push_back(charT c);
5927
5928 basic_string&amp; assign(const basic_string&amp; str);
5929 void swap(basic_string&amp; str);</pre>
5930 </blockquote>
5931 <p><b>Rationale:</b></p>
5932 <p>Although the standard is in general not consistent in declaration
5933 style, the basic_string declarations are consistent other than the
5934 above.  The LWG felt that this was sufficient reason to merit the
5935 change.
5936 </p>
5937 <hr>
5938 <a name="210"><h3>210.&nbsp;distance first and last confused</h3></a><p><b>Section:</b>&nbsp;25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Lisa Lippincott&nbsp; <b>Date:</b>&nbsp;15 Feb 2000</p>
5939 <p>In paragraph 9 of section 25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a>, it is written:</p>
5940 <blockquote>
5941   <p>      In the description of the algorithms operators + and - are used
5942            for some of the iterator categories for which they do not have to
5943            be defined. In these cases the semantics of [...] a-b is the same
5944            as of<br>
5945   <br>
5946   &nbsp;&nbsp;&nbsp;&nbsp; <tt>return distance(a, b);</tt></p>
5947 </blockquote>
5948 <p><b>Proposed resolution:</b></p>
5949 <p>On the last line of paragraph 9 of section 25 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.algorithms"> [lib.algorithms]</a> change
5950 <tt>"a-b"</tt> to <tt>"b-a".</tt></p>
5951 <p><b>Rationale:</b></p>
5952 <p>There are two ways to fix the defect; change the description to b-a
5953 or change the return to distance(b,a).  The LWG preferred the
5954 former for consistency.</p>
5955 <hr>
5956 <a name="211"><h3>211.&nbsp;operator&gt;&gt;(istream&amp;, string&amp;) doesn't set failbit</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Scott Snyder&nbsp; <b>Date:</b>&nbsp;4 Feb 2000</p>
5957 <p>The description of the stream extraction operator for std::string (section
5958 21.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in
5959 the case that the operator fails to extract any characters from the input
5960 stream.</p>
5961 <p>This implies that the typical construction</p>
5962 <blockquote>
5963   <pre>std::istream is;
5964 std::string str;
5965 ...
5966 while (is &gt;&gt; str) ... ;</pre>
5967 </blockquote>
5968 <p>(which tests failbit) is not required to terminate at EOF.</p>
5969 <p>Furthermore, this is inconsistent with other extraction operators,
5970 which do include this requirement. (See sections 27.6.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted"> [lib.istream.formatted]</a> and 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>), where this
5971 requirement is present, either explicitly or implicitly, for the
5972 extraction operators. It is also present explicitly in the description
5973 of getline (istream&amp;, string&amp;, charT) in section 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> paragraph 8.)</p>
5974 <p><b>Proposed resolution:</b></p>
5975 <p>Insert new paragraph after paragraph 2 in section 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>:</p>
5976 <blockquote>
5977
5978 <p>If the function extracts no characters, it calls
5979 is.setstate(ios::failbit) which may throw ios_base::failure
5980 (27.4.4.3).</p>
5981 </blockquote>
5982 <hr>
5983 <a name="212"><h3>212.&nbsp;Empty range behavior unclear for several algorithms</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Nico Josuttis&nbsp; <b>Date:</b>&nbsp;26 Feb 2000</p>
5984 <p>The standard doesn't specify what min_element() and max_element() shall
5985 return if the range is empty (first equals last). The usual implementations
5986 return last. This problem seems also apply to partition(), stable_partition(),
5987 next_permutation(), and prev_permutation().</p>
5988 <p><b>Proposed resolution:</b></p>
5989 <p>In 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> - Minimum and maximum, paragraphs 7 and
5990 9, append: Returns last if first==last.</p>
5991 <p><b>Rationale:</b></p>
5992 <p>The LWG looked in some detail at all of the above mentioned
5993 algorithms, but believes that except for min_element() and
5994 max_element() it is already clear that last is returned if first ==
5995 last.</p>
5996 <hr>
5997 <a name="214"><h3>214.&nbsp;set::find() missing const overload</h3></a><p><b>Section:</b>&nbsp;23.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.set"> [lib.set]</a>, 23.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.multiset"> [lib.multiset]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;28 Feb 2000</p>
5998 <p>The specification for the associative container requirements in
5999 Table 69 state that the find member function should "return
6000 iterator; const_iterator for constant a". The map and multimap
6001 container descriptions have two overloaded versions of find, but set
6002 and multiset do not, all they have is:</p>
6003 <blockquote>
6004   <pre>iterator find(const key_type &amp; x) const;</pre>
6005 </blockquote>
6006 <p><b>Proposed resolution:</b></p>
6007 <p>Change the prototypes for find(), lower_bound(), upper_bound(), and
6008 equal_range() in section 23.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.set"> [lib.set]</a> and section 23.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.multiset"> [lib.multiset]</a> to each have two overloads:</p>
6009 <blockquote>
6010   <pre>iterator find(const key_type &amp; x);
6011 const_iterator find(const key_type &amp; x) const;</pre>
6012   <pre>iterator lower_bound(const key_type &amp; x);
6013 const_iterator lower_bound(const key_type &amp; x) const;</pre>
6014   <pre>iterator upper_bound(const key_type &amp; x);
6015 const_iterator upper_bound(const key_type &amp; x) const;</pre>
6016   <pre>pair&lt;iterator, iterator&gt; equal_range(const key_type &amp; x);
6017 pair&lt;const_iterator, const_iterator&gt; equal_range(const key_type &amp; x) const;</pre>
6018 </blockquote>
6019
6020 <p><i>[Tokyo: At the request of the LWG, Judy Ward provided wording
6021 extending the proposed resolution to lower_bound, upper_bound, and
6022 equal_range.]</i></p>
6023 <hr>
6024 <a name="217"><h3>217.&nbsp;Facets example (Classifying Japanese characters) contains errors</h3></a><p><b>Section:</b>&nbsp;22.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facets.examples"> [lib.facets.examples]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;29 Feb 2000</p>
6025 <p>The example in 22.2.8, paragraph 11 contains the following errors:</p>
6026 <p>1) The member function `My::JCtype::is_kanji()' is non-const; the function
6027 must be const in order for it to be callable on a const object (a reference to
6028 which which is what std::use_facet&lt;&gt;() returns).</p>
6029 <p>2) In file filt.C, the definition of `JCtype::id' must be qualified with the
6030 name of the namespace `My'.</p>
6031 <p>3) In the definition of `loc' and subsequently in the call to use_facet&lt;&gt;()
6032 in main(), the name of the facet is misspelled: it should read `My::JCtype'
6033 rather than `My::JCType'.</p>
6034 <p><b>Proposed resolution:</b></p>
6035 <p>Replace the "Classifying Japanese characters" example in 22.2.8,
6036 paragraph 11 with the following:</p>
6037 <pre>#include &lt;locale&gt;</pre>
6038 <pre>namespace My {
6039     using namespace std;
6040     class JCtype : public locale::facet {
6041     public:
6042         static locale::id id;     //  required for use as a new locale facet
6043         bool is_kanji (wchar_t c) const;
6044         JCtype() {}
6045     protected:
6046         ~JCtype() {}
6047     };
6048 }</pre>
6049 <pre>//  file:  filt.C
6050 #include &lt;iostream&gt;
6051 #include &lt;locale&gt;
6052 #include "jctype"                 //  above
6053 std::locale::id My::JCtype::id;   //  the static  JCtype  member
6054 declared above.</pre>
6055 <pre>int main()
6056 {
6057     using namespace std;
6058     typedef ctype&lt;wchar_t&gt; wctype;
6059     locale loc(locale(""),              //  the user's preferred locale...
6060                new My::JCtype);         //  and a new feature ...
6061     wchar_t c = use_facet&lt;wctype&gt;(loc).widen('!');
6062     if (!use_facet&lt;My::JCtype&gt;(loc).is_kanji(c))
6063         cout &lt;&lt; "no it isn't!" &lt;&lt; endl;
6064     return 0;
6065 }</pre>
6066 <hr>
6067 <a name="220"><h3>220.&nbsp;~ios_base() usage valid?</h3></a><p><b>Section:</b>&nbsp;27.4.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios.base.cons"> [lib.ios.base.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Jonathan Schilling, Howard Hinnant&nbsp; <b>Date:</b>&nbsp;13 Mar 2000</p>
6068 <p>The pre-conditions for the ios_base destructor are described in 27.4.2.7
6069 paragraph 2:</p>
6070 <blockquote>
6071   <p>Effects: Destroys an object of class ios_base. Calls each registered
6072   callback pair (fn,index) (27.4.2.6) as (*fn)(erase_event,*this,index) at such
6073   time that any ios_base member function called from within fn has well defined
6074   results.</p>
6075 </blockquote>
6076 <p>But what is not clear is: If no callback functions were ever registered, does
6077 it matter whether the ios_base members were ever initialized?</p>
6078 <p>For instance, does this program have defined behavior:</p>
6079 <blockquote>
6080   <pre>#include &lt;ios&gt;</pre>
6081   <pre>class D : public std::ios_base { };</pre>
6082   <pre>int main() { D d; }</pre>
6083 </blockquote>
6084 <p>It seems that registration of a callback function would surely affect the
6085 state of an ios_base. That is, when you register a callback function with an
6086 ios_base, the ios_base must record that fact somehow.</p>
6087 <p>But if after construction the ios_base is in an indeterminate state, and that
6088 state is not made determinate before the destructor is called, then how would
6089 the destructor know if any callbacks had indeed been registered? And if the
6090 number of callbacks that had been registered is indeterminate, then is not the
6091 behavior of the destructor undefined?</p>
6092 <p>By comparison, the basic_ios class description in 27.4.4.1 paragraph 2 makes
6093 it explicit that destruction before initialization results in undefined
6094 behavior.</p>
6095 <p><b>Proposed resolution:</b></p>
6096 <p>Modify 27.4.2.7 paragraph 1 from</p>
6097 <blockquote>
6098   <p>Effects: Each ios_base member has an indeterminate value after
6099   construction.</p>
6100 </blockquote>
6101 <p>to</p>
6102 <blockquote>
6103   <p>Effects: Each ios_base member has an indeterminate
6104 value after construction. These members must be initialized by calling
6105 basic_ios::init. If an ios_base object is destroyed before these
6106 initializations have taken place, the behavior is undefined.</p>
6107 </blockquote>
6108 <hr>
6109 <a name="221"><h3>221.&nbsp;num_get&lt;&gt;::do_get stage 2 processing broken</h3></a><p><b>Section:</b>&nbsp;22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;14 Mar 2000</p>
6110 <p>Stage 2 processing of numeric conversion is broken.</p>
6111
6112 <p>Table 55 in 22.2.2.1.2 says that when basefield is 0 the integral
6113 conversion specifier is %i. A %i specifier determines a number's base
6114 by its prefix (0 for octal, 0x for hex), so the intention is clearly
6115 that a 0x prefix is allowed.  Paragraph 8 in the same section,
6116 however, describes very precisely how characters are processed. (It
6117 must be done "as if" by a specified code fragment.) That
6118 description does not allow a 0x prefix to be recognized.</p>
6119
6120 <p>Very roughly, stage 2 processing reads a char_type ct. It converts
6121 ct to a char, not by using narrow but by looking it up in a
6122 translation table that was created by widening the string literal
6123 "0123456789abcdefABCDEF+-". The character "x" is
6124 not found in that table, so it can't be recognized by stage 2
6125 processing.</p>
6126 <p><b>Proposed resolution:</b></p>
6127 <p>In 22.2.2.1.2 paragraph 8, replace the line:</p>
6128 <blockquote>
6129   <pre>static const char src[] = "0123456789abcdefABCDEF+-";</pre>
6130 </blockquote>
6131 <p>with the line:</p>
6132 <blockquote>
6133   <pre>static const char src[] = "0123456789abcdefxABCDEFX+-";</pre>
6134 </blockquote>
6135 <p><b>Rationale:</b></p>
6136 <p>If we're using the technique of widening a string literal, the
6137 string literal must contain every character we wish to recognize.
6138 This technique has the consequence that alternate representations
6139 of digits will not be recognized.  This design decision was made
6140 deliberately, with full knowledge of that limitation.</p>
6141 <hr>
6142 <a name="222"><h3>222.&nbsp;Are throw clauses necessary if a throw is already implied by the effects clause?</h3></a><p><b>Section:</b>&nbsp;17.3.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;17 Mar 2000</p>
6143 <p>Section 21.3.6.8 describes the basic_string::compare function this way:</p>
6144 <blockquote>
6145   <pre>21.3.6.8 - basic_string::compare [lib.string::compare]
6146
6147 int compare(size_type pos1, size_type n1,
6148                 const basic_string&lt;charT,traits,Allocator&gt;&amp;  str ,
6149                 size_type  pos2 , size_type  n2 ) const;
6150
6151 -4- Returns:
6152
6153     basic_string&lt;charT,traits,Allocator&gt;(*this,pos1,n1).compare(
6154                  basic_string&lt;charT,traits,Allocator&gt;(str,pos2,n2)) .</pre>
6155 </blockquote>
6156 <p>and the constructor that's implicitly called by the above is
6157 defined to throw an out-of-range exception if pos &gt; str.size(). See
6158 section 21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a> paragraph 4.</p>
6159
6160 <p>On the other hand, the compare function descriptions themselves don't have
6161 "Throws: " clauses and according to 17.3.1.3, paragraph 3, elements
6162 that do not apply to a function are omitted.</p>
6163 <p>So it seems there is an inconsistency in the standard -- are the
6164 "Effects" clauses correct, or are the "Throws" clauses
6165 missing?</p>
6166 <p><b>Proposed resolution:</b></p>
6167 <p>In 17.3.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> paragraph 3, the footnote 148 attached to
6168 the sentence "Descriptions of function semantics contain the
6169 following elements (as appropriate):", insert the word
6170 "further" so that the foot note reads:</p>
6171 <blockquote>
6172   <p>To save space, items that do not apply to a function are
6173   omitted. For example, if a function does not specify any further
6174   preconditions, there will be no "Requires" paragraph.</p>
6175 </blockquote>
6176 <p><b>Rationale:</b></p>
6177 <p>The standard is somewhat inconsistent, but a failure to note a
6178 throw condition in a throws clause does not grant permission not to
6179 throw.  The inconsistent wording is in a footnote, and thus
6180 non-normative. The proposed resolution from the LWG clarifies the
6181 footnote.</p>
6182 <hr>
6183 <a name="223"><h3>223.&nbsp;reverse algorithm should use iter_swap rather than swap</h3></a><p><b>Section:</b>&nbsp;25.2.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.reverse"> [lib.alg.reverse]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;21 Mar 2000</p>
6184 <p>Shouldn't the effects say "applies iter_swap to all pairs..."?</p>
6185 <p><b>Proposed resolution:</b></p>
6186 <p>In 25.2.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.reverse"> [lib.alg.reverse]</a>, replace:</p>
6187   <blockquote>
6188   Effects: For each non-negative integer i &lt;= (last - first)/2,
6189   applies swap to all pairs of iterators first + i, (last - i) - 1.
6190   </blockquote>
6191 <p>with:</p>
6192   <blockquote>
6193   Effects: For each non-negative integer i &lt;= (last - first)/2,
6194   applies iter_swap to all pairs of iterators first + i, (last - i) - 1.
6195   </blockquote>
6196 <hr>
6197 <a name="224"><h3>224.&nbsp;clear() complexity for associative containers refers to undefined N</h3></a><p><b>Section:</b>&nbsp;23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Ed Brey&nbsp; <b>Date:</b>&nbsp;23 Mar 2000</p>
6198 <p>In the associative container requirements table in 23.1.2 paragraph 7,
6199 a.clear() has complexity "log(size()) + N". However, the meaning of N
6200 is not defined.</p>
6201 <p><b>Proposed resolution:</b></p>
6202 <p>In the associative container requirements table in 23.1.2 paragraph
6203 7, the complexity of a.clear(), change "log(size()) + N" to
6204 "linear in <tt>size()</tt>".</p>
6205 <p><b>Rationale:</b></p>
6206 <p>It's the "log(size())", not the "N", that is in
6207 error: there's no difference between <i>O(N)</i> and <i>O(N +
6208 log(N))</i>.  The text in the standard is probably an incorrect
6209 cut-and-paste from the range version of <tt>erase</tt>.</p>
6210 <hr>
6211 <a name="225"><h3>225.&nbsp;std:: algorithms use of other unqualified algorithms</h3></a><p><b>Section:</b>&nbsp;17.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.global.functions"> [lib.global.functions]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;01 Apr 2000</p>
6212 <p>Are algorithms in std:: allowed to use other algorithms without qualification, so functions in
6213 user namespaces might be found through Koenig lookup?</p>
6214 <p>For example, a popular standard library implementation includes this
6215 implementation of std::unique:</p>
6216 <blockquote>
6217 <pre>namespace std {
6218     template &lt;class _ForwardIter&gt;
6219     _ForwardIter unique(_ForwardIter __first, _ForwardIter __last) {
6220       __first = adjacent_find(__first, __last);
6221       return unique_copy(__first, __last, __first);
6222     }
6223     }</pre>
6224 </blockquote>
6225 <p>Imagine two users on opposite sides of town, each using unique on his own
6226 sequences bounded by my_iterators . User1 looks at his standard library
6227 implementation and says, "I know how to implement a more efficient
6228 unique_copy for my_iterators", and writes:</p>
6229 <blockquote>
6230 <pre>namespace user1 {
6231     class my_iterator;
6232     // faster version for my_iterator
6233     my_iterator unique_copy(my_iterator, my_iterator, my_iterator);
6234     }</pre>
6235 </blockquote>
6236 <p>user1::unique_copy() is selected by Koenig lookup, as he intended.</p>
6237 <p>User2 has other needs, and writes:</p>
6238 <blockquote>
6239 <pre>namespace user2 {
6240     class my_iterator;
6241     // Returns true iff *c is a unique copy of *a and *b.
6242     bool unique_copy(my_iterator a, my_iterator b, my_iterator c);
6243     }</pre>
6244 </blockquote>
6245 <p>User2 is shocked to find later that his fully-qualified use of
6246 std::unique(user2::my_iterator, user2::my_iterator, user2::my_iterator) fails to
6247 compile (if he's lucky). Looking in the standard, he sees the following Effects
6248 clause for unique():</p>
6249 <blockquote>
6250   <p>Effects: Eliminates all but the first element from every consecutive group
6251   of equal elements referred to by the iterator i in the range [first, last) for
6252   which the following corresponding conditions hold: *i == *(i - 1) or pred(*i,
6253   *(i - 1)) != false</p>
6254 </blockquote>
6255 <p>The standard gives user2 absolutely no reason to think he can interfere with
6256 std::unique by defining names in namespace user2. His standard library has been
6257 built with the template export feature, so he is unable to inspect the
6258 implementation. User1 eventually compiles his code with another compiler, and
6259 his version of unique_copy silently stops being called. Eventually, he realizes
6260 that he was depending on an implementation detail of his library and had no
6261 right to expect his unique_copy() to be called portably.</p>
6262 <p>On the face of it, and given above scenario, it may seem obvious that the
6263 implementation of unique() shown is non-conforming because it uses unique_copy()
6264 rather than ::std::unique_copy(). Most standard library implementations,
6265 however, seem to disagree with this notion.</p>
6266 <p> <i>[Tokyo:&nbsp; Steve Adamczyk from
6267 the core working group indicates that "std::" is sufficient;&nbsp;
6268 leading "::" qualification is not required because any namespace
6269 qualification is sufficient to suppress Koenig lookup.]</i></p>
6270 <p><b>Proposed resolution:</b></p>
6271 <p>Add a paragraph and a note at the end of
6272 17.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.global.functions"> [lib.global.functions]</a>:</p>
6273 <blockquote>
6274
6275 <p>Unless otherwise specified, no global or non-member function in the
6276 standard library shall use a function from another namespace which is
6277 found through <i>argument-dependent name lookup</i> (3.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/basic.html#basic.lookup.koenig"> [basic.lookup.koenig]</a>).</p>
6278
6279 <p>[Note: the phrase "unless otherwise specified" is intended to
6280 allow Koenig lookup in cases like that of ostream_iterators:<br>
6281
6282 <br>
6283   Effects:</p>
6284   <blockquote>
6285 <p>*out_stream &lt;&lt; value;<br>
6286       if(delim != 0) *out_stream &lt;&lt; delim;<br>
6287       return (*this);</p>
6288     <p>--end note]</p>
6289   </blockquote>
6290 </blockquote>
6291
6292 <p><i>[Tokyo: The LWG agrees that this is a defect in the standard, but
6293 is as yet unsure if the proposed resolution is the best
6294 solution. Furthermore, the LWG believes that the same problem of
6295 unqualified library names applies to wording in the standard itself,
6296 and has opened issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a> accordingly. Any resolution of
6297 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> should be coordinated with the resolution of
6298 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</a>.]</i></p>
6299
6300 <p><i>[Toronto: The LWG is not sure if this is a defect in the
6301 standard.  Most LWG members believe that an implementation of
6302 <tt>std::unique</tt> like the one quoted in this issue is already
6303 illegal, since, under certain circumstances, its semantics are not
6304 those specified in the standard.  The standard's description of
6305 <tt>unique</tt> does not say that overloading <tt>adjacent_find</tt>
6306 should have any effect.]</i></p>
6307
6308 <p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
6309 225, 226, and 229.  Their conclusion was that the issues should be
6310 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
6311 EWG portion (Dave will write a proposal). The LWG and EWG had
6312 (separate) discussions of this plan the next day.  The proposed
6313 resolution for this issue is in accordance with Howard's paper.]</i></p>
6314
6315 <p><b>Rationale:</b></p>
6316 <p>It could be argued that this proposed isn't strictly necessary,
6317   that the Standard doesn't grant implementors license to write a
6318   standard function that behaves differently than specified in the
6319   Standard just because of an unrelated user-defined name in some
6320   other namespace.  However, this is at worst a clarification.  It is
6321   surely right that algorithsm shouldn't pick up random names, that
6322   user-defined names should have no effect unless otherwise specified.
6323   Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</a> deals with the question of when it is
6324   appropriate for the standard to explicitly specify otherwise.</p>
6325 <hr>
6326 <a name="226"><h3>226.&nbsp;User supplied specializations or overloads of namespace std function templates</h3></a><p><b>Section:</b>&nbsp;17.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;01 Apr 2000</p>
6327 <p>The issues are:&nbsp;</p>
6328 <p>1. How can a 3rd party library implementor (lib1) write a version of a standard
6329 algorithm which is specialized to work with his own class template?&nbsp;</p>
6330 <p>2. How can another library implementor (lib2) write a generic algorithm which
6331 will take advantage of the specialized algorithm in lib1?</p>
6332 <p>This appears to be the only viable answer under current language rules:</p>
6333 <blockquote>
6334   <pre>namespace lib1
6335 {
6336     // arbitrary-precision numbers using T as a basic unit
6337     template &lt;class T&gt;
6338     class big_num { //...
6339     };
6340     </pre>
6341   <pre>    // defining this in namespace std is illegal (it would be an
6342     // overload), so we hope users will rely on Koenig lookup
6343     template &lt;class T&gt;
6344     void swap(big_int&lt;T&gt;&amp;, big_int&lt;T&gt;&amp;);
6345 }</pre>
6346   <pre>#include &lt;algorithm&gt;
6347 namespace lib2
6348 {
6349     template &lt;class T&gt;
6350     void generic_sort(T* start, T* end)
6351     {
6352             ...
6353         // using-declaration required so we can work on built-in types
6354         using std::swap;
6355         // use Koenig lookup to find specialized algorithm if available
6356         swap(*x, *y);
6357     }
6358 }</pre>
6359 </blockquote>
6360 <p>This answer has some drawbacks. First of all, it makes writing lib2 difficult
6361 and somewhat slippery. The implementor needs to remember to write the
6362 using-declaration, or generic_sort will fail to compile when T is a built-in
6363 type. The second drawback is that the use of this style in lib2 effectively
6364 "reserves" names in any namespace which defines types which may
6365 eventually be used with lib2. This may seem innocuous at first when applied to
6366 names like swap, but consider more ambiguous names like unique_copy() instead.
6367 It is easy to imagine the user wanting to define these names differently in his
6368 own namespace. A definition with semantics incompatible with the standard
6369 library could cause serious problems (see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>).</p>
6370 <p>Why, you may ask, can't we just partially specialize std::swap()? It's
6371 because the language doesn't allow for partial specialization of function
6372 templates. If you write:</p>
6373 <blockquote>
6374   <pre>namespace std
6375 {
6376     template &lt;class T&gt;
6377     void swap(lib1::big_int&lt;T&gt;&amp;, lib1::big_int&lt;T&gt;&amp;);
6378 }</pre>
6379 </blockquote>
6380 <p>You have just overloaded std::swap, which is illegal under the current
6381 language rules. On the other hand, the following full specialization is legal:</p>
6382 <blockquote>
6383   <pre>namespace std
6384 {
6385     template &lt;&gt;
6386     void swap(lib1::other_type&amp;, lib1::other_type&amp;);
6387 }</pre>
6388 </blockquote>
6389
6390 <p>This issue reflects concerns raised by the "Namespace issue
6391 with specialized swap" thread on comp.lang.c++.moderated. A
6392 similar set of concerns was earlier raised on the boost.org mailing
6393 list and the ACCU-general mailing list.  Also see library reflector
6394 message c++std-lib-7354.</p>
6395
6396 <p>
6397 J. C. van Winkel points out (in c++std-lib-9565) another unexpected
6398 fact: it's impossible to output a container of std::pair's using copy
6399 and an ostream_iterator, as long as both pair-members are built-in or
6400 std:: types.  That's because a user-defined operator&lt;&lt; for (for
6401 example) std::pair&lt;const std::string, int&gt; will not be found:
6402 lookup for operator&lt;&lt; will be performed only in namespace std.
6403 Opinions differed on whether or not this was a defect, and, if so,
6404 whether the defect is that something is wrong with user-defined
6405 functionality and std, or whether it's that the standard library does
6406 not provide an operator&lt;&lt; for std::pair&lt;&gt;.
6407 </p>
6408
6409 <p><b>Proposed resolution:</b></p>
6410
6411 <p>Adopt the wording proposed in Howard Hinnant's paper
6412   N1523=03-0106, "Proposed Resolution To LWG issues 225, 226, 229".</p>
6413
6414
6415 <p><i>[Tokyo: Summary, "There is no conforming way to extend
6416 std::swap for user defined templates."&nbsp; The LWG agrees that
6417 there is a problem.  Would like more information before
6418 proceeding. This may be a core issue.  Core issue 229 has been opened
6419 to discuss the core aspects of this problem. It was also noted that
6420 submissions regarding this issue have been received from several
6421 sources, but too late to be integrated into the issues list.
6422 ]</i></p>
6423
6424 <p><i>[Post-Tokyo: A paper with several proposed resolutions,
6425 J16/00-0029==WG21/N1252, "Shades of namespace std functions
6426 " by Alan Griffiths, is in the Post-Tokyo mailing. It
6427 should be considered a part of this issue.]</i></p>
6428
6429 <p><i>[Toronto: Dave Abrahams and Peter Dimov have proposed a
6430 resolution that involves core changes: it would add partial
6431 specialization of function template.  The Core Working Group is
6432 reluctant to add partial specialization of function templates.  It is
6433 viewed as a large change, CWG believes that proposal presented leaves
6434 some syntactic issues unanswered; if the CWG does add partial
6435 specialization of function templates, it wishes to develop its own
6436 proposal.  The LWG continues to believe that there is a serious
6437 problem: there is no good way for users to force the library to use
6438 user specializations of generic standard library functions, and in
6439 certain cases (e.g. transcendental functions called by
6440 <tt>valarray</tt> and <tt>complex</tt>) this is important.  Koenig
6441 lookup isn't adequate, since names within the library must be
6442 qualified with <tt>std</tt> (see issue 225), specialization doesn't
6443 work (we don't have partial specialization of function templates), and
6444 users aren't permitted to add overloads within namespace std.
6445 ]</i></p>
6446
6447 <p><i>[Copenhagen: Discussed at length, with no consensus.  Relevant
6448 papers in the pre-Copenhagen mailing: N1289, N1295, N1296.  Discussion
6449 focused on four options. (1) Relax restrictions on overloads within
6450 namespace std. (2) Mandate that the standard library use unqualified
6451 calls for <tt>swap</tt> and possibly other functions.  (3) Introduce
6452 helper class templates for <tt>swap</tt> and possibly other functions.
6453 (4) Introduce partial specialization of function templates.  Every
6454 option had both support and opposition.  Straw poll (first number is
6455 support, second is strongly opposed): (1) 6, 4; (2) 6, 7; (3) 3, 8;
6456 (4) 4, 4.]</i></p>
6457
6458 <p><i>[Redmond: Discussed, again no consensus.  Herb presented an
6459 argument that a user who is defining a type <tt>T</tt> with an
6460 associated <tt>swap</tt> should not be expected to put that
6461 <tt>swap</tt> in namespace std, either by overloading or by partial
6462 specialization.  The argument is that <tt>swap</tt> is part of
6463 <tt>T</tt>'s interface, and thus should to in the same namespace as
6464 <tt>T</tt> and only in that namespace.  If we accept this argument,
6465 the consequence is that standard library functions should use
6466 unqualified call of <tt>swap</tt>.  (And which other functions? Any?)
6467 A small group (Nathan, Howard, Jeremy, Dave, Matt, Walter, Marc) will
6468 try to put together a proposal before the next meeting.]</i></p>
6469
6470 <p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
6471 225, 226, and 229.  Their conclusion was that the issues should be
6472 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
6473 EWG portion (Dave will write a proposal). The LWG and EWG had
6474 (separate) discussions of this plan the next day.  The proposed
6475 resolution is the one proposed by Howard.]</i></p>
6476
6477 <p><i>[Santa Cruz: the LWG agreed with the general direction of
6478   Howard's paper, N1387.  (Roughly: Koenig lookup is disabled unless
6479   we say otherwise; this issue is about when we do say otherwise.)
6480   However, there were concerns about wording.  Howard will provide new
6481   wording.  Bill and Jeremy will review it.]</i></p>
6482
6483 <p><i>[Kona: Howard proposed the new wording.  The LWG accepted his
6484   proposed resolution.]</i></p>
6485
6486 <p><b>Rationale:</b></p>
6487 <p>Informally: introduce a Swappable concept, and specify that the
6488   value types of the iterators passed to certain standard algorithms
6489   (such as iter_swap, swap_ranges, reverse, rotate, and sort) conform
6490   to that concept.  The Swappable concept will make it clear that
6491   these algorithms use unqualified lookup for the calls
6492   to <tt>swap</tt>.  Also, in <font color="red">26.3.3.3</font> paragraph 1,
6493   state that the valarray transcendentals use unqualified lookup.</p>
6494 <hr>
6495 <a name="227"><h3>227.&nbsp;std::swap() should require CopyConstructible or DefaultConstructible arguments</h3></a><p><b>Section:</b>&nbsp;25.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.swap"> [lib.alg.swap]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#TC">TC</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;09 Apr 2000</p>
6496 <p>25.2.2 reads:</p>
6497 <blockquote>
6498   <p><tt>  template&lt;class T&gt; void swap(T&amp; a, T&amp; b);</tt><br>
6499   <br>
6500   Requires:    Type T is Assignable (_lib.container.requirements_).<br>
6501   Effects:    Exchanges values stored in two locations.</p>
6502 </blockquote>
6503 <p>The only reasonable** generic implementation of swap requires construction of a
6504    new temporary copy of one of its arguments:</p>
6505 <blockquote>
6506 <pre>template&lt;class T&gt; void swap(T&amp; a, T&amp; b);
6507   {
6508       T tmp(a);
6509       a = b;
6510       b = tmp;
6511   }</pre>
6512 </blockquote>
6513 <p>But a type which is only Assignable cannot be swapped by this implementation.</p>
6514 <p>**Yes, there's also an unreasonable implementation which would require T to be
6515    DefaultConstructible instead of CopyConstructible. I don't think this is worthy
6516    of consideration:</p>
6517 <blockquote>
6518 <pre>template&lt;class T&gt; void swap(T&amp; a, T&amp; b);
6519 {
6520     T tmp;
6521     tmp = a;
6522     a = b;
6523     b = tmp;
6524 }</pre>
6525 </blockquote>
6526 <p><b>Proposed resolution:</b></p>
6527 <p>Change 25.2.2 paragraph 1 from:</p>
6528 <blockquote>
6529 <p>  Requires: Type T is Assignable (23.1).</p>
6530 </blockquote>
6531 <p>to:</p>
6532 <blockquote>
6533 <p>  Requires: Type T is CopyConstructible (20.1.3) and Assignable (23.1)</p>
6534 </blockquote>
6535 <hr>
6536 <a name="228"><h3>228.&nbsp;Incorrect specification of "..._byname" facets</h3></a><p><b>Section:</b>&nbsp;22.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.categories"> [lib.locale.categories]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;20 Apr 2000</p>
6537 <p>The sections 22.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.ctype.byname"> [lib.locale.ctype.byname]</a>, 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>,
6538 <font color="red">22.2.1.6</font>, 22.2.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.numpunct.byname"> [lib.locale.numpunct.byname]</a>, 22.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.collate.byname"> [lib.locale.collate.byname]</a>, 22.2.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.put.byname"> [lib.locale.time.put.byname]</a>, 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>, and 22.2.7.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.messages.byname"> [lib.locale.messages.byname]</a> overspecify the
6539 definitions of the "..._byname" classes by listing a bunch
6540 of virtual functions. At the same time, no semantics of these
6541 functions are defined. Real implementations do not define these
6542 functions because the functional part of the facets is actually
6543 implemented in the corresponding base classes and the constructor of
6544 the "..._byname" version just provides suitable date used by
6545 these implementations. For example, the 'numpunct' methods just return
6546 values from a struct. The base class uses a statically initialized
6547 struct while the derived version reads the contents of this struct
6548 from a table.  However, no virtual function is defined in
6549 'numpunct_byname'.</p>
6550
6551 <p>For most classes this does not impose a problem but specifically
6552 for 'ctype' it does: The specialization for 'ctype_byname&lt;char&gt;'
6553 is required because otherwise the semantics would change due to the
6554 virtual functions defined in the general version for 'ctype_byname':
6555 In 'ctype&lt;char&gt;' the method 'do_is()' is not virtual but it is
6556 made virtual in both 'ctype&lt;cT&gt;' and 'ctype_byname&lt;cT&gt;'.
6557 Thus, a class derived from 'ctype_byname&lt;char&gt;' can tell whether
6558 this class is specialized or not under the current specification:
6559 Without the specialization, 'do_is()' is virtual while with
6560 specialization it is not virtual.</p>
6561 <p><b>Proposed resolution:</b></p>
6562 <p>&nbsp; Change section 22.2.1.2 (lib.locale.ctype.byname) to become:</p>
6563 <pre>     namespace std {
6564        template &lt;class charT&gt;
6565        class ctype_byname : public ctype&lt;charT&gt; {
6566        public:
6567          typedef ctype&lt;charT&gt;::mask mask;
6568          explicit ctype_byname(const char*, size_t refs = 0);
6569        protected:
6570         ~ctype_byname();             //  virtual
6571        };
6572      }</pre>
6573 <p>&nbsp; Change section 22.2.1.6 (lib.locale.codecvt.byname) to become:</p>
6574 <pre>    namespace std {
6575       template &lt;class internT, class externT, class stateT&gt;
6576       class codecvt_byname : public codecvt&lt;internT, externT, stateT&gt; {
6577       public:
6578        explicit codecvt_byname(const char*, size_t refs = 0);
6579       protected:
6580       ~codecvt_byname();             //  virtual
6581        };
6582      }
6583 </pre>
6584 <p>&nbsp; Change section 22.2.3.2 (lib.locale.numpunct.byname) to become:</p>
6585 <pre>     namespace std {
6586        template &lt;class charT&gt;
6587        class numpunct_byname : public numpunct&lt;charT&gt; {
6588      //  this class is specialized for  char  and  wchar_t.
6589        public:
6590          typedef charT                char_type;
6591          typedef basic_string&lt;charT&gt;  string_type;
6592          explicit numpunct_byname(const char*, size_t refs = 0);
6593        protected:
6594         ~numpunct_byname();          //  virtual
6595        };
6596      }</pre>
6597 <p>&nbsp; Change section 22.2.4.2 (lib.locale.collate.byname) to become:</p>
6598 <pre>     namespace std {
6599        template &lt;class charT&gt;
6600        class collate_byname : public collate&lt;charT&gt; {
6601        public:
6602          typedef basic_string&lt;charT&gt; string_type;
6603          explicit collate_byname(const char*, size_t refs = 0);
6604        protected:
6605         ~collate_byname();           //  virtual
6606        };
6607      }</pre>
6608 <p>&nbsp; Change section 22.2.5.2 (lib.locale.time.get.byname) to become:</p>
6609 <pre>     namespace std {
6610        template &lt;class charT, class InputIterator = istreambuf_iterator&lt;charT&gt; &gt;
6611        class time_get_byname : public time_get&lt;charT, InputIterator&gt; {
6612        public:
6613          typedef time_base::dateorder dateorder;
6614          typedef InputIterator        iter_type</pre>
6615 <pre>         explicit time_get_byname(const char*, size_t refs = 0);
6616        protected:
6617         ~time_get_byname();          //  virtual
6618        };
6619      }</pre>
6620 <p>&nbsp; Change section 22.2.5.4 (lib.locale.time.put.byname) to become:</p>
6621 <pre>     namespace std {
6622        template &lt;class charT, class OutputIterator = ostreambuf_iterator&lt;charT&gt; &gt;
6623        class time_put_byname : public time_put&lt;charT, OutputIterator&gt;
6624        {
6625        public:
6626          typedef charT          char_type;
6627          typedef OutputIterator iter_type;</pre>
6628 <pre>         explicit time_put_byname(const char*, size_t refs = 0);
6629        protected:
6630         ~time_put_byname();          //  virtual
6631        };
6632      }"</pre>
6633 <p>&nbsp; Change section 22.2.6.4 (lib.locale.moneypunct.byname) to become:</p>
6634 <pre>     namespace std {
6635        template &lt;class charT, bool Intl = false&gt;
6636        class moneypunct_byname : public moneypunct&lt;charT, Intl&gt; {
6637        public:
6638          typedef money_base::pattern pattern;
6639          typedef basic_string&lt;charT&gt; string_type;</pre>
6640 <pre>         explicit moneypunct_byname(const char*, size_t refs = 0);
6641        protected:
6642         ~moneypunct_byname();        //  virtual
6643        };
6644      }</pre>
6645 <p>&nbsp; Change section 22.2.7.2 (lib.locale.messages.byname) to become:</p>
6646 <pre>     namespace std {
6647        template &lt;class charT&gt;
6648        class messages_byname : public messages&lt;charT&gt; {
6649        public:
6650          typedef messages_base::catalog catalog;
6651          typedef basic_string&lt;charT&gt;    string_type;</pre>
6652 <pre>         explicit messages_byname(const char*, size_t refs = 0);
6653        protected:
6654         ~messages_byname();          //  virtual
6655        };
6656      }</pre>
6657 <p>Remove 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> completely (because in
6658 this case only those members are defined to be virtual which are
6659 defined to be virtual in 'ctype&lt;cT&gt;'.)</p>
6660
6661 <p><i>[Post-Tokyo: Dietmar Kühl submitted this issue at the request of
6662 the LWG to solve the underlying problems raised by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#138">138</a>.]</i></p>
6663
6664 <p><i>[Copenhagen: proposed resolution was revised slightly, to remove
6665 three last virtual functions from <tt>messages_byname</tt>.]</i></p>
6666
6667 <hr>
6668 <a name="229"><h3>229.&nbsp;Unqualified references of other library entities</h3></a><p><b>Section:</b>&nbsp;17.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.contents"> [lib.contents]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;19 Apr 2000</p>
6669 <p>Throughout the library chapters, the descriptions of library entities refer
6670 to other library entities without necessarily qualifying the names.</p>
6671
6672 <p>For example, section 25.2.2 "Swap" describes the effect of
6673 swap_ranges in terms of the unqualified name "swap". This section
6674 could reasonably be interpreted to mean that the library must be implemented so
6675 as to do a lookup of the unqualified name "swap", allowing users to
6676 override any ::std::swap function when Koenig lookup applies.</p>
6677
6678 <p>Although it would have been best to use explicit qualification with
6679 "::std::" throughout, too many lines in the standard would have to be
6680 adjusted to make that change in a Technical Corrigendum.</p>
6681
6682 <p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#182">182</a>, which addresses qualification of
6683 <tt>size_t</tt>, is a special case of this.
6684 </p>
6685 <p><b>Proposed resolution:</b></p>
6686 <p>To section 17.4.1.1 "Library contents" Add the following paragraph:</p>
6687 <blockquote>
6688   <p>Whenever a name x defined in the standard library is mentioned, the name x
6689   is assumed to be fully qualified as ::std::x, unless explicitly described
6690   otherwise. For example, if the Effects section for library function F is
6691   described as calling library function G, the function ::std::G is meant.</p>
6692 </blockquote>
6693
6694 <p><i>[Post-Tokyo: Steve Clamage submitted this issue at the request of
6695 the LWG to solve a problem in the standard itself similar to the
6696 problem within implementations of library identified by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a>.  Any resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</a> should be
6697 coordinated with the resolution of this issue.]</i></p>
6698
6699 <p><i>[post-Toronto: Howard is undecided about whether it is
6700 appropriate for all standard library function names referred to in
6701 other standard library functions to be explicitly qualified by
6702 <tt>std</tt>: it is common advice that users should define global
6703 functions that operate on their class in the same namespace as the
6704 class, and this requires argument-dependent lookup if those functions
6705 are intended to be called by library code.  Several LWG members are
6706 concerned that valarray appears to require argument-dependent lookup,
6707 but that the wording may not be clear enough to fall under
6708 "unless explicitly described otherwise".]</i></p>
6709
6710 <p><i>[Curaçao: An LWG-subgroup spent an afternoon working on issues
6711 225, 226, and 229.  Their conclusion was that the issues should be
6712 separated into an LWG portion (Howard's paper, N1387=02-0045), and a
6713 EWG portion (Dave will write a proposal). The LWG and EWG had
6714 (separate) discussions of this plan the next day.  This paper resolves
6715 issues 225 and 226.  In light of that resolution, the proposed
6716 resolution for the current issue makes sense.]</i></p>
6717
6718 <hr>
6719 <a name="230"><h3>230.&nbsp;Assignable specified without also specifying CopyConstructible</h3></a><p><b>Section:</b>&nbsp;17 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.library"> [lib.library]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;26 Apr 2000</p>
6720 <p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#227">227</a> identified an instance (std::swap) where
6721 Assignable was specified without also specifying
6722 CopyConstructible. The LWG asked that the standard be searched to
6723 determine if the same defect existed elsewhere.</p>
6724
6725 <p>There are a number of places (see proposed resolution below) where
6726 Assignable is specified without also specifying
6727 CopyConstructible. There are also several cases where both are
6728 specified. For example, 26.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.rand.req"> [lib.rand.req]</a>.</p>
6729 <p><b>Proposed resolution:</b></p>
6730 <p>In  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 for value_type:
6731 change "T is Assignable" to "T is CopyConstructible and
6732 Assignable"
6733 </p>
6734
6735 <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> table 69 X::key_type; change
6736 "Key is Assignable" to "Key is
6737 CopyConstructible and Assignable"<br>
6738 </p>
6739
6740 <p>In 24.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.output.iterators"> [lib.output.iterators]</a> paragraph 1, change:
6741 </p>
6742 <blockquote>
6743 <p> A class or a built-in type X satisfies the requirements of an
6744 output iterator if X is an Assignable type (23.1) and also the
6745 following expressions are valid, as shown in Table 73:
6746 </p>
6747 </blockquote>
6748 <p>to:
6749 </p>
6750 <blockquote>
6751 <p> A class or a built-in type X satisfies the requirements of an
6752 output iterator if X is a CopyConstructible (20.1.3) and Assignable
6753 type (23.1) and also the following expressions are valid, as shown in
6754 Table 73:
6755 </p>
6756 </blockquote>
6757
6758 <p><i>[Post-Tokyo: Beman Dawes submitted this issue at the request of
6759 the LWG.  He asks that the 25.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a> and 25.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.fill"> [lib.alg.fill]</a> changes be studied carefully, as it is not clear that
6760 CopyConstructible is really a requirement and may be
6761 overspecification.]</i></p>
6762
6763 <p><i>[Portions of the resolution for issue 230 have been superceded by
6764 the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#276">276</a>.]</i></p>
6765
6766 <p><b>Rationale:</b></p>
6767 <p>The original proposed resolution also included changes to input
6768 iterator, fill, and replace.  The LWG believes that those changes are
6769 not necessary.  The LWG considered some blanket statement, where an
6770 Assignable type was also required to be Copy Constructible, but
6771 decided against this because fill and replace really don't require the
6772 Copy Constructible property.</p>
6773 <hr>
6774 <a name="231"><h3>231.&nbsp;Precision in iostream?</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze, Stephen Clamage&nbsp; <b>Date:</b>&nbsp; 25 Apr 2000</p>
6775 <p>What is the following program supposed to output?</p>
6776 <pre>#include &lt;iostream&gt;
6777
6778     int
6779     main()
6780     {
6781         std::cout.setf( std::ios::scientific , std::ios::floatfield ) ;
6782         std::cout.precision( 0 ) ;
6783         std::cout &lt;&lt; 1.00 &lt;&lt; '\n' ;
6784         return 0 ;
6785     }</pre>
6786 <p>From my C experience, I would expect "1e+00"; this is what
6787 <tt>printf("%.0e" , 1.00 );</tt> does. G++ outputs
6788 "1.000000e+00".</p>
6789
6790 <p>The only indication I can find in the standard is 22.2.2.2.2/11,
6791 where it says "For conversion from a floating-point type, if
6792 (flags &amp; fixed) != 0 or if str.precision() &gt; 0, then
6793 str.precision() is specified in the conversion specification."
6794 This is an obvious error, however, fixed is not a mask for a field,
6795 but a value that a multi-bit field may take -- the results of and'ing
6796 fmtflags with ios::fixed are not defined, at least not if
6797 ios::scientific has been set. G++'s behavior corresponds to what might
6798 happen if you do use (flags &amp; fixed) != 0 with a typical
6799 implementation (floatfield == 3 &lt;&lt; something, fixed == 1
6800 &lt;&lt; something, and scientific == 2 &lt;&lt; something).</p>
6801
6802 <p>Presumably, the intent is either (flags &amp; floatfield) != 0, or
6803 (flags &amp; floatfield) == fixed; the first gives something more or
6804 less like the effect of precision in a printf floating point
6805 conversion. Only more or less, of course. In order to implement printf
6806 formatting correctly, you must know whether the precision was
6807 explicitly set or not. Say by initializing it to -1, instead of 6, and
6808 stating that for floating point conversions, if precision &lt; -1, 6
6809 will be used, for fixed point, if precision &lt; -1, 1 will be used,
6810 etc. Plus, of course, if precision == 0 and flags &amp; floatfield ==
6811 0, 1 should be = used. But it probably isn't necessary to emulate all
6812 of the anomalies of printf:-).</p>
6813 <p><b>Proposed resolution:</b></p>
6814 <p>
6815 Replace 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 11, with the following
6816 sentence:
6817 </p>
6818 <blockquote>
6819 For conversion from a floating-point type,
6820 <tt><i>str</i>.precision()</tt> is specified in the conversion
6821 specification.
6822 </blockquote>
6823 <p><b>Rationale:</b></p>
6824 <p>The floatfield determines whether numbers are formatted as if
6825 with %f, %e, or %g.  If the <tt>fixed</tt> bit is set, it's %f,
6826 if <tt>scientific</tt> it's %e, and if both bits are set, or
6827 neither, it's %g.</p>
6828 <p>Turning to the C standard, a precision of 0 is meaningful
6829 for %f and %e.  For %g, precision 0 is taken to be the same as
6830 precision 1.</p>
6831 <p>The proposed resolution has the effect that if neither
6832 <tt>fixed</tt> nor <tt>scientific</tt> is set we'll be
6833 specifying a precision of 0, which will be internally
6834 turned into 1.  There's no need to call it out as a special
6835 case.</p>
6836 <p>The output of the above program will be "1e+00".</p>
6837
6838 <p><i>[Post-Curaçao: Howard provided improved wording covering the case
6839 where precision is 0 and mode is %g.]</i></p>
6840
6841 <hr>
6842 <a name="232"><h3>232.&nbsp;"depends" poorly defined in 17.4.3.1</h3></a><p><b>Section:</b>&nbsp;17.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.reserved.names"> [lib.reserved.names]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Peter Dimov&nbsp; <b>Date:</b>&nbsp;18 Apr 2000</p>
6843 <p>17.4.3.1/1 uses the term "depends" to limit the set of allowed
6844 specializations of standard templates to those that "depend on a
6845 user-defined name of external linkage."</p>
6846 <p>This term, however, is not adequately defined, making it possible to
6847 construct a specialization that is, I believe, technically legal according to
6848 17.4.3.1/1, but that specializes a standard template for a built-in type such as
6849 'int'.</p>
6850 <p>The following code demonstrates the problem:</p>
6851 <blockquote>
6852   <pre>#include &lt;algorithm&gt;</pre>
6853   <pre>template&lt;class T&gt; struct X
6854 {
6855  typedef T type;
6856 };</pre>
6857   <pre>namespace std
6858 {
6859  template&lt;&gt; void swap(::X&lt;int&gt;::type&amp; i, ::X&lt;int&gt;::type&amp; j);
6860 }</pre>
6861 </blockquote>
6862 <p><b>Proposed resolution:</b></p>
6863 <p>Change "user-defined name" to "user-defined
6864 type".</p>
6865 <p><b>Rationale:</b></p>
6866 <p>This terminology is used in section 2.5.2 and 4.1.1 of <i>The C++
6867 Programming Language</i>.  It disallows the example in the issue,
6868 since the underlying type itself is not user-defined.  The only
6869 possible problem I can see is for non-type templates, but there's no
6870 possible way for a user to come up with a specialization for bitset,
6871 for example, that might not have already been specialized by the
6872 implementor?</p>
6873
6874 <p><i>[Toronto: this may be related to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#120">120</a>.]</i></p>
6875
6876 <p><i>[post-Toronto: Judy provided the above proposed resolution and
6877 rationale.]</i></p>
6878 <hr>
6879 <a name="234"><h3>234.&nbsp;Typos in allocator definition</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;24 Apr 2000</p>
6880 <p>In paragraphs 12 and 13 the effects of <tt>construct()</tt> and
6881 <tt>destruct()</tt> are described as returns but the functions actually
6882 return <tt>void</tt>.</p>
6883 <p><b>Proposed resolution:</b></p>
6884 <p>Substitute "Returns" by "Effect".</p>
6885 <hr>
6886 <a name="235"><h3>235.&nbsp;No specification of default ctor for reverse_iterator</h3></a><p><b>Section:</b>&nbsp;24.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iterator"> [lib.reverse.iterator]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;24 Apr 2000</p>
6887 <p>The declaration of <tt>reverse_iterator</tt> lists a default
6888 constructor.  However, no specification is given what this constructor
6889 should do.</p>
6890 <p><b>Proposed resolution:</b></p>
6891   <p>In section 24.4.1.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.cons"> [lib.reverse.iter.cons]</a> add the following
6892   paragraph:</p>
6893       <blockquote>
6894       <p><tt>reverse_iterator()</tt></p>
6895
6896       <p>Default initializes <tt>current</tt>. Iterator operations
6897       applied to the resulting iterator have defined behavior if and
6898       only if the corresponding operations are defined on a default
6899       constructed iterator of type <tt>Iterator</tt>.</p>
6900       </blockquote>
6901   <p><i>[pre-Copenhagen: Dietmar provide wording for proposed
6902   resolution.]</i></p>
6903 <hr>
6904 <a name="237"><h3>237.&nbsp;Undefined expression in complexity specification</h3></a><p><b>Section:</b>&nbsp;23.2.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.cons"> [lib.deque.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;24 Apr 2000</p>
6905 <p>The complexity specification in paragraph 6 says that the complexity
6906 is linear in <tt>first - last</tt>. Even if <tt>operator-()</tt> is
6907 defined on iterators this term is in general undefined because it
6908 would have to be <tt>last - first</tt>.</p>
6909 <p><b>Proposed resolution:</b></p>
6910   <p>Change paragraph 6 from</p>
6911      <blockquote>Linear in <i>first - last</i>.</blockquote>
6912   <p>to become</p>
6913      <blockquote>Linear in <i>distance(first, last)</i>.</blockquote>
6914 <hr>
6915 <a name="238"><h3>238.&nbsp;Contradictory results of stringbuf initialization.</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dietmar Kühl&nbsp; <b>Date:</b>&nbsp;11 May 2000</p>
6916 <p>In 27.7.1.1 paragraph 4 the results of calling the constructor of
6917 'basic_stringbuf' are said to be <tt>str() == str</tt>. This is fine
6918 that far but consider this code:</p>
6919
6920 <pre>  std::basic_stringbuf&lt;char&gt; sbuf("hello, world", std::ios_base::openmode(0));
6921   std::cout &lt;&lt; "'" &lt;&lt; sbuf.str() &lt;&lt; "'\n";
6922 </pre>
6923
6924 <p>Paragraph 3 of 27.7.1.1 basically says that in this case neither
6925 the output sequence nor the input sequence is initialized and
6926 paragraph 2 of 27.7.1.2 basically says that <tt>str()</tt> either
6927 returns the input or the output sequence. None of them is initialized,
6928 ie. both are empty, in which case the return from <tt>str()</tt> is
6929 defined to be <tt>basic_string&lt;cT&gt;()</tt>.</p>
6930
6931 <p>However, probably only test cases in some testsuites will detect this
6932 "problem"...</p>
6933 <p><b>Proposed resolution:</b></p>
6934 <p>Remove 27.7.1.1 paragraph 4.</p>
6935 <p><b>Rationale:</b></p>
6936 <p>We could fix 27.7.1.1 paragraph 4, but there would be no point.  If
6937 we fixed it, it would say just the same thing as text that's already
6938 in the standard.</p>
6939 <hr>
6940 <a name="239"><h3>239.&nbsp;Complexity of unique() and/or unique_copy incorrect</h3></a><p><b>Section:</b>&nbsp;25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
6941 <p>The complexity of unique and unique_copy are inconsistent with each
6942 other and inconsistent with the implementations.&nbsp; The standard
6943 specifies:</p>
6944
6945 <p>for unique():</p>
6946
6947 <blockquote>-3- Complexity: If the range (last - first) is not empty, exactly
6948 (last - first) - 1 applications of the corresponding predicate, otherwise
6949 no applications of the predicate.</blockquote>
6950
6951 <p>for unique_copy():</p>
6952
6953 <blockquote>-7- Complexity: Exactly last - first applications of the corresponding
6954 predicate.</blockquote>
6955
6956 <p>
6957 The implementations do it the other way round: unique() applies the
6958 predicate last-first times and unique_copy() applies it last-first-1
6959 times.</p>
6960
6961 <p>As both algorithms use the predicate for pair-wise comparison of
6962 sequence elements I don't see a justification for unique_copy()
6963 applying the predicate last-first times, especially since it is not
6964 specified to which pair in the sequence the predicate is applied
6965 twice.</p>
6966 <p><b>Proposed resolution:</b></p>
6967 <p>Change both complexity sections in 25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a> to:</p>
6968
6969 <blockquote>Complexity: For nonempty ranges, exactly last - first - 1
6970 applications of the corresponding predicate.</blockquote>
6971
6972 <hr>
6973 <a name="240"><h3>240.&nbsp;Complexity of adjacent_find() is meaningless</h3></a><p><b>Section:</b>&nbsp;25.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.adjacent.find"> [lib.alg.adjacent.find]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
6974 <p>The complexity section of adjacent_find is defective:</p>
6975
6976 <blockquote>
6977 <pre>template &lt;class ForwardIterator&gt;
6978 ForwardIterator adjacent_find(ForwardIterator first, ForwardIterator last
6979                               BinaryPredicate pred);
6980 </pre>
6981
6982 <p>-1- Returns: The first iterator i such that both i and i + 1 are in
6983 the range [first, last) for which the following corresponding
6984 conditions hold: *i == *(i + 1), pred(*i, *(i + 1)) != false. Returns
6985 last if no such iterator is found.</p>
6986
6987 <p>-2- Complexity: Exactly find(first, last, value) - first applications
6988 of the corresponding predicate.
6989 </p>
6990 </blockquote>
6991
6992 <p>In the Complexity section, it is not defined what "value"
6993 is supposed to mean. My best guess is that "value" means an
6994 object for which one of the conditions pred(*i,value) or
6995 pred(value,*i) is true, where i is the iterator defined in the Returns
6996 section. However, the value type of the input sequence need not be
6997 equality-comparable and for this reason the term find(first, last,
6998 value) - first is meaningless.</p>
6999
7000 <p>A term such as find_if(first, last, bind2nd(pred,*i)) - first or
7001 find_if(first, last, bind1st(pred,*i)) - first might come closer to
7002 the intended specification.  Binders can only be applied to function
7003 objects that have the function call operator declared const, which is
7004 not required of predicates because they can have non-const data
7005 members. For this reason, a specification using a binder could only be
7006 an "as-if" specification.</p>
7007 <p><b>Proposed resolution:</b></p>
7008 <p>Change the complexity section in 25.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.adjacent.find"> [lib.alg.adjacent.find]</a> to:</p>
7009 <blockquote>
7010 For a nonempty range, exactly <tt>min((<i>i</i> - <i>first</i>) + 1,
7011 (<i>last</i> - <i>first</i>) - 1)</tt> applications of the
7012 corresponding predicate, where <i>i</i> is <tt>adjacent_find</tt>'s
7013 return value.
7014 </blockquote>
7015
7016 <p><i>[Copenhagen: the original resolution specified an upper
7017 bound.  The LWG preferred an exact count.]</i></p>
7018
7019 <hr>
7020 <a name="241"><h3>241.&nbsp;Does unique_copy() require CopyConstructible and Assignable?</h3></a><p><b>Section:</b>&nbsp;25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
7021
7022 <p>Some popular implementations of unique_copy() create temporary
7023 copies of values in the input sequence, at least if the input iterator
7024 is a pointer.  Such an implementation is built on the assumption that
7025 the value type is CopyConstructible and Assignable.</p>
7026
7027 <p>It is common practice in the standard that algorithms explicitly
7028 specify any additional requirements that they impose on any of the
7029 types used by the algorithm. An example of an algorithm that creates
7030 temporary copies and correctly specifies the additional requirements
7031 is accumulate(), 26.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.rand.req"> [lib.rand.req]</a>.</p>
7032
7033 <p>Since the specifications of unique() and unique_copy() do not
7034 require CopyConstructible and Assignable of the InputIterator's value
7035 type the above mentioned implementations are not standard-compliant. I
7036 cannot judge whether this is a defect in the standard or a defect in
7037 the implementations.</p>
7038 <p><b>Proposed resolution:</b></p>
7039 <p>In 25.2.8 change:</p>
7040
7041 <blockquote>
7042 -4- Requires: The ranges [first, last) and [result, result+(last-first))
7043 shall not overlap.
7044 </blockquote>
7045
7046 <p>to:</p>
7047
7048 <blockquote>
7049   <p>-4- Requires: The ranges [first, last) and [result,
7050   result+(last-first)) shall not overlap. The expression *result =
7051   *first must be valid. If neither InputIterator nor OutputIterator
7052   meets the requirements of forward iterator then the value type of
7053   InputIterator must be copy constructible. Otherwise copy
7054   constructible is not required. </p>
7055 </blockquote>
7056
7057 <p><i>[Redmond: the original proposed resolution didn't impose an
7058 explicit requirement that the iterator's value type must be copy
7059 constructible, on the grounds that an input iterator's value type must
7060 always be copy constructible.  Not everyone in the LWG thought that
7061 this requirement was clear from table 72.  It has been suggested that
7062 it might be possible to implement <tt>unique_copy</tt> without
7063 requiring assignability, although current implementations do impose
7064 that requirement.  Howard provided new wording.]</i></p>
7065
7066 <p><i>[
7067 Curaçao: The LWG changed the PR editorially to specify
7068 "neither...nor...meet..." as clearer than
7069 "both...and...do not meet...". Change believed to be so
7070 minor as not to require re-review.
7071 ]</i></p>
7072
7073 <hr>
7074 <a name="242"><h3>242.&nbsp;Side effects of function objects</h3></a><p><b>Section:</b>&nbsp;25.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.transform"> [lib.alg.transform]</a>, 26.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.rand"> [lib.rand]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Angelika Langer&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
7075 <p>The algorithms transform(), accumulate(), inner_product(),
7076 partial_sum(), and adjacent_difference() require that the function
7077 object supplied to them shall not have any side effects.</p>
7078
7079 <p>The standard defines a side effect in 1.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/intro.html#intro.execution"> [intro.execution]</a> as:</p>
7080 <blockquote>-7- Accessing an object designated by a volatile lvalue (basic.lval),
7081 modifying an object, calling a library I/O function, or calling a function
7082 that does any of those operations are all side effects, which are changes
7083 in the state of the execution environment.</blockquote>
7084
7085 <p>As a consequence, the function call operator of a function object supplied
7086 to any of the algorithms listed above cannot modify data members, cannot
7087 invoke any function that has a side effect, and cannot even create and
7088 modify temporary objects.&nbsp; It is difficult to imagine a function object
7089 that is still useful under these severe limitations. For instance, any
7090 non-trivial transformator supplied to transform() might involve creation
7091 and modification of temporaries, which is prohibited according to the current
7092 wording of the standard.</p>
7093
7094 <p>On the other hand, popular implementations of these algorithms exhibit
7095 uniform and predictable behavior when invoked with a side-effect-producing
7096 function objects. It looks like the strong requirement is not needed for
7097 efficient implementation of these algorithms.</p>
7098
7099 <p>The requirement of&nbsp; side-effect-free function objects could be
7100 replaced by a more relaxed basic requirement (which would hold for all
7101 function objects supplied to any algorithm in the standard library):</p>
7102 <blockquote>A function objects supplied to an algorithm shall not invalidate
7103 any iterator or sequence that is used by the algorithm. Invalidation of
7104 the sequence includes destruction of the sorting order if the algorithm
7105 relies on the sorting order (see section 25.3 - Sorting and related operations
7106 [lib.alg.sorting]).</blockquote>
7107
7108 <p>I can't judge whether it is intended that the function objects supplied
7109 to transform(), accumulate(), inner_product(), partial_sum(), or adjacent_difference()
7110 shall not modify sequence elements through dereferenced iterators.</p>
7111
7112 <p>It is debatable whether this issue is a defect or a change request.
7113 Since the consequences for user-supplied function objects are drastic and
7114 limit the usefulness of the algorithms significantly I would consider it
7115 a defect.</p>
7116 <p><b>Proposed resolution:</b></p>
7117
7118 <p><i>Things to notice about these changes:</i></p>
7119
7120 <ol>
7121 <li> <i>The fully-closed ("[]" as opposed to half-closed "[)" ranges
7122      are intentional. we want to prevent side-effects from
7123      invalidating the end iterators.</i>
7124 </li>
7125
7126 <li> <i>That has the unintentional side-effect of prohibiting
7127      modification of the end element as a side-effect. This could
7128      conceivably be significant in some cases.</i>
7129 </li>
7130
7131 <li> <i>The wording also prevents side-effects from modifying elements
7132      of the output sequence. I can't imagine why anyone would want
7133      to do this, but it is arguably a restriction that implementors
7134      don't need to place on users.</i>
7135 </li>
7136
7137 <li> <i>Lifting the restrictions imposed in #2 and #3 above is possible
7138      and simple, but would require more verbiage.</i>
7139 </li>
7140 </ol>
7141
7142 <p>Change 25.2.3/2 from:</p>
7143
7144 <blockquote>
7145    -2- Requires: op and binary_op shall not have any side effects.
7146 </blockquote>
7147
7148 <p>to:</p>
7149
7150 <blockquote>
7151   -2- Requires: in the ranges [first1, last1], [first2, first2 +
7152   (last1 - first1)] and [result, result + (last1- first1)], op and
7153   binary_op shall neither modify elements nor invalidate iterators or
7154   subranges.
7155   [Footnote: The use of fully closed ranges is intentional --end footnote]
7156 </blockquote>
7157
7158
7159 <p>Change 25.2.3/2 from:</p>
7160
7161 <blockquote>
7162    -2- Requires: op and binary_op shall not have any side effects.
7163 </blockquote>
7164
7165 <p>to:</p>
7166
7167 <blockquote>
7168   -2- Requires: op and binary_op shall not invalidate iterators or
7169    subranges, or modify elements in the ranges [first1, last1],
7170    [first2, first2 + (last1 - first1)], and [result, result + (last1
7171    - first1)].
7172   [Footnote: The use of fully closed ranges is intentional --end footnote]
7173 </blockquote>
7174
7175
7176 <p>Change 26.4.1/2 from:</p>
7177
7178 <blockquote>
7179   -2- Requires: T must meet the requirements of CopyConstructible
7180    (lib.copyconstructible) and Assignable (lib.container.requirements)
7181    types. binary_op shall not cause side effects.
7182 </blockquote>
7183
7184 <p>to:</p>
7185
7186 <blockquote>
7187   -2- Requires: T must meet the requirements of CopyConstructible
7188    (lib.copyconstructible) and Assignable
7189    (lib.container.requirements) types. In the range [first, last],
7190    binary_op shall neither modify elements nor invalidate iterators
7191    or subranges.
7192   [Footnote: The use of a fully closed range is intentional --end footnote]
7193 </blockquote>
7194
7195 <p>Change 26.4.2/2 from:</p>
7196
7197 <blockquote>
7198   -2- Requires: T must meet the requirements of CopyConstructible
7199    (lib.copyconstructible) and Assignable (lib.container.requirements)
7200    types. binary_op1 and binary_op2 shall not cause side effects.
7201 </blockquote>
7202
7203 <p>to:</p>
7204
7205 <blockquote>
7206   -2- Requires: T must meet the requirements of CopyConstructible
7207    (lib.copyconstructible) and Assignable (lib.container.requirements)
7208    types. In the ranges [first, last] and [first2, first2 + (last -
7209    first)], binary_op1 and binary_op2 shall neither modify elements
7210    nor invalidate iterators or subranges.
7211   [Footnote: The use of fully closed ranges is intentional --end footnote]
7212 </blockquote>
7213
7214
7215 <p>Change 26.4.3/4 from:</p>
7216
7217 <blockquote>
7218   -4- Requires: binary_op is expected not to have any side effects.
7219 </blockquote>
7220
7221 <p>to:</p>
7222
7223 <blockquote>
7224   -4- Requires: In the ranges [first, last] and [result, result +
7225    (last - first)], binary_op shall neither modify elements nor
7226    invalidate iterators or subranges.
7227   [Footnote: The use of fully closed ranges is intentional --end footnote]
7228 </blockquote>
7229
7230 <p>Change 26.4.4/2 from:</p>
7231
7232 <blockquote>
7233   -2- Requires: binary_op shall not have any side effects.
7234 </blockquote>
7235
7236 <p>to:</p>
7237
7238 <blockquote>
7239   -2- Requires: In the ranges [first, last] and [result, result +
7240    (last - first)], binary_op shall neither modify elements nor
7241    invalidate iterators or subranges.
7242   [Footnote: The use of fully closed ranges is intentional --end footnote]
7243 </blockquote>
7244
7245 <p><i>[Toronto: Dave Abrahams supplied wording.]</i></p>
7246
7247 <p><i>[Copenhagen: Proposed resolution was modified slightly. Matt
7248 added footnotes pointing out that the use of closed ranges was
7249 intentional.]</i></p>
7250
7251 <hr>
7252 <a name="243"><h3>243.&nbsp;<tt>get</tt> and <tt>getline</tt> when sentry reports failure</h3></a><p><b>Section:</b>&nbsp;27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;May 15 2000</p>
7253 <p>basic_istream&lt;&gt;::get(), and basic_istream&lt;&gt;::getline(),
7254 are unclear with respect to the behavior and side-effects of the named
7255 functions in case of an error.</p>
7256
7257 <p>27.6.1.3, p1 states that "... If the sentry object returns
7258 true, when converted to a value of type bool, the function endeavors
7259 to obtain the requested input..." It is not clear from this (or
7260 the rest of the paragraph) what precisely the behavior should be when
7261 the sentry ctor exits by throwing an exception or when the sentry
7262 object returns false.  In particular, what is the number of characters
7263 extracted that gcount() returns supposed to be?</p>
7264
7265 <p>27.6.1.3 p8 and p19 say about the effects of get() and getline():
7266 "...  In any case, it then stores a null character (using
7267 charT()) into the next successive location of the array." Is not
7268 clear whether this sentence applies if either of the conditions above
7269 holds (i.e., when sentry fails).</p>
7270 <p><b>Proposed resolution:</b></p>
7271 <p>Add to 27.6.1.3, p1 after the sentence</p>
7272
7273 <blockquote>
7274 "... If the sentry object returns true, when converted to a value of
7275 type bool, the function endeavors to obtain the requested input."
7276 </blockquote>
7277
7278 <p>the following</p>
7279
7280
7281 <blockquote>
7282 "Otherwise, if the sentry constructor exits by throwing an exception or
7283 if the sentry object returns false, when converted to a value of type
7284 bool, the function returns without attempting to obtain any input. In
7285 either case the number of extracted characters is set to 0; unformatted
7286 input functions taking a character array of non-zero size as an argument
7287 shall also store a null character (using charT()) in the first location
7288 of the array."
7289 </blockquote>
7290 <p><b>Rationale:</b></p>
7291 <p>Although the general philosophy of the input functions is that the
7292 argument should not be modified upon failure, <tt>getline</tt>
7293 historically added a terminating null unconditionally.  Most
7294 implementations still do that.  Earlier versions of the draft standard
7295 had language that made this an unambiguous requirement; those words
7296 were moved to a place where their context made them less clear.  See
7297 Jerry Schwarz's message c++std-lib-7618.</p>
7298 <hr>
7299 <a name="247"><h3>247.&nbsp;<tt>vector</tt>, <tt>deque::insert</tt> complexity</h3></a><p><b>Section:</b>&nbsp;23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Lisa Lippincott&nbsp; <b>Date:</b>&nbsp;06 June 2000</p>
7300 <p>Paragraph 2 of 23.2.4.3 [lib.vector.modifiers] describes the complexity
7301 of <tt>vector::insert</tt>:</p>
7302
7303    <blockquote>
7304    Complexity: If first and last are forward iterators, bidirectional
7305    iterators, or random access iterators, the complexity is linear in
7306    the number of elements in the range [first, last) plus the distance
7307    to the end of the vector. If they are input iterators, the complexity
7308    is proportional to the number of elements in the range [first, last)
7309    times the distance to the end of the vector.
7310    </blockquote>
7311
7312 <p>First, this fails to address the non-iterator forms of
7313 <tt>insert</tt>.</p>
7314
7315 <p>Second, the complexity for input iterators misses an edge case --
7316 it requires that an arbitrary number of elements can be added at
7317 the end of a <tt>vector</tt> in constant time.</p>
7318
7319 <p>I looked to see if <tt>deque</tt> had a similar problem, and was
7320 surprised to find that <tt>deque</tt> places no requirement on the
7321 complexity of inserting multiple elements (23.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.array.size"> [lib.array.size]</a>,
7322 paragraph 3):</p>
7323
7324    <blockquote>
7325    Complexity: In the worst case, inserting a single element into a
7326    deque takes time linear in the minimum of the distance from the
7327    insertion point to the beginning of the deque and the distance
7328    from the insertion point to the end of the deque. Inserting a
7329    single element either at the beginning or end of a deque always
7330    takes constant time and causes a single call to the copy constructor
7331    of T.
7332    </blockquote>
7333 <p><b>Proposed resolution:</b></p>
7334
7335 <p>Change Paragraph 2 of 23.2.4.3 [lib.vector.modifiers] to</p>
7336    <blockquote>
7337    Complexity: The complexity is linear in the number of elements
7338    inserted plus the distance to the end of the vector.
7339    </blockquote>
7340
7341    <p><i>[For input iterators, one may achieve this complexity by first
7342    inserting at the end of the <tt>vector</tt>, and then using
7343    <tt>rotate</tt>.]</i></p>
7344
7345 <p>Change 23.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.array.size"> [lib.array.size]</a>, paragraph 3, to:</p>
7346
7347    <blockquote>
7348    Complexity: The complexity is linear in the number of elements
7349    inserted plus the shorter of the distances to the beginning and
7350    end of the deque.  Inserting a single element at either the
7351    beginning or the end of a deque causes a single call to the copy
7352    constructor of T.
7353    </blockquote>
7354
7355 <p><b>Rationale:</b></p>
7356 <p>This is a real defect, and proposed resolution fixes it: some
7357   complexities aren't specified that should be.  This proposed
7358   resolution does constrain deque implementations (it rules out the
7359   most naive possible implementations), but the LWG doesn't see a
7360   reason to permit that implementation.</p>
7361 <hr>
7362 <a name="248"><h3>248.&nbsp;time_get fails to set eofbit</h3></a><p><b>Section:</b>&nbsp;22.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.category.time"> [lib.category.time]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;22 June 2000</p>
7363 <p>There is no requirement that any of time_get member functions set
7364 ios::eofbit when they reach the end iterator while parsing their input.
7365 Since members of both the num_get and money_get facets are required to
7366 do so (22.2.2.1.2, and 22.2.6.1.2, respectively), time_get members
7367 should follow the same requirement for consistency.</p>
7368 <p><b>Proposed resolution:</b></p>
7369 <p>Add paragraph 2 to section 22.2.5.1 with the following text:</p>
7370
7371 <blockquote>
7372 If the end iterator is reached during parsing by any of the get()
7373 member functions, the member sets ios_base::eofbit in err.
7374 </blockquote>
7375 <p><b>Rationale:</b></p>
7376 <p>Two alternative resolutions were proposed.  The LWG chose this one
7377 because it was more consistent with the way eof is described for other
7378 input facets.</p>
7379 <hr>
7380 <a name="250"><h3>250.&nbsp;splicing invalidates iterators</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Brian Parker &nbsp; <b>Date:</b>&nbsp;14 Jul 2000</p>
7381 <p>
7382 Section 23.2.2.4 [lib.list.ops] states that
7383 </p>
7384 <pre>  void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
7385 </pre>
7386 <p>
7387 <i>invalidates</i> all iterators and references to list <tt>x</tt>.
7388 </p>
7389
7390 <p>
7391 This is unnecessary and defeats an important feature of splice. In
7392 fact, the SGI STL guarantees that iterators to <tt>x</tt> remain valid
7393 after <tt>splice</tt>.
7394 </p>
7395 <p><b>Proposed resolution:</b></p>
7396
7397 <p>Add a footnote to 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>, paragraph 1:</p>
7398 <blockquote>
7399 [<i>Footnote:</i> As specified in 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>, paragraphs
7400 4-5, the semantics described in this clause applies only to the case
7401 where allocators compare equal.  --end footnote]
7402 </blockquote>
7403
7404 <p>In 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>, replace paragraph 4 with:</p>
7405 <blockquote>
7406 Effects: Inserts the contents of x before position and x becomes
7407 empty.  Pointers and references to the moved elements of x now refer to
7408 those same elements but as members of *this.  Iterators referring to the
7409 moved elements will continue to refer to their elements, but they now
7410 behave as iterators into *this, not into x.
7411 </blockquote>
7412
7413 <p>In 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>, replace paragraph 7 with:</p>
7414 <blockquote>
7415 Effects: Inserts an element pointed to by i from list x before
7416 position and removes the element from x. The result is unchanged if
7417 position == i or position == ++i.  Pointers and references to *i continue
7418 to refer to this same element but as a member of *this.  Iterators to *i
7419 (including i itself) continue to refer to the same element, but now
7420 behave as iterators into *this, not into x.
7421 </blockquote>
7422
7423 <p>In 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>, replace paragraph 12 with:</p>
7424 <blockquote>
7425 Requires: [first, last) is a valid range in x. The result is
7426 undefined if position is an iterator in the range [first, last).
7427 Pointers and references to the moved elements of x now refer to those
7428 same elements but as members of *this.  Iterators referring to the moved
7429 elements will continue to refer to their elements, but they now behave as
7430 iterators into *this, not into x.
7431 </blockquote>
7432
7433 <p><i>[pre-Copenhagen: Howard provided wording.]</i></p>
7434 <p><b>Rationale:</b></p>
7435 <p>The original proposed resolution said that iterators and references
7436 would remain "valid".  The new proposed resolution clarifies what that
7437 means.  Note that this only applies to the case of equal allocators.
7438 From 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> paragraph 4, the behavior of list when
7439 allocators compare nonequal is outside the scope of the standard.</p>
7440 <hr>
7441 <a name="251"><h3>251.&nbsp;basic_stringbuf missing allocator_type</h3></a><p><b>Section:</b>&nbsp;27.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf"> [lib.stringbuf]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jul 2000</p>
7442 <p>The synopsis for the template class <tt>basic_stringbuf</tt>
7443 doesn't list a typedef for the template parameter
7444 <tt>Allocator</tt>. This makes it impossible to determine the type of
7445 the allocator at compile time. It's also inconsistent with all other
7446 template classes in the library that do provide a typedef for the
7447 <tt>Allocator</tt> parameter.</p>
7448 <p><b>Proposed resolution:</b></p>
7449 <p>Add to the synopses of the class templates basic_stringbuf (27.7.1),
7450 basic_istringstream (27.7.2), basic_ostringstream (27.7.3), and
7451 basic_stringstream (27.7.4) the typedef:</p>
7452 <pre>  typedef Allocator allocator_type;
7453 </pre>
7454 <hr>
7455 <a name="252"><h3>252.&nbsp;missing casts/C-style casts used in iostreams</h3></a><p><b>Section:</b>&nbsp;27.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.string.streams"> [lib.string.streams]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jul 2000</p>
7456 <p>27.7.2.2, p1 uses a C-style cast rather than the more appropriate
7457 const_cast&lt;&gt; in the Returns clause for basic_istringstream&lt;&gt;::rdbuf().
7458 The same C-style cast is being used in 27.7.3.2, p1, D.7.2.2, p1, and
7459 D.7.3.2, p1, and perhaps elsewhere. 27.7.6, p1 and D.7.2.2, p1 are missing
7460 the cast altogether.</p>
7461
7462 <p>C-style casts have not been deprecated, so the first part of this
7463 issue is stylistic rather than a matter of correctness.</p>
7464 <p><b>Proposed resolution:</b></p>
7465 <p>In 27.7.2.2, p1 replace </p>
7466 <pre>  -1- Returns: (basic_stringbuf&lt;charT,traits,Allocator&gt;*)&amp;sb.</pre>
7467
7468 <p>with</p>
7469 <pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
7470
7471
7472 <p>In 27.7.3.2, p1 replace</p>
7473 <pre>  -1- Returns: (basic_stringbuf&lt;charT,traits,Allocator&gt;*)&amp;sb.</pre>
7474
7475 <p>with</p>
7476 <pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
7477
7478 <p>In 27.7.6, p1, replace</p>
7479 <pre>  -1- Returns: &amp;sb</pre>
7480
7481 <p>with</p>
7482 <pre>  -1- Returns: const_cast&lt;basic_stringbuf&lt;charT,traits,Allocator&gt;*&gt;(&amp;sb).</pre>
7483
7484 <p>In D.7.2.2, p1 replace</p>
7485 <pre>  -2- Returns: &amp;sb. </pre>
7486
7487 <p>with</p>
7488 <pre>  -2- Returns: const_cast&lt;strstreambuf*&gt;(&amp;sb).</pre>
7489 <hr>
7490 <a name="253"><h3>253.&nbsp;valarray helper functions are almost entirely useless</h3></a><p><b>Section:</b>&nbsp;26.5.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.cons"> [lib.valarray.cons]</a>, 26.5.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.valarray.assign"> [lib.valarray.assign]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Robert Klarer&nbsp; <b>Date:</b>&nbsp;31 Jul 2000</p>
7491 <p>This discussion is adapted from message c++std-lib-7056 posted
7492 November 11, 1999.  I don't think that anyone can reasonably claim
7493 that the problem described below is NAD.</p>
7494
7495 <p>These valarray constructors can never be called:</p>
7496
7497 <pre>   template &lt;class T&gt;
7498          valarray&lt;T&gt;::valarray(const slice_array&lt;T&gt; &amp;);
7499    template &lt;class T&gt;
7500          valarray&lt;T&gt;::valarray(const gslice_array&lt;T&gt; &amp;);
7501    template &lt;class T&gt;
7502          valarray&lt;T&gt;::valarray(const mask_array&lt;T&gt; &amp;);
7503    template &lt;class T&gt;
7504          valarray&lt;T&gt;::valarray(const indirect_array&lt;T&gt; &amp;);
7505 </pre>
7506
7507 <p>Similarly, these valarray assignment operators cannot be
7508 called:</p>
7509
7510 <pre>     template &lt;class T&gt;
7511      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const slice_array&lt;T&gt; &amp;);
7512      template &lt;class T&gt;
7513      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const gslice_array&lt;T&gt; &amp;);
7514      template &lt;class T&gt;
7515      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const mask_array&lt;T&gt; &amp;);
7516      template &lt;class T&gt;
7517      valarray&lt;T&gt; valarray&lt;T&gt;::operator=(const indirect_array&lt;T&gt; &amp;);
7518 </pre>
7519
7520 <p>Please consider the following example:</p>
7521
7522 <pre>   #include &lt;valarray&gt;
7523    using namespace std;
7524
7525    int main()
7526    {
7527        valarray&lt;double&gt; va1(12);
7528        valarray&lt;double&gt; va2(va1[slice(1,4,3)]); // line 1
7529    }
7530 </pre>
7531
7532
7533 <p>Since the valarray va1 is non-const, the result of the sub-expression
7534 va1[slice(1,4,3)] at line 1 is an rvalue of type const
7535 std::slice_array&lt;double&gt;.  This slice_array rvalue is then used to
7536 construct va2.  The constructor that is used to construct va2 is
7537 declared like this:</p>
7538
7539 <pre>     template &lt;class T&gt;
7540      valarray&lt;T&gt;::valarray(const slice_array&lt;T&gt; &amp;);
7541 </pre>
7542
7543 <p>Notice the constructor's const reference parameter.  When the
7544 constructor is called, a slice_array must be bound to this reference.
7545 The rules for binding an rvalue to a const reference are in 8.5.3,
7546 paragraph 5 (see also 13.3.3.1.4).  Specifically, paragraph 5
7547 indicates that a second slice_array rvalue is constructed (in this
7548 case copy-constructed) from the first one; it is this second rvalue
7549 that is bound to the reference parameter.  Paragraph 5 also requires
7550 that the constructor that is used for this purpose be callable,
7551 regardless of whether the second rvalue is elided.  The
7552 copy-constructor in this case is not callable, however, because it is
7553 private.  Therefore, the compiler should report an error.</p>
7554
7555 <p>Since slice_arrays are always rvalues, the valarray constructor that has a
7556 parameter of type const slice_array&lt;T&gt; &amp; can never be called.  The
7557 same reasoning applies to the three other constructors and the four
7558 assignment operators that are listed at the beginning of this post.
7559 Furthermore, since these functions cannot be called, the valarray helper
7560 classes are almost entirely useless.</p>
7561 <p><b>Proposed resolution:</b></p>
7562 <p>slice_array:</p>
7563 <ul>
7564 <li> Make the copy constructor and copy-assignment operator declarations
7565      public in the slice_array class template definition in 26.5.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a> </li>
7566 <li> remove paragraph 3 of 26.5.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.slice.array"> [lib.template.slice.array]</a>
7567 </li>
7568 <li> remove the copy constructor declaration from 26.5.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.cons.slice.arr"> [lib.cons.slice.arr]</a>
7569 </li>
7570 <li> change paragraph 1 of 26.5.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.cons.slice.arr"> [lib.cons.slice.arr]</a> to read "This constructor is declared
7571     to be private.  This constructor need not be defined."</li>
7572 <li> remove the first sentence of paragraph 1 of 26.5.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a>
7573 </li>
7574 <li> Change the first three words of the second sentence of paragraph 1 of
7575     26.5.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.slice.arr.assign"> [lib.slice.arr.assign]</a> to "These assignment operators have"</li>
7576 </ul>
7577
7578 <p>gslice_array:</p>
7579 <ul>
7580 <li> Make the copy constructor and copy-assignment operator declarations
7581     public in the gslice_array class template definition in 26.5.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a> </li>
7582 <li> remove the note in paragraph 3 of 26.5.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.gslice.array"> [lib.template.gslice.array]</a>
7583 </li>
7584 <li> remove the copy constructor declaration from 26.5.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.gslice.array.cons"> [lib.gslice.array.cons]</a>
7585 </li>
7586 <li> change paragraph 1 of 26.5.7.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.gslice.array.cons"> [lib.gslice.array.cons]</a> to read "This constructor is declared
7587     to be private.  This constructor need not be defined."</li>
7588 <li> remove the first sentence of paragraph 1 of 26.5.7.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.gslice.array.assign"> [lib.gslice.array.assign]</a>
7589 </li>
7590 <li> Change the first three words of the second sentence of paragraph 1 of
7591     26.5.7.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.gslice.array.assign"> [lib.gslice.array.assign]</a> to "These assignment operators have"</li>
7592 </ul>
7593
7594 <p>mask_array:</p>
7595 <ul>
7596 <li> Make the copy constructor and copy-assignment operator declarations
7597     public in the mask_array class template definition in 26.5.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a> </li>
7598 <li> remove the note in paragraph 2 of 26.5.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.mask.array"> [lib.template.mask.array]</a>
7599 </li>
7600 <li> remove the copy constructor declaration from 26.5.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.mask.array.cons"> [lib.mask.array.cons]</a>
7601 </li>
7602 <li> change paragraph 1 of 26.5.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.mask.array.cons"> [lib.mask.array.cons]</a> to read "This constructor is declared
7603     to be private.  This constructor need not be defined."</li>
7604 <li> remove the first sentence of paragraph 1 of 26.5.8.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.mask.array.assign"> [lib.mask.array.assign]</a>
7605 </li>
7606 <li> Change the first three words of the second sentence of paragraph 1 of
7607     26.5.8.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.mask.array.assign"> [lib.mask.array.assign]</a> to "These assignment operators have"</li>
7608 </ul>
7609
7610 <p>indirect_array:</p>
7611 <ul>
7612 <li>Make the copy constructor and copy-assignment operator declarations
7613     public in the indirect_array class definition in 26.5.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a>
7614 </li>
7615 <li> remove the note in paragraph 2 of 26.5.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.template.indirect.array"> [lib.template.indirect.array]</a>
7616 </li>
7617 <li> remove the copy constructor declaration from 26.5.9.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.indirect.array.cons"> [lib.indirect.array.cons]</a>
7618 </li>
7619 <li> change the descriptive text in 26.5.9.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.indirect.array.cons"> [lib.indirect.array.cons]</a> to read "This constructor is
7620     declared to be private.  This constructor need not be defined."</li>
7621 <li> remove the first sentence of paragraph 1 of 26.5.9.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.indirect.array.assign"> [lib.indirect.array.assign]</a>
7622 </li>
7623 <li> Change the first three words of the second sentence of paragraph 1 of
7624     26.5.9.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.indirect.array.assign"> [lib.indirect.array.assign]</a> to "These assignment operators have"</li>
7625 </ul>
7626 <p><i>[Proposed resolution was modified in Santa Cruz: explicitly make
7627 copy constructor and copy assignment operators public, instead of
7628 removing them.]</i></p>
7629 <p><b>Rationale:</b></p>
7630 <p>Keeping the valarray constructors private is untenable.  Merely
7631 making valarray a friend of the helper classes isn't good enough,
7632 because access to the copy constructor is checked in the user's
7633 environment.</p>
7634
7635 <p>Making the assignment operator public is not strictly necessary to
7636 solve this problem.  A majority of the LWG <i>(straw poll: 13-4)</i>
7637 believed we should make the assignment operators public, in addition
7638 to the copy constructors, for reasons of symmetry and user
7639 expectation.</p>
7640 <hr>
7641 <a name="256"><h3>256.&nbsp;typo in 27.4.4.2, p17: copy_event does not exist</h3></a><p><b>Section:</b>&nbsp;27.4.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.basic.ios.members"> [lib.basic.ios.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;21 Aug 2000</p>
7642 <p>
7643 27.4.4.2, p17 says
7644 </p>
7645
7646 <blockquote>
7647 -17- Before copying any parts of rhs, calls each registered callback
7648 pair (fn,index) as (*fn)(erase_event,*this,index). After all parts but
7649 exceptions() have been replaced, calls each callback pair that was
7650 copied from rhs as (*fn)(copy_event,*this,index).
7651 </blockquote>
7652
7653 <p>
7654 The name copy_event isn't defined anywhere. The intended name was
7655 copyfmt_event.
7656 </p>
7657 <p><b>Proposed resolution:</b></p>
7658 <p>Replace copy_event with copyfmt_event in the named paragraph.</p>
7659 <hr>
7660 <a name="259"><h3>259.&nbsp;<tt>basic_string::operator[]</tt> and const correctness</h3></a><p><b>Section:</b>&nbsp;21.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.access"> [lib.string.access]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Chris Newton &nbsp; <b>Date:</b>&nbsp;27 Aug 2000</p>
7661 <p>
7662 <i>Paraphrased from a message that Chris Newton posted to comp.std.c++:</i>
7663 </p>
7664
7665 <p>
7666 The standard's description of <tt>basic_string&lt;&gt;::operator[]</tt>
7667 seems to violate const correctness.
7668 </p>
7669
7670 <p>
7671 The standard (21.3.4/1) says that "If <tt>pos &lt; size()</tt>,
7672 returns <tt>data()[pos]</tt>." The types don't work.  The
7673 return value of <tt>data()</tt> is <tt>const charT*</tt>, but
7674 <tt>operator[]</tt> has a non-const version whose return type is <tt>reference</tt>.
7675 </p>
7676 <p><b>Proposed resolution:</b></p>
7677 <p>
7678 In section 21.3.4, paragraph 1, change
7679 "<tt>data()[<i>pos</i>]</tt>" to "<tt>*(begin() +
7680 <i>pos</i>)</tt>".
7681 </p>
7682 <hr>
7683 <a name="260"><h3>260.&nbsp;Inconsistent return type of <tt>istream_iterator::operator++(int)</tt>
7684 </h3></a><p><b>Section:</b>&nbsp;24.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istream.iterator.ops"> [lib.istream.iterator.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;27 Aug 2000</p>
7685 <p>The synopsis of istream_iterator::operator++(int) in 24.5.1 shows
7686 it as returning the iterator by value. 24.5.1.2, p5 shows the same
7687 operator as returning the iterator by reference. That's incorrect
7688 given the Effects clause below (since a temporary is returned). The
7689 `&amp;' is probably just a typo.</p>
7690 <p><b>Proposed resolution:</b></p>
7691 <p>Change the declaration in 24.5.1.2, p5 from</p>
7692  <pre> istream_iterator&lt;T,charT,traits,Distance&gt;&amp; operator++(int);
7693  </pre>
7694 <p>to</p>
7695  <pre> istream_iterator&lt;T,charT,traits,Distance&gt; operator++(int);
7696  </pre>
7697 <p>(that is, remove the `&amp;').</p>
7698 <hr>
7699 <a name="261"><h3>261.&nbsp;Missing description of <tt>istream_iterator::operator!=</tt>
7700 </h3></a><p><b>Section:</b>&nbsp;24.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istream.iterator.ops"> [lib.istream.iterator.ops]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;27 Aug 2000</p>
7701 <p>
7702 24.5.1, p3 lists the synopsis for
7703 </p>
7704
7705 <pre>   template &lt;class T, class charT, class traits, class Distance&gt;
7706         bool operator!=(const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; x,
7707                         const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; y);
7708 </pre>
7709
7710 <p>
7711 but there is no description of what the operator does (i.e., no Effects
7712 or Returns clause) in 24.5.1.2.
7713 </p>
7714 <p><b>Proposed resolution:</b></p>
7715 <p>
7716 Add paragraph 7 to the end of section 24.5.1.2 with the following text:
7717 </p>
7718
7719 <pre>   template &lt;class T, class charT, class traits, class Distance&gt;
7720         bool operator!=(const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; x,
7721                         const istream_iterator&lt;T,charT,traits,Distance&gt;&amp; y);
7722 </pre>
7723
7724 <p>-7- Returns: !(x == y).</p>
7725 <hr>
7726 <a name="262"><h3>262.&nbsp;Bitmask operator ~ specified incorrectly</h3></a><p><b>Section:</b>&nbsp;17.3.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;03 Sep 2000</p>
7727 <p>
7728 The ~ operation should be applied after the cast to int_type.
7729 </p>
7730 <p><b>Proposed resolution:</b></p>
7731 <p>
7732 Change 17.3.2.1.2 [lib.bitmask.types] operator~ from:
7733 </p>
7734
7735 <pre>   bitmask operator~ ( bitmask X )
7736      { return static_cast&lt; bitmask&gt;(static_cast&lt;int_type&gt;(~ X)); }
7737 </pre>
7738
7739 <p>
7740 to:
7741 </p>
7742
7743 <pre>   bitmask operator~ ( bitmask X )
7744      { return static_cast&lt; bitmask&gt;(~static_cast&lt;int_type&gt;(X)); }
7745 </pre>
7746 <hr>
7747 <a name="263"><h3>263.&nbsp;Severe restriction on <tt>basic_string</tt> reference counting</h3></a><p><b>Section:</b>&nbsp;21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Kevlin Henney&nbsp; <b>Date:</b>&nbsp;04 Sep 2000</p>
7748 <p>
7749 The note in paragraph 6 suggests that the invalidation rules for
7750 references, pointers, and iterators in paragraph 5 permit a reference-
7751 counted implementation (actually, according to paragraph 6, they permit
7752 a "reference counted implementation", but this is a minor editorial fix).
7753 </p>
7754
7755 <p>
7756 However, the last sub-bullet is so worded as to make a reference-counted
7757 implementation unviable. In the following example none of the
7758 conditions for iterator invalidation are satisfied:
7759 </p>
7760
7761 <pre>    // first example: "*******************" should be printed twice
7762     string original = "some arbitrary text", copy = original;
7763     const string &amp; alias = original;
7764
7765     string::const_iterator i = alias.begin(), e = alias.end();
7766     for(string::iterator j = original.begin(); j != original.end(); ++j)
7767         *j = '*';
7768     while(i != e)
7769         cout &lt;&lt; *i++;
7770     cout &lt;&lt; endl;
7771     cout &lt;&lt; original &lt;&lt; endl;
7772 </pre>
7773
7774 <p>
7775 Similarly, in the following example:
7776 </p>
7777
7778 <pre>    // second example: "some arbitrary text" should be printed out
7779     string original = "some arbitrary text", copy = original;
7780     const string &amp; alias = original;
7781
7782     string::const_iterator i = alias.begin();
7783     original.begin();
7784     while(i != alias.end())
7785         cout &lt;&lt; *i++;
7786 </pre>
7787
7788 <p>
7789 I have tested this on three string implementations, two of which were
7790 reference counted. The reference-counted implementations gave
7791 "surprising behavior" because they invalidated iterators on
7792 the first call to non-const begin since construction. The current
7793 wording does not permit such invalidation because it does not take
7794 into account the first call since construction, only the first call
7795 since various member and non-member function calls.
7796 </p>
7797 <p><b>Proposed resolution:</b></p>
7798 <p>
7799 Change the following sentence in 21.3 paragraph 5 from
7800 </p>
7801
7802 <blockquote>
7803     Subsequent to any of the above uses except the forms of insert() and
7804     erase() which return iterators, the first call to non-const member
7805     functions operator[](), at(), begin(), rbegin(), end(), or rend().
7806 </blockquote>
7807
7808 <p>to</p>
7809
7810 <blockquote>
7811     Following construction or any of the above uses, except the forms of
7812     insert() and erase() that return iterators, the first call to non-
7813     const member functions operator[](), at(), begin(), rbegin(), end(),
7814     or rend().
7815 </blockquote>
7816 <hr>
7817 <a name="264"></a><h3><a name="264">264.&nbsp;Associative container <tt>insert(i, j)</tt> complexity requirements are not feasible.</a></h3><p><b>Section:</b>&nbsp;23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;John Potter&nbsp; <b>Date:</b>&nbsp;07 Sep 2000</p>
7818 <p>
7819 Table 69 requires linear time if [i, j) is sorted.  Sorted is necessary but not sufficient.
7820 Consider inserting a sorted range of even integers into a set&lt;int&gt; containing the odd
7821 integers in the same range.
7822 </p>
7823
7824 <p><i>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#102">102</a></i></p>
7825 <p><b>Proposed resolution:</b></p>
7826 <p>
7827 In Table 69, in section 23.1.2, change the complexity clause for
7828 insertion of a range from "N log(size() + N) (N is the distance
7829 from i to j) in general; linear if [i, j) is sorted according to
7830 value_comp()" to "N log(size() + N), where N is the distance
7831 from i to j".
7832 </p>
7833
7834 <p><i>[Copenhagen: Minor fix in proposed resolution: fixed unbalanced
7835 parens in the revised wording.]</i></p>
7836
7837 <p><b>Rationale:</b></p>
7838 <p>
7839 Testing for valid insertions could be less efficient than simply
7840 inserting the elements when the range is not both sorted and between
7841 two adjacent existing elements; this could be a QOI issue.
7842 </p>
7843
7844 <p>
7845 The LWG considered two other options: (a) specifying that the
7846 complexity was linear if [i, j) is sorted according to value_comp()
7847 and between two adjacent existing elements; or (b) changing to
7848 Klog(size() + N) + (N - K) (N is the distance from i to j and K is the
7849 number of elements which do not insert immediately after the previous
7850 element from [i, j) including the first).  The LWG felt that, since
7851 we can't guarantee linear time complexity whenever the range to be
7852 inserted is sorted, it's more trouble than it's worth to say that it's
7853 linear in some special cases.
7854 </p>
7855 <hr>
7856 <a name="265"><h3>265.&nbsp;std::pair::pair() effects overly restrictive</h3></a><p><b>Section:</b>&nbsp;20.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.pairs"> [lib.pairs]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;11 Sep 2000</p>
7857 <p>
7858 I don't see any requirements on the types of the elements of the
7859 std::pair container in 20.2.2. From the descriptions of the member
7860 functions it appears that they must at least satisfy the requirements of
7861 20.1.3 [lib.copyconstructible] and 20.1.4 [lib.default.con.req], and in
7862 the case of the [in]equality operators also the requirements of 20.1.1
7863 [lib.equalitycomparable] and 20.1.2 [lib.lessthancomparable].
7864 </p>
7865
7866 <p>
7867 I believe that the the CopyConstructible requirement is unnecessary in
7868 the case of 20.2.2, p2.
7869 </p>
7870 <p><b>Proposed resolution:</b></p>
7871 <p>Change the Effects clause in 20.2.2, p2 from</p>
7872
7873 <blockquote>
7874 -2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
7875 first(T1()), second(T2()) {} </tt>
7876 </blockquote>
7877
7878 <p>to</p>
7879
7880 <blockquote>
7881 -2- <b>Effects</b>: Initializes its members as if implemented: <tt> pair() :
7882 first(), second() {} </tt>
7883 </blockquote>
7884 <p><b>Rationale:</b></p>
7885 <p>The existing specification of pair's constructor appears to be a
7886 historical artifact: there was concern that pair's members be properly
7887 zero-initialized when they are built-in types.  At one time there was
7888 uncertainty about whether they would be zero-initialized if the
7889 default constructor was written the obvious way.  This has been
7890 clarified by core issue 178, and there is no longer any doubt that
7891 the straightforward implementation is correct.</p>
7892 <hr>
7893 <a name="266"><h3>266.&nbsp;bad_exception::~bad_exception() missing Effects clause</h3></a><p><b>Section:</b>&nbsp;18.7.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.bad.exception"> [lib.bad.exception]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;24 Sep 2000</p>
7894 <p>
7895 The synopsis for std::bad_exception lists the function ~bad_exception()
7896 but there is no description of what the function does (the Effects
7897 clause is missing).
7898 </p>
7899 <p><b>Proposed resolution:</b></p>
7900 <p>
7901 Remove the destructor from the class synopses of
7902 <tt>bad_alloc</tt> (<font color="red">18.4.2.1</font>),
7903 <tt>bad_cast</tt> (18.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.alloc.errors"> [lib.alloc.errors]</a>),
7904 <tt>bad_typeid</tt> (<font color="red">18.5.3</font>),
7905 and <tt>bad_exception</tt> (18.7.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.bad.exception"> [lib.bad.exception]</a>).
7906 </p>
7907 <p><b>Rationale:</b></p>
7908 <p>
7909 This is a general problem with the exception classes in clause 18.
7910 The proposed resolution is to remove the destructors from the class
7911 synopses, rather than to document the destructors' behavior, because
7912 removing them is more consistent with how exception classes are
7913 described in clause 19.
7914 </p>
7915 <hr>
7916 <a name="268"><h3>268.&nbsp;Typo in locale synopsis</h3></a><p><b>Section:</b>&nbsp;22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;5 Oct 2000</p>
7917 <p>The synopsis of the class std::locale in 22.1.1 contains two typos:
7918 the semicolons after the declarations of the default ctor
7919 locale::locale() and the copy ctor locale::locale(const locale&amp;)
7920 are missing.</p>
7921 <p><b>Proposed resolution:</b></p>
7922 <p>Add the missing semicolons, i.e., change</p>
7923
7924 <pre>    //  construct/copy/destroy:
7925         locale() throw()
7926         locale(const locale&amp; other) throw()
7927 </pre>
7928
7929 <p>in the synopsis in 22.1.1 to</p>
7930
7931 <pre>    //  construct/copy/destroy:
7932         locale() throw();
7933         locale(const locale&amp; other) throw();
7934 </pre>
7935 <hr>
7936 <a name="270"><h3>270.&nbsp;Binary search requirements overly strict</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;18 Oct 2000</p>
7937 <p>
7938 Each of the four binary search algorithms (lower_bound, upper_bound,
7939 equal_range, binary_search) has a form that allows the user to pass a
7940 comparison function object.  According to 25.3, paragraph 2, that
7941 comparison function object has to be a strict weak ordering.
7942 </p>
7943
7944 <p>
7945 This requirement is slightly too strict.  Suppose we are searching
7946 through a sequence containing objects of type X, where X is some
7947 large record with an integer key.  We might reasonably want to look
7948 up a record by key, in which case we would want to write something
7949 like this:
7950 </p>
7951 <pre>    struct key_comp {
7952       bool operator()(const X&amp; x, int n) const {
7953         return x.key() &lt; n;
7954       }
7955     }
7956
7957     std::lower_bound(first, last, 47, key_comp());
7958 </pre>
7959
7960 <p>
7961 key_comp is not a strict weak ordering, but there is no reason to
7962 prohibit its use in lower_bound.
7963 </p>
7964
7965 <p>
7966 There's no difficulty in implementing lower_bound so that it allows
7967 the use of something like key_comp.  (It will probably work unless an
7968 implementor takes special pains to forbid it.)  What's difficult is
7969 formulating language in the standard to specify what kind of
7970 comparison function is acceptable.  We need a notion that's slightly
7971 more general than that of a strict weak ordering, one that can encompass
7972 a comparison function that involves different types.  Expressing that
7973 notion may be complicated.
7974 </p>
7975
7976 <p><i>Additional questions raised at the Toronto meeting:</i></p>
7977 <ul>
7978 <li> Do we really want to specify what ordering the implementor must
7979      use when calling the function object?  The standard gives
7980      specific expressions when describing these algorithms, but it also
7981      says that other expressions (with different argument order) are
7982      equivalent.</li>
7983 <li> If we are specifying ordering, note that the standard uses both
7984      orderings when describing <tt>equal_range</tt>.</li>
7985 <li> Are we talking about requiring these algorithms to work properly
7986      when passed a binary function object whose two argument types
7987      are not the same, or are we talking about requirements when
7988      they are passed a binary function object with several overloaded
7989      versions of <tt>operator()</tt>?</li>
7990 <li> The definition of a strict weak ordering does not appear to give
7991      any guidance on issues of overloading; it only discusses expressions,
7992      and all of the values in these expressions are of the same type.
7993      Some clarification would seem to be in order.</li>
7994 </ul>
7995
7996 <p><i>Additional discussion from Copenhagen:</i></p>
7997 <ul>
7998 <li>It was generally agreed that there is a real defect here: if
7999 the predicate is merely required to be a Strict Weak Ordering, then
8000 it's possible to pass in a function object with an overloaded
8001 operator(), where the version that's actually called does something
8002 completely inappropriate.  (Such as returning a random value.)</li>
8003
8004 <li>An alternative formulation was presented in a paper distributed by
8005 David Abrahams at the meeting, "Binary Search with Heterogeneous
8006 Comparison", J16-01/0027 = WG21 N1313: Instead of viewing the
8007 predicate as a Strict Weak Ordering acting on a sorted sequence, view
8008 the predicate/value pair as something that partitions a sequence.
8009 This is almost equivalent to saying that we should view binary search
8010 as if we are given a unary predicate and a sequence, such that f(*p)
8011 is true for all p below a specific point and false for all p above it.
8012 The proposed resolution is based on that alternative formulation.</li>
8013 </ul>
8014 <p><b>Proposed resolution:</b></p>
8015
8016 <p>Change 25.3 [lib.alg.sorting] paragraph 3 from:</p>
8017
8018 <blockquote>
8019   3 For all algorithms that take Compare, there is a version that uses
8020   operator&lt; instead. That is, comp(*i, *j) != false defaults to *i &lt;
8021   *j != false. For the algorithms to work correctly, comp has to
8022   induce a strict weak ordering on the values.
8023 </blockquote>
8024
8025 <p>to:</p>
8026
8027 <blockquote>
8028   3 For all algorithms that take Compare, there is a version that uses
8029   operator&lt; instead. That is, comp(*i, *j) != false defaults to *i
8030   &lt; *j != false. For algorithms other than those described in
8031   lib.alg.binary.search (25.3.3) to work correctly, comp has to induce
8032   a strict weak ordering on the values.
8033 </blockquote>
8034
8035 <p>Add the following paragraph after 25.3 [lib.alg.sorting] paragraph 5:</p>
8036
8037 <blockquote>
8038   -6- A sequence [start, finish) is partitioned with respect to an
8039   expression f(e) if there exists an integer n such that
8040   for all 0 &lt;= i &lt; distance(start, finish), f(*(begin+i)) is true if
8041   and only if i &lt; n.
8042 </blockquote>
8043
8044 <p>Change 25.3.3 [lib.alg.binary.search] paragraph 1 from:</p>
8045
8046 <blockquote>
8047   -1- All of the algorithms in this section are versions of binary
8048    search and assume that the sequence being searched is in order
8049    according to the implied or explicit comparison function. They work
8050    on non-random access iterators minimizing the number of
8051    comparisons, which will be logarithmic for all types of
8052    iterators. They are especially appropriate for random access
8053    iterators, because these algorithms do a logarithmic number of
8054    steps through the data structure. For non-random access iterators
8055    they execute a linear number of steps.
8056 </blockquote>
8057
8058 <p>to:</p>
8059
8060 <blockquote>
8061    -1- All of the algorithms in this section are versions of binary
8062     search and assume that the sequence being searched is partitioned
8063     with respect to an expression formed by binding the search key to
8064     an argument of the implied or explicit comparison function. They
8065     work on non-random access iterators minimizing the number of
8066     comparisons, which will be logarithmic for all types of
8067     iterators. They are especially appropriate for random access
8068     iterators, because these algorithms do a logarithmic number of
8069     steps through the data structure. For non-random access iterators
8070     they execute a linear number of steps.
8071 </blockquote>
8072
8073 <p>Change 25.3.3.1 [lib.lower.bound] paragraph 1 from:</p>
8074
8075 <blockquote>
8076    -1- Requires: Type T is LessThanComparable
8077     (lib.lessthancomparable).
8078 </blockquote>
8079
8080 <p>to:</p>
8081
8082 <blockquote>
8083    -1- Requires: The elements e of [first, last) are partitioned with
8084    respect to the expression e &lt; value or comp(e, value)
8085 </blockquote>
8086
8087
8088 <p>Remove 25.3.3.1 [lib.lower.bound] paragraph 2:</p>
8089
8090 <blockquote>
8091    -2- Effects: Finds the first position into which value can be
8092     inserted without violating the ordering.
8093 </blockquote>
8094
8095 <p>Change 25.3.3.2 [lib.upper.bound] paragraph 1 from:</p>
8096
8097 <blockquote>
8098   -1- Requires: Type T is LessThanComparable (lib.lessthancomparable).
8099 </blockquote>
8100
8101 <p>to:</p>
8102
8103 <blockquote>
8104    -1- Requires: The elements e of [first, last) are partitioned with
8105    respect to the expression !(value &lt; e) or !comp(value, e)
8106 </blockquote>
8107
8108 <p>Remove 25.3.3.2 [lib.upper.bound] paragraph 2:</p>
8109
8110 <blockquote>
8111    -2- Effects: Finds the furthermost position into which value can be
8112     inserted without violating the ordering.
8113 </blockquote>
8114
8115 <p>Change 25.3.3.3 [lib.equal.range] paragraph 1 from:</p>
8116
8117 <blockquote>
8118    -1- Requires: Type T is LessThanComparable
8119     (lib.lessthancomparable).
8120 </blockquote>
8121
8122 <p>to:</p>
8123
8124 <blockquote>
8125    -1- Requires: The elements e of [first, last) are partitioned with
8126    respect to the expressions e &lt; value and !(value &lt; e) or
8127    comp(e, value) and !comp(value, e).  Also, for all elements e of
8128    [first, last), e &lt; value implies !(value &lt; e) or comp(e,
8129    value) implies !comp(value, e)
8130 </blockquote>
8131
8132 <p>Change 25.3.3.3 [lib.equal.range] paragraph 2 from:</p>
8133
8134 <blockquote>
8135    -2- Effects: Finds the largest subrange [i, j) such that the value
8136     can be inserted at any iterator k in it without violating the
8137     ordering. k satisfies the corresponding conditions: !(*k &lt; value)
8138     &amp;&amp; !(value &lt; *k) or comp(*k, value) == false &amp;&amp; comp(value, *k) ==
8139     false.
8140 </blockquote>
8141
8142 <p>to:</p>
8143
8144 <pre>   -2- Returns:
8145          make_pair(lower_bound(first, last, value),
8146                    upper_bound(first, last, value))
8147        or
8148          make_pair(lower_bound(first, last, value, comp),
8149                    upper_bound(first, last, value, comp))
8150 </pre>
8151
8152 <p>Change 25.3.3.3 [lib.binary.search] paragraph 1 from:</p>
8153
8154 <blockquote>
8155    -1- Requires: Type T is LessThanComparable
8156     (lib.lessthancomparable).
8157 </blockquote>
8158
8159 <p>to:</p>
8160
8161 <blockquote>
8162    -1- Requires: The elements e of [first, last) are partitioned with
8163    respect to the expressions e &lt; value and !(value &lt; e) or comp(e,
8164    value) and !comp(value, e). Also, for all elements e of [first,
8165    last), e &lt; value implies !(value &lt; e) or comp(e, value) implies
8166    !comp(value, e)
8167 </blockquote>
8168
8169 <p><i>[Copenhagen: Dave Abrahams provided this wording]</i></p>
8170
8171 <p><i>[Redmond: Minor changes in wording.  (Removed "non-negative", and
8172 changed the "other than those described in" wording.) Also, the LWG
8173 decided to accept the "optional" part.]</i></p>
8174
8175 <p><b>Rationale:</b></p>
8176 <p>The proposed resolution reinterprets binary search. Instead of
8177 thinking about searching for a value in a sorted range, we view that
8178 as an important special case of a more general algorithm: searching
8179 for the partition point in a partitioned range.</p>
8180
8181 <p>We also add a guarantee that the old wording did not: we ensure
8182 that the upper bound is no earlier than the lower bound, that
8183 the pair returned by equal_range is a valid range, and that the first
8184 part of that pair is the lower bound.</p>
8185 <hr>
8186 <a name="271"><h3>271.&nbsp;basic_iostream missing typedefs</h3></a><p><b>Section:</b>&nbsp;27.6.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostreamclass"> [lib.iostreamclass]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Nov 2000</p>
8187 <p>
8188 Class template basic_iostream has no typedefs.  The typedefs it
8189 inherits from its base classes can't be used, since (for example)
8190 basic_iostream&lt;T&gt;::traits_type is ambiguous.
8191 </p>
8192 <p><b>Proposed resolution:</b></p>
8193
8194 <p>Add the following to basic_iostream's class synopsis in
8195 27.6.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostreamclass"> [lib.iostreamclass]</a>, immediately after <tt>public</tt>:</p>
8196
8197 <pre>  // types:
8198   typedef charT                     char_type;
8199   typedef typename traits::int_type int_type;
8200   typedef typename traits::pos_type pos_type;
8201   typedef typename traits::off_type off_type;
8202   typedef traits                    traits_type;
8203 </pre>
8204 <hr>
8205 <a name="272"><h3>272.&nbsp;Missing parentheses around subexpression</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Nov 2000</p>
8206 <p>
8207 27.4.4.3, p4 says about the postcondition of the function: If
8208 rdbuf()!=0 then state == rdstate(); otherwise
8209 rdstate()==state|ios_base::badbit.
8210 </p>
8211
8212 <p>
8213 The expression on the right-hand-side of the operator==() needs to be
8214 parenthesized in order for the whole expression to ever evaluate to
8215 anything but non-zero.
8216 </p>
8217 <p><b>Proposed resolution:</b></p>
8218 <p>
8219 Add parentheses like so: rdstate()==(state|ios_base::badbit).
8220 </p>
8221 <hr>
8222 <a name="273"><h3>273.&nbsp;Missing ios_base qualification on members of a dependent class</h3></a><p><b>Section:</b>&nbsp;27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Nov 2000</p>
8223 <p>27.5.2.4.2, p4, and 27.8.1.6, p2, 27.8.1.7, p3, 27.8.1.9, p2,
8224 27.8.1.10, p3 refer to in and/or out w/o ios_base:: qualification.
8225 That's incorrect since the names are members of a dependent base
8226 class (14.6.2 [temp.dep]) and thus not visible.</p>
8227 <p><b>Proposed resolution:</b></p>
8228 <p>Qualify the names with the name of the class of which they are
8229 members, i.e., ios_base.</p>
8230 <hr>
8231 <a name="274"><h3>274.&nbsp;a missing/impossible allocator requirement</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Nov 2000</p>
8232 <p>
8233 I see that table 31 in 20.1.5, p3 allows T in std::allocator&lt;T&gt; to be of
8234 any type. But the synopsis in 20.4.1 calls for allocator&lt;&gt;::address() to
8235 be overloaded on reference and const_reference, which is ill-formed for
8236 all T = const U. In other words, this won't work:
8237 </p>
8238
8239 <p>
8240 template class std::allocator&lt;const int&gt;;
8241 </p>
8242
8243 <p>
8244 The obvious solution is to disallow specializations of allocators on
8245 const types. However, while containers' elements are required to be
8246 assignable (which rules out specializations on const T's), I think that
8247 allocators might perhaps be potentially useful for const values in other
8248 contexts. So if allocators are to allow const types a partial
8249 specialization of std::allocator&lt;const T&gt; would probably have to be
8250 provided.
8251 </p>
8252 <p><b>Proposed resolution:</b></p>
8253 <p>Change the text in row 1, column 2 of table 32 in 20.1.5, p3 from</p>
8254
8255     <blockquote>
8256     any type
8257     </blockquote>
8258
8259 <p>to</p>
8260     <blockquote>
8261     any non-const, non-reference type
8262     </blockquote>
8263
8264 <p><i>[Redmond: previous proposed resolution was "any non-const,
8265 non-volatile, non-reference type".  Got rid of the "non-volatile".]</i></p>
8266
8267 <p><b>Rationale:</b></p>
8268 <p>
8269 Two resolutions were originally proposed: one that partially
8270 specialized std::allocator for const types, and one that said an
8271 allocator's value type may not be const.  The LWG chose the second.
8272 The first wouldn't be appropriate, because allocators are intended for
8273 use by containers, and const value types don't work in containers.
8274 Encouraging the use of allocators with const value types would only
8275 lead to unsafe code.
8276 </p>
8277 <p>
8278 The original text for proposed resolution 2 was modified so that it
8279 also forbids volatile types and reference types.
8280 </p>
8281
8282 <p><i>[Curaçao: LWG double checked and believes volatile is correctly
8283 excluded from the PR.]</i></p>
8284
8285 <hr>
8286 <a name="275"><h3>275.&nbsp;Wrong type in num_get::get() overloads</h3></a><p><b>Section:</b>&nbsp;22.2.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;02 Nov 2000</p>
8287 <p>
8288 In 22.2.2.1.1, we have a list of overloads for num_get&lt;&gt;::get().
8289 There are eight overloads, all of which are identical except for the
8290 last parameter.  The overloads are:
8291 </p>
8292 <ul>
8293 <li> long&amp; </li>
8294 <li> unsigned short&amp; </li>
8295 <li> unsigned int&amp; </li>
8296 <li> unsigned long&amp; </li>
8297 <li> short&amp; </li>
8298 <li> double&amp; </li>
8299 <li> long double&amp; </li>
8300 <li> void*&amp; </li>
8301 </ul>
8302
8303 <p>
8304 There is a similar list, in 22.2.2.1.2, of overloads for
8305 num_get&lt;&gt;::do_get().  In this list, the last parameter has
8306 the types:
8307 </p>
8308 <ul>
8309 <li> long&amp; </li>
8310 <li> unsigned short&amp; </li>
8311 <li> unsigned int&amp; </li>
8312 <li> unsigned long&amp; </li>
8313 <li> float&amp; </li>
8314 <li> double&amp; </li>
8315 <li> long double&amp; </li>
8316 <li> void*&amp; </li>
8317 </ul>
8318
8319 <p>
8320 These two lists are not identical.  They should be, since
8321 <tt>get</tt> is supposed to call <tt>do_get</tt> with exactly
8322 the arguments it was given.
8323 </p>
8324 <p><b>Proposed resolution:</b></p>
8325 <p>In 22.2.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.members"> [lib.facet.num.get.members]</a>, change</p>
8326 <pre>  iter_type get(iter_type in, iter_type end, ios_base&amp; str,
8327                 ios_base::iostate&amp; err, short&amp; val) const;
8328 </pre>
8329 <p>to</p>
8330 <pre>  iter_type get(iter_type in, iter_type end, ios_base&amp; str,
8331                 ios_base::iostate&amp; err, float&amp; val) const;
8332 </pre>
8333 <hr>
8334 <a name="276"></a><h3><a name="276">276.&nbsp;Assignable requirement for container value type overly strict</a></h3><p><b>Section:</b>&nbsp;23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Peter Dimov&nbsp; <b>Date:</b>&nbsp;07 Nov 2000</p>
8335 <p>
8336 23.1/3 states that the objects stored in a container must be
8337 Assignable.  23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a>, paragraph 2,
8338 states that map satisfies all requirements for a container, while in
8339 the same time defining value_type as pair&lt;const Key, T&gt; - a type
8340 that is not Assignable.
8341 </p>
8342
8343 <p>
8344 It should be noted that there exists a valid and non-contradictory
8345 interpretation of the current text. The wording in 23.1/3 avoids
8346 mentioning value_type, referring instead to "objects stored in a
8347 container." One might argue that map does not store objects of
8348 type map::value_type, but of map::mapped_type instead, and that the
8349 Assignable requirement applies to map::mapped_type, not
8350 map::value_type.
8351 </p>
8352
8353 <p>
8354 However, this makes map a special case (other containers store objects of
8355 type value_type) and the Assignable requirement is needlessly restrictive in
8356 general.
8357 </p>
8358
8359 <p>
8360 For example, the proposed resolution of active library issue
8361 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103">103</a> is to make set::iterator a constant iterator; this
8362 means that no set operations can exploit the fact that the stored
8363 objects are Assignable.
8364 </p>
8365
8366 <p>
8367 This is related to, but slightly broader than, closed issue
8368 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#140">140</a>.
8369 </p>
8370 <p><b>Proposed resolution:</b></p>
8371 <p>23.1/3: Strike the trailing part of the sentence:</p>
8372     <blockquote>
8373     , and the additional requirements of Assignable types from 23.1/3
8374     </blockquote>
8375 <p>so that it reads:</p>
8376     <blockquote>
8377     -3- The type of objects stored in these components must meet the
8378     requirements of CopyConstructible types (lib.copyconstructible).
8379     </blockquote>
8380
8381 <p>23.1/4: Modify to make clear that this requirement is not for all
8382 containers.  Change to:</p>
8383
8384 <blockquote>
8385 -4- Table 64 defines the Assignable requirement.  Some containers
8386 require this property of the types to be stored in the container.  T is
8387 the type used to instantiate the container. t is a value of T, and u is
8388 a value of (possibly const) T.
8389 </blockquote>
8390
8391 <p>23.1, Table 65: in the first row, change "T is Assignable" to "T is
8392 CopyConstructible".</p>
8393
8394 <p>23.2.1/2: Add sentence for Assignable requirement.  Change to:</p>
8395
8396 <blockquote>
8397 -2- A deque satisfies all of the requirements of a container and of a
8398 reversible container (given in tables in lib.container.requirements) and
8399 of a sequence, including the optional sequence requirements
8400 (lib.sequence.reqmts).  In addition to the requirements on the stored
8401 object described in 23.1[lib.container.requirements], the stored object
8402 must also meet the requirements of Assignable.  Descriptions are
8403 provided here only for operations on deque that are not described in one
8404 of these tables or for operations where there is additional semantic
8405 information.
8406 </blockquote>
8407
8408 <p>23.2.2/2:  Add Assignable requirement to specific methods of list.
8409 Change to:</p>
8410
8411 <blockquote>
8412 <p>-2- A list satisfies all of the requirements of a container and of a
8413 reversible container (given in two tables in lib.container.requirements)
8414 and of a sequence, including most of the the optional sequence
8415 requirements (lib.sequence.reqmts). The exceptions are the operator[]
8416 and at member functions, which are not provided.
8417
8418 [Footnote: These member functions are only provided by containers whose
8419 iterators are random access iterators. --- end foonote]
8420 </p>
8421
8422 <p>list does not require the stored type T to be Assignable unless the
8423 following methods are instantiated:
8424
8425 [Footnote: Implementors are permitted but not required to take advantage
8426 of T's Assignable properties for these methods. -- end foonote]
8427 </p>
8428 <pre>     list&lt;T,Allocator&gt;&amp; operator=(const list&lt;T,Allocator&gt;&amp;  x );
8429      template &lt;class InputIterator&gt;
8430        void assign(InputIterator first, InputIterator last);
8431      void assign(size_type n, const T&amp; t);
8432 </pre>
8433
8434
8435 <p>Descriptions are provided here only for operations on list that are not
8436 described in one of these tables or for operations where there is
8437 additional semantic information.</p>
8438 </blockquote>
8439
8440 <p>23.2.4/2:   Add sentence for Assignable requirement.  Change to:</p>
8441
8442 <blockquote>
8443 -2- A vector satisfies all of the requirements of a container and of a
8444 reversible container (given in two tables in lib.container.requirements)
8445 and of a sequence, including most of the optional sequence requirements
8446 (lib.sequence.reqmts). The exceptions are the push_front and pop_front
8447 member functions, which are not provided.  In addition to the
8448 requirements on the stored object described in
8449 23.1[lib.container.requirements], the stored object must also meet the
8450 requirements of Assignable.  Descriptions are provided here only for
8451 operations on vector that are not described in one of these tables or
8452 for operations where there is additional semantic information.
8453 </blockquote>
8454 <p><b>Rationale:</b></p>
8455 <p>list, set, multiset, map, multimap are able to store non-Assignables.
8456 However, there is some concern about <tt>list&lt;T&gt;</tt>:
8457 although in general there's no reason for T to be Assignable, some
8458 implementations of the member functions <tt>operator=</tt> and
8459 <tt>assign</tt> do rely on that requirement.  The LWG does not want
8460 to forbid such implementations.</p>
8461
8462 <p>Note that the type stored in a standard container must still satisfy
8463 the requirements of the container's allocator; this rules out, for
8464 example, such types as "const int".  See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#274">274</a>
8465 for more details.
8466 </p>
8467
8468 <p>In principle we could also relax the "Assignable" requirement for
8469 individual <tt>vector</tt> member functions, such as
8470 <tt>push_back</tt>.  However, the LWG did not see great value in such
8471 selective relaxation.  Doing so would remove implementors' freedom to
8472 implement <tt>vector::push_back</tt> in terms of
8473 <tt>vector::insert</tt>.</p>
8474
8475 <hr>
8476 <a name="278"><h3>278.&nbsp;What does iterator validity mean?</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;P.J. Plauger&nbsp; <b>Date:</b>&nbsp;27 Nov 2000</p>
8477 <p>
8478 Section 23.2.2.4 [lib.list.ops] states that
8479 </p>
8480 <pre>  void splice(iterator position, list&lt;T, Allocator&gt;&amp; x);
8481 </pre>
8482 <p>
8483 <i>invalidates</i> all iterators and references to list <tt>x</tt>.
8484 </p>
8485
8486 <p>
8487 But what does the C++ Standard mean by "invalidate"?  You
8488 can still dereference the iterator to a spliced list element, but
8489 you'd better not use it to delimit a range within the original
8490 list. For the latter operation, it has definitely lost some of its
8491 validity.
8492 </p>
8493
8494 <p>
8495 If we accept the proposed resolution to issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250">250</a>,
8496 then we'd better clarify that a "valid" iterator need no
8497 longer designate an element within the same container as it once did.
8498 We then have to clarify what we mean by invalidating a past-the-end
8499 iterator, as when a vector or string grows by reallocation. Clearly,
8500 such an iterator has a different kind of validity. Perhaps we should
8501 introduce separate terms for the two kinds of "validity."
8502 </p>
8503 <p><b>Proposed resolution:</b></p>
8504 <p>Add the following text to the end of section 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>,
8505 after paragraph 5:</p>
8506 <blockquote>
8507 An <i>invalid</i> iterator is an iterator that may be
8508 singular. [Footnote: This definition applies to pointers, since
8509 pointers are iterators. The effect of dereferencing an iterator that
8510 has been invalidated is undefined.]
8511 </blockquote>
8512
8513 <p><i>[post-Copenhagen: Matt provided wording.]</i></p>
8514
8515 <p><i>[Redmond: General agreement with the intent, some objections to
8516 the wording.  Dave provided new wording.]</i></p>
8517 <p><b>Rationale:</b></p>
8518 <p>This resolution simply defines a term that the Standard uses but
8519   never defines, "invalid", in terms of a term that is defined,
8520   "singular".</p>
8521
8522 <p>Why do we say "may be singular", instead of "is singular"?  That's
8523   becuase a valid iterator is one that is known to be nonsingular.
8524   Invalidating an iterator means changing it in such a way that it's
8525   no longer known to be nonsingular.  An example: inserting an
8526   element into the middle of a vector is correctly said to invalidate
8527   all iterators pointing into the vector.  That doesn't necessarily
8528   mean they all become singular.</p>
8529 <hr>
8530 <a name="280"><h3>280.&nbsp;Comparison of reverse_iterator to const reverse_iterator</h3></a><p><b>Section:</b>&nbsp;24.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iterators"> [lib.reverse.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Cleary&nbsp; <b>Date:</b>&nbsp;27 Nov 2000</p>
8531 <p>
8532 This came from an email from Steve Cleary to Fergus in reference to
8533 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#179">179</a>. The library working group briefly discussed
8534 this in Toronto and believed it should be a separate issue.  There was
8535 also some reservations about whether this was a worthwhile problem to
8536 fix.
8537 </p>
8538
8539 <p>
8540 Steve said: "Fixing reverse_iterator. std::reverse_iterator can
8541 (and should) be changed to preserve these additional
8542 requirements." He also said in email that it can be done without
8543 breaking user's code: "If you take a look at my suggested
8544 solution, reverse_iterator doesn't have to take two parameters; there
8545 is no danger of breaking existing code, except someone taking the
8546 address of one of the reverse_iterator global operator functions, and
8547 I have to doubt if anyone has ever done that. . .  <i>But</i>, just in
8548 case they have, you can leave the old global functions in as well --
8549 they won't interfere with the two-template-argument functions.  With
8550 that, I don't see how <i>any</i> user code could break."
8551 </p>
8552 <p><b>Proposed resolution:</b></p>
8553 <p>
8554 <b>Section:</b> 24.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iterator"> [lib.reverse.iterator]</a>
8555 add/change the following declarations:</p>
8556 <pre>  A) Add a templated assignment operator, after the same manner
8557         as the templated copy constructor, i.e.:
8558
8559   template &lt; class U &gt;
8560   reverse_iterator &lt; Iterator &gt;&amp; operator=(const reverse_iterator&lt; U &gt;&amp; u);
8561
8562   B) Make all global functions (except the operator+) have
8563   two template parameters instead of one, that is, for
8564   operator ==, !=, &lt;, &gt;, &lt;=, &gt;=, - replace:
8565
8566        template &lt; class Iterator &gt;
8567        typename reverse_iterator&lt; Iterator &gt;::difference_type operator-(
8568                  const reverse_iterator&lt; Iterator &gt;&amp; x,
8569                  const reverse_iterator&lt; Iterator &gt;&amp; y);
8570
8571   with:
8572
8573       template &lt; class Iterator1, class Iterator2 &gt;
8574       typename reverse_iterator &lt; Iterator1 &gt;::difference_type operator-(
8575                  const reverse_iterator &lt; Iterator1 &gt; &amp; x,
8576                  const reverse_iterator &lt; Iterator2 &gt; &amp; y);
8577 </pre>
8578 <p>
8579 Also make the addition/changes for these signatures in
8580 24.4.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.ops"> [lib.reverse.iter.ops]</a>.
8581 </p>
8582
8583 <p><i>[
8584 Copenhagen: The LWG is concerned that the proposed resolution
8585 introduces new overloads.  Experience shows that introducing
8586 overloads is always risky, and that it would be inappropriate to
8587 make this change without implementation experience.  It may be
8588 desirable to provide this feature in a different way.
8589 ]</i></p>
8590
8591 <p><i>[
8592 Lillehammer: We now have implementation experience, and agree that
8593 this solution is safe and correct.
8594 ]</i></p>
8595
8596 <hr>
8597 <a name="281"><h3>281.&nbsp;std::min() and max() requirements overly restrictive</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Dec 2000</p>
8598 <p>The requirements in 25.3.7, p1 and 4 call for T to satisfy the
8599 requirements of <tt>LessThanComparable</tt> (20.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>)
8600 and <tt>CopyConstructible</tt> (20.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.copyconstructible"> [lib.copyconstructible]</a>).
8601 Since the functions take and return their arguments and result by
8602 const reference, I believe the <tt>CopyConstructible</tt> requirement
8603 is unnecessary.
8604 </p>
8605 <p><b>Proposed resolution:</b></p>
8606 <p>Remove the <tt>CopyConstructible</tt> requirement. Specifically, replace
8607 25.3.7, p1 with</p>
8608 <p><b>-1- Requires:</b> Type T is <tt>LessThanComparable</tt>
8609 (20.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>).
8610 </p>
8611 <p>and replace 25.3.7, p4 with</p>
8612 <p><b>-4- Requires:</b> Type T is <tt>LessThanComparable</tt>
8613 (20.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.lessthancomparable"> [lib.lessthancomparable]</a>).
8614 </p>
8615 <hr>
8616 <a name="282"><h3>282.&nbsp;What types does numpunct grouping refer to?</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;5 Dec 2000</p>
8617 <p>
8618 Paragraph 16 mistakenly singles out integral types for inserting
8619 thousands_sep() characters.  This conflicts with the syntax for floating
8620 point numbers described under 22.2.3.1/2.
8621 </p>
8622 <p><b>Proposed resolution:</b></p>
8623 <p>Change paragraph 16 from:</p>
8624
8625 <blockquote>
8626 For integral types, punct.thousands_sep() characters are inserted into
8627 the sequence as determined by the value returned by punct.do_grouping()
8628 using the method described in 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>.
8629 </blockquote>
8630
8631 <p>To:</p>
8632
8633 <blockquote>
8634 For arithmetic types, punct.thousands_sep() characters are inserted into
8635 the sequence as determined by the value returned by punct.do_grouping()
8636 using the method described in 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>.
8637 </blockquote>
8638
8639 <p><i>[
8640 Copenhagen: Opinions were divided about whether this is actually an
8641 inconsistency, but at best it seems to have been unintentional.  This
8642 is only an issue for floating-point output: The standard is
8643 unambiguous that implementations must parse thousands_sep characters
8644 when performing floating-point.  The standard is also unambiguous that
8645 this requirement does not apply to the "C" locale.
8646 ]</i></p>
8647
8648 <p><i>[
8649 A survey of existing practice is needed; it is believed that some
8650 implementations do insert thousands_sep characters for floating-point
8651 output and others fail to insert thousands_sep characters for
8652 floating-point input even though this is unambiguously required by the
8653 standard.
8654 ]</i></p>
8655
8656 <p><i>[Post-Curaçao: the above proposed resolution is the consensus of
8657 Howard, Bill, Pete, Benjamin, Nathan, Dietmar, Boris, and Martin.]</i></p>
8658
8659 <hr>
8660 <a name="283"><h3>283.&nbsp;std::replace() requirement incorrect/insufficient</h3></a><p><b>Section:</b>&nbsp;25.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;15 Dec 2000</p>
8661 <p>
8662 (revision of the further discussion)
8663 There are a number of problems with the requires clauses for the
8664 algorithms in 25.1 and 25.2. The requires clause of each algorithm
8665 should describe the necessary and sufficient requirements on the inputs
8666 to the algorithm such that the algorithm compiles and runs properly.
8667 Many of the requires clauses fail to do this. Here is a summary of the kinds
8668 of mistakes:
8669 </p>
8670
8671 <ol>
8672 <li>
8673 Use of EqualityComparable, which only puts requirements on a single
8674 type, when in fact an equality operator is required between two
8675 different types, typically either T and the iterator's value type
8676 or between the value types of two different iterators.
8677 </li>
8678 <li>
8679 Use of Assignable for T when in fact what was needed is Assignable
8680 for the value_type of the iterator, and convertability from T to the
8681 value_type of the iterator. Or for output iterators, the requirement
8682 should be that T is writable to the iterator (output iterators do
8683 not have value types).
8684 </li>
8685 </ol>
8686
8687 <p>
8688 Here is the list of algorithms that contain mistakes:
8689 </p>
8690
8691 <ul>
8692 <li>25.1.2 std::find</li>
8693 <li>25.1.6 std::count</li>
8694 <li>25.1.8 std::equal</li>
8695 <li>25.1.9 std::search, std::search_n</li>
8696 <li>25.2.4 std::replace, std::replace_copy</li>
8697 <li>25.2.5 std::fill</li>
8698 <li>25.2.7 std::remove, std::remove_copy</li>
8699 </ul>
8700
8701 <p>
8702 Also, in the requirements for EqualityComparable, the requirement that
8703 the operator be defined for const objects is lacking.
8704 </p>
8705
8706 <p><b>Proposed resolution:</b></p>
8707
8708 <p>20.1.1 Change p1 from</p>
8709
8710 <p>In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
8711 instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
8712 values of type <tt>T</tt>.
8713 </p>
8714
8715 <p>to</p>
8716
8717 <p>
8718 In Table 28, <tt>T</tt> is a type to be supplied by a C++ program
8719 instantiating a template, <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> are
8720 values of type <tt>const T</tt>.
8721 </p>
8722
8723 <p>25 Between p8 and p9</p>
8724
8725 <p>Add the following sentence:</p>
8726
8727 <p>When the description of an algorithm gives an expression such as
8728 <tt>*first == value</tt> for a condition, it is required that the expression
8729 evaluate to either true or false in boolean contexts.</p>
8730
8731 <p>25.1.2 Change p1 by deleting the requires clause.</p>
8732
8733 <p>25.1.6 Change p1 by deleting the requires clause.</p>
8734
8735 <p>25.1.9</p>
8736
8737 <p>Change p4 from</p>
8738
8739 <p>-4- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt>
8740 (20.1.1), type Size is convertible to integral type (4.7.12.3).
8741 </p>
8742
8743 <p>to</p>
8744
8745 <p>-4- Requires: The type <tt>Size</tt> is convertible to integral
8746 type (4.7.12.3).</p>
8747
8748 <p>25.2.4 Change p1 from</p>
8749
8750 <p>-1- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1 ) (and, for <tt>replace()</tt>, <tt>EqualityComparable</tt> (20.1.1 )).</p>
8751
8752 <p>to</p>
8753
8754 <p>-1- Requires: The expression <tt>*first = new_value</tt> must be valid.</p>
8755
8756 <p>and change p4 from</p>
8757
8758 <p>-4- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1) (and,
8759 for <tt>replace_copy()</tt>, <tt>EqualityComparable</tt>
8760 (20.1.1)). The ranges <tt>[first, last)</tt> and <tt>[result, result +
8761 (last - first))</tt> shall not overlap.</p>
8762
8763 <p>to</p>
8764
8765 <p>-4- Requires: The results of the expressions <tt>*first</tt> and
8766 <tt>new_value</tt> must be writable to the result output iterator. The
8767 ranges <tt>[first, last)</tt> and <tt>[result, result + (last -
8768 first))</tt> shall not overlap.</p>
8769
8770
8771 <p>25.2.5 Change p1 from</p>
8772
8773 <p>-1- Requires: Type <tt>T</tt> is <tt>Assignable</tt> (23.1). The
8774 type <tt>Size</tt> is convertible to an integral type (4.7.12.3).</p>
8775
8776 <p>to</p>
8777
8778 <p>-1- Requires: The expression <tt>value</tt> must be is writable to
8779 the output iterator. The type <tt>Size</tt> is convertible to an
8780 integral type (4.7.12.3).</p>
8781
8782 <p>25.2.7 Change p1 from</p>
8783
8784 <p>-1- Requires: Type <tt>T</tt> is <tt>EqualityComparable</tt> (20.1.1).</p>
8785
8786 <p>to</p>
8787
8788 <p>
8789 -1- Requires: The value type of the iterator must be
8790 <tt>Assignable</tt> (23.1).
8791 </p>
8792
8793 <p><b>Rationale:</b></p>
8794 <p>
8795 The general idea of the proposed solution is to remove the faulty
8796 requires clauses and let the returns and effects clauses speak for
8797 themselves. That is, the returns clauses contain expressions that must
8798 be valid, and therefore already imply the correct requirements. In
8799 addition, a sentence is added at the beginning of chapter 25 saying
8800 that expressions given as conditions must evaluate to true or false in
8801 a boolean context. An alternative would be to say that the type of
8802 these condition expressions must be literally bool, but that would be
8803 imposing a greater restriction that what the standard currently says
8804 (which is convertible to bool).
8805 </p>
8806 <hr>
8807 <a name="284"><h3>284.&nbsp;unportable example in 20.3.7, p6</h3></a><p><b>Section:</b>&nbsp;20.5.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.comparisons"> [lib.comparisons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;26 Dec 2000</p>
8808 <p>The example in 20.5.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.comparisons"> [lib.comparisons]</a>, p6 shows how to use the C
8809 library function <tt>strcmp()</tt> with the function pointer adapter
8810 <tt>ptr_fun()</tt>. But since it's unspecified whether the C library
8811 functions have <tt>extern "C"</tt> or <tt>extern
8812 "C++"</tt> linkage [17.4.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.using.linkage"> [lib.using.linkage]</a>], and since
8813 function pointers with different the language linkage specifications
8814 (7.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/dcl.html#dcl.link"> [dcl.link]</a>) are incompatible, whether this example is
8815 well-formed is unspecified.
8816 </p>
8817 <p><b>Proposed resolution:</b></p>
8818 <p>Change 20.5.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.comparisons"> [lib.comparisons]</a> paragraph 6 from:</p>
8819 <blockquote>
8820   <p>[<i>Example:</i></p>
8821   <pre>    replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++");
8822   </pre>
8823   <p>replaces each <tt>C</tt> with <tt>C++</tt> in sequence <tt>v</tt>.</p>
8824 </blockquote>
8825
8826
8827 <p>to:</p>
8828 <blockquote>
8829   <p>[<i>Example:</i></p>
8830   <pre>    int compare(const char*, const char*);
8831     replace_if(v.begin(), v.end(),
8832                not1(bind2nd(ptr_fun(compare), "abc")), "def");
8833   </pre>
8834   <p>replaces each <tt>abc</tt> with <tt>def</tt> in sequence <tt>v</tt>.</p>
8835 </blockquote>
8836
8837 <p>Also, remove footnote 215 in that same paragraph.</p>
8838
8839 <p><i>[Copenhagen: Minor change in the proposed resolution.  Since this
8840 issue deals in part with C and C++ linkage, it was believed to be too
8841 confusing for the strings in the example to be "C" and "C++".
8842 ]</i></p>
8843
8844 <p><i>[Redmond: More minor changes.  Got rid of the footnote (which
8845 seems to make a sweeping normative requirement, even though footnotes
8846 aren't normative), and changed the sentence after the footnote so that
8847 it corresponds to the new code fragment.]</i></p>
8848
8849 <hr>
8850 <a name="285"><h3>285.&nbsp;minor editorial errors in fstream ctors</h3></a><p><b>Section:</b>&nbsp;27.8.1.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ifstream.cons"> [lib.ifstream.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;31 Dec 2000</p>
8851 <p>27.8.1.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ifstream.cons"> [lib.ifstream.cons]</a>, p2, 27.8.1.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ofstream.cons"> [lib.ofstream.cons]</a>, p2, and
8852 27.8.1.12 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstream.cons"> [lib.fstream.cons]</a>, p2 say about the effects of each constructor:
8853 </p>
8854
8855 <p>... If that function returns a null pointer, calls
8856 <tt>setstate(failbit)</tt> (which may throw <tt>ios_base::failure</tt>).
8857 </p>
8858
8859 <p>The parenthetical note doesn't apply since the ctors cannot throw an
8860 exception due to the requirement in 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>, p3
8861 that <tt>exceptions()</tt> be initialized to <tt>ios_base::goodbit</tt>.
8862 </p>
8863 <p><b>Proposed resolution:</b></p>
8864 <p>
8865 Strike the parenthetical note from the Effects clause in each of the
8866 paragraphs mentioned above.
8867 </p>
8868 <hr>
8869 <a name="286"><h3>286.&nbsp;&lt;cstdlib&gt; requirements missing size_t typedef</h3></a><p><b>Section:</b>&nbsp;25.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.c.library"> [lib.alg.c.library]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;30 Dec 2000</p>
8870 <p>
8871 The &lt;cstdlib&gt; header file contains prototypes for bsearch and
8872 qsort (C++ Standard section 25.4 paragraphs 3 and 4) and other
8873 prototypes (C++ Standard section 21.4 paragraph 1 table 49) that
8874 require the typedef size_t. Yet size_t is not listed in the
8875 &lt;cstdlib&gt; synopsis table 78 in section 25.4.
8876 </p>
8877 <p><b>Proposed resolution:</b></p>
8878 <p>
8879 Add the type size_t to Table 78 (section 25.4) and add
8880 the type size_t &lt;cstdlib&gt; to Table 97 (section C.2).
8881 </p>
8882 <p><b>Rationale:</b></p>
8883 <p>Since size_t is in &lt;stdlib.h&gt;, it must also be in &lt;cstdlib&gt;.</p>
8884 <hr>
8885 <a name="288"><h3>288.&nbsp;&lt;cerrno&gt; requirements missing macro EILSEQ</h3></a><p><b>Section:</b>&nbsp;19.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-diagnostics.html#lib.errno"> [lib.errno]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Judy Ward&nbsp; <b>Date:</b>&nbsp;30 Dec 2000</p>
8886 <p>
8887 ISO/IEC 9899:1990/Amendment1:1994 Section 4.3 States: "The list
8888 of macros defined in &lt;errno.h&gt; is adjusted to include a new
8889 macro, EILSEQ"
8890 </p>
8891
8892 <p>
8893 ISO/IEC 14882:1998(E) section 19.3 does not refer
8894 to the above amendment.
8895 </p>
8896
8897 <p><b>Proposed resolution:</b></p>
8898 <p>
8899 Update Table 26 (section 19.3) "Header  &lt;cerrno&gt; synopsis"
8900 and Table 95 (section C.2) "Standard Macros" to include EILSEQ.
8901 </p>
8902 <hr>
8903 <a name="291"><h3>291.&nbsp;Underspecification of set algorithms</h3></a><p><b>Section:</b>&nbsp;25.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.set.operations"> [lib.alg.set.operations]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;03 Jan 2001</p>
8904 <p>
8905 The standard library contains four algorithms that compute set
8906 operations on sorted ranges: <tt>set_union</tt>, <tt>set_intersection</tt>,
8907 <tt>set_difference</tt>, and <tt>set_symmetric_difference</tt>.  Each
8908 of these algorithms takes two sorted ranges as inputs, and writes the
8909 output of the appropriate set operation to an output range.  The elements
8910 in the output range are sorted.
8911 </p>
8912
8913 <p>
8914 The ordinary mathematical definitions are generalized so that they
8915 apply to ranges containing multiple copies of a given element.  Two
8916 elements are considered to be "the same" if, according to an
8917 ordering relation provided by the user, neither one is less than the
8918 other.  So, for example, if one input range contains five copies of an
8919 element and another contains three, the output range of <tt>set_union</tt>
8920 will contain five copies, the output range of
8921 <tt>set_intersection</tt> will contain three, the output range of
8922 <tt>set_difference</tt> will contain two, and the output range of
8923 <tt>set_symmetric_difference</tt> will contain two.
8924 </p>
8925
8926 <p>
8927 Because two elements can be "the same" for the purposes
8928 of these set algorithms, without being identical in other respects
8929 (consider, for example, strings under case-insensitive comparison),
8930 this raises a number of unanswered questions:
8931 </p>
8932
8933 <ul>
8934 <li>If we're copying an element that's present in both of the
8935 input ranges, which one do we copy it from?</li>
8936 <li>If there are <i>n</i> copies of an element in the relevant
8937 input range, and the output range will contain fewer copies (say
8938 <i>m</i>) which ones do we choose?  The first <i>m</i>, or the last
8939 <i>m</i>, or something else?</li>
8940 <li>Are these operations stable?  That is, does a run of equivalent
8941 elements appear in the output range in the same order as as it
8942 appeared in the input range(s)?</li>
8943 </ul>
8944
8945 <p>
8946 The standard should either answer these questions, or explicitly
8947 say that the answers are unspecified.  I prefer the former option,
8948 since, as far as I know, all existing implementations behave the
8949 same way.
8950 </p>
8951
8952 <p><b>Proposed resolution:</b></p>
8953
8954 <p>Add the following to the end of 25.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.set.union"> [lib.set.union]</a> paragraph 5:</p>
8955 <blockquote>
8956 If [first1, last1) contains <i>m</i> elements that are equivalent to
8957 each other and [first2, last2) contains <i>n</i> elements that are
8958 equivalent to them, then max(<i>m</i>, <i>n</i>) of these elements
8959 will be copied to the output range: all <i>m</i> of these elements
8960 from [first1, last1), and the last max(<i>n-m</i>, 0) of them from
8961 [first2, last2), in that order.
8962 </blockquote>
8963
8964 <p>Add the following to the end of 25.3.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.set.intersection"> [lib.set.intersection]</a> paragraph 5:</p>
8965 <blockquote>
8966 If [first1, last1) contains <i>m</i> elements that are equivalent to each
8967 other and [first2, last2) contains <i>n</i> elements that are
8968 equivalent to them, the first min(<i>m</i>, <i>n</i>) of those
8969 elements from [first1, last1) are copied to the output range.
8970 </blockquote>
8971
8972 <p>Add a new paragraph, <b>Notes</b>, after 25.3.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.set.difference"> [lib.set.difference]</a>
8973 paragraph 4:</p>
8974 <blockquote>
8975 If [first1, last1) contains <i>m</i> elements that are equivalent to each
8976 other and [first2, last2) contains <i>n</i> elements that are
8977 equivalent to them, the last max(<i>m-n</i>, 0) elements from
8978 [first1, last1) are copied to the output range.
8979 </blockquote>
8980
8981 <p>Add a new paragraph, <b>Notes</b>, after 25.3.5.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.set.symmetric.difference"> [lib.set.symmetric.difference]</a>
8982 paragraph 4:</p>
8983 <blockquote>
8984 If [first1, last1) contains <i>m</i> elements that are equivalent to
8985 each other and [first2, last2) contains <i>n</i> elements that are
8986 equivalent to them, then |<i>m - n</i>| of those elements will be
8987 copied to the output range: the last <i>m - n</i> of these elements
8988 from [first1, last1) if <i>m</i> &gt; <i>n</i>, and the last <i>n -
8989 m</i> of these elements from [first2, last2) if <i>m</i> &lt; <i>n</i>.
8990 </blockquote>
8991
8992 <p><i>[Santa Cruz: it's believed that this language is clearer than
8993   what's in the Standard.  However, it's also believed that the
8994   Standard may already make these guarantees (although not quite in
8995   these words).  Bill and Howard will check and see whether they think
8996   that some or all of these changes may be redundant.  If so, we may
8997   close this issue as NAD.]</i></p>
8998
8999 <p><b>Rationale:</b></p>
9000 <p>For simple cases, these descriptions are equivalent to what's
9001   already in the Standard.  For more complicated cases, they describe
9002   the behavior of existing implementations.</p>
9003 <hr>
9004 <a name="292"><h3>292.&nbsp;effects of a.copyfmt (a)</h3></a><p><b>Section:</b>&nbsp;27.4.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.basic.ios.members"> [lib.basic.ios.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;05 Jan 2001</p>
9005 <p>The Effects clause of the member function <tt>copyfmt()</tt> in
9006 27.4.4.2, p15 doesn't consider the case where the left-hand side
9007 argument is identical to the argument on the right-hand side, that is
9008 <tt>(this == &amp;rhs)</tt>.  If the two arguments are identical there
9009 is no need to copy any of the data members or call any callbacks
9010 registered with <tt>register_callback()</tt>.  Also, as Howard Hinnant
9011 points out in message c++std-lib-8149 it appears to be incorrect to
9012 allow the object to fire <tt>erase_event</tt> followed by
9013 <tt>copyfmt_event</tt> since the callback handling the latter event
9014 may inadvertently attempt to access memory freed by the former.
9015 </p>
9016 <p><b>Proposed resolution:</b></p>
9017 <p>Change the Effects clause in 27.4.4.2, p15 from</p>
9018
9019 <blockquote>
9020 <b>-15- Effects:</b>Assigns to the member objects of <tt>*this</tt>
9021 the corresponding member objects of <tt>rhs</tt>, except that...
9022 </blockquote>
9023
9024 <p>to</p>
9025
9026 <blockquote>
9027 <b>-15- Effects:</b>If <tt>(this == &amp;rhs)</tt> does nothing. Otherwise
9028 assigns to the member objects of <tt>*this</tt> the corresponding member
9029 objects of <tt>rhs</tt>, except that...
9030 </blockquote>
9031 <hr>
9032 <a name="294"><h3>294.&nbsp;User defined macros and standard headers</h3></a><p><b>Section:</b>&nbsp;17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze&nbsp; <b>Date:</b>&nbsp;11 Jan 2001</p>
9033 <p>Paragraph 2 of 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a> reads: "A
9034 translation unit that includes a header shall not contain any macros
9035 that define names declared in that header." As I read this, it
9036 would mean that the following program is legal:</p>
9037
9038 <pre>  #define npos 3.14
9039   #include &lt;sstream&gt;
9040 </pre>
9041
9042 <p>since npos is not defined in &lt;sstream&gt;.  It is, however, defined
9043 in &lt;string&gt;, and it is hard to imagine an implementation in
9044 which &lt;sstream&gt; didn't include &lt;string&gt;.</p>
9045
9046 <p>I think that this phrase was probably formulated before it was
9047 decided that a standard header may freely include other standard
9048 headers.  The phrase would be perfectly appropriate for C, for
9049 example.  In light of 17.4.4.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.headers"> [lib.res.on.headers]</a> paragraph 1, however,
9050 it isn't stringent enough.</p>
9051 <p><b>Proposed resolution:</b></p>
9052 <p>For 17.4.3.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.macro.names"> [lib.macro.names]</a>, replace the current wording, which reads:</p>
9053 <blockquote>
9054      <p>Each name defined as a macro in a header is reserved to the
9055      implementation for any use if the translation unit includes
9056      the header.168)</p>
9057
9058      <p>A translation unit that includes a header shall not contain any
9059      macros that define names declared or defined in that header. Nor shall
9060      such a translation unit define macros for names lexically
9061      identical to keywords.</p>
9062
9063      <p>168) It is not permissible to remove a library macro definition by
9064      using the #undef directive.</p>
9065 </blockquote>
9066
9067 <p>with the wording:</p>
9068
9069 <blockquote>
9070      <p>A translation unit that includes a standard library header shall not
9071      #define or #undef names declared in any standard library header.</p>
9072
9073      <p>A translation unit shall not #define or #undef names lexically
9074      identical to keywords.</p>
9075 </blockquote>
9076
9077 <p><i>[Lillehammer: Beman provided new wording]</i></p>
9078
9079 <hr>
9080 <a name="295"><h3>295.&nbsp;Is abs defined in &lt;cmath&gt;?</h3></a><p><b>Section:</b>&nbsp;26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numarray"> [lib.numarray]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Jens Maurer&nbsp; <b>Date:</b>&nbsp;12 Jan 2001</p>
9081 <p>
9082 Table 80 lists the contents of the &lt;cmath&gt; header.  It does not
9083 list <tt>abs()</tt>.  However, 26.5, paragraph 6, which lists added
9084 signatures present in &lt;cmath&gt;, does say that several overloads
9085 of <tt>abs()</tt> should be defined in &lt;cmath&gt;.
9086 </p>
9087 <p><b>Proposed resolution:</b></p>
9088 <p>
9089 Add <tt>abs</tt> to Table 80.  Also, remove the parenthetical list
9090 of functions "(abs(), div(), rand(), srand())" from 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numarray"> [lib.numarray]</a>,
9091 paragraph 1.
9092 </p>
9093
9094 <p><i>[Copenhagen: Modified proposed resolution so that it also gets
9095 rid of that vestigial list of functions in paragraph 1.]</i></p>
9096
9097 <p><b>Rationale:</b></p>
9098 <p>All this DR does is fix a typo; it's uncontroversial.  A
9099 separate question is whether we're doing the right thing in
9100 putting some overloads in &lt;cmath&gt; that we aren't also
9101 putting in &lt;cstdlib&gt;.  That's issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#323">323</a>.</p>
9102 <hr>
9103 <a name="297"><h3>297.&nbsp;const_mem_fun_t&lt;&gt;::argument_type should be const T*</h3></a><p><b>Section:</b>&nbsp;20.5.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.logical.operations"> [lib.logical.operations]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;6 Jan 2001</p>
9104 <p>The class templates <tt>const_mem_fun_t</tt> in 20.5.8, p8 and
9105 <tt>const_mem_fun1_t</tt>
9106 in 20.5.8, p9 derive from <tt>unary_function&lt;T*, S&gt;</tt>, and
9107 <tt>binary_function&lt;T*,
9108 A, S&gt;</tt>, respectively. Consequently, their <tt>argument_type</tt>, and
9109 <tt>first_argument_type</tt>
9110 members, respectively, are both defined to be <tt>T*</tt> (non-const).
9111 However, their function call member operator takes a <tt>const T*</tt>
9112 argument. It is my opinion that <tt>argument_type</tt> should be <tt>const
9113 T*</tt> instead, so that one can easily refer to it in generic code. The
9114 example below derived from existing code fails to compile due to the
9115 discrepancy:
9116 </p>
9117
9118 <p><tt>template &lt;class T&gt;</tt>
9119 <br><tt>void foo (typename T::argument_type arg)&nbsp;&nbsp; // #1</tt>
9120 <br><tt>{</tt>
9121 <br><tt>&nbsp;&nbsp;&nbsp; typename T::result_type (T::*pf) (typename
9122 T::argument_type)
9123 const =&nbsp;&nbsp; // #2</tt>
9124 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &amp;T::operator();</tt>
9125 <br><tt>}</tt>
9126 </p>
9127
9128 <p><tt>struct X { /* ... */ };</tt></p>
9129
9130 <p><tt>int main ()</tt>
9131 <br><tt>{</tt>
9132 <br><tt>&nbsp;&nbsp;&nbsp; const X x;</tt>
9133 <br><tt>&nbsp;&nbsp;&nbsp; foo&lt;std::const_mem_fun_t&lt;void, X&gt;
9134 &gt;(&amp;x);&nbsp;&nbsp;
9135 // #3</tt>
9136 <br><tt>}</tt>
9137 </p>
9138
9139 <p>#1 <tt>foo()</tt> takes a plain unqualified <tt>X*</tt> as an argument
9140 <br>#2 the type of the pointer is incompatible with the type of the member
9141 function
9142 <br>#3 the address of a constant being passed to a function taking a non-const
9143 <tt>X*</tt>
9144 </p>
9145 <p><b>Proposed resolution:</b></p>
9146 <p>Replace the top portion of the definition of the class template
9147 const_mem_fun_t in 20.5.8, p8
9148 </p>
9149 <p><tt>template &lt;class S, class T&gt; class const_mem_fun_t</tt>
9150 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
9151 unary_function&lt;T*, S&gt; {</tt>
9152 </p>
9153 <p>with</p>
9154 <p><tt>template &lt;class S, class T&gt; class const_mem_fun_t</tt>
9155 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
9156 unary_function&lt;<b>const</b> T*, S&gt; {</tt>
9157 </p>
9158 <p>Also replace the top portion of the definition of the class template
9159 const_mem_fun1_t in 20.5.8, p9</p>
9160 <p><tt>template &lt;class S, class T, class A&gt; class const_mem_fun1_t</tt>
9161 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
9162 binary_function&lt;T*, A, S&gt; {</tt>
9163 </p>
9164 <p>with</p>
9165 <p><tt>template &lt;class S, class T, class A&gt; class const_mem_fun1_t</tt>
9166 <br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : public
9167 binary_function&lt;<b>const</b> T*, A, S&gt; {</tt>
9168 </p>
9169 <p><b>Rationale:</b></p>
9170 <p>This is simply a contradiction: the <tt>argument_type</tt> typedef,
9171 and the argument type itself, are not the same.</p>
9172 <hr>
9173 <a name="298"><h3>298.&nbsp;::operator delete[] requirement incorrect/insufficient</h3></a><p><b>Section:</b>&nbsp;18.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;John A. Pedretti&nbsp; <b>Date:</b>&nbsp;10 Jan 2001</p>
9174 <p>
9175 The default behavior of <tt>operator delete[]</tt> described in 18.5.1.2, p12 -
9176 namely that for non-null value of <i>ptr</i>, the operator reclaims storage
9177 allocated by the earlier call to the default <tt>operator new[]</tt> - is not
9178 correct in all cases. Since the specified <tt>operator new[]</tt> default
9179 behavior is to call <tt>operator new</tt> (18.5.1.2, p4, p8), which can be
9180 replaced, along with <tt>operator delete</tt>, by the user, to implement their
9181 own memory management, the specified default behavior of<tt> operator
9182 delete[]</tt> must be to call <tt>operator delete</tt>.
9183 </p>
9184 <p><b>Proposed resolution:</b></p>
9185 <p>Change 18.5.1.2, p12 from</p>
9186 <blockquote>
9187 <b>-12-</b> <b>Default behavior:</b>
9188 <ul>
9189 <li>
9190 For a null value of <i><tt>ptr</tt></i> , does nothing.
9191 </li>
9192 <li>
9193 Any other value of <i><tt>ptr</tt></i> shall be a value returned
9194 earlier by a call to the default <tt>operator new[](std::size_t)</tt>.
9195 [Footnote: The value must not have been invalidated by an intervening
9196 call to <tt>operator delete[](void*)</tt> (17.4.3.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.res.on.arguments"> [lib.res.on.arguments]</a>).
9197 --- end footnote]
9198 For such a non-null value of <i><tt>ptr</tt></i> , reclaims storage
9199 allocated by the earlier call to the default <tt>operator new[]</tt>.
9200 </li>
9201 </ul>
9202 </blockquote>
9203
9204 <p>to</p>
9205
9206 <blockquote>
9207 <b>-12-</b> <b>Default behavior: </b>Calls <tt>operator
9208 delete(</tt><i>ptr</i>)
9209 or <tt>operator delete(<i>ptr</i>, std::nothrow)</tt> respectively.
9210 </blockquote>
9211 <p>and expunge paragraph 13.</p>
9212 <hr>
9213 <a name="300"><h3>300.&nbsp;list::merge() specification incomplete</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;John Pedretti&nbsp; <b>Date:</b>&nbsp;23 Jan 2001</p>
9214 <p>
9215 The "Effects" clause for list::merge() (23.2.2.4, p23)
9216 appears to be incomplete: it doesn't cover the case where the argument
9217 list is identical to *this (i.e., this == &amp;x). The requirement in the
9218 note in p24 (below) is that x be empty after the merge which is surely
9219 unintended in this case.
9220 </p>
9221 <p><b>Proposed resolution:</b></p>
9222 <p>In 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>, replace paragraps 23-25 with:</p>
9223 <blockquote>
9224 <p>
9225 23 Effects: if (&amp;x == this) does nothing; otherwise, merges the two
9226 sorted ranges [begin(), end()) and [x.begin(), x.end()).  The result
9227 is a range in which the elements will be sorted in non-decreasing
9228 order according to the ordering defined by comp; that is, for every
9229 iterator i in the range other than the first, the condition comp(*i,
9230 *(i - 1)) will be false.
9231 </p>
9232
9233 <p>
9234 24 Notes: Stable: if (&amp;x != this), then for equivalent elements in the
9235 two original ranges, the elements from the original range [begin(),
9236 end()) always precede the elements from the original range [x.begin(),
9237 x.end()).  If (&amp;x != this) the range [x.begin(), x.end()) is empty
9238 after the merge.
9239 </p>
9240
9241 <p>
9242 25 Complexity: At most size() + x.size() - 1 applications of comp if
9243 (&amp;x !  = this); otherwise, no applications of comp are performed.  If
9244 an exception is thrown other than by a comparison there are no
9245 effects.
9246 </p>
9247
9248 </blockquote>
9249
9250 <p><i>[Copenhagen: The original proposed resolution did not fix all of
9251 the problems in 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>, p22-25.  Three different
9252 paragraphs (23, 24, 25) describe the effects of <tt>merge</tt>.
9253 Changing p23, without changing the other two, appears to introduce
9254 contradictions.  Additionally, "merges the argument list into the
9255 list" is excessively vague.]</i></p>
9256
9257 <p><i>[Post-Curaçao: Robert Klarer provided new wording.]</i></p>
9258
9259 <hr>
9260 <a name="301"><h3>301.&nbsp;basic_string template ctor effects clause omits allocator argument</h3></a><p><b>Section:</b>&nbsp;21.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string.cons"> [lib.string.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;27 Jan 2001</p>
9261 <p>
9262 The effects clause for the basic_string template ctor in 21.3.1, p15
9263 leaves out the third argument of type Allocator. I believe this to be
9264 a mistake.
9265 </p>
9266 <p><b>Proposed resolution:</b></p>
9267 <p>Replace</p>
9268
9269 <blockquote>
9270     <p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
9271     type, equivalent to</p>
9272
9273     <blockquote><tt>basic_string(static_cast&lt;size_type&gt;(begin),
9274     static_cast&lt;value_type&gt;(end))</tt></blockquote>
9275 </blockquote>
9276
9277 <p>with</p>
9278
9279 <blockquote>
9280     <p><b>-15- Effects:</b> If <i><tt>InputIterator</tt></i> is an integral
9281     type, equivalent to</p>
9282
9283     <blockquote><tt>basic_string(static_cast&lt;size_type&gt;(begin),
9284     static_cast&lt;value_type&gt;(end), <b>a</b>)</tt></blockquote>
9285 </blockquote>
9286 <hr>
9287 <a name="303"><h3>303.&nbsp;Bitset input operator underspecified</h3></a><p><b>Section:</b>&nbsp;23.3.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.operators"> [lib.bitset.operators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;5 Feb 2001</p>
9288 <p>
9289 In 23.3.5.3, we are told that <tt>bitset</tt>'s input operator
9290 "Extracts up to <i>N</i> (single-byte) characters from
9291 <i>is</i>.", where <i>is</i> is a stream of type
9292 <tt>basic_istream&lt;charT, traits&gt;</tt>.
9293 </p>
9294
9295 <p>
9296 The standard does not say what it means to extract single byte
9297 characters from a stream whose character type, <tt>charT</tt>, is in
9298 general not a single-byte character type.  Existing implementations
9299 differ.
9300 </p>
9301
9302 <p>
9303 A reasonable solution will probably involve <tt>widen()</tt> and/or
9304 <tt>narrow()</tt>, since they are the supplied mechanism for
9305 converting a single character between <tt>char</tt> and
9306 arbitrary <tt>charT</tt>.
9307 </p>
9308
9309 <p>Narrowing the input characters is not the same as widening the
9310 literals <tt>'0'</tt> and <tt>'1'</tt>, because there may be some
9311 locales in which more than one wide character maps to the narrow
9312 character <tt>'0'</tt>.  Narrowing means that alternate
9313 representations may be used for bitset input, widening means that
9314 they may not be.</p>
9315
9316 <p>Note that for numeric input, <tt>num_get&lt;&gt;</tt>
9317 (22.2.2.1.2/8) compares input characters to widened version of narrow
9318 character literals.</p>
9319
9320 <p>From Pete Becker, in c++std-lib-8224:</p>
9321 <blockquote>
9322 <p>
9323 Different writing systems can have different representations for the
9324 digits that represent 0 and 1. For example, in the Unicode representation
9325 of the Devanagari script (used in many of the Indic languages) the digit 0
9326 is 0x0966, and the digit 1 is 0x0967. Calling narrow would translate those
9327 into '0' and '1'. But Unicode also provides the ASCII values 0x0030 and
9328 0x0031 for for the Latin representations of '0' and '1', as well as code
9329 points for the same numeric values in several other scripts (Tamil has no
9330 character for 0, but does have the digits 1-9), and any of these values
9331 would also be narrowed to '0' and '1'.
9332 </p>
9333
9334 <p>...</p>
9335
9336 <p>
9337 It's fairly common to intermix both native and Latin
9338 representations of numbers in a document. So I think the rule has to be
9339 that if a wide character represents a digit whose value is 0 then the bit
9340 should be cleared; if it represents a digit whose value is 1 then the bit
9341 should be set; otherwise throw an exception. So in a Devanagari locale,
9342 both 0x0966 and 0x0030 would clear the bit, and both 0x0967 and 0x0031
9343 would set it. Widen can't do that. It would pick one of those two values,
9344 and exclude the other one.
9345 </p>
9346
9347 </blockquote>
9348
9349 <p>From Jens Maurer, in c++std-lib-8233:</p>
9350
9351 <blockquote>
9352 <p>
9353 Whatever we decide, I would find it most surprising if
9354 bitset conversion worked differently from int conversion
9355 with regard to alternate local representations of
9356 numbers.
9357 </p>
9358
9359 <p>Thus, I think the options are:</p>
9360 <ul>
9361  <li> Have a new defect issue for 22.2.2.1.2/8 so that it will
9362 require the use of narrow().</li>
9363
9364  <li> Have a defect issue for bitset() which describes clearly
9365 that widen() is to be used.</li>
9366 </ul>
9367 </blockquote>
9368 <p><b>Proposed resolution:</b></p>
9369
9370     <p>Replace the first two sentences of paragraph 5 with:</p>
9371
9372     <blockquote>
9373     Extracts up to <i>N</i> characters from <i>is</i>. Stores these
9374     characters in a temporary object <i>str</i> of type
9375     <tt>basic_string&lt;charT, traits&gt;</tt>, then evaluates the
9376     expression <tt><i>x</i> = bitset&lt;N&gt;(<i>str</i>)</tt>.
9377     </blockquote>
9378
9379     <p>Replace the third bullet item in paragraph 5 with:</p>
9380     <ul><li>
9381     the next input character is neither <tt><i>is</i>.widen(0)</tt>
9382     nor <tt><i>is</i>.widen(1)</tt> (in which case the input character
9383     is not extracted).
9384     </li></ul>
9385
9386 <p><b>Rationale:</b></p>
9387 <p>Input for <tt>bitset</tt> should work the same way as numeric
9388 input.  Using <tt>widen</tt> does mean that alternative digit
9389 representations will not be recognized, but this was a known
9390 consequence of the design choice.</p>
9391 <hr>
9392 <a name="305"><h3>305.&nbsp;Default behavior of codecvt&lt;wchar_t, char, mbstate_t&gt;::length()</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;24 Jan 2001</p>
9393 <p>22.2.1.5/3 introduces codecvt in part with:</p>
9394
9395 <blockquote>
9396   codecvt&lt;wchar_t,char,mbstate_t&gt; converts between the native
9397   character sets for tiny and wide characters. Instantiations on
9398   mbstate_t perform conversion between encodings known to the library
9399   implementor.
9400 </blockquote>
9401
9402 <p>But 22.2.1.5.2/10 describes do_length in part with:</p>
9403
9404 <blockquote>
9405   ... codecvt&lt;wchar_t, char, mbstate_t&gt; ... return(s) the lesser of max and
9406   (from_end-from).
9407 </blockquote>
9408
9409 <p>
9410 The semantics of do_in and do_length are linked.  What one does must
9411 be consistent with what the other does.  22.2.1.5/3 leads me to
9412 believe that the vendor is allowed to choose the algorithm that
9413 codecvt&lt;wchar_t,char,mbstate_t&gt;::do_in performs so that it makes
9414 his customers happy on a given platform.  But 22.2.1.5.2/10 explicitly
9415 says what codecvt&lt;wchar_t,char,mbstate_t&gt;::do_length must
9416 return.  And thus indirectly specifies the algorithm that
9417 codecvt&lt;wchar_t,char,mbstate_t&gt;::do_in must perform.  I believe
9418 that this is not what was intended and is a defect.
9419 </p>
9420
9421 <p>Discussion from the -lib reflector:
9422
9423 <br>This proposal would have the effect of making the semantics of
9424 all of the virtual functions in <tt>codecvt&lt;wchar_t, char,
9425 mbstate_t&gt;</tt> implementation specified.  Is that what we want, or
9426 do we want to mandate specific behavior for the base class virtuals
9427 and leave the implementation specified behavior for the codecvt_byname
9428 derived class?  The tradeoff is that former allows implementors to
9429 write a base class that actually does something useful, while the
9430 latter gives users a way to get known and specified---albeit
9431 useless---behavior, and is consistent with the way the standard
9432 handles other facets.  It is not clear what the original intention
9433 was.</p>
9434
9435 <p>
9436 Nathan has suggest a compromise: a character that is a widened version
9437 of the characters in the basic execution character set must be
9438 converted to a one-byte sequence, but there is no such requirement
9439 for characters that are not part of the basic execution character set.
9440 </p>
9441 <p><b>Proposed resolution:</b></p>
9442 <p>
9443 Change 22.2.1.5.2/5 from:
9444 </p>
9445 <p>
9446 The instantiations required in Table 51 (lib.locale.category), namely
9447 codecvt&lt;wchar_t,char,mbstate_t&gt; and
9448 codecvt&lt;char,char,mbstate_t&gt;, store no characters. Stores no more
9449 than (to_limit-to) destination elements. It always leaves the to_next
9450 pointer pointing one beyond the last element successfully stored.
9451 </p>
9452 <p>
9453 to:
9454 </p>
9455 <p>
9456 Stores no more than (to_limit-to) destination elements, and leaves the
9457 to_next pointer pointing one beyond the last element successfully
9458 stored.  codecvt&lt;char,char,mbstate_t&gt; stores no characters.
9459 </p>
9460
9461 <p>Change 22.2.1.5.2/10 from:</p>
9462
9463 <blockquote>
9464 -10- Returns: (from_next-from) where from_next is the largest value in
9465 the range [from,from_end] such that the sequence of values in the
9466 range [from,from_next) represents max or fewer valid complete
9467 characters of type internT. The instantiations required in Table 51
9468 (21.1.1.1.1), namely codecvt&lt;wchar_t, char, mbstate_t&gt; and
9469 codecvt&lt;char, char, mbstate_t&gt;, return the lesser of max and
9470 (from_end-from).
9471 </blockquote>
9472
9473 <p>to:</p>
9474
9475 <blockquote>
9476 -10- Returns: (from_next-from) where from_next is the largest value in
9477 the range [from,from_end] such that the sequence of values in the range
9478 [from,from_next) represents max or fewer valid complete characters of
9479 type internT. The instantiation codecvt&lt;char, char, mbstate_t&gt; returns
9480 the lesser of max and (from_end-from).
9481 </blockquote>
9482
9483 <p><i>[Redmond: Nathan suggested an alternative resolution: same as
9484 above, but require that, in the default encoding, a character from the
9485 basic execution character set would map to a single external
9486 character.  The straw poll was 8-1 in favor of the proposed
9487 resolution.]</i></p>
9488
9489 <p><b>Rationale:</b></p>
9490 <p>The default encoding should be whatever users of a given platform
9491 would expect to be the most natural.  This varies from platform to
9492 platform.  In many cases there is a preexisting C library, and users
9493 would expect the default encoding to be whatever C uses in the default
9494 "C" locale.  We could impose a guarantee like the one Nathan suggested
9495 (a character from the basic execution character set must map to a
9496 single external character), but this would rule out important
9497 encodings that are in common use: it would rule out JIS, for
9498 example, and it would rule out a fixed-width encoding of UCS-4.</p>
9499
9500 <p><i>[Curaçao: fixed rationale typo at the request of Ichiro Koshida;
9501 "shift-JIS" changed to "JIS".]</i></p>
9502
9503 <hr>
9504 <a name="306"><h3>306.&nbsp;offsetof macro and non-POD types</h3></a><p><b>Section:</b>&nbsp;18.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.types"> [lib.support.types]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;21 Feb 2001</p>
9505 <p>Spliced together from reflector messages c++std-lib-8294 and -8295:</p>
9506
9507 <p>18.1, paragraph 5, reads: "The macro <tt>offsetof</tt>
9508 accepts a restricted set of <i>type</i> arguments in this
9509 International Standard. <i>type</i> shall be a POD structure or a POD
9510 union (clause 9). The result of applying the offsetof macro to a field
9511 that is a static data member or a function member is
9512 undefined."</p>
9513
9514 <p>For the POD requirement, it doesn't say "no diagnostic
9515 required" or "undefined behavior". I read 1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/intro.html#intro.compliance"> [intro.compliance]</a>, paragraph 1, to mean that a diagnostic is required.
9516 It's not clear whether this requirement was intended.  While it's
9517 possible to provide such a diagnostic, the extra complication doesn't
9518 seem to add any value.
9519 </p>
9520 <p><b>Proposed resolution:</b></p>
9521 <p>Change 18.1, paragraph 5, to "If <i>type</i> is not a POD
9522 structure or a POD union the results are undefined."</p>
9523
9524 <p><i>[Copenhagen: straw poll was 7-4 in favor.  It was generally
9525 agreed that requiring a diagnostic was inadvertent, but some LWG
9526 members thought that diagnostics should be required whenever
9527 possible.]</i></p>
9528
9529 <hr>
9530 <a name="307"><h3>307.&nbsp;Lack of reference typedefs in container adaptors</h3></a><p><b>Section:</b>&nbsp;23.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list"> [lib.list]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;13 Mar 2001</p>
9531
9532 <p>From reflector message c++std-lib-8330.  See also lib-8317.</p>
9533
9534 <p>
9535 The standard is currently inconsistent in 23.2.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.capacity"> [lib.list.capacity]</a>
9536 paragraph 1 and 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.modifiers"> [lib.list.modifiers]</a> paragraph 1.
9537 23.2.3.3/1, for example, says:
9538 </p>
9539
9540 <blockquote>
9541 -1- Any sequence supporting operations back(), push_back() and pop_back()
9542 can be used to instantiate stack. In particular, vector (lib.vector), list
9543 (lib.list) and deque (lib.deque) can be used.
9544 </blockquote>
9545
9546 <p>But this is false: vector&lt;bool&gt; can not be used, because the
9547 container adaptors return a T&amp; rather than using the underlying
9548 container's reference type.</p>
9549
9550 <p>This is a contradiction that can be fixed by:</p>
9551
9552 <ol>
9553 <li>Modifying these paragraphs to say that vector&lt;bool&gt;
9554     is an exception.</li>
9555 <li>Removing the vector&lt;bool&gt; specialization.</li>
9556 <li>Changing the return types of stack and priority_queue to use
9557     reference typedef's.</li>
9558 </ol>
9559
9560 <p>
9561 I propose 3.  This does not preclude option 2 if we choose to do it
9562 later (see issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#96">96</a>); the issues are independent.  Option
9563 3 offers a small step towards support for proxied containers.  This
9564 small step fixes a current contradiction, is easy for vendors to
9565 implement, is already implemented in at least one popular lib, and
9566 does not break any code.
9567 </p>
9568
9569 <p><b>Proposed resolution:</b></p>
9570 <p>Summary: Add reference and const_reference typedefs to queue,
9571 priority_queue and stack.  Change return types of "value_type&amp;" to
9572 "reference".  Change return types of "const value_type&amp;" to
9573 "const_reference".  Details:</p>
9574
9575 <p>Change 23.2.3.1/1 from:</p>
9576
9577 <pre>  namespace std {
9578     template &lt;class T, class Container = deque&lt;T&gt; &gt;
9579     class queue {
9580     public:
9581       typedef typename Container::value_type            value_type;
9582       typedef typename Container::size_type             size_type;
9583       typedef          Container                        container_type;
9584     protected:
9585       Container c;
9586
9587     public:
9588       explicit queue(const Container&amp; = Container());
9589
9590       bool      empty() const             { return c.empty(); }
9591       size_type size()  const             { return c.size(); }
9592       value_type&amp;       front()           { return c.front(); }
9593       const value_type&amp; front() const     { return c.front(); }
9594       value_type&amp;       back()            { return c.back(); }
9595       const value_type&amp; back() const      { return c.back(); }
9596       void push(const value_type&amp; x)      { c.push_back(x); }
9597       void pop()                          { c.pop_front(); }
9598     };
9599 </pre>
9600
9601 <p>to:</p>
9602
9603 <pre>  namespace std {
9604     template &lt;class T, class Container = deque&lt;T&gt; &gt;
9605     class queue {
9606     public:
9607       typedef typename Container::value_type            value_type;
9608       typedef typename Container::reference             reference;
9609       typedef typename Container::const_reference       const_reference;
9610       typedef typename Container::value_type            value_type;
9611       typedef typename Container::size_type             size_type;
9612       typedef          Container                        container_type;
9613     protected:
9614       Container c;
9615
9616     public:
9617       explicit queue(const Container&amp; = Container());
9618
9619       bool      empty() const             { return c.empty(); }
9620       size_type size()  const             { return c.size(); }
9621       reference         front()           { return c.front(); }
9622       const_reference   front() const     { return c.front(); }
9623       reference         back()            { return c.back(); }
9624       const_reference   back() const      { return c.back(); }
9625       void push(const value_type&amp; x)      { c.push_back(x); }
9626       void pop()                          { c.pop_front(); }
9627     };
9628 </pre>
9629
9630 <p>Change 23.2.3.2/1 from:</p>
9631
9632 <pre>  namespace std {
9633     template &lt;class T, class Container = vector&lt;T&gt;,
9634               class Compare = less&lt;typename Container::value_type&gt; &gt;
9635     class priority_queue {
9636     public:
9637       typedef typename Container::value_type            value_type;
9638       typedef typename Container::size_type             size_type;
9639       typedef          Container                        container_type;
9640     protected:
9641       Container c;
9642       Compare comp;
9643
9644     public:
9645       explicit priority_queue(const Compare&amp; x = Compare(),
9646                               const Container&amp; = Container());
9647       template &lt;class InputIterator&gt;
9648         priority_queue(InputIterator first, InputIterator last,
9649                        const Compare&amp; x = Compare(),
9650                        const Container&amp; = Container());
9651
9652       bool      empty() const       { return c.empty(); }
9653       size_type size()  const       { return c.size(); }
9654       const value_type&amp; top() const { return c.front(); }
9655       void push(const value_type&amp; x);
9656       void pop();
9657     };
9658                                   //  no equality is provided
9659   }
9660 </pre>
9661
9662 <p>to:</p>
9663
9664 <pre>  namespace std {
9665     template &lt;class T, class Container = vector&lt;T&gt;,
9666               class Compare = less&lt;typename Container::value_type&gt; &gt;
9667     class priority_queue {
9668     public:
9669       typedef typename Container::value_type            value_type;
9670       typedef typename Container::reference             reference;
9671       typedef typename Container::const_reference       const_reference;
9672       typedef typename Container::size_type             size_type;
9673       typedef          Container                        container_type;
9674     protected:
9675       Container c;
9676       Compare comp;
9677
9678     public:
9679       explicit priority_queue(const Compare&amp; x = Compare(),
9680                               const Container&amp; = Container());
9681       template &lt;class InputIterator&gt;
9682         priority_queue(InputIterator first, InputIterator last,
9683                        const Compare&amp; x = Compare(),
9684                        const Container&amp; = Container());
9685
9686       bool      empty() const       { return c.empty(); }
9687       size_type size()  const       { return c.size(); }
9688       const_reference   top() const { return c.front(); }
9689       void push(const value_type&amp; x);
9690       void pop();
9691     };
9692                                   //  no equality is provided
9693   }
9694 </pre>
9695
9696 <p>And change 23.2.3.3/1 from:</p>
9697
9698 <pre>  namespace std {
9699     template &lt;class T, class Container = deque&lt;T&gt; &gt;
9700     class stack {
9701     public:
9702       typedef typename Container::value_type            value_type;
9703       typedef typename Container::size_type             size_type;
9704       typedef          Container                        container_type;
9705     protected:
9706       Container c;
9707
9708     public:
9709       explicit stack(const Container&amp; = Container());
9710
9711       bool      empty() const             { return c.empty(); }
9712       size_type size()  const             { return c.size(); }
9713       value_type&amp;       top()             { return c.back(); }
9714       const value_type&amp; top() const       { return c.back(); }
9715       void push(const value_type&amp; x)      { c.push_back(x); }
9716       void pop()                          { c.pop_back(); }
9717     };
9718
9719     template &lt;class T, class Container&gt;
9720       bool operator==(const stack&lt;T, Container&gt;&amp; x,
9721                       const stack&lt;T, Container&gt;&amp; y);
9722     template &lt;class T, class Container&gt;
9723       bool operator&lt; (const stack&lt;T, Container&gt;&amp; x,
9724                       const stack&lt;T, Container&gt;&amp; y);
9725     template &lt;class T, class Container&gt;
9726       bool operator!=(const stack&lt;T, Container&gt;&amp; x,
9727                       const stack&lt;T, Container&gt;&amp; y);
9728     template &lt;class T, class Container&gt;
9729       bool operator&gt; (const stack&lt;T, Container&gt;&amp; x,
9730                       const stack&lt;T, Container&gt;&amp; y);
9731     template &lt;class T, class Container&gt;
9732       bool operator&gt;=(const stack&lt;T, Container&gt;&amp; x,
9733                       const stack&lt;T, Container&gt;&amp; y);
9734     template &lt;class T, class Container&gt;
9735       bool operator&lt;=(const stack&lt;T, Container&gt;&amp; x,
9736                       const stack&lt;T, Container&gt;&amp; y);
9737   }
9738 </pre>
9739
9740 <p>to:</p>
9741
9742 <pre>  namespace std {
9743     template &lt;class T, class Container = deque&lt;T&gt; &gt;
9744     class stack {
9745     public:
9746       typedef typename Container::value_type            value_type;
9747       typedef typename Container::reference             reference;
9748       typedef typename Container::const_reference       const_reference;
9749       typedef typename Container::size_type             size_type;
9750       typedef          Container                        container_type;
9751     protected:
9752       Container c;
9753
9754     public:
9755       explicit stack(const Container&amp; = Container());
9756
9757       bool      empty() const             { return c.empty(); }
9758       size_type size()  const             { return c.size(); }
9759       reference         top()             { return c.back(); }
9760       const_reference   top() const       { return c.back(); }
9761       void push(const value_type&amp; x)      { c.push_back(x); }
9762       void pop()                          { c.pop_back(); }
9763     };
9764
9765     template &lt;class T, class Container&gt;
9766       bool operator==(const stack&lt;T, Container&gt;&amp; x,
9767                       const stack&lt;T, Container&gt;&amp; y);
9768     template &lt;class T, class Container&gt;
9769       bool operator&lt; (const stack&lt;T, Container&gt;&amp; x,
9770                       const stack&lt;T, Container&gt;&amp; y);
9771     template &lt;class T, class Container&gt;
9772       bool operator!=(const stack&lt;T, Container&gt;&amp; x,
9773                       const stack&lt;T, Container&gt;&amp; y);
9774     template &lt;class T, class Container&gt;
9775       bool operator&gt; (const stack&lt;T, Container&gt;&amp; x,
9776                       const stack&lt;T, Container&gt;&amp; y);
9777     template &lt;class T, class Container&gt;
9778       bool operator&gt;=(const stack&lt;T, Container&gt;&amp; x,
9779                       const stack&lt;T, Container&gt;&amp; y);
9780     template &lt;class T, class Container&gt;
9781       bool operator&lt;=(const stack&lt;T, Container&gt;&amp; x,
9782                       const stack&lt;T, Container&gt;&amp; y);
9783   }
9784 </pre>
9785
9786 <p><i>[Copenhagen: This change was discussed before the IS was released
9787 and it was deliberately not adopted.  Nevertheless, the LWG believes
9788 (straw poll: 10-2) that it is a genuine defect.]</i></p>
9789
9790 <hr>
9791 <a name="308"><h3>308.&nbsp;Table 82 mentions unrelated headers</h3></a><p><b>Section:</b>&nbsp;27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;15 Mar 2001</p>
9792 <p>
9793 Table 82 in section 27 mentions the header &lt;cstdlib&gt; for String
9794 streams (27.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.string.streams"> [lib.string.streams]</a>) and the headers &lt;cstdio&gt; and
9795 &lt;cwchar&gt; for File streams (27.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a>). It's not clear
9796 why these headers are mentioned in this context since they do not
9797 define any of the library entities described by the
9798 subclauses. According to 17.4.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.contents"> [lib.contents]</a>, only such headers
9799 are to be listed in the summary.
9800 </p>
9801 <p><b>Proposed resolution:</b></p>
9802 <p>Remove &lt;cstdlib&gt; and &lt;cwchar&gt; from
9803 Table 82.</p>
9804
9805 <p><i>[Copenhagen: changed the proposed resolution slightly.  The
9806 original proposed resolution also said to remove &lt;cstdio&gt; from
9807 Table 82.  However, &lt;cstdio&gt; is mentioned several times within
9808 section 27.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.file.streams"> [lib.file.streams]</a>, including 27.8.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.c.files"> [lib.c.files]</a>.]</i></p>
9809
9810 <hr>
9811 <a name="310"><h3>310.&nbsp;Is errno a macro?</h3></a><p><b>Section:</b>&nbsp;17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a>, 19.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-diagnostics.html#lib.errno"> [lib.errno]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;21 Mar 2001</p>
9812   <p>
9813   Exactly how should errno be declared in a conforming C++ header?
9814   </p>
9815
9816   <p>
9817   The C standard says in 7.1.4 that it is unspecified whether errno is a
9818   macro or an identifier with external linkage.  In some implementations
9819   it can be either, depending on compile-time options.  (E.g., on
9820   Solaris in multi-threading mode, errno is a macro that expands to a
9821   function call, but is an extern int otherwise.  "Unspecified" allows
9822   such variability.)
9823   </p>
9824
9825   <p>The C++ standard:</p>
9826   <ul>
9827   <li>17.4.1.2 says in a note that errno must be macro in C. (false)</li>
9828   <li>17.4.3.1.3 footnote 166 says errno is reserved as an external
9829       name (true), and implies that it is an identifier.</li>
9830   <li>19.3 simply lists errno as a macro (by what reasoning?) and goes
9831       on to say that the contents of of C++ &lt;errno.h&gt; are the
9832       same as in C, begging the question.</li>
9833   <li>C.2, table 95 lists errno as a macro, without comment.</li>
9834   </ul>
9835
9836   <p>I find no other references to errno.</p>
9837
9838   <p>We should either explicitly say that errno must be a macro, even
9839   though it need not be a macro in C, or else explicitly leave it
9840   unspecified.  We also need to say something about namespace std.
9841   A user who includes &lt;cerrno&gt; needs to know whether to write
9842   <tt>errno</tt>, or <tt>::errno</tt>, or <tt>std::errno</tt>, or
9843   else &lt;cerrno&gt; is useless.</p>
9844
9845   <p>Two acceptable fixes:</p>
9846   <ul>
9847     <li><p>errno must be a macro. This is trivially satisfied by adding<br>
9848         &nbsp;&nbsp;#define errno (::std::errno)<br>
9849         to the headers if errno is not already a macro. You then always
9850         write errno without any scope qualification, and it always expands
9851         to a correct reference. Since it is always a macro, you know to
9852         avoid using errno as a local identifer.</p></li>
9853     <li><p>errno is in the global namespace. This fix is inferior, because
9854         ::errno is not guaranteed to be well-formed.</p></li>
9855   </ul>
9856
9857   <p><i>[
9858     This issue was first raised in 1999, but it slipped through
9859     the cracks.
9860   ]</i></p>
9861 <p><b>Proposed resolution:</b></p>
9862   <p>Change the Note in section 17.4.1.2p5 from</p>
9863
9864     <blockquote>
9865     Note: the names defined as macros in C include the following:
9866     assert, errno, offsetof, setjmp, va_arg, va_end, and va_start.
9867     </blockquote>
9868
9869   <p>to</p>
9870
9871     <blockquote>
9872     Note: the names defined as macros in C include the following:
9873     assert, offsetof, setjmp, va_arg, va_end, and va_start.
9874     </blockquote>
9875
9876   <p>In section 19.3, change paragraph 2 from</p>
9877
9878     <blockquote>
9879     The contents are the same as the Standard C library header
9880     &lt;errno.h&gt;.
9881     </blockquote>
9882
9883   <p>to</p>
9884
9885     <blockquote>
9886     The contents are the same as the Standard C library header
9887     &lt;errno.h&gt;, except that errno shall be defined as a macro.
9888     </blockquote>
9889 <p><b>Rationale:</b></p>
9890 <p>C++ must not leave it up to the implementation to decide whether or
9891 not a name is a macro; it must explicitly specify exactly which names
9892 are required to be macros.  The only one that really works is for it
9893 to be a macro.</p>
9894
9895 <p><i>[Curaçao: additional rationale added.]</i></p>
9896
9897 <hr>
9898 <a name="311"><h3>311.&nbsp;Incorrect wording in basic_ostream class synopsis</h3></a><p><b>Section:</b>&nbsp;27.6.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream"> [lib.ostream]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;21 Mar 2001</p>
9899
9900 <p>In 27.6.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream"> [lib.ostream]</a>, the synopsis of class basic_ostream says:</p>
9901
9902 <pre>  // partial specializationss
9903   template&lt;class traits&gt;
9904     basic_ostream&lt;char,traits&gt;&amp; operator&lt;&lt;( basic_ostream&lt;char,traits&gt;&amp;,
9905                                             const char * );
9906 </pre>
9907
9908 <p>Problems:</p>
9909 <ul>
9910 <li>Too many 's's at the end of "specializationss" </li>
9911 <li>This is an overload, not a partial specialization</li>
9912 </ul>
9913
9914 <p><b>Proposed resolution:</b></p>
9915 <p>In the synopsis in 27.6.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream"> [lib.ostream]</a>, remove the
9916 <i>// partial specializationss</i> comment.  Also remove the same
9917 comment (correctly spelled, but still incorrect) from the synopsis in
9918 27.6.2.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a>.
9919 </p>
9920
9921 <p><i>[
9922 Pre-Redmond: added 27.6.2.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a> because of Martin's
9923 comment in c++std-lib-8939.
9924 ]</i></p>
9925
9926 <hr>
9927 <a name="312"><h3>312.&nbsp;Table 27 is missing headers</h3></a><p><b>Section:</b>&nbsp;20 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.utilities"> [lib.utilities]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;29 Mar 2001</p>
9928 <p>Table 27 in section 20 lists the header &lt;memory&gt; (only) for
9929 Memory (lib.memory) but neglects to mention the headers
9930 &lt;cstdlib&gt; and &lt;cstring&gt; that are discussed in 20.4.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.rel"> [lib.meta.rel]</a>.</p>
9931 <p><b>Proposed resolution:</b></p>
9932 <p>Add &lt;cstdlib&gt; and &lt;cstring&gt; to Table 27, in the same row
9933 as &lt;memory&gt;.</p>
9934 <hr>
9935 <a name="315"><h3>315.&nbsp;Bad "range" in list::unique complexity</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;1 May 2001</p>
9936 <p>
9937 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>, Para 21 describes the complexity of
9938 list::unique as: "If the range (last - first) is not empty, exactly
9939 (last - first) -1 applications of the corresponding predicate,
9940 otherwise no applications of the predicate)".
9941 </p>
9942
9943 <p>
9944 "(last - first)" is not a range.
9945 </p>
9946 <p><b>Proposed resolution:</b></p>
9947 <p>
9948 Change the "range" from (last - first) to [first, last).
9949 </p>
9950 <hr>
9951 <a name="316"><h3>316.&nbsp;Vague text in Table 69</h3></a><p><b>Section:</b>&nbsp;23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;4 May 2001</p>
9952 <p>Table 69 says this about a_uniq.insert(t):</p>
9953
9954 <blockquote>
9955 inserts t if and only if there is no element in the container with key
9956 equivalent to the key of t. The bool component of the returned pair
9957 indicates whether the insertion takes place and the iterator component of the
9958 pair points to the element with key equivalent to the key of t.
9959 </blockquote>
9960
9961 <p>The description should be more specific about exactly how the bool component
9962 indicates whether the insertion takes place.</p>
9963 <p><b>Proposed resolution:</b></p>
9964 <p>Change the text in question to</p>
9965
9966 <blockquote>
9967 ...The bool component of the returned pair is true if and only if the insertion
9968 takes place...
9969 </blockquote>
9970 <hr>
9971 <a name="317"><h3>317.&nbsp;Instantiation vs. specialization of facets</h3></a><p><b>Section:</b>&nbsp;22 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.localization"> [lib.localization]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;4 May 2001</p>
9972 <p>
9973 The localization section of the standard refers to specializations of
9974 the facet templates as instantiations even though the required facets
9975 are typically specialized rather than explicitly (or implicitly)
9976 instantiated. In the case of ctype&lt;char&gt; and
9977 ctype_byname&lt;char&gt; (and the wchar_t versions), these facets are
9978 actually required to be specialized. The terminology should be
9979 corrected to make it clear that the standard doesn't mandate explicit
9980 instantiation (the term specialization encompasses both explicit
9981 instantiations and specializations).
9982 </p>
9983 <p><b>Proposed resolution:</b></p>
9984 <p>
9985 In the following paragraphs, replace all occurrences of the word
9986 instantiation or instantiations with specialization or specializations,
9987 respectively:
9988 </p>
9989
9990 <blockquote>
9991 22.1.1.1.1, p4, Table 52, 22.2.1.1, p2, 22.2.1.5, p3, 22.2.1.5.1, p5,
9992 22.2.1.5.2, p10, 22.2.2, p2, 22.2.3.1, p1, 22.2.3.1.2, p1, p2 and p3,
9993 22.2.4.1, p1, 22.2.4.1.2, p1, 22,2,5, p1, 22,2,6, p2, 22.2.6.3.2, p7, and
9994 Footnote 242.
9995 </blockquote>
9996
9997 <p>And change the text in 22.1.1.1.1, p4 from</p>
9998
9999 <blockquote>
10000     An implementation is required to provide those instantiations
10001     for facet templates identified as members of a category, and
10002     for those shown in Table 52:
10003 </blockquote>
10004
10005 <p>to</p>
10006
10007 <blockquote>
10008     An implementation is required to provide those specializations...
10009 </blockquote>
10010
10011 <p><i>[Nathan will review these changes, and will look for places where
10012 explicit specialization is necessary.]</i></p>
10013
10014 <p><b>Rationale:</b></p>
10015 <p>This is a simple matter of outdated language.  The language to
10016 describe templates was clarified during the standardization process,
10017 but the wording in clause 22 was never updated to reflect that
10018 change.</p>
10019 <hr>
10020 <a name="318"><h3>318.&nbsp;Misleading comment in definition of numpunct_byname</h3></a><p><b>Section:</b>&nbsp;22.2.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.numpunct.byname"> [lib.locale.numpunct.byname]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;12 May 2001</p>
10021 <p>The definition of the numpunct_byname template contains the following
10022 comment:</p>
10023
10024 <pre>    namespace std {
10025         template &lt;class charT&gt;
10026         class numpunct_byname : public numpunct&lt;charT&gt; {
10027     // this class is specialized for char and wchar_t.
10028         ...
10029 </pre>
10030
10031 <p>There is no documentation of the specializations and it seems
10032 conceivable that an implementation will not explicitly specialize the
10033 template at all, but simply provide the primary template.</p>
10034 <p><b>Proposed resolution:</b></p>
10035 <p>Remove the comment from the text in 22.2.3.2 and from the proposed
10036 resolution of library issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#228">228</a>.</p>
10037 <hr>
10038 <a name="319"><h3>319.&nbsp;Storage allocation wording confuses "Required behavior", "Requires"</h3></a><p><b>Section:</b>&nbsp;18.5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a>, 18.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;15 May 2001</p>
10039 <p>The standard specifies 17.3.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> that "Required
10040 behavior" elements describe "the semantics of a function definition
10041 provided by either the implementation or a C++ program."</p>
10042
10043 <p>The standard specifies 17.3.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.structure.specifications"> [lib.structure.specifications]</a> that "Requires"
10044 elements describe "the preconditions for calling the function."</p>
10045
10046 <p>In the sections noted below, the current wording specifies
10047 "Required Behavior" for what are actually preconditions, and thus
10048 should be specified as "Requires".</p>
10049
10050 <p><b>Proposed resolution:</b></p>
10051
10052 <p>In 18.5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a> Para 12 Change:</p>
10053 <blockquote>
10054   <p>Required behavior: accept a value of ptr that is null or that was
10055   returned by an earlier call ...</p>
10056 </blockquote>
10057 <p>to:</p>
10058 <blockquote>
10059   <p>Requires: the value of ptr is null or the value returned by an
10060   earlier call ...</p>
10061 </blockquote>
10062
10063 <p>In 18.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a> Para 11 Change:</p>
10064 <blockquote>
10065   <p>Required behavior: accept a value of ptr that is null or that was
10066   returned by an earlier call ...</p>
10067 </blockquote>
10068 <p>to:</p>
10069 <blockquote>
10070   <p>Requires: the value of ptr is null or the value returned by an
10071   earlier call ...</p>
10072 </blockquote>
10073
10074 <hr>
10075 <a name="320"><h3>320.&nbsp;list::assign overspecified</h3></a><p><b>Section:</b>&nbsp;23.2.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.deque.cons"> [lib.deque.cons]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;17 May 2001</p>
10076 <p>
10077 Section 23.2.2.1, paragraphs 6-8 specify that list assign (both forms) have
10078 the "effects" of a call to erase followed by a call to insert.
10079 </p>
10080
10081 <p>
10082 I would like to document that implementers have the freedom to implement
10083 assign by other methods, as long as the end result is the same and the
10084 exception guarantee is as good or better than the basic guarantee.
10085 </p>
10086
10087 <p>
10088 The motivation for this is to use T's assignment operator to recycle
10089 existing nodes in the list instead of erasing them and reallocating
10090 them with new values.  It is also worth noting that, with careful
10091 coding, most common cases of assign (everything but assignment with
10092 true input iterators) can elevate the exception safety to strong if
10093 T's assignment has a nothrow guarantee (with no extra memory cost).
10094 Metrowerks does this.  However I do not propose that this subtlety be
10095 standardized.  It is a QoI issue.  </p>
10096
10097 <p>Existing practise:
10098 Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't.
10099 </p>
10100 <p><b>Proposed resolution:</b></p>
10101 <p>Change 23.2.2.1/7 from:</p>
10102
10103 <blockquote>
10104 <p>Effects:</p>
10105
10106 <pre>   erase(begin(), end());
10107    insert(begin(), first, last);
10108 </pre>
10109 </blockquote>
10110
10111 <p>to:</p>
10112
10113 <blockquote>
10114 <p>Effects: Replaces the contents of the list with the range [first, last).</p>
10115 </blockquote>
10116
10117 <p>In 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>, in Table 67 (sequence requirements),
10118 add two new rows:</p>
10119 <pre>      a.assign(i,j)     void      pre: i,j are not iterators into a.
10120                                   Replaces elements in a with a copy
10121                                   of [i, j).
10122
10123       a.assign(n,t)     void      pre: t is not a reference into a.
10124                                   Replaces elements in a with n copies
10125                                   of t.
10126 </pre>
10127
10128 <p>Change 23.2.2.1/8 from:</p>
10129
10130 <blockquote>
10131 <p>Effects:</p>
10132 <pre>   erase(begin(), end());
10133    insert(begin(), n, t);
10134 </pre>
10135 </blockquote>
10136 <p>to:</p>
10137
10138 <blockquote>
10139 <p>Effects: Replaces the contents of the list with n copies of t.</p>
10140 </blockquote>
10141
10142 <p><i>[Redmond: Proposed resolution was changed slightly.  Previous
10143 version made explicit statement about exception safety, which wasn't
10144 consistent with the way exception safety is expressed elsewhere.
10145 Also, the change in the sequence requirements is new.  Without that
10146 change, the proposed resolution would have required that assignment of
10147 a subrange would have to work.  That too would have been
10148 overspecification; it would effectively mandate that assignment use a
10149 temporary.  Howard provided wording.
10150 ]</i></p>
10151
10152 <p><i>[Curaçao: Made editorial improvement in wording; changed
10153 "Replaces elements in a with copies of elements in [i, j)."
10154 with "Replaces the elements of a with a copy of [i, j)."
10155 Changes not deemed serious enough to requre rereview.]</i></p>
10156
10157 <hr>
10158 <a name="321"><h3>321.&nbsp;Typo in num_get</h3></a><p><b>Section:</b>&nbsp;22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Kevin Djang&nbsp; <b>Date:</b>&nbsp;17 May 2001</p>
10159 <p>
10160 Section 22.2.2.1.2 at p7 states that "A length specifier is added to
10161 the conversion function, if needed, as indicated in Table 56."
10162 However, Table 56 uses the term "length modifier", not "length
10163 specifier".
10164 </p>
10165 <p><b>Proposed resolution:</b></p>
10166 <p>
10167 In 22.2.2.1.2 at p7, change the text "A length specifier is added ..."
10168 to be "A length modifier is added ..."
10169 </p>
10170 <p><b>Rationale:</b></p>
10171 <p>C uses the term "length modifier".  We should be consistent.</p>
10172 <hr>
10173 <a name="322"><h3>322.&nbsp;iterator and const_iterator should have the same value type</h3></a><p><b>Section:</b>&nbsp;23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;17 May 2001</p>
10174 <p>
10175 It's widely assumed that, if X is a container,
10176 iterator_traits&lt;X::iterator&gt;::value_type and
10177 iterator_traits&lt;X::const_iterator&gt;::value_type should both be
10178 X::value_type.  However, this is nowhere stated.  The language in
10179 Table 65 is not precise about the iterators' value types (it predates
10180 iterator_traits), and could even be interpreted as saying that
10181 iterator_traits&lt;X::const_iterator&gt;::value_type should be "const
10182 X::value_type".
10183 </p>
10184
10185 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#279">279</a>.</p>
10186 <p><b>Proposed resolution:</b></p>
10187 <p>In Table 65 ("Container Requirements"), change the return type for
10188 X::iterator to "iterator type whose value type is T".  Change the
10189 return type for X::const_iterator to "constant iterator type whose
10190 value type is T".</p>
10191 <p><b>Rationale:</b></p>
10192 <p>
10193 This belongs as a container requirement, rather than an iterator
10194 requirement, because the whole notion of iterator/const_iterator
10195 pairs is specific to containers' iterator.
10196 </p>
10197 <p>
10198 It is existing practice that (for example)
10199 iterator_traits&lt;list&lt;int&gt;::const_iterator&gt;::value_type
10200 is "int", rather than "const int".  This is consistent with
10201 the way that const pointers are handled: the standard already
10202 requires that iterator_traits&lt;const int*&gt;::value_type is int.
10203 </p>
10204 <hr>
10205 <a name="324"><h3>324.&nbsp;Do output iterators have value types?</h3></a><p><b>Section:</b>&nbsp;24.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.output.iterators"> [lib.output.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;7 June 2001</p>
10206
10207 <p>Table 73 suggests that output iterators have value types.  It
10208 requires the expression "*a = t".  Additionally, although Table 73
10209 never lists "a = t" or "X(a) = t" in the "expressions" column, it
10210 contains a note saying that "a = t" and "X(a) = t" have equivalent
10211 (but nowhere specified!) semantics.</p>
10212
10213 <p>According to 24.1/9, t is supposed to be "a value of value type
10214 T":</p>
10215
10216     <blockquote>
10217     In the following sections, a and b denote values of X, n denotes a
10218     value of the difference type Distance, u, tmp, and m denote
10219     identifiers, r denotes a value of X&amp;, t denotes a value of
10220     value type T.
10221     </blockquote>
10222
10223 <p>Two other parts of the standard that are relevant to whether
10224 output iterators have value types:</p>
10225
10226 <ul>
10227     <li>24.1/1 says "All iterators i support the expression *i,
10228     resulting in a value of some class, enumeration, or built-in type
10229     T, called the value type of the iterator".</li>
10230
10231     <li>
10232     24.3.1/1, which says "In the case of an output iterator, the types
10233     iterator_traits&lt;Iterator&gt;::difference_type
10234     iterator_traits&lt;Iterator&gt;::value_type are both defined as void."
10235     </li>
10236 </ul>
10237
10238 <p>The first of these passages suggests that "*i" is supposed to
10239 return a useful value, which contradicts the note in 24.1.2/2 saying
10240 that the only valid use of "*i" for output iterators is in an
10241 expression of the form "*i = t".  The second of these passages appears
10242 to contradict Table 73, because it suggests that "*i"'s return value
10243 should be void.  The second passage is also broken in the case of a an
10244 iterator type, like non-const pointers, that satisfies both the output
10245 iterator requirements and the forward iterator requirements.</p>
10246
10247 <p>What should the standard say about <tt>*i</tt>'s return value when
10248 i is an output iterator, and what should it say about that t is in the
10249 expression "*i = t"?  Finally, should the standard say anything about
10250 output iterators' pointer and reference types?</p>
10251
10252 <p><b>Proposed resolution:</b></p>
10253 <p>24.1 p1, change</p>
10254
10255 <blockquote>
10256 <p>All iterators <tt>i</tt> support the expression <tt>*i</tt>, resulting
10257 in a value of some class, enumeration, or built-in type <tt>T</tt>,
10258 called the value type of the iterator.</p>
10259 </blockquote>
10260
10261 <p>to</p>
10262
10263 <blockquote>
10264 <p>All input iterators <tt>i</tt> support the expression <tt>*i</tt>,
10265 resulting in a value of some class, enumeration, or built-in type
10266 <tt>T</tt>, called the value type of the iterator. All output
10267 iterators support the expression <tt>*i = o</tt> where <tt>o</tt> is a
10268 value of some type that is in the set of types that are <i>writable</i> to
10269 the particular iterator type of <tt>i</tt>.
10270 </p>
10271 </blockquote>
10272
10273 <p>24.1 p9, add</p>
10274
10275 <blockquote>
10276 <p><tt>o</tt> denotes a value of some type that is writable to the
10277 output iterator.
10278 </p>
10279 </blockquote>
10280
10281 <p>Table 73, change</p>
10282
10283 <blockquote>
10284 <pre>*a = t
10285 </pre>
10286 </blockquote>
10287
10288 <p>to</p>
10289
10290 <blockquote>
10291 <pre>*r = o
10292 </pre>
10293 </blockquote>
10294
10295 <p>and change</p>
10296
10297 <blockquote>
10298 <pre>*r++ = t
10299 </pre>
10300 </blockquote>
10301
10302 <p>to</p>
10303
10304 <blockquote>
10305 <pre>*r++ = o
10306 </pre>
10307 </blockquote>
10308
10309 <p><i>[post-Redmond: Jeremy provided wording]</i></p>
10310
10311 <p><b>Rationale:</b></p>
10312 <p>The LWG considered two options: change all of the language that
10313 seems to imply that output iterators have value types, thus making it
10314 clear that output iterators have no value types, or else define value
10315 types for output iterator consistently.  The LWG chose the former
10316 option, because it seems clear that output iterators were never
10317 intended to have value types.  This was a deliberate design decision,
10318 and any language suggesting otherwise is simply a mistake.</p>
10319
10320 <p>A future revision of the standard may wish to revisit this design
10321 decision.</p>
10322 <hr>
10323 <a name="325"><h3>325.&nbsp;Misleading text in moneypunct&lt;&gt;::do_grouping</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;02 Jul 2001</p>
10324 <p>The Returns clause in 22.2.6.3.2, p3 says about
10325 moneypunct&lt;charT&gt;::do_grouping()
10326 </p>
10327
10328 <blockquote>
10329     Returns: A pattern defined identically as the result of
10330     numpunct&lt;charT&gt;::do_grouping().241)
10331 </blockquote>
10332
10333 <p>Footnote 241 then reads</p>
10334
10335 <blockquote>
10336     This is most commonly the value "\003" (not "3").
10337 </blockquote>
10338
10339 <p>
10340 The returns clause seems to imply that the two member functions must
10341 return an identical value which in reality may or may not be true,
10342 since the facets are usually implemented in terms of struct std::lconv
10343 and return the value of the grouping and mon_grouping, respectively.
10344 The footnote also implies that the member function of the moneypunct
10345 facet (rather than the overridden virtual functions in moneypunct_byname)
10346 most commonly return "\003", which contradicts the C standard which
10347 specifies the value of "" for the (most common) C locale.
10348 </p>
10349
10350 <p><b>Proposed resolution:</b></p>
10351 <p>Replace the text in Returns clause in 22.2.6.3.2, p3 with the following:</p>
10352
10353 <blockquote>
10354     Returns: A pattern defined identically as, but not necessarily
10355     equal to, the result of numpunct&lt;charT&gt;::do_grouping().241)
10356 </blockquote>
10357
10358 <p>and replace the text in Footnote 241 with the following:</p>
10359
10360 <blockquote>
10361     To specify grouping by 3s the value is "\003", not "3".
10362 </blockquote>
10363 <p><b>Rationale:</b></p>
10364 <p>
10365 The fundamental problem is that the description of the locale facet
10366 virtuals serves two purposes: describing the behavior of the base
10367 class, and describing the meaning of and constraints on the behavior
10368 in arbitrary derived classes.  The new wording makes that separation a
10369 little bit clearer.  The footnote (which is nonnormative) is not
10370 supposed to say what the grouping is in the "C" locale or in any other
10371 locale. It is just a reminder that the values are interpreted as small
10372 integers, not ASCII characters.
10373 </p>
10374 <hr>
10375 <a name="327"><h3>327.&nbsp;Typo in time_get facet in table 52</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Tiki Wan&nbsp; <b>Date:</b>&nbsp;06 Jul 2001</p>
10376 <p>The <tt>wchar_t</tt> versions of <tt>time_get</tt> and
10377 <tt>time_get_byname</tt> are listed incorrectly in table 52,
10378 required instantiations.  In both cases the second template
10379 parameter is given as OutputIterator.  It should instead be
10380 InputIterator, since these are input facets.</p>
10381 <p><b>Proposed resolution:</b></p>
10382 <p>
10383 In table 52, required instantiations, in
10384 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>, change</p>
10385 <pre>    time_get&lt;wchar_t, OutputIterator&gt;
10386     time_get_byname&lt;wchar_t, OutputIterator&gt;
10387 </pre>
10388 <p>to</p>
10389 <pre>    time_get&lt;wchar_t, InputIterator&gt;
10390     time_get_byname&lt;wchar_t, InputIterator&gt;
10391 </pre>
10392
10393 <p><i>[Redmond: Very minor change in proposed resolution.  Original had
10394 a typo, wchart instead of wchar_t.]</i></p>
10395
10396 <hr>
10397 <a name="328"><h3>328.&nbsp;Bad sprintf format modifier in money_put&lt;&gt;::do_put()</h3></a><p><b>Section:</b>&nbsp;22.2.6.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.money.put.virtuals"> [lib.locale.money.put.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;07 Jul 2001</p>
10398 <p>The sprintf format string , "%.01f" (that's the digit one), in the
10399 description of the do_put() member functions of the money_put facet in
10400 22.2.6.2.2, p1 is incorrect. First, the f format specifier is wrong
10401 for values of type long double, and second, the precision of 01
10402 doesn't seem to make sense. What was most likely intended was
10403 "%.0Lf"., that is a precision of zero followed by the L length
10404 modifier.</p>
10405 <p><b>Proposed resolution:</b></p>
10406 <p>Change the format string to "%.0Lf".</p>
10407 <p><b>Rationale:</b></p>
10408 <p>Fixes an obvious typo</p>
10409 <hr>
10410 <a name="329"><h3>329.&nbsp;vector capacity, reserve and reallocation</h3></a><p><b>Section:</b>&nbsp;23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.priority.queue"> [lib.priority.queue]</a>, 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Anthony Williams&nbsp; <b>Date:</b>&nbsp;13 Jul 2001</p>
10411 <p>
10412 There is an apparent contradiction about which circumstances can cause
10413 a reallocation of a vector in Section 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.priority.queue"> [lib.priority.queue]</a> and
10414 section 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a>.
10415 </p>
10416
10417 <p>23.2.4.2p5 says:</p>
10418 <blockquote>
10419 Notes: Reallocation invalidates all the references, pointers, and iterators
10420 referring to the elements in the sequence. It is guaranteed that no
10421 reallocation takes place during insertions that happen after a call to
10422 reserve() until the time when an insertion would make the size of the vector
10423 greater than the size specified in the most recent call to reserve().
10424 </blockquote>
10425
10426 <p>Which implies if I do</p>
10427
10428 <pre>  std::vector&lt;int&gt; vec;
10429   vec.reserve(23);
10430   vec.reserve(0);
10431   vec.insert(vec.end(),1);
10432 </pre>
10433
10434 <p>then the implementation may reallocate the vector for the insert,
10435 as the size specified in the previous call to reserve was zero.</p>
10436
10437 <p>However, the previous paragraphs (23.2.4.2, p1-2) state:</p>
10438 <blockquote>
10439 <p>
10440 (capacity) Returns: The total number of elements the vector
10441 can hold without requiring reallocation
10442 </p>
10443 <p>
10444 ...After reserve(), capacity() is greater or equal to the
10445 argument of reserve if reallocation happens; and equal to the previous value
10446 of capacity() otherwise...
10447 </p>
10448 </blockquote>
10449
10450 <p>
10451 This implies that vec.capacity() is still 23, and so the insert()
10452 should not require a reallocation, as vec.size() is 0. This is backed
10453 up by 23.2.4.3p1:
10454 </p>
10455 <blockquote>
10456 (insert) Notes: Causes reallocation if the new size is greater than the old
10457 capacity.
10458 </blockquote>
10459
10460 <p>
10461 Though this doesn't rule out reallocation if the new size is less
10462 than the old capacity, I think the intent is clear.
10463 </p>
10464
10465 <p><b>Proposed resolution:</b></p>
10466 <p>Change the wording of 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.priority.queue"> [lib.priority.queue]</a> paragraph 5 to:</p>
10467
10468 <blockquote>
10469 Notes: Reallocation invalidates all the references, pointers, and
10470 iterators referring to the elements in the sequence. It is guaranteed
10471 that no reallocation takes place during insertions that happen after a
10472 call to reserve() until the time when an insertion would make the size
10473 of the vector greater than the value of capacity().
10474 </blockquote>
10475
10476 <p><i>[Redmond: original proposed resolution was modified slightly.  In
10477 the original, the guarantee was that there would be no reallocation
10478 until the size would be greater than the value of capacity() after the
10479 most recent call to reserve().  The LWG did not believe that the
10480 "after the most recent call to reserve()" added any useful
10481 information.]</i></p>
10482
10483 <p><b>Rationale:</b></p>
10484 <p>There was general agreement that, when reserve() is called twice in
10485 succession and the argument to the second invocation is smaller than
10486 the argument to the first, the intent was for the second invocation to
10487 have no effect.  Wording implying that such cases have an effect on
10488 reallocation guarantees was inadvertant.</p>
10489 <hr>
10490 <a name="331"><h3>331.&nbsp;bad declaration of destructor for ios_base::failure</h3></a><p><b>Section:</b>&nbsp;27.4.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;PremAnand M. Rao&nbsp; <b>Date:</b>&nbsp;23 Aug 2001</p>
10491 <p>
10492 With the change in 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> to state
10493    "An implementation may strengthen the exception-specification for a
10494     non-virtual function by removing listed exceptions."
10495 (issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#119">119</a>)
10496 and the following declaration of ~failure() in ios_base::failure
10497 </p>
10498 <pre>    namespace std {
10499        class ios_base::failure : public exception {
10500        public:
10501            ...
10502            virtual ~failure();
10503            ...
10504        };
10505      }
10506 </pre>
10507 <p>the class failure cannot be implemented since in 18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.type.info"> [lib.type.info]</a> the destructor of class exception has an empty
10508 exception specification:</p>
10509 <pre>    namespace std {
10510        class exception {
10511        public:
10512          ...
10513          virtual ~exception() throw();
10514          ...
10515        };
10516      }
10517 </pre>
10518 <p><b>Proposed resolution:</b></p>
10519 <p>Remove the declaration of ~failure().</p>
10520 <p><b>Rationale:</b></p>
10521 <p>The proposed resolution is consistent with the way that destructors
10522 of other classes derived from <tt>exception</tt> are handled.</p>
10523 <hr>
10524 <a name="333"><h3>333.&nbsp;does endl imply synchronization with the device?</h3></a><p><b>Section:</b>&nbsp;27.6.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.manip"> [lib.ostream.manip]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;PremAnand M. Rao&nbsp; <b>Date:</b>&nbsp;27 Aug 2001</p>
10525 <p>A footnote in 27.6.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.manip"> [lib.ostream.manip]</a> states:</p>
10526 <blockquote>
10527     [Footnote: The effect of executing cout &lt;&lt; endl is to insert a
10528      newline character in the output sequence controlled by cout, then
10529      synchronize it with any external file with which it might be
10530      associated. --- end foonote]
10531 </blockquote>
10532
10533 <p>
10534 Does the term "file" here refer to the external device?
10535 This leads to some implementation ambiguity on systems with fully
10536 buffered files where a newline does not cause a flush to the device.
10537 </p>
10538
10539 <p>
10540 Choosing to sync with the device leads to significant performance
10541 penalties for each call to endl, while not sync-ing leads to
10542 errors under special circumstances.
10543 </p>
10544
10545 <p>
10546 I could not find any other statement that explicitly defined
10547 the behavior one way or the other.
10548 </p>
10549 <p><b>Proposed resolution:</b></p>
10550 <p>Remove footnote 300 from section 27.6.2.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.manip"> [lib.ostream.manip]</a>.</p>
10551 <p><b>Rationale:</b></p>
10552 <p>We already have normative text saying what <tt>endl</tt> does: it
10553 inserts a newline character and calls <tt>flush</tt>.  This footnote
10554 is at best redundant, at worst (as this issue says) misleading,
10555 because it appears to make promises about what <tt>flush</tt>
10556 does.</p>
10557 <hr>
10558 <a name="334"><h3>334.&nbsp;map::operator[] specification forces inefficient implementation</h3></a><p><b>Section:</b>&nbsp;23.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map.access"> [lib.map.access]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andrea Griffini&nbsp; <b>Date:</b>&nbsp;02 Sep 2001</p>
10559 <p>
10560 The current standard describes map::operator[] using a
10561 code example. That code example is however quite
10562 inefficient because it requires several useless copies
10563 of both the passed key_type value and of default
10564 constructed mapped_type instances.
10565 My opinion is that was not meant by the comitee to
10566 require all those temporary copies.
10567 </p>
10568
10569 <p>Currently map::operator[] behaviour is specified as: </p>
10570 <pre>  Returns:
10571     (*((insert(make_pair(x, T()))).first)).second.
10572 </pre>
10573
10574 <p>
10575 This specification however uses make_pair that is a
10576 template function of which parameters in this case
10577 will be deduced being of type const key_type&amp; and
10578 const T&amp;. This will create a pair&lt;key_type,T&gt; that
10579 isn't the correct type expected by map::insert so
10580 another copy will be required using the template
10581 conversion constructor available in pair to build
10582 the required pair&lt;const key_type,T&gt; instance.
10583 </p>
10584
10585 <p>If we consider calling of key_type copy constructor
10586 and mapped_type default constructor and copy
10587 constructor as observable behaviour (as I think we
10588 should) then the standard is in this place requiring
10589 two copies of a key_type element plus a default
10590 construction and two copy construction of a mapped_type
10591 (supposing the addressed element is already present
10592 in the map; otherwise at least another copy
10593 construction for each type).
10594 </p>
10595
10596 <p>A simple (half) solution would be replacing the description with:</p>
10597 <pre>  Returns:
10598     (*((insert(value_type(x, T()))).first)).second.
10599 </pre>
10600
10601 <p>This will remove the wrong typed pair construction that
10602 requires one extra copy of both key and value.</p>
10603
10604 <p>However still the using of map::insert requires temporary
10605 objects while the operation, from a logical point of view,
10606 doesn't require any. </p>
10607
10608 <p>I think that a better solution would be leaving free an
10609 implementer to use a different approach than map::insert
10610 that, because of its interface, forces default constructed
10611 temporaries and copies in this case.
10612 The best solution in my opinion would be just requiring
10613 map::operator[] to return a reference to the mapped_type
10614 part of the contained element creating a default element
10615 with the specified key if no such an element is already
10616 present in the container. Also a logarithmic complexity
10617 requirement should be specified for the operation.
10618 </p>
10619
10620 <p>
10621 This would allow library implementers to write alternative
10622 implementations not using map::insert and reaching optimal
10623 performance in both cases of the addressed element being
10624 present or absent from the map (no temporaries at all and
10625 just the creation of a new pair inside the container if
10626 the element isn't present).
10627 Some implementer has already taken this option but I think
10628 that the current wording of the standard rules that as
10629 non-conforming.
10630 </p>
10631
10632 <p><b>Proposed resolution:</b></p>
10633
10634 <p>
10635 Replace 23.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map.access"> [lib.map.access]</a> paragraph 1 with
10636 </p>
10637 <blockquote>
10638 <p>
10639 -1- Effects:  If there is no key equivalent to x in the map, inserts
10640 value_type(x, T()) into the map.
10641 </p>
10642 <p>
10643 -2- Returns: A reference to the mapped_type corresponding to x in *this.
10644 </p>
10645 <p>
10646 -3- Complexity: logarithmic.
10647 </p>
10648 </blockquote>
10649
10650 <p><i>[This is the second option mentioned above.  Howard provided
10651 wording.  We may also wish to have a blanket statement somewhere in
10652 clause 17 saying that we do not intend the semantics of sample code
10653 fragments to be interpreted as specifing exactly how many copies are
10654 made.  See issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#98">98</a> for a similar problem.]</i></p>
10655
10656 <p><b>Rationale:</b></p>
10657 <p>
10658 This is the second solution described above; as noted, it is
10659 consistent with existing practice.
10660 </p>
10661
10662 <p>Note that we now need to specify the complexity explicitly, because
10663 we are no longer defining <tt>operator[]</tt> in terms of
10664 <tt>insert</tt>.</p>
10665 <hr>
10666 <a name="335"><h3>335.&nbsp;minor issue with char_traits, table 37</h3></a><p><b>Section:</b>&nbsp;21.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits.require"> [lib.char.traits.require]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;06 Sep 2001</p>
10667 <p>
10668 Table 37, in 21.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits.require"> [lib.char.traits.require]</a>, descibes char_traits::assign
10669 as:
10670 </p>
10671 <pre>  X::assign(c,d)   assigns c = d.
10672 </pre>
10673
10674 <p>And para 1 says:</p>
10675
10676 <blockquote>
10677  [...] c and d denote values of type CharT [...]
10678 </blockquote>
10679
10680 <p>
10681 Naturally, if c and d are <i>values</i>, then the assignment is
10682 (effectively) meaningless. It's clearly intended that (in the case of
10683 assign, at least), 'c' is intended to be a reference type.
10684 </p>
10685
10686 <p>I did a quick survey of the four implementations I happened to have
10687 lying around, and sure enough they all have signatures:</p>
10688 <pre>    assign( charT&amp;, const charT&amp; );
10689 </pre>
10690
10691 <p>(or the equivalent). It's also described this way in Nico's book.
10692 (Not to mention the synopses of char_traits&lt;char&gt; in 21.1.3.1
10693 and char_traits&lt;wchar_t&gt; in 21.1.3.2...)
10694 </p>
10695 <p><b>Proposed resolution:</b></p>
10696 <p>Add the following to 21.1.1 para 1:</p>
10697 <blockquote>
10698  r denotes an lvalue of CharT
10699 </blockquote>
10700
10701 <p>and change the description of assign in the table to:</p>
10702 <pre>  X::assign(r,d)   assigns r = d
10703 </pre>
10704 <hr>
10705 <a name="336"><h3>336.&nbsp;Clause 17 lack of references to deprecated headers</h3></a><p><b>Section:</b>&nbsp;17 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.library"> [lib.library]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Detlef Vollmann&nbsp; <b>Date:</b>&nbsp;05 Sep 2001</p>
10706 <p>From c++std-edit-873:</p>
10707
10708 <p>17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a>, Table 11.  In this table, the header
10709 &lt;strstream&gt; is missing.</p>
10710
10711 <p>This shows a general problem: The whole clause 17 refers quite
10712 often to clauses 18 through 27, but D.7 is also a part of the standard
10713 library (though a deprecated one).</p>
10714
10715 <p><b>Proposed resolution:</b></p>
10716
10717 <p>To 17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a> Table 11, C++ Library Headers, add
10718 "&lt;strstream&gt;".</p>
10719
10720 <p>In the following places, change "clauses 17 through 27" to "clauses
10721 17 through 27 and Annex D":</p>
10722
10723 <ul>
10724 <li>1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/intro.html#intro.refs"> [intro.refs]</a> Normative references/1/footnote 1</li>
10725 <li>1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/intro.html#intro.defs"> [intro.defs]</a> Definitions/1</li>
10726 <li>7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/dcl.html#dcl.dcl"> [dcl.dcl]</a> Library introduction/9</li>
10727 <li>17.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.description"> [lib.description]</a> Method of description (Informative)/1</li>
10728 <li>17.3.2.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.character.seq"> [lib.character.seq]</a> Character sequences/1/bullet 2</li>
10729 <li>17.3.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.functions.within.classes"> [lib.functions.within.classes]</a> Functions within classes/1</li>
10730 <li>17.3.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.objects.within.classes"> [lib.objects.within.classes]</a> Private members/1/(2 places)</li>
10731 <li>17.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.requirements"> [lib.requirements]</a> Library-wide requirements/1</li>
10732 <li>17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a> Headers/4</li>
10733 <li>17.4.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a> Replacement functions/1</li>
10734 <li>17.4.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.global.functions"> [lib.global.functions]</a> Global or non-member functions/2</li>
10735 <li>17.4.4.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.protection.within.classes"> [lib.protection.within.classes]</a> Protection within classes/1</li>
10736 </ul>
10737
10738
10739 <hr>
10740 <a name="337"><h3>337.&nbsp;replace_copy_if's template parameter should be InputIterator</h3></a><p><b>Section:</b>&nbsp;25.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Detlef Vollmann&nbsp; <b>Date:</b>&nbsp;07 Sep 2001</p>
10741 <p>From c++std-edit-876:</p>
10742
10743 <p>
10744 In section 25.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.replace"> [lib.alg.replace]</a> before p4: The name of the first
10745 parameter of template replace_copy_if should be "InputIterator"
10746 instead of "Iterator".  According to 17.3.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.type.descriptions"> [lib.type.descriptions]</a> p1 the
10747 parameter name conveys real normative meaning.
10748 </p>
10749 <p><b>Proposed resolution:</b></p>
10750 <p>Change <tt>Iterator</tt> to <tt>InputIterator</tt>.</p>
10751 <hr>
10752 <a name="338"><h3>338.&nbsp; is whitespace allowed between `-' and a digit?</h3></a><p><b>Section:</b>&nbsp;22.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.categories"> [lib.locale.categories]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;17 Sep 2001</p>
10753 <p>
10754 From Stage 2 processing in 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>, p8 and 9 (the
10755 original text or the text corrected by the proposed resolution of
10756 issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#221">221</a>) it seems clear that no whitespace is allowed
10757 within a number, but 22.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.numpunct"> [lib.locale.numpunct]</a>, p2, which gives the
10758 format for integer and floating point values, says that whitespace is
10759 optional between a plusminus and a sign.
10760 </p>
10761
10762 <p>
10763 The text needs to be clarified to either consistently allow or
10764 disallow whitespace between a plusminus and a sign. It might be
10765 worthwhile to consider the fact that the C library stdio facility does
10766 not permit whitespace embedded in numbers and neither does the C or
10767 C++ core language (the syntax of integer-literals is given in 2.13.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lex.html#lex.icon"> [lex.icon]</a>, that of floating-point-literals in 2.13.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lex.html#lex.fcon"> [lex.fcon]</a> of the C++ standard).
10768 </p>
10769 <p><b>Proposed resolution:</b></p>
10770 <p>Change the first part of 22.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.numpunct"> [lib.locale.numpunct]</a> paragraph 2 from:</p>
10771 <blockquote>
10772 <p>
10773 The syntax for number formats is as follows, where <tt>digit</tt>
10774 represents the radix set specified by the <tt>fmtflags</tt> argument
10775 value, <tt>whitespace</tt> is as determined by the facet
10776 <tt>ctype&lt;charT&gt;</tt> (22.2.1.1), and <tt>thousands-sep</tt> and
10777 <tt>decimal-point</tt> are the results of corresponding
10778 <tt>numpunct&lt;charT&gt;</tt> members.  Integer values have the
10779 format:
10780 </p>
10781 <pre>  integer   ::= [sign] units
10782   sign      ::= plusminus [whitespace]
10783   plusminus ::= '+' | '-'
10784   units     ::= digits [thousands-sep units]
10785   digits    ::= digit [digits]
10786 </pre>
10787 </blockquote>
10788 <p>to:</p>
10789 <blockquote>
10790 <p>
10791 The syntax for number formats is as follows, where <tt>digit</tt>
10792 represents the radix set specified by the <tt>fmtflags</tt> argument
10793 value, and <tt>thousands-sep</tt> and <tt>decimal-point</tt> are the
10794 results of corresponding <tt>numpunct&lt;charT&gt;</tt> members.
10795 Integer values have the format:
10796 </p>
10797 <pre>  integer   ::= [sign] units
10798   sign      ::= plusminus
10799   plusminus ::= '+' | '-'
10800   units     ::= digits [thousands-sep units]
10801   digits    ::= digit [digits]
10802 </pre>
10803 </blockquote>
10804 <p><b>Rationale:</b></p>
10805 <p>It's not clear whether the format described in 22.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.numpunct"> [lib.locale.numpunct]</a> paragraph 2 has any normative weight: nothing in the
10806 standard says how, or whether, it's used.  However, there's no reason
10807 for it to differ gratuitously from the very specific description of
10808 numeric processing in 22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>.  The proposed
10809 resolution removes all mention of "whitespace" from that format.</p>
10810 <hr>
10811 <a name="339"><h3>339.&nbsp;definition of bitmask type restricted to clause 27</h3></a><p><b>Section:</b>&nbsp;22.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.category.ctype"> [lib.category.ctype]</a>, 17.3.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;17 September 2001</p>
10812 <p>
10813 The ctype_category::mask type is declared to be an enum 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> with p1 then stating that it is a bitmask type, most
10814 likely referring to the definition of bitmask type in 17.3.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a>, p1. However, the said definition only applies to
10815 clause 27, making the reference in 22.2.1 somewhat dubious.
10816 </p>
10817 <p><b>Proposed resolution:</b></p>
10818 <p>Clarify 17.3.2.1.2, p1 by changing the current text from</p>
10819     <blockquote>
10820     Several types defined in clause 27 are bitmask types. Each bitmask type
10821     can be implemented as an enumerated type that overloads certain operators,
10822     as an integer type, or as a bitset (23.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.template.bitset"> [lib.template.bitset]</a>).
10823     </blockquote>
10824 <p>to read</p>
10825     <blockquote>
10826     Several types defined in clauses lib.language.support through
10827     lib.input.output and Annex D are bitmask types. Each bitmask type can
10828     be implemented as an enumerated type that overloads certain operators,
10829     as an integer  type, or as a bitset (lib.template.bitset).
10830     </blockquote>
10831
10832 <p>
10833 Additionally, change the definition in 22.2.1 to adopt the same
10834 convention as in clause 27 by replacing the existing text with the
10835 following (note, in particluar, the cross-reference to 17.3.2.1.2 in
10836 22.2.1, p1):
10837 </p>
10838
10839 <blockquote>
10840 <p>22.2.1 The ctype category [lib.category.ctype]</p>
10841 <pre>namespace std {
10842     class ctype_base {
10843     public:
10844         typedef <b><i>T</i></b> mask;
10845
10846         // numeric values are for exposition only.
10847         static const mask space = 1 &lt;&lt; 0;
10848         static const mask print = 1 &lt;&lt; 1;
10849         static const mask cntrl = 1 &lt;&lt; 2;
10850         static const mask upper = 1 &lt;&lt; 3;
10851         static const mask lower = 1 &lt;&lt; 4;
10852         static const mask alpha = 1 &lt;&lt; 5;
10853         static const mask digit = 1 &lt;&lt; 6;
10854         static const mask punct = 1 &lt;&lt; 7;
10855         static const mask xdigit = 1 &lt;&lt; 8;
10856         static const mask alnum = alpha | digit;
10857         static const mask graph = alnum | punct;
10858     };
10859 }
10860 </pre>
10861
10862 <p>The type <tt>mask</tt> is a bitmask type (17.3.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a>).</p>
10863 </blockquote>
10864
10865 <p><i>[Curaçao: The LWG notes that T above should be bold-italics to be
10866 consistent with the rest of the standard.]</i></p>
10867
10868 <hr>
10869 <a name="340"><h3>340.&nbsp;interpretation of <tt>has_facet&lt;Facet&gt;(loc)</tt>
10870 </h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2001</p>
10871 <p>
10872 It's unclear whether 22.1.1.1.1, p3 says that
10873 <tt>has_facet&lt;Facet&gt;(loc)</tt> returns true for any <tt>Facet</tt>
10874 from Table 51 or whether it includes Table 52 as well:
10875 </p>
10876
10877 <blockquote>
10878 For any locale <tt>loc</tt> either constructed, or returned by
10879 locale::classic(), and any facet <tt>Facet</tt> that is a member of a
10880 standard category, <tt>has_facet&lt;Facet&gt;(loc)</tt> is true. Each
10881 locale member function which takes a <tt>locale::category</tt>
10882 argument operates on the corresponding set of facets.
10883 </blockquote>
10884
10885 <p>
10886 It seems that it comes down to which facets are considered to be members of a
10887 standard category. Intuitively, I would classify all the facets in Table 52 as
10888 members of their respective standard categories, but there are an unbounded set
10889 of them...
10890 </p>
10891
10892 <p>
10893 The paragraph implies that, for instance, <tt>has_facet&lt;num_put&lt;C,
10894 OutputIterator&gt; &gt;(loc)</tt> must always return true. I don't think that's
10895 possible. If it were, then <tt>use_facet&lt;num_put&lt;C, OutputIterator&gt;
10896 &gt;(loc)</tt> would have to return a reference to a distinct object for each
10897 valid specialization of <tt>num_put&lt;C, OutputIteratory&gt;</tt>, which is
10898 clearly impossible.
10899 </p>
10900
10901 <p>
10902 On the other hand, if none of the facets in Table 52 is a member of a standard
10903 category then none of the locale member functions that operate on entire
10904 categories of facets will work properly.
10905 </p>
10906
10907 <p>
10908 It seems that what p3 should mention that it's required (permitted?)
10909 to hold only for specializations of <tt>Facet</tt> from Table 52 on
10910 <tt>C</tt> from the set { <tt>char</tt>, <tt>wchar_t</tt> }, and
10911 <tt>InputIterator</tt> and <tt>OutputIterator</tt> from the set of
10912 {
10913 {i,o}<tt>streambuf_iterator</tt>&lt;{<tt>char</tt>,<tt>wchar_t</tt>}<tt>&gt;</tt>
10914 }.
10915 </p>
10916 <p><b>Proposed resolution:</b></p>
10917 <p>In 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 3, change
10918 "that is a member of a standard category" to "shown in Table 51".</p>
10919 <p><b>Rationale:</b></p>
10920 <p>The facets in Table 52 are an unbounded set.  Locales should not be
10921 required to contain an infinite number of facets.</p>
10922
10923 <p>It's not necessary to talk about which values of InputIterator and
10924 OutputIterator must be supported.  Table 51 already contains a
10925 complete list of the ones we need.</p>
10926 <hr>
10927 <a name="341"><h3>341.&nbsp;Vector reallocation and swap</h3></a><p><b>Section:</b>&nbsp;23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.priority.queue"> [lib.priority.queue]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Anthony Williams&nbsp; <b>Date:</b>&nbsp;27 Sep 2001</p>
10928 <p>It is a common idiom to reduce the capacity of a vector by swapping it with
10929 an empty one:</p>
10930 <pre>  std::vector&lt;SomeType&gt; vec;
10931   // fill vec with data
10932   std::vector&lt;SomeType&gt;().swap(vec);
10933   // vec is now empty, with minimal capacity
10934 </pre>
10935
10936 <p>However, the wording of 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.priority.queue"> [lib.priority.queue]</a>paragraph 5 prevents
10937 the capacity of a vector being reduced, following a call to
10938 reserve(). This invalidates the idiom, as swap() is thus prevented
10939 from reducing the capacity. The proposed wording for issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#329">329</a> does not affect this.  Consequently, the example above
10940 requires the temporary to be expanded to cater for the contents of
10941 vec, and the contents be copied across. This is a linear-time
10942 operation.</p>
10943
10944 <p>However, the container requirements state that swap must have constant
10945 complexity (23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> note to table 65).</p>
10946
10947 <p>This is an important issue, as reallocation affects the validity of
10948 references and iterators.</p>
10949
10950 <p>If the wording of 23.2.4.2p5 is taken to be the desired intent, then
10951 references and iterators remain valid after a call to swap, if they refer to
10952 an element before the new end() of the vector into which they originally
10953 pointed, in which case they refer to the element at the same index position.
10954 Iterators and references that referred to an element whose index position
10955 was beyond the new end of the vector are invalidated.</p>
10956
10957 <p>If the note to table 65 is taken as the desired intent, then there are two
10958 possibilities with regard to iterators and references:</p>
10959
10960 <ol>
10961 <li>All Iterators and references into both vectors are invalidated.</li>
10962 <li>Iterators and references into either vector remain valid, and remain
10963 pointing to the same element. Consequently iterators and references that
10964 referred to one vector now refer to the other, and vice-versa.</li>
10965 </ol>
10966 <p><b>Proposed resolution:</b></p>
10967 <p>Add a new paragraph after 23.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.priority.queue"> [lib.priority.queue]</a> paragraph 5:</p>
10968 <blockquote>
10969 <pre>  void swap(vector&lt;T,Allocator&gt;&amp; x);
10970 </pre>
10971 <p><b>Effects:</b> Exchanges the contents and capacity() of <tt>*this</tt>
10972 with that of <tt>x</tt>.</p>
10973 <p><b>Complexity:</b> Constant time.</p>
10974 </blockquote>
10975
10976 <p><i>[This solves the problem reported for this issue.  We may also
10977 have a problem with a circular definition of swap() for other
10978 containers.]</i></p>
10979
10980 <p><b>Rationale:</b></p>
10981 <p>
10982 swap should be constant time.  The clear intent is that it should just
10983 do pointer twiddling, and that it should exchange all properties of
10984 the two vectors, including their reallocation guarantees.
10985 </p>
10986 <hr>
10987 <a name="345"><h3>345.&nbsp;type tm in &lt;cwchar&gt;</h3></a><p><b>Section:</b>&nbsp;21.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.c.strings"> [lib.c.strings]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Clark Nelson&nbsp; <b>Date:</b>&nbsp;19 Oct 2001</p>
10988 <p>
10989 C99, and presumably amendment 1 to C90, specify that &lt;wchar.h&gt;
10990 declares struct tm as an incomplete type. However, table 48 in 21.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.c.strings"> [lib.c.strings]</a> does not mention the type tm as being declared in
10991 &lt;cwchar&gt;. Is this omission intentional or accidental?
10992 </p>
10993 <p><b>Proposed resolution:</b></p>
10994 <p>In section 21.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.c.strings"> [lib.c.strings]</a>, add "tm" to table 48.</p>
10995 <hr>
10996 <a name="346"></a><h3><a name="346">346.&nbsp;Some iterator member functions should be const</a></h3><p><b>Section:</b>&nbsp;24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Jeremy Siek&nbsp; <b>Date:</b>&nbsp;20 Oct 2001</p>
10997 <p>Iterator member functions and operators that do not change the state
10998 of the iterator should be defined as const member functions or as
10999 functions that take iterators either by const reference or by
11000 value. The standard does not explicitly state which functions should
11001 be const.  Since this a fairly common mistake, the following changes
11002 are suggested to make this explicit.</p>
11003
11004 <p>The tables almost indicate constness properly through naming: r
11005 for non-const and a,b for const iterators. The following changes
11006 make this more explicit and also fix a couple problems.</p>
11007 <p><b>Proposed resolution:</b></p>
11008 <p>In 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a> Change the first section of p9 from
11009 "In the following sections, a and b denote values of X..." to
11010 "In the following sections, a and b denote values of type const X...".</p>
11011
11012 <p>In Table 73, change</p>
11013 <pre>    a-&gt;m   U&amp;         ...
11014 </pre>
11015
11016 <p>to</p>
11017
11018 <pre>    a-&gt;m   const U&amp;   ...
11019     r-&gt;m   U&amp;         ...
11020 </pre>
11021
11022 <p>In Table 73 expression column, change</p>
11023
11024 <pre>    *a = t
11025 </pre>
11026
11027 <p>to</p>
11028
11029 <pre>    *r = t
11030 </pre>
11031
11032 <p><i>[Redmond: The container requirements should be reviewed to see if
11033 the same problem appears there.]</i></p>
11034
11035 <hr>
11036 <a name="347"><h3>347.&nbsp;locale::category and bitmask requirements</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;P.J. Plauger, Nathan Myers&nbsp; <b>Date:</b>&nbsp;23 Oct 2001</p>
11037 <p>
11038 In 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 1, the category members
11039 are described as bitmask elements.  In fact, the bitmask requirements
11040 in 17.3.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.bitmask.types"> [lib.bitmask.types]</a> don't seem quite right: <tt>none</tt>
11041 and <tt>all</tt> are bitmask constants, not bitmask elements.</p>
11042
11043 <p>In particular, the requirements for <tt>none</tt> interact poorly
11044 with the requirement that the LC_* constants from the C library must
11045 be recognizable as C++ locale category constants.  LC_* values should
11046 not be mixed with these values to make category values.</p>
11047
11048 <p>We have two options for the proposed resolution.  Informally:
11049 option 1 removes the requirement that LC_* values be recognized as
11050 category arguments.  Option 2 changes the category type so that this
11051 requirement is implementable, by allowing <tt>none</tt> to be some
11052 value such as 0x1000 instead of 0.</p>
11053
11054 <p>Nathan writes: "I believe my proposed resolution [Option 2] merely
11055 re-expresses the status quo more clearly, without introducing any
11056 changes beyond resolving the DR.</p>
11057
11058 <p><b>Proposed resolution:</b></p>
11059 <p>Replace the first two paragraphs of 22.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.types"> [lib.locale.types]</a> with:</p>
11060 <blockquote>
11061 <pre>    typedef int category;
11062 </pre>
11063
11064 <p>Valid category values include the <tt>locale</tt> member bitmask
11065 elements <tt>collate</tt>, <tt>ctype</tt>, <tt>monetary</tt>,
11066 <tt>numeric</tt>, <tt>time</tt>, and <tt>messages</tt>, each of which
11067 represents a single locale category. In addition, <tt>locale</tt> member
11068 bitmask constant <tt>none</tt> is defined as zero and represents no
11069 category. And locale member bitmask constant <tt>all</tt> is defined such that
11070 the expression</p>
11071 <pre>    (collate | ctype | monetary | numeric | time | messages | all) == all
11072 </pre>
11073 <p>
11074 is <tt>true</tt>, and represents the union of all categories.  Further
11075 the expression <tt>(X | Y)</tt>, where <tt>X</tt> and <tt>Y</tt> each
11076 represent a single category, represents the union of the two
11077 categories.
11078 </p>
11079
11080 <p>
11081 <tt>locale</tt> member functions expecting a <tt>category</tt>
11082 argument require one of the <tt>category</tt> values defined above, or
11083 the union of two or more such values. Such a <tt>category</tt>
11084 argument identifies a set of locale categories. Each locale category,
11085 in turn, identifies a set of locale facets, including at least those
11086 shown in Table 51:
11087 </p>
11088 </blockquote>
11089 <p><i>[Curaçao: need input from locale experts.]</i></p>
11090
11091 <p><b>Rationale:</b></p>
11092
11093 <p>The LWG considered, and rejected, an alternate proposal (described
11094   as "Option 2" in the discussion).  The main reason for rejecting it
11095   was that library implementors were concerened about implementation
11096   difficult, given that getting a C++ library to work smoothly with a
11097   separately written C library is already a delicate business.  Some
11098   library implementers were also concerned about the issue of adding
11099   extra locale categories.</p>
11100
11101 <blockquote>
11102 <p><b>Option 2:</b> <br>
11103 Replace the first paragraph of 22.1.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.types"> [lib.locale.types]</a> with:</p>
11104 <blockquote>
11105 <p>
11106 Valid category values include the enumerated values.  In addition, the
11107 result of applying commutative operators | and &amp; to any two valid
11108 values is valid, and results in the setwise union and intersection,
11109 respectively, of the argument categories.  The values <tt>all</tt> and
11110 <tt>none</tt> are defined such that for any valid value <tt>cat</tt>, the
11111 expressions <tt>(cat | all == all)</tt>, <tt>(cat &amp; all == cat)</tt>,
11112 <tt>(cat | none == cat)</tt> and <tt>(cat &amp; none == none)</tt> are
11113 true.  For non-equal values <tt>cat1</tt> and <tt>cat2</tt> of the
11114 remaining enumerated values, <tt>(cat1 &amp; cat2 == none)</tt> is true.
11115 For any valid categories <tt>cat1</tt> and <tt>cat2</tt>, the result
11116 of <tt>(cat1 &amp; ~cat2)</tt> is valid, and equals the setwise union of
11117 those categories found in <tt>cat1</tt> but not found in <tt>cat2</tt>.
11118 [Footnote: it is not required that <tt>all</tt> equal the setwise union
11119 of the other enumerated values; implementations may add extra categories.]
11120 </p>
11121 </blockquote>
11122 </blockquote>
11123 <hr>
11124 <a name="349"><h3>349.&nbsp;Minor typographical error in ostream_iterator</h3></a><p><b>Section:</b>&nbsp;24.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.ostream.iterator"> [lib.ostream.iterator]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andy Sawyer&nbsp; <b>Date:</b>&nbsp;24 Oct 2001</p>
11125 <p>24.5.2 [lib.ostream.iterator] states:</p>
11126 <pre>    [...]
11127
11128     private:
11129     // basic_ostream&lt;charT,traits&gt;* out_stream; exposition only
11130     // const char* delim; exposition only
11131 </pre>
11132
11133 <p>Whilst it's clearly marked "exposition only", I suspect 'delim'
11134 should be of type 'const charT*'.</p>
11135 <p><b>Proposed resolution:</b></p>
11136 <p>
11137 In 24.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.ostream.iterator"> [lib.ostream.iterator]</a>, replace <tt>const char* delim</tt> with
11138 <tt>const charT* delim</tt>.
11139 </p>
11140 <hr>
11141 <a name="352"><h3>352.&nbsp;missing fpos requirements</h3></a><p><b>Section:</b>&nbsp;21.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits.typedefs"> [lib.char.traits.typedefs]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;2 Dec 2001</p>
11142 <p>
11143 <i>(1)</i>
11144 There are no requirements on the <tt>stateT</tt> template parameter of
11145 <tt>fpos</tt> listed in 27.4.3. The interface appears to require that
11146 the type be at least Assignable and CopyConstructible (27.4.3.1, p1),
11147 and I think also DefaultConstructible (to implement the operations in
11148 Table 88).
11149 </p>
11150 <p>
11151 21.1.2, p3, however, only requires that
11152 <tt>char_traits&lt;charT&gt;::state_type</tt> meet the requirements of
11153 CopyConstructible types.
11154 </p>
11155 <p>
11156 <i>(2)</i>
11157 Additionally, the <tt>stateT</tt> template argument has no
11158 corresponding typedef in fpos which might make it difficult to use in
11159 generic code.
11160 </p>
11161 <p><b>Proposed resolution:</b></p>
11162 <p>
11163 Modify 21.1.2, p4 from
11164 </p>
11165 <p>
11166     Requires: <tt>state_type</tt> shall meet the requirements of
11167               CopyConstructible types (20.1.3).
11168 </p>
11169 <p>
11170     Requires: state_type shall meet the requirements of Assignable
11171               (23.1, p4), CopyConstructible (20.1.3), and
11172               DefaultConstructible  (20.1.4) types.
11173 </p>
11174
11175 <p><b>Rationale:</b></p>
11176 <p>The LWG feels this is two issues, as indicated above. The first is
11177 a defect---std::basic_fstream is unimplementable without these
11178 additional requirements---and the proposed resolution fixes it.  The
11179 second is questionable; who would use that typedef?  The class
11180 template fpos is used only in a very few places, all of which know the
11181 state type already.  Unless motivation is provided, the second should
11182 be considered NAD.</p>
11183 <hr>
11184 <a name="354"><h3>354.&nbsp;Associative container lower/upper bound requirements</h3></a><p><b>Section:</b>&nbsp;23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Hans Aberg&nbsp; <b>Date:</b>&nbsp;17 Dec 2001</p>
11185 <p>
11186 Discussions in the thread "Associative container lower/upper bound
11187 requirements" on comp.std.c++ suggests that there is a defect in the
11188 C++ standard, Table 69 of section 23.1.2, "Associative containers",
11189 [lib.associative.reqmts].  It currently says:</p>
11190
11191 <blockquote>
11192 <p>
11193 a.find(k): returns an iterator pointing to an element with the key equivalent to
11194 k, or a.end() if such an element is not found.
11195 </p>
11196
11197 <p>
11198 a.lower_bound(k): returns an iterator pointing to the first element with
11199 key not less than k.
11200 </p>
11201
11202 <p>
11203 a.upper_bound(k): returns an iterator pointing to the first element with
11204 key greater than k.
11205 </p>
11206 </blockquote>
11207
11208 <p>
11209 We have "or a.end() if such an element is not found" for
11210 <tt>find</tt>, but not for <tt>upper_bound</tt> or
11211 <tt>lower_bound</tt>.  As the text stands, one would be forced to
11212 insert a new element into the container and return an iterator to that
11213 in case the sought iterator does not exist, which does not seem to be
11214 the intention (and not possible with the "const" versions).
11215 </p>
11216 <p><b>Proposed resolution:</b></p>
11217
11218 <p>Change Table 69 of section 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> indicated entries
11219 to:</p>
11220
11221 <blockquote>
11222 <p>
11223 a.lower_bound(k): returns an iterator pointing to the first element with
11224 key not less than k, or a.end() if such an element is not found.
11225 </p>
11226
11227 <p>
11228 a.upper_bound(k): returns an iterator pointing to the first element with
11229 key greater than k, or a.end() if such an element is not found.
11230 </p>
11231 </blockquote>
11232
11233 <p><i>[Curaçao: LWG reviewed PR.]</i></p>
11234
11235 <hr>
11236 <a name="355"><h3>355.&nbsp;Operational semantics for a.back()</h3></a><p><b>Section:</b>&nbsp;23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Yaroslav Mironov&nbsp; <b>Date:</b>&nbsp;23 Jan 2002</p>
11237
11238 <p>Table 68 "Optional Sequence Operations" in 23.1.1/12
11239 specifies operational semantics for "a.back()" as
11240 "*--a.end()", which may be ill-formed <i>[because calling
11241 operator-- on a temporary (the return) of a built-in type is
11242 ill-formed]</i>, provided a.end() returns a simple pointer rvalue
11243 (this is almost always the case for std::vector::end(), for
11244 example). Thus, the specification is not only incorrect, it
11245 demonstrates a dangerous construct: "--a.end()" may
11246 successfully compile and run as intended, but after changing the type
11247 of the container or the mode of compilation it may produce
11248 compile-time error. </p>
11249
11250 <p><b>Proposed resolution:</b></p>
11251 <p>Change the specification in table 68 "Optional Sequence
11252 Operations" in 23.1.1/12 for "a.back()" from</p>
11253
11254
11255 <blockquote>
11256 *--a.end()
11257 </blockquote>
11258
11259 <p>to</p>
11260
11261 <blockquote>
11262   { iterator tmp = a.end(); --tmp; return *tmp; }
11263 </blockquote>
11264
11265 <p>and the specification for "a.pop_back()" from</p>
11266
11267 <blockquote>
11268 a.erase(--a.end())
11269 </blockquote>
11270
11271 <p>to</p>
11272
11273 <blockquote>
11274   { iterator tmp = a.end(); --tmp; a.erase(tmp); }
11275 </blockquote>
11276
11277 <p><i>[Curaçao: LWG changed PR from "{ X::iterator tmp =
11278 a.end(); return *--tmp; }" to "*a.rbegin()", and from
11279 "{ X::iterator tmp = a.end(); a.erase(--tmp); }" to
11280 "a.erase(rbegin())".]</i></p>
11281
11282 <p><i>[There is a second possible defect; table 68 "Optional
11283 Sequence Operations" in the "Operational Semantics"
11284 column uses operations present only in the "Reversible
11285 Container" requirements, yet there is no stated dependency
11286 between these separate requirements tables. Ask in Santa Cruz if the
11287 LWG would like a new issue opened.]</i></p>
11288
11289 <p><i>[Santa Cruz: the proposed resolution is even worse than what's in
11290   the current standard: erase is undefined for reverse iterator.  If
11291   we're going to make the change, we need to define a temporary and
11292   use operator--.  Additionally, we don't know how prevalent this is:
11293   do we need to make this change in more than one place?  Martin has
11294   volunteered to review the standard and see if this problem occurs
11295   elsewhere.]</i></p>
11296
11297 <p><i>[Oxford: Matt provided new wording to address the concerns raised
11298   in Santa Cruz.  It does not appear that this problem appears
11299   anywhere else in clauses 23 or 24.]</i></p>
11300
11301 <p><i>[Kona: In definition of operational semantics of back(), change
11302 "*tmp" to "return *tmp;"]</i></p>
11303
11304 <hr>
11305 <a name="358"><h3>358.&nbsp;interpreting <tt>thousands_sep</tt> after a <tt>decimal_point</tt>
11306 </h3></a><p><b>Section:</b>&nbsp;22.2.2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.get.virtuals"> [lib.facet.num.get.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;12 Mar 2002</p>
11307 <p>
11308 I don't think <tt>thousands_sep</tt> is being treated correctly after
11309 decimal_point has been seen. Since grouping applies only to the
11310 integral part of the number, the first such occurrence should, IMO,
11311 terminate Stage 2. (If it does not terminate it, then 22.2.2.1.2, p12
11312 and 22.2.3.1.2, p3 need to explain how <tt>thousands_sep</tt> is to be
11313 interpreted in the fractional part of a number.)
11314 </p>
11315
11316 <p>
11317 The easiest change I can think of that resolves this issue would be
11318 something like below.
11319 </p>
11320 <p><b>Proposed resolution:</b></p>
11321 <p>
11322 Change the first sentence of 22.2.2.1.2, p9 from
11323 </p>
11324
11325 <blockquote>
11326     If discard is true then the position of the character is
11327     remembered, but the character is otherwise ignored. If it is not
11328     discarded, then a check is made to determine if c is allowed as
11329     the next character of an input field of the conversion specifier
11330     returned by stage 1. If so it is accumulated.
11331 </blockquote>
11332
11333 <p>to</p>
11334
11335 <blockquote>
11336     If <tt>discard</tt> is true, then if <tt>'.'</tt> has not yet been
11337     accumulated, then the position of the character is remembered, but
11338     the character is otherwise ignored. Otherwise, if <tt>'.'</tt> has
11339     already been accumulated, the character is discarded and Stage 2
11340      terminates. ...
11341 </blockquote>
11342
11343 <p><b>Rationale:</b></p>
11344 <p>We believe this reflects the intent of the Standard.  Thousands sep
11345   characters after the decimal point are not useful in any locale.
11346   Some formatting conventions do group digits that follow the decimal
11347   point, but they usually introduce a different grouping character
11348   instead of reusing the thousand sep character.  If we want to add
11349   support for such conventions, we need to do so explicitly.</p>
11350
11351 <hr>
11352 <a name="359"><h3>359.&nbsp;num_put&lt;&gt;::do_put (..., bool) undocumented</h3></a><p><b>Section:</b>&nbsp;22.2.2.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.facet.num.put.members"> [lib.facet.num.put.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;12 Mar 2002</p>
11353 <p>22.2.2.2.1, p1:</p>
11354
11355     <pre>    iter_type put (iter_type out, ios_base&amp; str, char_type fill,
11356                    bool val) const;
11357     ...
11358
11359     1   Returns: do_put (out, str, fill, val).
11360     </pre>
11361
11362 <p>AFAICS, the behavior of do_put (..., bool) is not documented anywhere,
11363 however, 22.2.2.2.2, p23:</p>
11364
11365 <blockquote>
11366 <pre>iter_type put (iter_type out, ios_base&amp; str, char_type fill,
11367                bool val) const;
11368 </pre>
11369
11370
11371         Effects: If (str.flags() &amp; ios_base::boolalpha) == 0 then do
11372              out = do_put(out, str, fill, (int)val)
11373            Otherwise do
11374 <pre>             string_type s =
11375                  val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
11376                      : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
11377 </pre>
11378            and then insert the characters of s into out. <i>out</i>.
11379 </blockquote>
11380
11381 <p>
11382 This means that the bool overload of <tt>do_put()</tt> will never be called,
11383 which contradicts the first paragraph. Perhaps the declaration
11384 should read <tt>do_put()</tt>, and not <tt>put()</tt>?
11385 </p>
11386
11387 <p>
11388 Note also that there is no <b>Returns</b> clause for this function, which
11389 should probably be corrected, just as should the second occurrence
11390 of <i>"out."</i> in the text.
11391 </p>
11392
11393 <p>
11394 I think the least invasive change to fix it would be something like
11395 the following:
11396 </p>
11397 <p><b>Proposed resolution:</b></p>
11398 <p>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>, just above paragraph 1, remove
11399   the <tt>bool</tt> overload.</p>
11400
11401 <p>
11402 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>, p23, make the following changes
11403 </p>
11404
11405 <blockquote>
11406      Replace <tt>put()</tt> with <tt>do_put()</tt> in the declaration
11407      of the member function.
11408 </blockquote>
11409
11410 <blockquote>
11411     Change the <b>Effects</b> clause to a <b>Returns</b> clause (to
11412     avoid the requirement to call <tt>do_put(..., int)</tt> from <tt>
11413     do_put (..., bool))</tt>
11414     like so:
11415 </blockquote>
11416
11417 <blockquote>
11418     23   <b>Returns</b>: If <tt>(str.flags() &amp;
11419          ios_base::boolalpha) == 0</tt> then
11420          <tt>do_put (out, str, fill, (long)val)</tt>
11421          Otherwise the function obtains a string <tt>s</tt> as if by
11422 <pre>             string_type s =
11423                 val ? use_facet&lt;ctype&lt;charT&gt; &gt;(loc).truename()
11424                     : use_facet&lt;ctype&lt;charT&gt; &gt;(loc).falsename();
11425 </pre>
11426          and then inserts each character <tt>c</tt> of s into out via
11427            <tt>*out++ = c</tt>
11428          and returns <tt>out</tt>.
11429 </blockquote>
11430
11431 <p><b>Rationale:</b></p>
11432 <p>
11433 This fixes a couple of obvious typos, and also fixes what appears to
11434 be a requirement of gratuitous inefficiency.
11435 </p>
11436 <hr>
11437 <a name="360"><h3>360.&nbsp;locale mandates inefficient implementation</h3></a><p><b>Section:</b>&nbsp;22.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale"> [lib.locale]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;12 Mar 2002</p>
11438 <p>
11439 22.1.1, p7 (copied below) allows iostream formatters and extractors
11440 to make assumptions about the values returned from facet members.
11441 However, such assumptions are apparently not guaranteed to hold
11442 in other cases (e.g., when the facet members are being called directly
11443 rather than as a result of iostream calls, or between successive
11444 calls to the same iostream functions with no interevening calls to
11445 <tt>imbue()</tt>, or even when the facet member functions are called
11446 from other member functions of other facets). This restriction
11447 prevents locale from being implemented efficiently.
11448 </p>
11449 <p><b>Proposed resolution:</b></p>
11450 <p>Change the first sentence in 22.1.1, p7 from</p>
11451 <blockquote>
11452     In successive calls to a locale facet member function during
11453     a call to an iostream inserter or extractor or a streambuf member
11454     function, the returned result shall be identical. [Note: This
11455     implies that such results may safely be reused without calling
11456     the locale facet member function again, and that member functions
11457     of iostream classes cannot safely call <tt>imbue()</tt>
11458     themselves, except as specified elsewhere. --end note]
11459 </blockquote>
11460
11461 <p>to</p>
11462
11463 <blockquote>
11464     In successive calls to a locale facet member function on a facet
11465     object installed in the same locale, the returned result shall be
11466     identical. ...
11467 </blockquote>
11468
11469 <p><b>Rationale:</b></p>
11470 <p>This change is reasonable becuase it clarifies the intent of this
11471   part of the standard.</p>
11472 <hr>
11473 <a name="362"><h3>362.&nbsp;bind1st/bind2nd type safety</h3></a><p><b>Section:</b>&nbsp;D.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/future.html#depr.lib.binders"> [depr.lib.binders]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Andrew Demkin&nbsp; <b>Date:</b>&nbsp;26 Apr 2002</p>
11474 <p>
11475 The definition of bind1st() (<font color="red">20.5.6.2</font>) can result in
11476 the construction of an unsafe binding between incompatible pointer
11477 types. For example, given a function whose first parameter type is
11478 'pointer to T', it's possible without error to bind an argument of
11479 type 'pointer to U' when U does not derive from T:
11480 </p>
11481 <pre>   foo(T*, int);
11482
11483    struct T {};
11484    struct U {};
11485
11486    U u;
11487
11488    int* p;
11489    int* q;
11490
11491    for_each(p, q, bind1st(ptr_fun(foo), &amp;u));    // unsafe binding
11492 </pre>
11493
11494 <p>
11495 The definition of bind1st() includes a functional-style conversion to
11496 map its argument to the expected argument type of the bound function
11497 (see below):
11498 </p>
11499 <pre>  typename Operation::first_argument_type(x)
11500 </pre>
11501
11502 <p>
11503 A functional-style conversion (5.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/expr.html#expr.type.conv"> [expr.type.conv]</a>) is defined to be
11504 semantically equivalent to an explicit cast expression (5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/expr.html#expr.cast"> [expr.cast]</a>), which may (according to 5.4, paragraph 5) be interpreted
11505 as a reinterpret_cast, thus masking the error.
11506 </p>
11507
11508 <p>The problem and proposed change also apply to <font color="red">20.5.6.4</font>.</p>
11509 <p><b>Proposed resolution:</b></p>
11510 <p>Add this sentence to the end of 20.5.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.arithmetic.operations"> [lib.arithmetic.operations]</a>/1:
11511   "Binders <tt>bind1st</tt> and <tt>bind2nd</tt> are deprecated in
11512   favor of <tt>std::tr1::bind</tt>."</p>
11513
11514 <p>(Notes to editor: (1) when and if tr1::bind is incorporated into
11515   the standard, "std::tr1::bind" should be changed to "std::bind". (2)
11516   20.5.6 should probably be moved to Annex D.</p>
11517 <p><b>Rationale:</b></p>
11518 <p>There is no point in fixing bind1st and bind2nd.  tr1::bind is a
11519   superior solution.  It solves this problem and others.</p>
11520 <hr>
11521 <a name="363"><h3>363.&nbsp;Missing exception specification in 27.4.2.1.1</h3></a><p><b>Section:</b>&nbsp;27.4.2.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios::failure"> [lib.ios::failure]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown and Marc Paterno&nbsp; <b>Date:</b>&nbsp;20 May 2002</p>
11522 <p>
11523 The destructor of ios_base::failure should have an empty throw
11524 specification, because the destructor of its base class, exception, is
11525 declared in this way.
11526 </p>
11527 <p><b>Proposed resolution:</b></p>
11528 <p>Change the destructor to</p>
11529 <pre>  virtual ~failure() throw();
11530 </pre>
11531 <p><b>Rationale:</b></p>
11532 <p>Fixes an obvious glitch.  This is almost editorial.</p>
11533 <hr>
11534 <a name="364"><h3>364.&nbsp;Inconsistent wording in 27.5.2.4.2</h3></a><p><b>Section:</b>&nbsp;27.5.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown, Marc Paterno&nbsp; <b>Date:</b>&nbsp;10 May 2002</p>
11535 <p>
11536 27.5.2.4.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.streambuf.virt.buffer"> [lib.streambuf.virt.buffer]</a> paragraph 1 is inconsistent with the Effects
11537 clause for seekoff.
11538 </p>
11539 <p><b>Proposed resolution:</b></p>
11540 <p>
11541 Make this paragraph, the Effects clause for setbuf, consistent in wording
11542 with the Effects clause for seekoff in paragraph 3 by amending paragraph 1
11543 to indicate the purpose of setbuf:
11544 </p>
11545
11546 <p>Original text:</p>
11547
11548 <blockquote>
11549 1 Effects: Performs an operation that is defined separately for each
11550 class derived from basic_streambuf in this clause (27.7.1.3, 27.8.1.4).
11551 </blockquote>
11552
11553 <p>Proposed text:</p>
11554
11555 <blockquote>
11556 1 Effects: Influences stream buffering in a way that is defined separately
11557 for each class derived from basic_streambuf in this clause
11558 (27.7.1.3, 27.8.1.4).
11559 </blockquote>
11560
11561 <p><b>Rationale:</b></p>
11562 <p>The LWG doesn't believe there is any normative difference between
11563   the existing wording and what's in the proposed resolution, but the
11564   change may make the intent clearer.</p>
11565 <hr>
11566 <a name="365"><h3>365.&nbsp;Lack of const-qualification in clause 27</h3></a><p><b>Section:</b>&nbsp;27 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.input.output"> [lib.input.output]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown, Marc Paterno&nbsp; <b>Date:</b>&nbsp;10 May 2002</p>
11567 <p>
11568 Some stream and streambuf member functions are declared non-const,
11569 even thought they appear only to report information rather than to
11570 change an object's logical state.  They should be declared const.  See
11571 document N1360 for details and rationale.
11572 </p>
11573
11574 <p>The list of member functions under discussion: <tt>in_avail</tt>,
11575 <tt>showmanyc</tt>, <tt>tellg</tt>, <tt>tellp</tt>, <tt>is_open</tt>.</p>
11576
11577 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a></p>
11578
11579 <p><b>Proposed resolution:</b></p>
11580 <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>
11581 <p>Replace</p>
11582 <pre>  bool is_open();
11583 </pre>
11584 <p>with</p>
11585 <pre>  bool is_open() const;
11586 </pre>
11587 <p><b>Rationale:</b></p>
11588 <p>Of the changes proposed in N1360, the only one that is safe is
11589 changing the filestreams' is_open to const.  The LWG believed that
11590 this was NAD the first time it considered this issue (issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#73">73</a>), but now thinks otherwise.  The corresponding streambuf
11591 member function, after all,is already const.</p>
11592
11593 <p>The other proposed changes are less safe, because some streambuf
11594 functions that appear merely to report a value do actually perform
11595 mutating operations.  It's not even clear that they should be
11596 considered "logically const", because streambuf has two interfaces, a
11597 public one and a protected one.  These functions may, and often do,
11598 change the state as exposed by the protected interface, even if the
11599 state exposed by the public interface is unchanged.</p>
11600
11601 <p>Note that implementers can make this change in a binary compatible
11602 way by providing both overloads; this would be a conforming extension.</p>
11603
11604 <hr>
11605 <a name="369"><h3>369.&nbsp;io stream objects and static ctors</h3></a><p><b>Section:</b>&nbsp;27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Ruslan Abdikeev&nbsp; <b>Date:</b>&nbsp;8 Jul 2002</p>
11606 <p>
11607 Is it safe to use standard iostream objects from constructors of
11608 static objects?  Are standard iostream objects constructed and are
11609 their associations established at that time?
11610 </p>
11611
11612 <p>Surpisingly enough, Standard does NOT require that.</p>
11613
11614 <p>
11615 27.3/2 [lib.iostream.objects] guarantees that standard iostream
11616 objects are constructed and their associations are established before
11617 the body of main() begins execution.  It also refers to ios_base::Init
11618 class as the panacea for constructors of static objects.
11619 </p>
11620
11621 <p>
11622 However, there's nothing in 27.3 [lib.iostream.objects],
11623 in 27.4.2 [lib.ios.base], and in 27.4.2.1.6 [lib.ios::Init],
11624 that would require implementations to allow access to standard
11625 iostream objects from constructors of static objects.
11626 </p>
11627
11628 <p>Details:</p>
11629
11630 <p>Core text refers to some magic object ios_base::Init, which will
11631 be discussed below:</p>
11632
11633 <blockquote>
11634     "The [standard iostream] objects are constructed, and their
11635     associations are established at some time prior to or during
11636     first time an object of class basic_ios&lt;charT,traits&gt;::Init
11637     is constructed, and in any case before the body of main
11638     begins execution." (27.3/2 [lib.iostream.objects])
11639 </blockquote>
11640
11641 <p>
11642 The first <i>non-normative</i> footnote encourages implementations
11643 to initialize standard iostream objects earlier than required.
11644 </p>
11645
11646 <p>However, the second <i>non-normative</i> footnote makes an explicit
11647 and unsupported claim:</p>
11648
11649 <blockquote>
11650   "Constructors and destructors for static objects can access these
11651   [standard iostream] objects to read input from stdin or write output
11652   to stdout or stderr." (27.3/2 footnote 265 [lib.iostream.objects])
11653 </blockquote>
11654
11655 <p>
11656 The only bit of magic is related to that ios_base::Init class.  AFAIK,
11657 the rationale behind ios_base::Init was to bring an instance of this
11658 class to each translation unit which #included &lt;iostream&gt; or
11659 related header.  Such an inclusion would support the claim of footnote
11660 quoted above, because in order to use some standard iostream object it
11661 is necessary to #include &lt;iostream&gt;.
11662 </p>
11663
11664 <p>
11665 However, while Standard explicitly describes ios_base::Init as
11666 an appropriate class for doing the trick, I failed to found a
11667 mention of an _instance_ of ios_base::Init in Standard.
11668 </p>
11669 <p><b>Proposed resolution:</b></p>
11670
11671 <p>Add to 27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>, p2, immediately before the last sentence
11672 of the paragraph, the following two sentences:</p>
11673
11674 <blockquote>
11675 If a translation unit includes &lt;iostream&gt;, or explicitly
11676 constructs an ios_base::Init object, these stream objects shall
11677 be constructed before dynamic initialization of non-local
11678 objects defined later in that translation unit, and these stream
11679 objects shall be destroyed after the destruction of dynamically
11680 initialized non-local objects defined later in that translation unit.
11681 </blockquote>
11682
11683 <p><i>[Lillehammer: Matt provided wording.]</i></p>
11684 <p><i>[Mont Tremblant: Matt provided revised wording.]</i></p>
11685 <p><b>Rationale:</b></p>
11686 <p>
11687 The original proposed resolution unconditionally required
11688 implementations to define an ios_base::Init object of some
11689 implementation-defined name in the header &lt;iostream&gt;. That's an
11690 overspecification. First, defining the object may be unnecessary
11691 and even detrimental to performance if an implementation can
11692 guarantee that the 8 standard iostream objects will be initialized
11693 before any other user-defined object in a program. Second, there
11694 is no need to require implementations to document the name of the
11695 object.</p>
11696
11697 <p>
11698 The new proposed resolution gives users guidance on what they need to
11699 do to ensure that stream objects are constructed during startup.</p>
11700 <hr>
11701 <a name="370"><h3>370.&nbsp;Minor error in basic_istream::get</h3></a><p><b>Section:</b>&nbsp;27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;15 Jul 2002</p>
11702 <p>Defect report for description of basic_istream::get (section 27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>), paragraph 15. The description for the get function
11703 with the following signature:</p>
11704
11705 <pre>  basic_istream&lt;charT,traits&gt;&amp; get(basic_streambuf&lt;char_type,traits&gt;&amp;
11706   sb);
11707 </pre>
11708
11709 <p>is incorrect. It reads</p>
11710
11711 <blockquote>
11712   Effects: Calls get(s,n,widen('\n'))
11713 </blockquote>
11714
11715 <p>which I believe should be:</p>
11716
11717 <blockquote>
11718   Effects: Calls get(sb,widen('\n'))
11719 </blockquote>
11720 <p><b>Proposed resolution:</b></p>
11721 <p>Change the <b>Effects</b> paragraph to:</p>
11722 <blockquote>
11723   Effects: Calls get(sb,this-&gt;widen('\n'))
11724 </blockquote>
11725
11726 <p><i>[Pre-Oxford: Minor correction from Howard: replaced 'widen'
11727       with 'this-&gt;widen'.]</i></p>
11728
11729 <p><b>Rationale:</b></p>
11730 <p>Fixes an obvious typo.</p>
11731 <hr>
11732 <a name="371"><h3>371.&nbsp;Stability of multiset and multimap member functions</h3></a><p><b>Section:</b>&nbsp;23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Frank Compagner&nbsp; <b>Date:</b>&nbsp;20 Jul 2002</p>
11733 <p>
11734 The requirements for multiset and multimap containers (23.1
11735 [lib.containers.requirements], 23.1.2 [lib.associative.reqmnts],
11736 23.3.2 [lib.multimap] and 23.3.4 [lib.multiset]) make no mention of
11737 the stability of the required (mutating) member functions. It appears
11738 the standard allows these functions to reorder equivalent elements of
11739 the container at will, yet the pervasive red-black tree implementation
11740 appears to provide stable behaviour.
11741 </p>
11742
11743 <p>This is of most concern when considering the behaviour of erase().
11744 A stability requirement would guarantee the correct working of the
11745 following 'idiom' that removes elements based on a certain predicate
11746 function.
11747 </p>
11748
11749 <pre>  multimap&lt;int, int&gt; m;
11750   multimap&lt;int, int&gt;::iterator i = m.begin();
11751   while (i != m.end()) {
11752       if (pred(i))
11753           m.erase (i++);
11754       else
11755           ++i;
11756   }
11757 </pre>
11758
11759 <p>
11760 Although clause 23.1.2/8 guarantees that i remains a valid iterator
11761 througout this loop, absence of the stability requirement could
11762 potentially result in elements being skipped. This would make
11763 this code incorrect, and, furthermore, means that there is no way
11764 of erasing these elements without iterating first over the entire
11765 container, and second over the elements to be erased. This would
11766 be unfortunate, and have a negative impact on both performance and
11767 code simplicity.
11768 </p>
11769
11770 <p>
11771 If the stability requirement is intended, it should be made explicit
11772 (probably through an extra paragraph in clause 23.1.2).
11773 </p>
11774 <p>
11775 If it turns out stability cannot be guaranteed, i'd argue that a
11776 remark or footnote is called for (also somewhere in clause 23.1.2) to
11777 warn against relying on stable behaviour (as demonstrated by the code
11778 above).  If most implementations will display stable behaviour, any
11779 problems emerging on an implementation without stable behaviour will
11780 be hard to track down by users. This would also make the need for an
11781 erase_if() member function that much greater.
11782 </p>
11783
11784 <p>This issue is somewhat related to LWG issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#130">130</a>.</p>
11785
11786 <p><b>Proposed resolution:</b></p>
11787
11788 <p>Add the following to the end of 23.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.associative.reqmts"> [lib.associative.reqmts]</a> paragraph 4:
11789 "For <tt>multiset</tt> and <tt>multimap</tt>, <tt>insert</tt>and <tt>erase</tt>
11790   are <i>stable</i>: they preserve the relative ordering of equivalent
11791   elements.</p>
11792
11793 <p><i>[Lillehammer: Matt provided wording]</i></p>
11794 <p><i>[Joe Gottman points out that the provided wording does not address
11795 multimap and multiset.  N1780 also addresses this issue and suggests
11796 wording.]</i></p>
11797
11798 <p><i>[Mont Tremblant: Changed set and map to multiset and multimap.]</i></p>
11799
11800 <p><b>Rationale:</b></p>
11801 <p>The LWG agrees that this guarantee is necessary for common user
11802   idioms to work, and that all existing implementations provide this
11803   property.  Note that this resolution guarantees stability for
11804   multimap and multiset, not for all associative containers in
11805   general.</p>
11806
11807 <hr>
11808 <a name="373"><h3>373.&nbsp;Are basic_istream and basic_ostream to use (exceptions()&amp;badbit) != 0 ?</h3></a><p><b>Section:</b>&nbsp;27.6.1.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.formatted.reqmts"> [lib.istream.formatted.reqmts]</a>, 27.6.2.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.formatted.reqmts"> [lib.ostream.formatted.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Keith Baker&nbsp; <b>Date:</b>&nbsp;23 Jul 2002</p>
11809
11810 <p>
11811 In 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> and 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>
11812 (exception()&amp;badbit) != 0 is used in testing for rethrow, yet
11813 exception() is the constructor to class std::exception in 18.6.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.type.info"> [lib.type.info]</a> that has no return type. Should member function
11814 exceptions() found in 27.4.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ios"> [lib.ios]</a> be used instead?
11815 </p>
11816
11817 <p><b>Proposed resolution:</b></p>
11818 <p>
11819 In 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> and 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>, change
11820 "(exception()&amp;badbit) != 0" to "(exceptions()&amp;badbit) != 0".
11821 </p>
11822 <p><b>Rationale:</b></p>
11823 <p>Fixes an obvious typo.</p>
11824 <hr>
11825 <a name="375"><h3>375.&nbsp;basic_ios should be ios_base in 27.7.1.3</h3></a><p><b>Section:</b>&nbsp;27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;14 Aug 2002</p>
11826 <p>
11827 In Section 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>: Table 90, Table 91, and paragraph
11828 14 all contain references to "basic_ios::" which should be
11829 "ios_base::".
11830 </p>
11831 <p><b>Proposed resolution:</b></p>
11832 <p>
11833 Change all references to "basic_ios" in Table 90, Table 91, and
11834 paragraph 14 to "ios_base".
11835 </p>
11836 <p><b>Rationale:</b></p>
11837 <p>Fixes an obvious typo.</p>
11838 <hr>
11839 <a name="376"><h3>376.&nbsp;basic_streambuf semantics</h3></a><p><b>Section:</b>&nbsp;27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;14 Aug 2002</p>
11840 <p>
11841 In Section 27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>, Table 90, the implication is that
11842 the four conditions should be mutually exclusive, but they are not.
11843 The first two cases, as written, are subcases of the third.</p>
11844
11845 <p>
11846 As written, it is unclear what should be the result if cases 1 and 2
11847 are both true, but case 3 is false.
11848 </p>
11849
11850 <p><b>Proposed resolution:</b></p>
11851
11852 <p>Rewrite these conditions as:</p>
11853 <blockquote>
11854 <p>
11855   (which &amp; (ios_base::in|ios_base::out)) == ios_base::in
11856 </p>
11857
11858 <p>
11859   (which &amp; (ios_base::in|ios_base::out)) == ios_base::out
11860 </p>
11861
11862 <p>
11863   (which &amp; (ios_base::in|ios_base::out)) ==
11864 (ios_base::in|ios_base::out)
11865    and way == either ios_base::beg or ios_base::end
11866 </p>
11867
11868 <p>Otherwise</p>
11869 </blockquote>
11870
11871 <p><b>Rationale:</b></p>
11872 <p>It's clear what we wanted to say, we just failed to say it.  This
11873   fixes it.</p>
11874 <hr>
11875 <a name="379"><h3>379.&nbsp;nonsensical ctype::do_widen() requirement</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;6 Sep 2002</p>
11876 <p>
11877 The last sentence in 22.2.1.1.2, p11 below doesn't seem to make sense.
11878 </p>
11879 <pre>  charT do_widen (char c) const;
11880
11881   -11- Effects: Applies the simplest reasonable transformation from
11882        a char value or sequence of char values to the corresponding
11883        charT value or values. The only characters for which unique
11884        transformations are required are those in the basic source
11885        character set (2.2). For any named ctype category with a
11886        ctype&lt;charT&gt; facet ctw and valid ctype_base::mask value
11887        M (is(M, c) || !ctw.is(M, do_widen(c))) is true.
11888 </pre>
11889 <p>
11890 Shouldn't the last sentence instead read
11891 </p>
11892 <pre>       For any named ctype category with a ctype&lt;char&gt; facet ctc
11893        and valid ctype_base::mask value M
11894        (ctc.is(M, c) || !is(M, do_widen(c))) is true.
11895 </pre>
11896 <p>
11897 I.e., if the narrow character c is not a member of a class of
11898 characters then neither is the widened form of c. (To paraphrase
11899 footnote 224.)
11900 </p>
11901 <p><b>Proposed resolution:</b></p>
11902 <p>
11903 Replace the last sentence of 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>, p11 with the
11904 following text:
11905 </p>
11906 <pre>       For any named ctype category with a ctype&lt;char&gt; facet ctc
11907        and valid ctype_base::mask value M,
11908        (ctc.is(M, c) || !is(M, do_widen(c))) is true.
11909 </pre>
11910
11911 <p><i>[Kona: Minor edit. Added a comma after the <i>M</i> for clarity.]</i></p>
11912
11913 <p><b>Rationale:</b></p>
11914 <p>The LWG believes this is just a typo, and that this is the correct fix.</p>
11915 <hr>
11916 <a name="380"><h3>380.&nbsp;typos in codecvt tables 53 and 54</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;6 Sep 2002</p>
11917 <p>
11918 Tables 53 and 54 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> are both titled "convert
11919 result values," when surely "do_in/do_out result values" must have
11920 been intended for Table 53 and "do_unshift result values" for Table
11921 54.
11922 </p>
11923 <p>
11924 Table 54, row 3 says that the meaning of partial is "more characters
11925 needed to be supplied to complete termination." The function is not
11926 supplied any characters, it is given a buffer which it fills with
11927 characters or, more precisely, destination elements (i.e., an escape
11928 sequence). So partial means that space for more than (to_limit - to)
11929 destination elements was needed to terminate a sequence given the
11930 value of state.
11931 </p>
11932 <p><b>Proposed resolution:</b></p>
11933 <p>
11934 Change the title of Table 53 to "do_in/do_out result values" and
11935 the title of Table 54 to "do_unshift result values."
11936 </p>
11937 <p>
11938 Change the text in Table 54, row 3 (the <b>partial</b> row), under the
11939 heading Meaning, to "space for more than (to_limit - to) destination
11940 elements was needed to terminate a sequence given the value of state."
11941 </p>
11942 <hr>
11943 <a name="381"><h3>381.&nbsp;detection of invalid mbstate_t in codecvt</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;6 Sep 2002</p>
11944 <p>
11945 All but one codecvt member functions that take a state_type argument
11946 list as one of their preconditions that the state_type argument have
11947 a valid value. However, according to 22.2.1.5.2, p6,
11948 codecvt::do_unshift() is the only codecvt member that is supposed to
11949 return error if the state_type object is invalid.
11950 </p>
11951
11952 <p>
11953 It seems to me that the treatment of state_type by all codecvt member
11954 functions should be the same and the current requirements should be
11955 changed. Since the detection of invalid state_type values may be
11956 difficult in general or computationally expensive in some specific
11957 cases, I propose the following:
11958 </p>
11959 <p><b>Proposed resolution:</b></p>
11960 <p>
11961 Add a new paragraph before 22.2.1.5.2, p5, and after the function
11962 declaration below
11963 </p>
11964 <pre>    result do_unshift(stateT&amp; state,
11965     externT* to, externT* to_limit, externT*&amp; to_next) const;
11966 </pre>
11967 <p>
11968 as follows:
11969 </p>
11970 <pre>    Requires: (to &lt;= to_end) well defined and true; state initialized,
11971     if at the beginning of a sequence, or else equal to the result of
11972     converting the preceding characters in the sequence.
11973 </pre>
11974 <p>
11975 and change the text in Table 54, row 4, the <b>error</b> row, under
11976 the heading Meaning, from
11977 </p>
11978 <pre>    state has invalid value
11979 </pre>
11980 <p>
11981 to
11982 </p>
11983 <pre>    an unspecified error has occurred
11984 </pre>
11985 <p><b>Rationale:</b></p>
11986 <p>The intent is that implementations should not be required to detect
11987 invalid state values; such a requirement appears nowhere else.  An
11988 invalid state value is a precondition violation, <i>i.e.</i> undefined
11989 behavior.  Implementations that do choose to detect invalid state
11990 values, or that choose to detect any other kind of error, may return
11991 <b>error</b> as an indication.</p>
11992 <hr>
11993 <a name="383"><h3>383.&nbsp;Bidirectional iterator assertion typo</h3></a><p><b>Section:</b>&nbsp;24.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.bidirectional.iterators"> [lib.bidirectional.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;ysapir (submitted via comp.std.c++)&nbsp; <b>Date:</b>&nbsp;17 Oct 2002</p>
11994 <p>
11995 Following a discussion on the boost list regarding end iterators and
11996 the possibility of performing operator--() on them, it seems to me
11997 that there is a typo in the standard.  This typo has nothing to do
11998 with that discussion.
11999 </p>
12000
12001 <p>
12002 I have checked this newsgroup, as well as attempted a search of the
12003 Active/Defect/Closed Issues List on the site for the words "s is
12004 derefer" so I believe this has not been proposed before.  Furthermore,
12005 the "Lists by Index" mentions only DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a> on section
12006 24.1.4, and DR <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a> is not related to this issue.
12007 </p>
12008
12009 <p>
12010 The standard makes the following assertion on bidirectional iterators,
12011 in section 24.1.4 [lib.bidirectional.iterators], Table 75:
12012 </p>
12013
12014 <pre>                         operational  assertion/note
12015 expression  return type   semantics    pre/post-condition
12016
12017 --r          X&amp;                        pre: there exists s such
12018                                        that r == ++s.
12019                                        post: s is dereferenceable.
12020                                        --(++r) == r.
12021                                        --r == --s implies r == s.
12022                                        &amp;r == &amp;--r.
12023 </pre>
12024
12025 <p>
12026 (See <a href="http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763">http://aspn.activestate.com/ASPN/Mail/Message/boost/1395763</a>.)
12027 </p>
12028
12029 <p>
12030 In particular, "s is dereferenceable" seems to be in error.  It seems
12031 that the intention was to say "r is dereferenceable".
12032 </p>
12033
12034 <p>
12035 If it were to say "r is dereferenceable" it would
12036 make perfect sense.  Since s must be dereferenceable prior to
12037 operator++, then the natural result of operator-- (to undo operator++)
12038 would be to make r dereferenceable.  Furthermore, without other
12039 assertions, and basing only on precondition and postconditions, we
12040 could not otherwise know this.  So it is also interesting information.
12041 </p>
12042
12043 <p><b>Proposed resolution:</b></p>
12044 <p>
12045 Change the guarantee to "postcondition: r is dereferenceable."
12046 </p>
12047 <p><b>Rationale:</b></p>
12048 <p>Fixes an obvious typo</p>
12049 <hr>
12050 <a name="384"><h3>384.&nbsp;equal_range has unimplementable runtime complexity</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Hans Bos&nbsp; <b>Date:</b>&nbsp;18 Oct 2002</p>
12051 <p>
12052 Section 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a>
12053 states that at most 2 * log(last - first) + 1
12054 comparisons are allowed for equal_range.
12055 </p>
12056
12057 <p>It is not possible to implement equal_range with these constraints.</p>
12058
12059 <p>In a range of one element as in:</p>
12060 <pre>    int x = 1;
12061     equal_range(&amp;x, &amp;x + 1, 1)
12062 </pre>
12063
12064 <p>it is easy to see that at least 2 comparison operations are needed.</p>
12065
12066 <p>For this case at most 2 * log(1) + 1 = 1 comparison is allowed.</p>
12067
12068 <p>I have checked a few libraries and they all use the same (nonconforming)
12069 algorithm for equal_range that has a complexity of</p>
12070 <pre>     2* log(distance(first, last)) + 2.
12071 </pre>
12072 <p>I guess this is the algorithm that the standard assumes for equal_range.</p>
12073
12074 <p>
12075 It is easy to see that 2 * log(distance) + 2 comparisons are enough
12076 since equal range can be implemented with lower_bound and upper_bound
12077 (both log(distance) + 1).
12078 </p>
12079
12080 <p>
12081 I think it is better to require something like 2log(distance) + O(1)  (or
12082 even logarithmic as multiset::equal_range).
12083 Then an implementation has more room to optimize for certain cases (e.g.
12084 have log(distance) characteristics when at most match is found in the range
12085 but 2log(distance) + 4 for the worst case).
12086 </p>
12087
12088 <p><b>Proposed resolution:</b></p>
12089 <p>In 25.3.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.lower.bound"> [lib.lower.bound]</a>/4, change <tt>log(last - first) + 1</tt>
12090 to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
12091
12092 <p>In 25.3.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.upper.bound"> [lib.upper.bound]</a>/4, change <tt>log(last - first) + 1</tt>
12093 to <tt>log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
12094
12095 <p>In 25.3.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.equal.range"> [lib.equal.range]</a>/4, change <tt>2*log(last - first) + 1</tt>
12096 to <tt>2*log<sub>2</sub>(last - first) + <i>O</i>(1)</tt>.</p>
12097
12098 <p><i>[Matt provided wording]</i></p>
12099 <p><b>Rationale:</b></p>
12100 <p>The LWG considered just saying <i>O</i>(log n) for all three, but
12101 Ê decided that threw away too much valuable information.Ê The fact
12102 Ê that lower_bound is twice as fast as equal_range is important.
12103 Ê However, it's better to allow an arbitrary additive constant than to
12104 Ê specify an exact count.Ê An exact count would have to
12105 Ê involve <tt>floor</tt> or <tt>ceil</tt>.Ê It would be too easy to
12106 Ê get this wrong, and don't provide any substantial value for users.</p>
12107 <hr>
12108 <a name="386"><h3>386.&nbsp;Reverse iterator's operator[] has impossible return type</h3></a><p><b>Section:</b>&nbsp;24.4.1.3.11 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.op-="> [lib.reverse.iter.op-=]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;23 Oct 2002</p>
12109 <p>In 24.4.1.3.11 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.op-="> [lib.reverse.iter.op-=]</a>, <tt>reverse_iterator&lt;&gt;::operator[]</tt>
12110 is specified as having a return type of <tt>reverse_iterator::reference</tt>,
12111 which is the same as <tt>iterator_traits&lt;Iterator&gt;::reference</tt>.
12112 (Where <tt>Iterator</tt> is the underlying iterator type.)</p>
12113
12114 <p>The trouble is that <tt>Iterator</tt>'s own operator[] doesn't
12115   necessarily have a return type
12116   of <tt>iterator_traits&lt;Iterator&gt;::reference</tt>.   Its
12117   return type is merely required to be convertible
12118   to <tt>Iterator</tt>'s value type.  The return type specified for
12119   reverse_iterator's operator[] would thus appear to be impossible.</p>
12120
12121 <p>With the resolution of issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#299">299</a>, the type of
12122   <tt>a[n]</tt> will continue to be required (for random access
12123   iterators) to be convertible to the value type, and also <tt>a[n] =
12124   t</tt> will be a valid expression.  Implementations of
12125   <tt>reverse_iterator</tt> will likely need to return a proxy from
12126   <tt>operator[]</tt> to meet these requirements. As mentioned in the
12127   comment from Dave Abrahams, the simplest way to specify that
12128   <tt>reverse_iterator</tt> meet this requirement to just mandate
12129   it and leave the return type of <tt>operator[]</tt> unspecified.</p>
12130
12131 <p><b>Proposed resolution:</b></p>
12132
12133 <p>In 24.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.reverse.iter.requirements"> [lib.reverse.iter.requirements]</a> change:</p>
12134
12135 <blockquote>
12136 <pre>reference operator[](difference_type n) const;
12137 </pre>
12138 </blockquote>
12139
12140 <p>to:</p>
12141
12142 <blockquote>
12143 <pre><b><i>unspecified</i></b> operator[](difference_type n) const; // see <font color="red">lib.random.access.iterators</font>
12144 </pre>
12145 </blockquote>
12146
12147
12148
12149
12150 <p><i>[
12151 Comments from Dave Abrahams: IMO we should resolve 386 by just saying
12152     that the return type of reverse_iterator's operator[] is
12153     unspecified, allowing the random access iterator requirements to
12154     impose an appropriate return type.  If we accept 299's proposed
12155     resolution (and I think we should), the return type will be
12156     readable and writable, which is about as good as we can do.
12157 ]</i></p>
12158 <hr>
12159 <a name="389"><h3>389.&nbsp;Const overload of valarray::operator[] returns by value</h3></a><p><b>Section:</b>&nbsp;26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex"> [lib.complex]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Gabriel Dos Reis&nbsp; <b>Date:</b>&nbsp;8 Nov 2002</p>
12160 <p>Consider the following program:</p>
12161 <pre>    #include &lt;iostream&gt;
12162     #include &lt;ostream&gt;
12163     #include &lt;vector&gt;
12164     #include &lt;valarray&gt;
12165     #include &lt;algorithm&gt;
12166     #include &lt;iterator&gt;
12167     template&lt;typename Array&gt;
12168     void print(const Array&amp; a)
12169     {
12170     using namespace std;
12171     typedef typename Array::value_type T;
12172     copy(&amp;a[0], &amp;a[0] + a.size(),
12173     ostream_iterator&lt;T&gt;(std::cout, " "));
12174     }
12175     template&lt;typename T, unsigned N&gt;
12176     unsigned size(T(&amp;)[N]) { return N; }
12177     int main()
12178     {
12179     double array[] = { 0.89, 9.3, 7, 6.23 };
12180     std::vector&lt;double&gt; v(array, array + size(array));
12181     std::valarray&lt;double&gt; w(array, size(array));
12182     print(v); // #1
12183     std::cout &lt;&lt; std::endl;
12184     print(w); // #2
12185     std::cout &lt;&lt; std::endl;
12186     }
12187 </pre>
12188
12189 <p>While the call numbered #1 succeeds, the call numbered #2 fails
12190 because the const version of the member function
12191 valarray&lt;T&gt;::operator[](size_t) returns a value instead of a
12192 const-reference. That seems to be so for no apparent reason, no
12193 benefit. Not only does that defeats users' expectation but it also
12194 does hinder existing software (written either in C or Fortran)
12195 integration within programs written in C++.  There is no reason why
12196 subscripting an expression of type valarray&lt;T&gt; that is const-qualified
12197 should not return a const T&amp;.</p>
12198 <p><b>Proposed resolution:</b></p>
12199 <p>In the class synopsis in 26.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.complex"> [lib.complex]</a>, and in
12200 <font color="red">26.3.2.3</font> just above paragraph 1, change</p>
12201 <pre>  T operator[](size_t const);
12202 </pre>
12203 <p>to</p>
12204 <pre>  const T&amp; operator[](size_t const);
12205 </pre>
12206
12207 <p><i>[Kona: fixed a minor typo: put semicolon at the end of the line
12208   wehre it belongs.]</i></p>
12209
12210 <p><b>Rationale:</b></p>
12211 <p>Return by value seems to serve no purpose.  Valaray was explicitly
12212 designed to have a specified layout so that it could easily be
12213 integrated with libraries in other languages, and return by value
12214 defeats that purpose.  It is believed that this change will have no
12215 impact on allowable optimizations.</p>
12216 <hr>
12217 <a name="391"><h3>391.&nbsp;non-member functions specified as const</h3></a><p><b>Section:</b>&nbsp;22.1.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.conversions"> [lib.conversions]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze&nbsp; <b>Date:</b>&nbsp;10 Dec 2002</p>
12218 <p>
12219 The specifications of toupper and tolower both specify the functions as
12220 const, althought they are not member functions, and are not specified as
12221 const in the header file synopsis in section 22.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locales"> [lib.locales]</a>.
12222 </p>
12223 <p><b>Proposed resolution:</b></p>
12224 <p>In 22.1.3.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.conversions"> [lib.conversions]</a>, remove <tt>const</tt> from the function
12225   declarations of std::toupper and std::tolower</p>
12226 <p><b>Rationale:</b></p>
12227 <p>Fixes an obvious typo</p>
12228 <hr>
12229 <a name="395"><h3>395.&nbsp;inconsistencies in the definitions of rand() and random_shuffle()</h3></a><p><b>Section:</b>&nbsp;26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numarray"> [lib.numarray]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;James Kanze&nbsp; <b>Date:</b>&nbsp;3 Jan 2003</p>
12230 <p>
12231 In 26.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-numerics.html#lib.numarray"> [lib.numarray]</a>, the C++ standard refers to the C standard for the
12232 definition of rand(); in the C standard, it is written that "The
12233 implementation shall behave as if no library function calls the rand
12234 function."
12235 </p>
12236
12237 <p>
12238 In 25.2.11 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.random.shuffle"> [lib.alg.random.shuffle]</a>, there is no specification as to
12239 how the two parameter version of the function generates its random
12240 value.  I believe that all current implementations in fact call rand()
12241 (in contradiction with the requirement avove); if an implementation does
12242 not call rand(), there is the question of how whatever random generator
12243 it does use is seeded.  Something is missing.
12244 </p>
12245
12246 <p><b>Proposed resolution:</b></p>
12247 <p>
12248 In [lib.c.math], add a paragraph specifying that the C definition of
12249 rand shal be modified to say that "Unless otherwise specified, the
12250 implementation shall behave as if no library function calls the rand
12251 function."
12252 </p>
12253
12254 <p>
12255 In [lib.alg.random.shuffle], add a sentence to the effect that "In
12256 the two argument form of the function, the underlying source of
12257 random numbers is implementation defined. [Note: in particular, an
12258 implementation is permitted to use <tt>rand</tt>.]
12259 </p>
12260 <p><b>Rationale:</b></p>
12261 <p>The original proposed resolution proposed requiring the
12262   two-argument from of <tt>random_shuffle</tt> to
12263   use <tt>rand</tt>. We don't want to do that, because some existing
12264   implementations already use something else: gcc
12265   uses <tt>lrand48</tt>, for example.  Using <tt>rand</tt> presents a
12266   problem if the number of elements in the sequence is greater than
12267   RAND_MAX.</p>
12268 <hr>
12269 <a name="400"><h3>400.&nbsp;redundant type cast in lib.allocator.members</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Markus Mauhart&nbsp; <b>Date:</b>&nbsp;27 Feb 2003</p>
12270 <p>
12271 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> allocator members, contains
12272 the following 3 lines:
12273 </p>
12274
12275 <pre>  12 Returns: new((void *) p) T( val)
12276      void destroy(pointer p);
12277   13 Returns: ((T*) p)-&gt;~T()
12278 </pre>
12279
12280 <p>
12281 The type cast "(T*) p" in the last line is redundant cause
12282 we know that std::allocator&lt;T&gt;::pointer is a typedef for T*.
12283 </p>
12284 <p><b>Proposed resolution:</b></p>
12285 <p>
12286 Replace "((T*) p)" with "p".
12287 </p>
12288 <p><b>Rationale:</b></p>
12289 <p>Just a typo, this is really editorial.</p>
12290 <hr>
12291 <a name="402"><h3>402.&nbsp;wrong new expression in [some_]allocator::construct</h3></a><p><b>Section:</b>&nbsp;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>, 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>, &nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Markus Mauhart&nbsp; <b>Date:</b>&nbsp;27 Feb 2003</p>
12292 <p>
12293 This applies to the new expression that is contained in both par12 of
12294 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> and in par2 (table 32) of 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>.
12295 I think this new expression is wrong, involving unintended side
12296 effects.
12297 </p>
12298
12299
12300 <p>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>  contains the following 3 lines:</p>
12301
12302 <pre>  11 Returns: the largest value N for which the call allocate(N,0) might succeed.
12303      void construct(pointer p, const_reference val);
12304   12 Returns: new((void *) p) T( val)
12305 </pre>
12306
12307
12308 <p>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> in table 32 has the following line:</p>
12309 <pre>  a.construct(p,t)   Effect: new((void*)p) T(t)
12310 </pre>
12311
12312 <p>
12313 .... with the prerequisits coming from the preceding two paragraphs,
12314 especially from table 31:
12315 </p>
12316
12317 <pre>  alloc&lt;T&gt;             a     ;// an allocator for T
12318   alloc&lt;T&gt;::pointer    p     ;// random access iterator
12319                               // (may be different from T*)
12320   alloc&lt;T&gt;::reference  r = *p;// T&amp;
12321   T const&amp;             t     ;
12322 </pre>
12323
12324 <p>
12325 Cause of using "new" but not "::new", any existing "T::operator new"
12326 function will hide the global placement new function. When there is no
12327 "T::operator new" with adequate signature,
12328 every_alloc&lt;T&gt;::construct(..) is ill-formed, and most
12329 std::container&lt;T,every_alloc&lt;T&gt;&gt; use it; a workaround
12330 would be adding placement new and delete functions with adequate
12331 signature and semantic to class T, but class T might come from another
12332 party. Maybe even worse is the case when T has placement new and
12333 delete functions with adequate signature but with "unknown" semantic:
12334 I dont like to speculate about it, but whoever implements
12335 any_container&lt;T,any_alloc&gt; and wants to use construct(..)
12336 probably must think about it.
12337 </p>
12338 <p><b>Proposed resolution:</b></p>
12339 <p>
12340 Replace "new" with "::new" in both cases.
12341 </p>
12342 <hr>
12343 <a name="403"><h3>403.&nbsp;basic_string::swap should not throw exceptions</h3></a><p><b>Section:</b>&nbsp;21.3.5.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::swap"> [lib.string::swap]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;25 Mar 2003</p>
12344
12345 <p>
12346 std::basic_string, 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> paragraph 2 says that
12347 basic_string "conforms to the requirements of a Sequence, as specified
12348 in (23.1.1)." The sequence requirements specified in (23.1.1) to not
12349 include any prohibition on swap members throwing exceptions.
12350 </p>
12351
12352 <p>
12353 Section 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> paragraph 10 does limit conditions under
12354 which exceptions may be thrown, but applies only to "all container
12355 types defined in this clause" and so excludes basic_string::swap
12356 because it is defined elsewhere.
12357 </p>
12358
12359 <p>
12360 Eric Niebler points out that 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a> paragraph 5 explicitly
12361 permits basic_string::swap to invalidates iterators, which is
12362 disallowed by 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> paragraph 10. Thus the standard would
12363 be contradictory if it were read or extended to read as having
12364 basic_string meet 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> paragraph 10 requirements.
12365 </p>
12366
12367 <p>
12368 Yet several LWG members have expressed the belief that the original
12369 intent was that basic_string::swap should not throw exceptions as
12370 specified by 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> paragraph 10, and that the standard is
12371 unclear on this issue. The complexity of basic_string::swap is
12372 specified as "constant time", indicating the intent was to avoid
12373 copying (which could cause a bad_alloc or other exception). An
12374 important use of swap is to ensure that exceptions are not thrown in
12375 exception-safe code.
12376 </p>
12377
12378 <p>
12379 Note: There remains long standing concern over whether or not it is
12380 possible to reasonably meet the 23.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.requirements"> [lib.container.requirements]</a> paragraph 10 swap
12381 requirements when allocators are unequal. The specification of
12382 basic_string::swap exception requirements is in no way intended to
12383 address, prejudice, or otherwise impact that concern.
12384 </p>
12385
12386
12387
12388
12389
12390 <p><b>Proposed resolution:</b></p>
12391 <p>
12392 In 21.3.5.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::swap"> [lib.string::swap]</a>, add a throws clause:
12393 </p>
12394
12395 <p>
12396 Throws: Shall not throw exceptions.
12397 </p>
12398 <hr>
12399 <a name="404"><h3>404.&nbsp;May a replacement allocation function be declared inline?</h3></a><p><b>Section:</b>&nbsp;17.4.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a>, 18.5.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete"> [lib.new.delete]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;24 Apr 2003</p>
12400 <p>
12401 The eight basic dynamic memory allocation functions (single-object
12402 and array versions of ::operator new and ::operator delete, in the
12403 ordinary and nothrow forms) are replaceable.  A C++ program may
12404 provide an alternative definition for any of them, which will be used
12405 in preference to the implementation's definition.
12406 </p>
12407
12408 <p>
12409 Three different parts of the standard mention requirements on
12410 replacement functions: 17.4.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a>, 18.5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a>
12411 and 18.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.array"> [lib.new.delete.array]</a>, and 3.7.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/basic.html#basic.stc.dynamic"> [basic.stc.dynamic]</a>.
12412 </p>
12413
12414 <p>None of these three places say whether a replacement function may
12415   be declared inline.  18.5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.new.delete.single"> [lib.new.delete.single]</a> paragraph 2 specifies a
12416   signature for the replacement function, but that's not enough:
12417   the <tt>inline</tt> specifier is not part of a function's signature.
12418   One might also reason from 7.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/dcl.html#dcl.fct.spec"> [dcl.fct.spec]</a> paragraph 2, which
12419   requires that "an inline function shall be defined in every
12420   translation unit in which it is used," but this may not be quite
12421   specific enough either.  We should either explicitly allow or
12422   explicitly forbid inline replacement memory allocation
12423   functions.</p>
12424 <p><b>Proposed resolution:</b></p>
12425 <p>
12426 Add a new sentence to the end of 17.4.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.replacement.functions"> [lib.replacement.functions]</a> paragraph 3:
12427 "The program's definitions shall not be specified as <tt>inline</tt>.
12428 No diagnostic is required."
12429 </p>
12430
12431 <p><i>[Kona: added "no diagnostic is required"]</i></p>
12432
12433 <p><b>Rationale:</b></p>
12434 <p>
12435 The fact that <tt>inline</tt> isn't mentioned appears to have been
12436 nothing more than an oversight.  Existing implementations do not
12437 permit inline functions as replacement memory allocation functions.
12438 Providing this functionality would be difficult in some cases, and is
12439 believed to be of limited value.
12440 </p>
12441 <hr>
12442 <a name="405"><h3>405.&nbsp;qsort and POD</h3></a><p><b>Section:</b>&nbsp;25.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.c.library"> [lib.alg.c.library]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Ray Lischner&nbsp; <b>Date:</b>&nbsp;08 Apr 2003</p>
12443 <p>
12444 Section 25.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.c.library"> [lib.alg.c.library]</a> describes bsearch and qsort, from the C
12445 standard library. Paragraph 4 does not list any restrictions on qsort,
12446 but it should limit the base parameter to point to POD.  Presumably,
12447 qsort sorts the array by copying bytes, which requires POD.
12448 </p>
12449 <p><b>Proposed resolution:</b></p>
12450 <p>
12451 In 25.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.c.library"> [lib.alg.c.library]</a> paragraph 4, just after the declarations and
12452 before the nonnormative note, add these words: "both of which have the
12453 same behavior as the original declaration.  The behavior is undefined
12454 unless the objects in the array pointed to by <i>base</i> are of POD
12455 type."
12456 </p>
12457
12458 <p><i>[Something along these lines is clearly necessary.  Matt
12459   provided wording.]</i></p>
12460 <hr>
12461 <a name="406"><h3>406.&nbsp;vector::insert(s) exception safety</h3></a><p><b>Section:</b>&nbsp;23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;27 Apr 2003</p>
12462 <p>
12463 There is a possible defect in the standard: the standard text was
12464 never intended to prevent arbitrary ForwardIterators, whose operations
12465 may throw exceptions, from being passed, and it also wasn't intended
12466 to require a temporary buffer in the case where ForwardIterators were
12467 passed (and I think most implementations don't use one).  As is, the
12468 standard appears to impose requirements that aren't met by any
12469 existing implementation.
12470 </p>
12471 <p><b>Proposed resolution:</b></p>
12472 <p>Replace 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a> paragraph 1 with:</p>
12473 <blockquote>
12474   1- Notes: Causes reallocation if the new size is greater than the
12475   old capacity. If no reallocation happens, all the iterators and
12476   references before the insertion point remain valid. If an exception
12477   is thrown other than by the copy constructor or assignment operator
12478   of T or by any InputIterator operation there are no effects.
12479 </blockquote>
12480
12481 <p><i>[We probably need to say something similar for deque.]</i></p>
12482
12483 <hr>
12484 <a name="407"><h3>407.&nbsp;Can singular iterators be destroyed?</h3></a><p><b>Section:</b>&nbsp;24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;3 June 2003</p>
12485 <p>
12486 Clause 24.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.requirements"> [lib.iterator.requirements]</a>, paragraph 5, says that the only expression
12487 that is defined for a singular iterator is "an assignment of a
12488 non-singular value to an iterator that holds a singular value".  This
12489 means that destroying a singular iterator (e.g. letting an automatic
12490 variable go out of scope) is technically undefined behavior.  This
12491 seems overly strict, and probably unintentional.
12492 </p>
12493 <p><b>Proposed resolution:</b></p>
12494 <p>
12495 Change the sentence in question to "... the only exceptions are
12496 destroying an iterator that holds a singular value, or the assignment
12497 of a non-singular value to an iterator that holds a singular value."
12498 </p>
12499 <hr>
12500 <a name="409"><h3>409.&nbsp;Closing an fstream should clear error state</h3></a><p><b>Section:</b>&nbsp;27.8.1.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a>, 27.8.1.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ofstream.members"> [lib.ofstream.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Nathan Myers&nbsp; <b>Date:</b>&nbsp;3 June 2003</p>
12501 <p>
12502 A strict reading of 27.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstreams"> [lib.fstreams]</a> shows that opening or
12503 closing a basic_[io]fstream does not affect the error bits.  This
12504 means, for example, that if you read through a file up to EOF, and
12505 then close the stream and reopen it at the beginning of the file,
12506 the EOF bit in the stream's error state is still set.  This is
12507 counterintuitive.
12508 </p>
12509 <p>
12510 The LWG considered this issue once before, as issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#22">22</a>,
12511 and put in a footnote to clarify that the strict reading was indeed
12512 correct.  We did that because we believed the standard was
12513 unambiguous and consistent, and that we should not make architectural
12514 changes in a TC.  Now that we're working on a new revision of the
12515 language, those considerations no longer apply.
12516 </p>
12517 <p><b>Proposed resolution:</b></p>
12518
12519 <p>Change 27.8.1.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a>, para. 3 from:</p>
12520
12521 <blockquote>
12522 Calls rdbuf()-&gt;open(s,mode|in). If that function returns a null
12523 pointer, calls setstate(failbit) (which may throw ios_base::failure
12524 [Footnote: (lib.iostate.flags)].
12525 </blockquote>
12526
12527 <p>to:</p>
12528
12529 <blockquote>Calls rdbuf()-&gt;open(s,mode|in). If that function returns
12530 a null pointer, calls setstate(failbit) (which may throw
12531 ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
12532 </blockquote>
12533
12534 <p>Change 27.8.1.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ofstream.members"> [lib.ofstream.members]</a>, para. 3 from:</p>
12535
12536 <blockquote>Calls rdbuf()-&gt;open(s,mode|out). If that function
12537 returns a null pointer, calls setstate(failbit) (which may throw
12538 ios_base::failure [Footnote: (lib.iostate.flags)).
12539 </blockquote>
12540
12541 <p>to:</p>
12542
12543 <blockquote>Calls rdbuf()-&gt;open(s,mode|out). If that function
12544 returns a null pointer, calls setstate(failbit) (which may throw
12545 ios_base::failure [Footnote: (lib.iostate.flags)), else calls clear().
12546 </blockquote>
12547
12548 <p>Change 27.8.1.13 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstream.members"> [lib.fstream.members]</a>, para. 3 from:</p>
12549
12550 <blockquote>Calls rdbuf()-&gt;open(s,mode), If that function returns a
12551 null pointer, calls setstate(failbit), (which may throw
12552 ios_base::failure). (lib.iostate.flags) )
12553 </blockquote>
12554
12555 <p>to:</p>
12556
12557 <blockquote>Calls rdbuf()-&gt;open(s,mode), If that function returns a
12558 null pointer, calls setstate(failbit), (which may throw
12559 ios_base::failure). (lib.iostate.flags) ), else calls clear().
12560 </blockquote>
12561
12562
12563
12564 <p><i>[Kona: the LWG agrees this is a good idea.  Post-Kona: Bill
12565 provided wording.  He suggests having open, not close, clear the error
12566 flags.]</i></p>
12567
12568 <p><i>[Post-Sydney: Howard provided a new proposed resolution.  The
12569   old one didn't make sense because it proposed to fix this at the
12570   level of basic_filebuf, which doesn't have access to the stream's
12571   error state.  Howard's proposed resolution fixes this at the level
12572   of the three fstream class template instead.]</i></p>
12573
12574 <hr>
12575 <a name="410"><h3>410.&nbsp;Missing semantics for stack and queue comparison operators</h3></a><p><b>Section:</b>&nbsp;23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.cons"> [lib.list.cons]</a>, 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.modifiers"> [lib.list.modifiers]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Hans Bos&nbsp; <b>Date:</b>&nbsp;7 Jun 2003</p>
12576 <p>
12577 Sections 23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.cons"> [lib.list.cons]</a> and 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.modifiers"> [lib.list.modifiers]</a> list
12578 comparison operators (==, !=, &lt;, &lt;=, &gt;, =&gt;) for queue and
12579 stack.  Only the semantics for queue::operator== (23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.cons"> [lib.list.cons]</a> par2) and queue::operator&lt; (23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.cons"> [lib.list.cons]</a>
12580 par3) are defined.
12581 </p>
12582 <p><b>Proposed resolution:</b></p>
12583
12584 <p>Add the following new paragraphs after 23.2.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.cons"> [lib.list.cons]</a>
12585   paragraph 3:</p>
12586
12587 <blockquote>
12588
12589 <pre>  operator!=
12590 </pre>
12591 <p>Returns: <tt>x.c != y.c</tt></p>
12592
12593 <pre>  operator&gt;
12594 </pre>
12595 <p>Returns: <tt>x.c &gt; y.c</tt></p>
12596
12597 <pre>  operator&lt;=
12598 </pre>
12599 <p>Returns: <tt>x.c &lt;= y.c</tt></p>
12600
12601 <pre>  operator&gt;=
12602 </pre>
12603 <p>Returns: <tt>x.c &gt;= y.c</tt></p>
12604
12605 </blockquote>
12606
12607 <p>Add the following paragraphs at the end of 23.2.3.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.list.modifiers"> [lib.list.modifiers]</a>:</p>
12608
12609 <blockquote>
12610
12611 <pre>  operator==
12612 </pre>
12613 <p>Returns: <tt>x.c == y.c</tt></p>
12614
12615 <pre>  operator&lt;
12616 </pre>
12617 <p>Returns: <tt>x.c &lt; y.c</tt></p>
12618
12619 <pre>  operator!=
12620 </pre>
12621 <p>Returns: <tt>x.c != y.c</tt></p>
12622
12623 <pre>  operator&gt;
12624 </pre>
12625 <p>Returns: <tt>x.c &gt; y.c</tt></p>
12626
12627 <pre>  operator&lt;=
12628 </pre>
12629 <p>Returns: <tt>x.c &lt;= y.c</tt></p>
12630
12631 <pre>  operator&gt;=
12632 </pre>
12633 <p>Returns: <tt>x.c &gt;= y.c</tt></p>
12634
12635 </blockquote>
12636
12637
12638 <p><i>[Kona: Matt provided wording.]</i></p>
12639
12640 <p><b>Rationale:</b></p>
12641 There isn't any real doubt about what these operators are
12642 supposed to do, but we ought to spell it out.
12643 <hr>
12644 <a name="411"><h3>411.&nbsp;Wrong names of set member functions</h3></a><p><b>Section:</b>&nbsp;25.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.set.operations"> [lib.alg.set.operations]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Daniel Frey&nbsp; <b>Date:</b>&nbsp;9 Jul 2003</p>
12645 <p>
12646 25.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.set.operations"> [lib.alg.set.operations]</a> paragraph 1 reads:
12647 "The semantics of the set operations are generalized to multisets in a
12648 standard way by defining union() to contain the maximum number of
12649 occurrences of every element, intersection() to contain the minimum, and
12650 so on."
12651 </p>
12652
12653 <p>
12654 This is wrong.  The name of the functions are set_union() and
12655 set_intersection(), not union() and intersection().
12656 </p>
12657 <p><b>Proposed resolution:</b></p>
12658 <p>Change that sentence to use the correct names.</p>
12659 <hr>
12660 <a name="412"><h3>412.&nbsp;Typo in 27.4.4.3</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;10 Jul 2003</p>
12661 <p>
12662 The Effects clause in 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> paragraph 5 says that the
12663 function only throws if the respective bits are already set prior to
12664 the function call. That's obviously not the intent. The typo ought to
12665 be corrected and the text reworded as: "If (<i>state</i> &amp;
12666 exceptions()) == 0, returns. ..."
12667 </p>
12668 <p><b>Proposed resolution:</b></p>
12669 <p>
12670 In 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> paragraph 5, replace "If (rdstate() &amp;
12671 exceptions()) == 0" with "If ((state | (rdbuf() ? goodbit : badbit))
12672 &amp; exceptions()) == 0".
12673 </p>
12674
12675 <p><i>[Kona: the original proposed resolution wasn't quite right.  We
12676   really do mean rdstate(); the ambiguity is that the wording in the
12677   standard doesn't make it clear whether we mean rdstate() before
12678   setting the new state, or rdsate() after setting it.  We intend the
12679   latter, of course. Post-Kona: Martin provided wording.]</i></p>
12680
12681 <hr>
12682 <a name="413"><h3>413.&nbsp;Proposed resolution to LDR#64 still wrong</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Bo Persson&nbsp; <b>Date:</b>&nbsp;13 Jul 2003</p>
12683 <p>
12684 The second sentence of the proposed resolution says:
12685 </p>
12686
12687 <p>
12688 "If it inserted no characters because it caught an exception thrown
12689 while extracting characters from sb and ..."
12690 </p>
12691
12692 <p>
12693 However, we are not extracting from sb, but extracting from the
12694 basic_istream (*this) and inserting into sb. I can't really tell if
12695 "extracting" or "sb" is a typo.
12696 </p>
12697
12698 <p><i>[
12699 Sydney: Definitely a real issue. We are, indeed, extracting characters
12700 from an istream and not from sb. The problem was there in the FDIS and
12701 wasn't fixed by issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#64">64</a>. Probably what was intended was
12702 to have *this instead of sb. We're talking about the exception flag
12703 state of a basic_istream object, and there's only one basic_istream
12704 object in this discussion, so that would be a consistent
12705 interpretation.  (But we need to be careful: the exception policy of
12706 this member function must be consistent with that of other
12707 extractors.)  PJP will provide wording.
12708 ]</i></p>
12709
12710 <p><b>Proposed resolution:</b></p>
12711 <p>Change the sentence from:</p>
12712
12713 <blockquote>
12714 If it inserted no characters because it caught an exception thrown
12715 while extracting characters from sb and failbit is on in exceptions(),
12716 then the caught exception is rethrown.
12717 </blockquote>
12718
12719 <p>to:</p>
12720
12721 <blockquote>
12722 If it inserted no characters because it caught an exception thrown
12723 while extracting characters from *this and failbit is on in exceptions(),
12724 then the caught exception is rethrown.
12725 </blockquote>
12726 <hr>
12727 <a name="414"><h3>414.&nbsp;Which iterators are invalidated by v.erase()?</h3></a><p><b>Section:</b>&nbsp;23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;19 Aug 2003</p>
12728 <p>
12729 Consider the following code fragment:
12730 </p>
12731 <blockquote>
12732 <pre>int A[8] = { 1,3,5,7,9,8,4,2 };
12733 std::vector&lt;int&gt; v(A, A+8);
12734
12735 std::vector&lt;int&gt;::iterator i1 = v.begin() + 3;
12736 std::vector&lt;int&gt;::iterator i2 = v.begin() + 4;
12737 v.erase(i1);
12738 </pre>
12739 </blockquote>
12740
12741 <p>
12742 Which iterators are invalidated by <tt>v.erase(i1)</tt>: i1, i2,
12743 both, or neither?
12744 </p>
12745
12746 <p>
12747 On all existing implementations that I know of, the status of i1 and
12748 i2 is the same: both of them will be iterators that point to some
12749 elements of the vector (albeit not the same elements they did
12750 before).  You won't get a crash if you use them.  Depending on
12751 exactly what you mean by "invalidate", you might say that neither one
12752 has been invalidated because they still point to <i>something</i>,
12753 or you might say that both have been invalidated because in both
12754 cases the elements they point to have been changed out from under the
12755 iterator.
12756 </p>
12757
12758 <p>
12759 The standard doesn't say either of those things.  It says that erase
12760 invalidates all iterators and references "after the point of the
12761 erase".  This doesn't include i1, since it's at the point of the
12762 erase instead of after it.  I can't think of any sensible definition
12763 of invalidation by which one can say that i2 is invalidated but i1
12764 isn't.
12765 </p>
12766
12767 <p>
12768 (This issue is important if you try to reason about iterator validity
12769 based only on the guarantees in the standard, rather than reasoning
12770 from typical implementation techniques.  Strict debugging modes,
12771 which some programmers find useful, do not use typical implementation
12772 techniques.)
12773 </p>
12774 <p><b>Proposed resolution:</b></p>
12775 <p>
12776 In 23.2.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.stack"> [lib.stack]</a> paragraph 3, change "Invalidates all the
12777 iterators and references after the point of the erase" to
12778 "Invalidates iterators and references at or after the point of the
12779 erase".
12780 </p>
12781 <p><b>Rationale:</b></p>
12782 <p>I believe this was essentially a typographical error, and that it
12783   was taken for granted that erasing an element invalidates iterators
12784   that point to it.  The effects clause in question treats iterators
12785   and references in parallel, and it would seem counterintuitive to
12786   say that a reference to an erased value remains valid.</p>
12787 <hr>
12788 <a name="415"><h3>415.&nbsp;behavior of std::ws</h3></a><p><b>Section:</b>&nbsp;27.6.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.manip"> [lib.istream.manip]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
12789 <p>
12790 According to 27.6.1.4, the ws() manipulator is not required to construct
12791 the sentry object. The manipulator is also not a member function so the
12792 text in 27.6.1, p1 through 4 that describes the exception policy for
12793 istream member functions does not apply. That seems inconsistent with
12794 the rest of extractors and all the other input functions (i.e., ws will
12795 not cause a tied stream to be flushed before extraction, it doesn't check
12796 the stream's exceptions or catch exceptions thrown during input, and it
12797 doesn't affect the stream's gcount).
12798 </p>
12799 <p><b>Proposed resolution:</b></p>
12800 <p>
12801 Add to 27.6.1.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.manip"> [lib.istream.manip]</a>, immediately before the first sentence
12802 of paragraph 1, the following text:
12803 </p>
12804
12805     <blockquote>
12806     Behaves as an unformatted input function (as described in
12807     27.6.1.3, paragraph 1), except that it does not count the number
12808     of characters extracted and does not affect the value returned by
12809     subsequent calls to is.gcount(). After constructing a sentry
12810     object...
12811     </blockquote>
12812
12813 <p><i>[Post-Kona: Martin provided wording]</i></p>
12814
12815 <hr>
12816 <a name="420"><h3>420.&nbsp;is std::FILE a complete type?</h3></a><p><b>Section:</b>&nbsp;27.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstreams"> [lib.fstreams]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
12817 <p>
12818 7.19.1, p2, of C99 requires that the FILE type only be declared in
12819 &lt;stdio.h&gt;.  None of the (implementation-defined) members of the
12820 struct is mentioned anywhere for obvious reasons.
12821 </p>
12822
12823 <p>
12824 C++ says in 27.8.1, p2 that FILE is a type that's defined in &lt;cstdio&gt;. Is
12825 it really the intent that FILE be a complete type or is an implementation
12826 allowed to just declare it without providing a full definition?
12827 </p>
12828 <p><b>Proposed resolution:</b></p>
12829 <p>In the first sentence of 27.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstreams"> [lib.fstreams]</a> paragraph 2, change
12830   "defined" to "declared".</p>
12831 <p><b>Rationale:</b></p>
12832 <p>We don't want to impose any restrictions beyond what the C standard
12833   already says. We don't want to make anything implementation defined,
12834   because that imposes new requirements in implementations.</p>
12835 <hr>
12836 <a name="425"><h3>425.&nbsp;return value of std::get_temporary_buffer</h3></a><p><b>Section:</b>&nbsp;20.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.help"> [lib.meta.help]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
12837 <p>
12838 The standard is not clear about the requirements on the value returned from
12839 a call to get_temporary_buffer(0). In particular, it fails to specify whether
12840 the call should return a distinct pointer each time it is called (like
12841 operator new), or whether the value is unspecified (as if returned by
12842 malloc). The standard also fails to mention what the required behavior
12843 is when the argument is less than 0.
12844 </p>
12845 <p><b>Proposed resolution:</b></p>
12846 <p>Change 20.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-utilities.html#lib.meta.help"> [lib.meta.help]</a> paragraph 2 from "...or a pair of 0
12847 values if no storage can be obtained" to "...or a pair of 0 values if
12848 no storage can be obtained or if <i>n</i> &lt;= 0."</p>
12849 <p><i>[Kona: Matt provided wording]</i></p>
12850 <hr>
12851 <a name="426"><h3>426.&nbsp;search_n(), fill_n(), and generate_n() with negative n</h3></a><p><b>Section:</b>&nbsp;25.1.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.search"> [lib.alg.search]</a>, 25.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.fill"> [lib.alg.fill]</a>, 25.2.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.generate"> [lib.alg.generate]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
12852 <p>
12853 The complexity requirements for these function templates are incorrect
12854 (or don't even make sense) for negative n:</p>
12855
12856 <p>25.1.9, p7 (search_n):
12857 <br>
12858 Complexity: At most (last1 - first1) * count applications
12859 of the corresponding predicate.</p>
12860
12861 <p>25.2.5, p3 (fill_n):
12862 <br>
12863 Complexity: Exactly last - first (or n) assignments.</p>
12864 <br>
12865
12866 <p>25.2.6, p3 (generate_n):
12867 <br>
12868 Complexity: Exactly last - first (or n) assignments.</p>
12869
12870 <p>
12871 In addition, the Requirements or the Effects clauses for the latter two
12872 templates don't say anything about the behavior when n is negative.
12873 </p>
12874 <p><b>Proposed resolution:</b></p>
12875 <p>Change 25.1.9, p7 to</p>
12876
12877 <blockquote>
12878 Complexity: At most (last1 - first1) * count applications
12879 of the corresponding predicate if count is positive,
12880 or 0 otherwise.
12881 </blockquote>
12882
12883 <p>Change 25.2.5, p2 to</p>
12884 <blockquote>
12885 Effects: Assigns value through all the iterators in the range [first,
12886 last), or [first, first + n) if n is positive, none otherwise.
12887 </blockquote>
12888
12889 <p>Change 25.2.5, p3 to:</p>
12890 <blockquote>
12891 Complexity: Exactly last - first (or n if n is positive,
12892 or 0 otherwise) assignments.
12893 </blockquote>
12894
12895 <p>
12896 Change 25.2.6, p1
12897 to (notice the correction for the misspelled "through"):
12898 </p>
12899 <blockquote>
12900 Effects: Invokes the function object genand assigns the return
12901 value of gen through all the iterators in the range [first, last),
12902 or [first, first + n) if n is positive, or [first, first)
12903 otherwise.
12904 </blockquote>
12905
12906 <p>Change 25.2.6, p3 to:</p>
12907 <blockquote>
12908 Complexity: Exactly last - first (or n if n is positive,
12909 or 0 otherwise) assignments.
12910 </blockquote>
12911 <p><b>Rationale:</b></p>
12912 <p>Informally, we want to say that whenever we see a negative number
12913   we treat it the same as if it were zero.  We believe the above
12914   changes do that (although they may not be the minimal way of saying
12915   so).  The LWG considered and rejected the alternative of saying that
12916   negative numbers are undefined behavior.</p>
12917 <hr>
12918 <a name="428"><h3>428.&nbsp;string::erase(iterator) validity</h3></a><p><b>Section:</b>&nbsp;21.3.5.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::erase"> [lib.string::erase]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;18 Sep 2003</p>
12919 <p>
12920 23.1.1, p3 along with Table 67 specify as a prerequisite for a.erase(q)
12921 that q must be a valid dereferenceable iterator into the sequence a.
12922 </p>
12923
12924 <p>
12925 However, 21.3.5.5, p5 describing string::erase(p) only requires that
12926 p be a valid iterator.
12927 </p>
12928
12929 <p>
12930 This may be interepreted as a relaxation of the general requirement,
12931 which is most likely not the intent.
12932 </p>
12933 <p><b>Proposed resolution:</b></p>
12934 <p>Remove 21.3.5.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::erase"> [lib.string::erase]</a> paragraph 5.</p>
12935 <p><b>Rationale:</b></p>
12936 <p>The LWG considered two options: changing the string requirements to
12937   match the general container requirements, or just removing the
12938   erroneous string requirements altogether.  The LWG chose the latter
12939   option, on the grounds that duplicating text always risks the
12940   possibility that it might be duplicated incorrectly.</p>
12941 <hr>
12942 <a name="432"><h3>432.&nbsp;stringbuf::overflow() makes only one write position available</h3></a><p><b>Section:</b>&nbsp;27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Christian W Brock&nbsp; <b>Date:</b>&nbsp;24 Sep 2003</p>
12943 <p>27.7.1.3 par 8 says:</p>
12944 <blockquote>
12945 Notes: The function can make a write position available only if
12946     ( mode &amp; ios_base::out) != 0. To make a write position
12947     available, the function reallocates (or initially allocates) an
12948     array object with a sufficient number of elements to hold the
12949     current array object (if any), plus one additional write position.
12950     If ( mode &amp; ios_base::in) != 0, the function alters the read end
12951     pointer egptr() to point just past the new write position (as
12952     does the write end pointer epptr()).
12953 </blockquote>
12954
12955 <p>
12956 The sentences "plus one additional write position." and especially
12957     "(as does the write end pointer epptr())" COULD by interpreted
12958     (and is interpreted by at least my library vendor) as:
12959 </p>
12960
12961 <blockquote>
12962     post-condition: epptr() == pptr()+1
12963 </blockquote>
12964
12965 <p>
12966 This WOULD force sputc() to call the virtual overflow() each time.
12967 </p>
12968
12969 <p>The proposed change also affects Defect Report 169.</p>
12970
12971 <p><b>Proposed resolution:</b></p>
12972 <p>27.7.1.1/2 Change:</p>
12973
12974 <blockquote>
12975 2- Notes: The function allocates no array object.
12976 </blockquote>
12977
12978 <p>
12979 to:
12980 </p>
12981
12982 <blockquote>
12983 2- Postcondition: str() == "".
12984 </blockquote>
12985
12986 <p>
12987 27.7.1.1/3 Change:
12988 </p>
12989
12990 <blockquote>
12991 <p>
12992 -3- Effects: Constructs an object of class basic_stringbuf,
12993 initializing the base class with basic_streambuf()
12994 (lib.streambuf.cons), and initializing mode with which . Then copies
12995 the content of str into the basic_stringbuf underlying character
12996 sequence and initializes the input and output sequences according to
12997 which. If which &amp; ios_base::out is true, initializes the output
12998 sequence with the underlying sequence. If which &amp; ios_base::in is
12999 true, initializes the input sequence with the underlying sequence.
13000 </p>
13001 </blockquote>
13002
13003 <p>to:</p>
13004
13005 <blockquote>
13006 <p>
13007 -3- Effects: Constructs an object of class basic_stringbuf,
13008 initializing the base class with basic_streambuf()
13009 (lib.streambuf.cons), and initializing mode with which. Then copies
13010 the content of str into the basic_stringbuf underlying character
13011 sequence. If which &amp; ios_base::out is true, initializes the output
13012 sequence such that pbase() points to the first underlying character,
13013 epptr() points one past the last underlying character, and if (which &amp;
13014 ios_base::ate) is true, pptr() is set equal to
13015 epptr() else pptr() is set equal to pbase(). If which &amp; ios_base::in
13016 is true, initializes the input sequence such that eback() and gptr()
13017 point to the first underlying character and egptr() points one past
13018 the last underlying character.
13019 </p>
13020 </blockquote>
13021
13022 <p>27.7.1.2/1 Change:</p>
13023
13024 <blockquote>
13025 <p>
13026 -1- Returns: A basic_string object whose content is equal to the
13027 basic_stringbuf underlying character sequence. If the buffer is only
13028 created in input mode, the underlying character sequence is equal to
13029 the input sequence; otherwise, it is equal to the output sequence. In
13030 case of an empty underlying character sequence, the function returns
13031 basic_string&lt;charT,traits,Allocator&gt;().
13032 </p>
13033 </blockquote>
13034
13035 <p>to:</p>
13036
13037 <blockquote>
13038 <p>
13039 -1- Returns: A basic_string object whose content is equal to the
13040 basic_stringbuf underlying character sequence. If the basic_stringbuf
13041 was created only in input mode, the resultant basic_string contains
13042 the character sequence in the range [eback(), egptr()).  If the
13043 basic_stringbuf was created with (which &amp; ios_base::out) being true
13044 then the resultant basic_string contains the character sequence in the
13045 range [pbase(), high_mark) where high_mark represents the position one
13046 past the highest initialized character in the buffer.  Characters can
13047 be initialized either through writing to the stream, or by
13048 constructing the basic_stringbuf with a basic_string, or by calling
13049 the str(basic_string) member function.  In the case of calling the
13050 str(basic_string) member function, all characters initialized prior to
13051 the call are now considered uninitialized (except for those
13052 characters re-initialized by the new basic_string).  Otherwise the
13053 basic_stringbuf has been created in neither input nor output mode and
13054 a zero length basic_string is returned.
13055 </p>
13056 </blockquote>
13057
13058 <p>
13059 27.7.1.2/2 Change:
13060 </p>
13061
13062 <blockquote>
13063 <p>
13064 -2- Effects: If the basic_stringbuf's underlying character sequence is
13065 not empty, deallocates it. Then copies the content of s into the
13066 basic_stringbuf underlying character sequence and initializes the
13067 input and output sequences according to the mode stored when creating
13068 the basic_stringbuf object. If (mode&amp;ios_base::out) is true, then
13069 initializes the output sequence with the underlying sequence. If
13070 (mode&amp;ios_base::in) is true, then initializes the input sequence with
13071 the underlying sequence.
13072 </p>
13073 </blockquote>
13074
13075 <p>to:</p>
13076
13077 <blockquote>
13078 <p>
13079 -2- Effects: Copies the content of s into the basic_stringbuf
13080 underlying character sequence. If mode &amp; ios_base::out is true,
13081 initializes the output sequence such that pbase() points to the first
13082 underlying character, epptr() points one past the last underlying
13083 character, and if (mode &amp; ios_base::ate) is true,
13084 pptr() is set equal to epptr() else pptr() is set equal to pbase(). If
13085 mode &amp; ios_base::in is true, initializes the input sequence such that
13086 eback() and gptr() point to the first underlying character and egptr()
13087 points one past the last underlying character.
13088 </p>
13089 </blockquote>
13090
13091 <p>Remove 27.2.1.2/3.  (Same rationale as issue 238: incorrect and unnecessary.)</p>
13092
13093 <p>27.7.1.3/1 Change:</p>
13094
13095 <blockquote>
13096 <p>
13097 1- Returns: If the input sequence has a read position available,
13098 returns traits::to_int_type(*gptr()).  Otherwise, returns
13099 traits::eof().
13100 </p>
13101 </blockquote>
13102
13103 <p>to:</p>
13104
13105 <blockquote>
13106 <p>
13107 1- Returns: If the input sequence has a read position available,
13108 returns traits::to_int_type(*gptr()).  Otherwise, returns
13109 traits::eof().  Any character in the underlying buffer which has been
13110 initialized is considered to be part of the input sequence.
13111 </p>
13112 </blockquote>
13113
13114 <p>27.7.1.3/9 Change:</p>
13115
13116 <blockquote>
13117 <p>
13118 -9- Notes: The function can make a write position available only if (
13119 mode &amp; ios_base::out) != 0. To make a write position available, the
13120 function reallocates (or initially allocates) an array object with a
13121 sufficient number of elements to hold the current array object (if
13122 any), plus one additional write position. If ( mode &amp; ios_base::in) !=
13123 0, the function alters the read end pointer egptr() to point just past
13124 the new write position (as does the write end pointer epptr()).
13125 </p>
13126 </blockquote>
13127
13128 <p>to:</p>
13129
13130 <blockquote>
13131 <p>
13132 -9- The function can make a write position available only if ( mode &amp;
13133 ios_base::out) != 0. To make a write position available, the function
13134 reallocates (or initially allocates) an array object with a sufficient
13135 number of elements to hold the current array object (if any), plus one
13136 additional write position. If ( mode &amp; ios_base::in) != 0, the
13137 function alters the read end pointer egptr() to point just past the
13138 new write position.
13139 </p>
13140 </blockquote>
13141
13142 <p>27.7.1.3/12 Change:</p>
13143
13144 <blockquote>
13145 <p>
13146 -12- _ If (newoff + off) &lt; 0, or (xend - xbeg) &lt; (newoff + off), the
13147 positioning operation fails. Otherwise, the function assigns xbeg +
13148 newoff + off to the next pointer xnext .
13149 </p>
13150 </blockquote>
13151
13152 <p>to:</p>
13153
13154 <blockquote>
13155 <p>
13156 -12- _ If (newoff + off) &lt; 0, or if (newoff + off) refers to an
13157 uninitialized character (as defined in 27.7.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.members"> [lib.stringbuf.members]</a>
13158 paragraph 1), the positioning operation fails. Otherwise, the function
13159 assigns xbeg + newoff + off to the next pointer xnext .
13160 </p>
13161 </blockquote>
13162
13163 <p><i>[post-Kona: Howard provided wording.  At Kona the LWG agreed that
13164   something along these lines was a good idea, but the original
13165   proposed resolution didn't say enough about the effect of various
13166   member functions on the underlying character sequences.]</i></p>
13167
13168 <p><b>Rationale:</b></p>
13169 <p>The current basic_stringbuf description is over-constrained in such
13170 a way as to prohibit vendors from making this the high-performance
13171 in-memory stream it was meant to be.  The fundamental problem is that
13172 the pointers: eback(), gptr(), egptr(), pbase(), pptr(), epptr() are
13173 observable from a derived client, and the current description
13174 restricts the range [pbase(), epptr()) from being grown geometrically.
13175 This change allows, but does not require, geometric growth of this
13176 range.</p>
13177
13178 <p>Backwards compatibility issues: These changes will break code that
13179 derives from basic_stringbuf, observes epptr(), and depends upon
13180 [pbase(), epptr()) growing by one character on each call to overflow()
13181 (i.e. test suites).  Otherwise there are no backwards compatibility
13182 issues.</p>
13183
13184 <p>27.7.1.1/2: The non-normative note is non-binding, and if it were
13185 binding, would be over specification.  The recommended change focuses
13186 on the important observable fact.</p>
13187
13188 <p>27.7.1.1/3: This change does two things: 1.  It describes exactly
13189 what must happen in terms of the sequences.  The terms "input
13190 sequence" and "output sequence" are not well defined.  2.  It
13191 introduces a common extension: open with app or ate mode.  I concur
13192 with issue 238 that paragraph 4 is both wrong and unnecessary.</p>
13193
13194 <p>27.7.1.2/1: This change is the crux of the efficiency issue.  The
13195 resultant basic_string is not dependent upon epptr(), and thus
13196 implementors are free to grow the underlying buffer geometrically
13197 during overflow() *and* place epptr() at the end of that buffer.</p>
13198
13199 <p>27.7.1.2/2:  Made consistent with the proposed 27.7.1.1/3.</p>
13200
13201 <p>27.7.1.3/1: Clarifies that characters written to the stream beyond
13202 the initially specified string are available for reading in an i/o
13203 basic_streambuf.</p>
13204
13205 <p>27.7.1.3/9: Made normative by removing "Notes:", and removed the
13206 trailing parenthetical comment concerning epptr().</p>
13207
13208 <p>27.7.1.3/12: Restricting the positioning to [xbeg, xend) is no
13209 longer allowable since [pbase(), epptr()) may now contain
13210 uninitialized characters.  Positioning is only allowable over the
13211 initialized range.</p>
13212 <hr>
13213 <a name="434"><h3>434.&nbsp;bitset::to_string() hard to use</h3></a><p><b>Section:</b>&nbsp;23.3.5.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.bitset.members"> [lib.bitset.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;15 Oct 2003</p>
13214 <p>
13215 It has been pointed out a number of times that the bitset to_string() member
13216 function template is tedious to use since callers must explicitly specify the
13217 entire template argument list (3 arguments). At least two implementations
13218 provide a number of overloads of this template to make it easier to use.
13219 </p>
13220 <p><b>Proposed resolution:</b></p>
13221 <p>In order to allow callers to specify no template arguments at all, just the
13222 first one (charT), or the first 2 (charT and traits), in addition to all
13223 three template arguments, add the following three overloads to both the
13224 interface (declarations only) of the class template bitset as well as to
13225 section 23.3.5.2, immediately after p34, the Returns clause of the existing
13226 to_string() member function template:</p>
13227
13228 <pre>    template &lt;class charT, class traits&gt;
13229     basic_string&lt;charT, traits, allocator&lt;charT&gt; &gt;
13230     to_string () const;
13231
13232     -34.1- Returns: to_string&lt;charT, traits, allocator&lt;charT&gt; &gt;().
13233
13234     template &lt;class charT&gt;
13235     basic_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;
13236     to_string () const;
13237
13238     -34.2- Returns: to_string&lt;charT, char_traits&lt;charT&gt;, allocator&lt;charT&gt; &gt;().
13239
13240     basic_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;
13241     to_string () const;
13242
13243     -34.3- Returns: to_string&lt;char, char_traits&lt;char&gt;, allocator&lt;char&gt; &gt;().
13244 </pre>
13245
13246 <p><i>[Kona: the LWG agrees that this is an improvement over the
13247   status quo.  Dietmar thought about an alternative using a proxy
13248   object but now believes that the proposed resolution above is the
13249   right choice.
13250 ]</i></p>
13251
13252 <hr>
13253 <a name="435"><h3>435.&nbsp;bug in DR 25</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;15 Oct 2003</p>
13254
13255 <p>
13256 It has been pointed out that the proposed resolution in DR 25 may not be
13257 quite up to snuff: <br>
13258 http://gcc.gnu.org/ml/libstdc++/2003-09/msg00147.html
13259 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#25<br>
13260 </p>
13261
13262 <p>
13263 It looks like Petur is right. The complete corrected text is copied below.
13264 I think we may have have been confused by the reference to 22.2.2.2.2 and
13265 the subsequent description of `n' which actually talks about the second
13266 argument to sputn(), not about the number of fill characters to pad with.
13267 </p>
13268
13269 <p>
13270 So the question is: was the original text correct? If the intent was to
13271 follow classic iostreams then it most likely wasn't, since setting width()
13272 to less than the length of the string doesn't truncate it on output. This
13273 is also the behavior of most implementations (except for SGI's standard
13274 iostreams where the operator does truncate).
13275 </p>
13276 <p><b>Proposed resolution:</b></p>
13277 <p>Change the text in 21.3.7.9, p4 from</p>
13278     <blockquote>
13279     If bool(k) is true, inserts characters as if by calling
13280     os.rdbuf()-&gt;sputn(str.data(), n), padding as described in stage 3
13281     of lib.facet.num.put.virtuals, where n is the larger of os.width()
13282     and str.size();
13283     </blockquote>
13284 <p>to</p>
13285     <blockquote>
13286     If bool(k) is true, determines padding as described in
13287     lib.facet.num.put.virtuals, and then inserts the resulting
13288     sequence of characters <tt>seq</tt> as if by calling
13289     <tt>os.rdbuf()-&gt;sputn(seq, n)</tt>, where <tt>n</tt> is the larger of
13290     <tt>os.width()</tt> and <tt>str.size()</tt>;
13291      </blockquote>
13292
13293 <p><i>[Kona: it appears that neither the original wording, DR25, nor the
13294   proposed resolution, is quite what we want.  We want to say that
13295   the string will be output, padded to os.width() if necessary.  We
13296   don't want to duplicate the padding rules in clause 22, because
13297   they're complicated, but we need to be careful because they weren't
13298   quite written with quite this case in mind.  We need to say what
13299   the character sequence is, and then defer to clause 22.  Post-Kona:
13300   Benjamin provided wording.]</i></p>
13301
13302 <hr>
13303 <a name="436"><h3>436.&nbsp;are cv-qualified facet types valid facets?</h3></a><p><b>Section:</b>&nbsp;22.1.1.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.facet"> [lib.locale.facet]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;15 Oct 2003</p>
13304 <p>
13305 Is "const std::ctype&lt;char&gt;" a valid template argument to has_facet, use_facet,
13306 and the locale template ctor? And if so, does it designate the same Facet as
13307 the non-const "std::ctype&lt;char&gt;?" What about "volatile std::ctype&lt;char&gt;?"
13308 Different implementations behave differently: some fail to compile, others
13309 accept such types but behave inconsistently.
13310 </p>
13311 <p><b>Proposed resolution:</b></p>
13312 <p>Change 22.1.1.1.2, p1 to read:</p>
13313
13314 <p>Template parameters in this clause which are required to be facets
13315 are those named Facet in declarations. A program that passes a type
13316 that is not a facet, or a type that refers to volatile-qualified
13317 facet, as an (explicit or deduced) template parameter to a locale
13318 function expecting a facet, is ill-formed.  A const-qualified facet is
13319 a valid template argument to any locale function that expects a Facet
13320 template parameter.</p>
13321
13322 <p><i>[Kona: changed the last sentence from a footnote to normative
13323 text.]</i></p>
13324
13325 <hr>
13326 <a name="438"><h3>438.&nbsp;Ambiguity in the "do the right thing" clause</h3></a><p><b>Section:</b>&nbsp;23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;20 Oct 2003</p>
13327
13328 <p>Section 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a>, paragraphs 9-11, fixed up the problem
13329 noticed with statements like:</p>
13330 <pre>vector&lt;int&gt; v(10, 1);
13331 </pre>
13332
13333 <p>The intent of the above statement was to construct with:</p>
13334 <pre>vector(size_type, const value_type&amp;);
13335 </pre>
13336
13337 <p>but early implementations failed to compile as they bound to:</p>
13338 <pre>template &lt;class InputIterator&gt;
13339 vector(InputIterator f, InputIterator l);
13340 </pre>
13341 <p>instead.</p>
13342
13343 <p>Paragraphs 9-11 say that if InputIterator is an integral type, then the
13344 member template constructor will have the same effect as:</p>
13345 <pre>vector&lt;static_cast&lt;size_type&gt;(f), static_cast&lt;value_type&gt;(l));
13346 </pre>
13347 <p>(and similarly for the other member template functions of sequences).</p>
13348
13349 <p>There is also a note that describes one implementation technique:</p>
13350 <blockquote>
13351    One way that sequence implementors can satisfy this requirement is to
13352    specialize the member template for every integral type.
13353 </blockquote>
13354
13355 <p>This might look something like:</p>
13356 <blockquote>
13357 <pre>template &lt;class T&gt;
13358 struct vector
13359 {
13360      typedef unsigned size_type;
13361
13362      explicit vector(size_type) {}
13363      vector(size_type, const T&amp;) {}
13364
13365      template &lt;class I&gt;
13366      vector(I, I);
13367
13368      // ...
13369 };
13370
13371 template &lt;class T&gt;
13372 template &lt;class I&gt;
13373 vector&lt;T&gt;::vector(I, I) { ... }
13374
13375 template &lt;&gt;
13376 template &lt;&gt;
13377 vector&lt;int&gt;::vector(int, int) { ... }
13378
13379 template &lt;&gt;
13380 template &lt;&gt;
13381 vector&lt;int&gt;::vector(unsigned, unsigned) { ... }
13382
13383 //  ...
13384 </pre>
13385 </blockquote>
13386
13387 <p>Label this solution 'A'.</p>
13388
13389 <p>The standard also says:</p>
13390 <blockquote>
13391  Less cumbersome implementation techniques also exist.
13392 </blockquote>
13393 <p>
13394 A popular technique is to not specialize as above, but instead catch
13395 every call with the member template, detect the type of InputIterator,
13396 and then redirect to the correct logic.  Something like:
13397 </p>
13398 <blockquote>
13399 <pre>template &lt;class T&gt;
13400 template &lt;class I&gt;
13401 vector&lt;T&gt;::vector(I f, I l)
13402 {
13403      choose_init(f, l, int2type&lt;is_integral&lt;I&gt;::value&gt;());
13404 }
13405
13406 template &lt;class T&gt;
13407 template &lt;class I&gt;
13408 vector&lt;T&gt;::choose_init(I f, I l, int2type&lt;false&gt;)
13409 {
13410     // construct with iterators
13411 }
13412
13413 template &lt;class T&gt;
13414 template &lt;class I&gt;
13415 vector&lt;T&gt;::choose_init(I f, I l, int2type&lt;true&gt;)
13416 {
13417     size_type sz = static_cast&lt;size_type&gt;(f);
13418     value_type v = static_cast&lt;value_type&gt;(l);
13419     // construct with sz,v
13420 }
13421 </pre>
13422 </blockquote>
13423
13424 <p>Label this solution 'B'.</p>
13425
13426 <p>Both of these solutions solve the case the standard specifically
13427 mentions:</p>
13428 <pre>vector&lt;int&gt; v(10, 1);  // ok, vector size 10, initialized to 1
13429 </pre>
13430
13431 <p>
13432 However, (and here is the problem), the two solutions have different
13433 behavior in some cases where the value_type of the sequence is not an
13434 integral type.  For example consider:
13435 </p>
13436 <blockquote><pre>     pair&lt;char, char&gt;                     p('a', 'b');
13437      vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;   d('a', 'b');
13438 </pre></blockquote>
13439 <p>
13440 The second line of this snippet is likely an error.  Solution A catches
13441 the error and refuses to compile.  The reason is that there is no
13442 specialization of the member template constructor that looks like:
13443 </p>
13444 <pre>template &lt;&gt;
13445 template &lt;&gt;
13446 vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;::vector(char, char) { ... }
13447 </pre>
13448
13449 <p>
13450 So the expression binds to the unspecialized member template
13451 constructor, and then fails (compile time) because char is not an
13452 InputIterator.
13453 </p>
13454
13455 <p>
13456 Solution B compiles the above example though.  'a' is casted to an
13457 unsigned integral type and used to size the outer vector.  'b' is
13458 static casted to the inner vector using it's explicit constructor:
13459 </p>
13460
13461 <pre>explicit vector(size_type n);
13462 </pre>
13463
13464 <p>
13465 and so you end up with a static_cast&lt;size_type&gt;('a') by
13466 static_cast&lt;size_type&gt;('b') matrix.
13467 </p>
13468
13469 <p>
13470 It is certainly possible that this is what the coder intended.  But the
13471 explicit qualifier on the inner vector has been thwarted at any rate.
13472 </p>
13473
13474 <p>
13475 The standard is not clear whether the expression:
13476 </p>
13477
13478 <pre>     vector&lt;vector&lt;pair&lt;char, char&gt; &gt; &gt;   d('a', 'b');
13479 </pre>
13480
13481 <p>
13482 (and similar expressions) are:
13483 </p>
13484
13485 <ol>
13486 <li>  undefined behavior.</li>
13487 <li>  illegal and must be rejected.</li>
13488 <li>  legal and must be accepted.</li>
13489 </ol>
13490
13491 <p>My preference is listed in the order presented.</p>
13492
13493 <p>There are still other techniques for implementing the requirements of
13494 paragraphs 9-11, namely the "restricted template technique" (e.g.
13495 enable_if).  This technique is the most compact and easy way of coding
13496 the requirements, and has the behavior of #2 (rejects the above
13497 expression).
13498 </p>
13499
13500 <p>
13501 Choosing 1 would allow all implementation techniques I'm aware of.
13502 Choosing 2 would allow only solution 'A' and the enable_if technique.
13503 Choosing 3 would allow only solution 'B'.
13504 </p>
13505
13506 <p>
13507 Possible wording for a future standard if we wanted to actively reject
13508 the expression above would be to change "static_cast" in paragraphs
13509 9-11 to "implicit_cast" where that is defined by:
13510 </p>
13511
13512 <blockquote>
13513 <pre>template &lt;class T, class U&gt;
13514 inline
13515 T implicit_cast(const U&amp; u)
13516 {
13517      return u;
13518 }
13519 </pre>
13520 </blockquote>
13521
13522 <p><b>Proposed resolution:</b></p>
13523
13524 Replace 23.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.sequence.reqmts"> [lib.sequence.reqmts]</a> paragraphs 9 - 11 with:
13525
13526 <p>For every sequence defined in this clause and in clause lib.strings:</p>
13527
13528 <ul>
13529   <li>
13530     <p>If the constructor</p>
13531        <pre>       template &lt;class InputIterator&gt;
13532        X(InputIterator f, InputIterator l,
13533          const allocator_type&amp; a = allocator_type())
13534        </pre>
13535     <p>is called with a type InputIterator that does not qualify as
13536     an input iterator, then the constructor will behave as if the
13537     overloaded constructor:</p>
13538        <pre>       X(size_type, const value_type&amp; = value_type(),
13539          const allocator_type&amp; = allocator_type())
13540        </pre>
13541     <p>were called instead, with the arguments static_cast&lt;size_type&gt;(f), l and a, respectively.</p>
13542   </li>
13543
13544   <li>
13545     <p>If the member functions of the forms:</p>
13546        <pre>       template &lt;class InputIterator&gt;          //  such as  insert()
13547        rt fx1(iterator p, InputIterator f, InputIterator l);
13548
13549        template &lt;class InputIterator&gt;          //  such as  append(), assign()
13550        rt fx2(InputIterator f, InputIterator l);
13551
13552        template &lt;class InputIterator&gt;          //  such as  replace()
13553        rt fx3(iterator i1, iterator i2, InputIterator f, InputIterator l);
13554        </pre>
13555     <p>are called with a type InputIterator that does not qualify as
13556     an input iterator, then these functions will behave as if the
13557     overloaded member functions:</p>
13558        <pre>       rt fx1(iterator, size_type, const value_type&amp;);
13559
13560        rt fx2(size_type, const value_type&amp;);
13561
13562        rt fx3(iterator, iterator, size_type, const value_type&amp;);
13563        </pre>
13564     <p>were called instead, with the same arguments.</p>
13565   </li>
13566 </ul>
13567
13568 <p>In the previous paragraph the alternative binding will fail if f
13569 is not implicitly convertible to X::size_type or if l is not implicitly
13570 convertible to X::value_type.</p>
13571
13572 <p>
13573 The extent to which an implementation determines that a type cannot be
13574 an input iterator is unspecified, except that as a minimum integral
13575 types shall not qualify as input iterators.
13576 </p>
13577
13578
13579
13580 <p><i>[
13581 Kona: agreed that the current standard requires <tt>v('a', 'b')</tt>
13582 to be accepted, and also agreed that this is surprising behavior.  The
13583 LWG considered several options, including something like
13584 implicit_cast, which doesn't appear to be quite what we want.  We
13585 considered Howards three options: allow acceptance or rejection,
13586 require rejection as a compile time error, and require acceptance.  By
13587 straw poll (1-6-1), we chose to require a compile time error.
13588 Post-Kona: Howard provided wording.
13589 ]</i></p>
13590
13591 <p><i>[
13592 Sydney: The LWG agreed with this general direction, but there was some
13593 discomfort with the wording in the original proposed resolution.
13594 Howard submitted new wording, and we will review this again in
13595 Redmond.
13596 ]</i></p>
13597
13598 <p><i>[Redmond: one very small change in wording: the first argument
13599   is cast to size_t.  This fixes the problem of something like
13600   <tt>vector&lt;vector&lt;int&gt; &gt;(5, 5)</tt>, where int is not
13601   implicitly convertible to the value type.]</i></p>
13602
13603 <p><b>Rationale:</b></p>
13604 <p>The proposed resolution fixes:</p>
13605
13606 <pre>  vector&lt;int&gt; v(10, 1);
13607 </pre>
13608
13609 <p>
13610 since as integral types 10 and 1 must be disqualified as input
13611 iterators and therefore the (size,value) constructor is called (as
13612 if).</p>
13613
13614 <p>The proposed resolution breaks:</p>
13615
13616 <pre>  vector&lt;vector&lt;T&gt; &gt; v(10, 1);
13617 </pre>
13618
13619 <p>
13620 because the integral type 1 is not *implicitly* convertible to
13621 vector&lt;T&gt;.  The wording above requires a diagnostic.</p>
13622
13623 <p>
13624 The proposed resolution leaves the behavior of the following code
13625 unspecified.
13626 </p>
13627
13628 <pre>  struct A
13629   {
13630     operator int () const {return 10;}
13631   };
13632
13633   struct B
13634   {
13635     B(A) {}
13636   };
13637
13638   vector&lt;B&gt; v(A(), A());
13639 </pre>
13640
13641 <p>
13642 The implementation may or may not detect that A is not an input
13643 iterator and employee the (size,value) constructor.  Note though that
13644 in the above example if the B(A) constructor is qualified explicit,
13645 then the implementation must reject the constructor as A is no longer
13646 implicitly convertible to B.
13647 </p>
13648 <hr>
13649 <a name="441"><h3>441.&nbsp;Is fpos::state const?</h3></a><p><b>Section:</b>&nbsp;27.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos"> [lib.fpos]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Vincent Leloup&nbsp; <b>Date:</b>&nbsp;17 Nov 2003</p>
13650 <p>
13651 In section 27.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos.members"> [lib.fpos.members]</a> fpos&lt;stateT&gt;::state() is declared
13652 non const, but in section 27.4.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos"> [lib.fpos]</a> it is declared const.
13653 </p>
13654 <p><b>Proposed resolution:</b></p>
13655 <p>
13656 In section 27.4.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fpos.members"> [lib.fpos.members]</a>, change the declaration of
13657 <tt>fpos&lt;stateT&gt;::state()</tt> to const.
13658 </p>
13659 <hr>
13660 <a name="442"><h3>442.&nbsp;sentry::operator bool() inconsistent signature</h3></a><p><b>Section:</b>&nbsp;27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Vincent Leloup&nbsp; <b>Date:</b>&nbsp;18 Nov 2003</p>
13661 <p>
13662 In section 27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a> paragraph 4, in description part
13663 basic_ostream&lt;charT, traits&gt;::sentry::operator bool() is declared
13664 as non const, but in section 27.6.2.3, in synopsis it is declared
13665 const.
13666 </p>
13667 <p><b>Proposed resolution:</b></p>
13668 <p>
13669 In section 27.6.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream::sentry"> [lib.ostream::sentry]</a> paragraph 4, change the declaration
13670 of <tt>sentry::operator bool()</tt> to const.
13671 </p>
13672 <hr>
13673 <a name="443"><h3>443.&nbsp;filebuf::close() inconsistent use of EOF</h3></a><p><b>Section:</b>&nbsp;27.8.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.members"> [lib.filebuf.members]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Vincent Leloup&nbsp; <b>Date:</b>&nbsp;20 Nov 2003</p>
13674 <p>
13675 In section 27.8.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.filebuf.members"> [lib.filebuf.members]</a> par6, in effects description of
13676 basic_filebuf&lt;charT, traits&gt;::close(), overflow(EOF) is used twice;
13677 should be overflow(traits::eof()).
13678 </p>
13679 <p><b>Proposed resolution:</b></p>
13680 <p>
13681 Change overflow(EOF) to overflow(traits::eof()).
13682 </p>
13683 <hr>
13684 <a name="444"><h3>444.&nbsp;Bad use of casts in fstream</h3></a><p><b>Section:</b>&nbsp;27.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstreams"> [lib.fstreams]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Vincent Leloup&nbsp; <b>Date:</b>&nbsp;20 Nov 2003</p>
13685 <p>
13686 27.8.1.7 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ifstream.members"> [lib.ifstream.members]</a> p1, 27.8.1.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ofstream.members"> [lib.ofstream.members]</a> p1, 27.8.1.13 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstream.members"> [lib.fstream.members]</a> p1 seems have same problem as exposed in LWG issue
13687 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#252">252</a>.
13688 </p>
13689 <p><b>Proposed resolution:</b></p>
13690
13691 <p><i>[Sydney: Genuine defect. 27.8.1.13 needs a cast to cast away
13692  constness. The other two places are stylistic: we could change the
13693  C-style casts to const_cast. Post-Sydney: Howard provided wording.
13694 ]</i></p>
13695
13696 <p>Change 27.8.1.7/1 from:</p>
13697 <blockquote>
13698   Returns: (basic_filebuf&lt;charT,traits&gt;*)&amp;sb.
13699 </blockquote>
13700
13701 <p>to:</p>
13702 <blockquote>
13703   Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
13704 </blockquote>
13705
13706 <p>Change 27.8.1.10/1 from:</p>
13707 <blockquote>
13708   Returns: (basic_filebuf&lt;charT,traits&gt;*)&amp;sb.
13709 </blockquote>
13710
13711 <p>to:</p>
13712 <blockquote>
13713   Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
13714 </blockquote>
13715
13716 <p>Change 27.8.1.13/1 from:</p>
13717 <blockquote>
13718   Returns: &amp;sb.
13719 </blockquote>
13720
13721 <p>to:</p>
13722 <blockquote>
13723   Returns: const_cast&lt;basic_filebuf&lt;charT,traits&gt;*&gt;(&amp;sb).
13724 </blockquote>
13725
13726
13727
13728 <hr>
13729 <a name="445"><h3>445.&nbsp;iterator_traits::reference unspecified for some iterator categories</h3></a><p><b>Section:</b>&nbsp;24.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.traits"> [lib.iterator.traits]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;9 Dec 2003</p>
13730 <p>
13731 The standard places no restrictions at all on the reference type
13732 of input, output, or forward iterators (for forward iterators it
13733 only specifies that *x must be value_type&amp; and doesn't mention
13734 the reference type).  Bidirectional iterators' reference type is
13735 restricted only by implication, since the base iterator's
13736 reference type is used as the return type of reverse_iterator's
13737 operator*, which must be T&amp; in order to be a conforming forward
13738 iterator.
13739 </p>
13740
13741 <p>
13742 Here's what I think we ought to be able to expect from an input
13743 or forward iterator's reference type R, where a is an iterator
13744 and V is its value_type
13745 </p>
13746
13747 <ul>
13748   <li>
13749       *a is convertible to R
13750   </li>
13751
13752   <li>
13753       R is convertible to V
13754   </li>
13755
13756   <li>
13757       static_cast&lt;V&gt;(static_cast&lt;R&gt;(*a)) is equivalent to
13758       static_cast&lt;V&gt;(*a)
13759   </li>
13760 </ul>
13761
13762 <p>A mutable forward iterator ought to satisfy, for x of type V:</p>
13763   <li>
13764       { R r = *a; r = x; } is equivalent to *a = x;
13765   </li>
13766
13767 <p>
13768 I think these requirements capture existing container iterators
13769 (including vector&lt;bool&gt;'s), but render istream_iterator invalid;
13770 its reference type would have to be changed to a constant
13771 reference.
13772 </p>
13773
13774
13775 <p>
13776 (Jeremy Siek) During the discussion in Sydney, it was felt that a
13777 simpler long term solution for this was needed. The solution proposed
13778 was to require <tt>reference</tt> to be the same type as <tt>*a</tt>
13779 and <tt>pointer</tt> to be the same type as <tt>a-&gt;</tt>.  Most
13780 iterators in the Standard Library already meet this requirement. Some
13781 iterators are output iterators, and do not need to meet the
13782 requirement, and others are only specified through the general
13783 iterator requirements (which will change with this resolution). The
13784 sole case where there is an explicit definition of the reference type
13785 that will need to change is <tt>istreambuf_iterator</tt> which returns
13786 <tt>charT</tt> from <tt>operator*</tt> but has a reference type of
13787 <tt>charT&amp;</tt>. We propose changing the reference type of
13788 <tt>istreambuf_iterator</tt> to <tt>charT</tt>.
13789 </p>
13790
13791 <p>The other option for resolving the issue with <tt>pointer</tt>,
13792   mentioned in the note below, is to remove <tt>pointer</tt>
13793   altogether. I prefer placing requirements on <tt>pointer</tt> to
13794   removing it for two reasons. First, <tt>pointer</tt> will become
13795   useful for implementing iterator adaptors and in particular,
13796   <tt>reverse_iterator</tt> will become more well defined. Second,
13797   removing <tt>pointer</tt> is a rather drastic and publicly-visible
13798   action to take.</p>
13799
13800 <p>The proposed resolution technically enlarges the requirements for
13801 iterators, which means there are existing iterators (such as
13802 <tt>istreambuf_iterator</tt>, and potentially some programmer-defined
13803 iterators) that will no longer meet the requirements. Will this break
13804 existing code? The scenario in which it would is if an algorithm
13805 implementation (say in the Standard Library) is changed to rely on
13806 <tt>iterator_traits::reference</tt>, and then is used with one of the
13807 iterators that do not have an appropriately defined
13808 <tt>iterator_traits::reference</tt>.
13809 </p>
13810
13811
13812 <p>The proposed resolution makes one other subtle change. Previously,
13813 it was required that output iterators have a <tt>difference_type</tt>
13814 and <tt>value_type</tt> of <tt>void</tt>, which means that a forward
13815 iterator could not be an output iterator. This is clearly a mistake,
13816 so I've changed the wording to say that those types may be
13817 <tt>void</tt>.
13818 </p>
13819
13820 <p><b>Proposed resolution:</b></p>
13821
13822 <p>In 24.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.traits"> [lib.iterator.traits]</a>, after:</p>
13823
13824 <blockquote>
13825 be defined as the iterator's difference type, value type and iterator
13826 category, respectively.
13827 </blockquote>
13828
13829 <p>add</p>
13830
13831 <blockquote>
13832 In addition, the types
13833 <pre>iterator_traits&lt;Iterator&gt;::reference
13834 iterator_traits&lt;Iterator&gt;::pointer
13835 </pre>
13836 must be defined as the iterator's reference and pointer types, that
13837 is, the same type as the type of <tt>*a</tt> and <tt>a-&gt;</tt>,
13838 respectively.
13839 </blockquote>
13840
13841 <p>In 24.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.iterator.traits"> [lib.iterator.traits]</a>, change:</p>
13842
13843 <blockquote>
13844 In the case of an output iterator, the types
13845 <pre>iterator_traits&lt;Iterator&gt;::difference_type
13846 iterator_traits&lt;Iterator&gt;::value_type
13847 </pre>
13848 are both defined as <tt>void</tt>.
13849 </blockquote>
13850
13851 <p>to:</p>
13852 <blockquote>
13853 In the case of an output iterator, the types
13854 <pre>iterator_traits&lt;Iterator&gt;::difference_type
13855 iterator_traits&lt;Iterator&gt;::value_type
13856 iterator_traits&lt;Iterator&gt;::reference
13857 iterator_traits&lt;Iterator&gt;::pointer
13858 </pre>
13859 may be defined as <tt>void</tt>.
13860 </blockquote>
13861
13862 <p>In 24.5.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.istreambuf.iterator"> [lib.istreambuf.iterator]</a>, change:</p>
13863 <blockquote>
13864 <pre>typename traits::off_type, charT*, charT&amp;&gt;
13865 </pre>
13866 </blockquote>
13867 <p>to:</p>
13868 <blockquote>
13869 <pre>typename traits::off_type, charT*, charT&gt;
13870 </pre>
13871 </blockquote>
13872
13873 <p><i>[
13874 Redmond: there was concern in Sydney that this might not be the only place
13875 where things were underspecified and needed to be changed.  Jeremy
13876 reviewed iterators in the standard and confirmed that nothing else
13877 needed to be changed.
13878 ]</i></p>
13879
13880 <hr>
13881 <a name="448"><h3>448.&nbsp;Random Access Iterators over abstract classes</h3></a><p><b>Section:</b>&nbsp;24.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.random.access.iterators"> [lib.random.access.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;7 Jan 2004</p>
13882 <p>
13883 Table 76, the random access iterator requirement table, says that the
13884 return type of a[n] must be "convertible to T".  When an iterator's
13885 value_type T is an abstract class, nothing is convertible to T.
13886 Surely this isn't an intended restriction?
13887 </p>
13888 <p><b>Proposed resolution:</b></p>
13889 <p>
13890 Change the return type to "convertible to T const&amp;".
13891 </p>
13892 <hr>
13893 <a name="449"><h3>449.&nbsp;Library Issue 306 Goes Too Far</h3></a><p><b>Section:</b>&nbsp;18.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-support.html#lib.support.types"> [lib.support.types]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Pete Becker&nbsp; <b>Date:</b>&nbsp;15 Jan 2004</p>
13894 <p>Original text:</p>
13895 <blockquote>
13896 The macro offsetof accepts a restricted set of type arguments in this
13897 International Standard. type shall be a POD structure or a POD union
13898 (clause 9). The result of applying the offsetof macro to a field that
13899 is a static data member or a function member is undefined."
13900 </blockquote>
13901
13902 <p>Revised text:</p>
13903 <blockquote>
13904 "If type is not a POD structure or a POD union the results are undefined."
13905 </blockquote>
13906
13907 <p>
13908 Looks to me like the revised text should have replaced only the second
13909 sentence. It doesn't make sense standing alone.
13910 </p>
13911
13912 <p><b>Proposed resolution:</b></p>
13913 <p>Change 18.1, paragraph 5, to:</p>
13914
13915 <blockquote>
13916 The macro offsetof accepts a restricted set of type arguments in this
13917 International Standard.  If type is not a POD structure or a POD union
13918 the results are undefined.  The result of applying the offsetof macro
13919 to a field that is a static data member or a function member is
13920 undefined."
13921 </blockquote>
13922 <hr>
13923 <a name="453"></a><h3><a name="453">453.&nbsp;basic_stringbuf::seekoff need not always fail for an empty stream</a></h3><p><b>Section:</b>&nbsp;27.7.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.stringbuf.virtuals"> [lib.stringbuf.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Bill Plauger&nbsp; <b>Date:</b>&nbsp;30 Jan 2004</p>
13924 <pre>  pos_type basic_stringbuf::seekoff(off_type, ios_base::seekdir,
13925                                     ios_base::openmode);
13926 </pre>
13927 <p>
13928 is obliged to fail if nothing has been inserted into the stream. This
13929 is unnecessary and undesirable. It should be permissible to seek to
13930 an effective offset of zero.</p>
13931
13932 <p><i>[
13933  Sydney: Agreed that this is an annoying problem: seeking to zero should be
13934  legal. Bill will provide wording.
13935 ]</i></p>
13936
13937 <p><b>Proposed resolution:</b></p>
13938 <p>Change the sentence from:</p>
13939 <blockquote>
13940 For a sequence to be positioned, if its next pointer (either
13941 gptr() or pptr()) is a null pointer, the positioning operation
13942 fails.
13943 </blockquote>
13944
13945 <p>to:</p>
13946
13947 <blockquote>
13948 For a sequence to be positioned, if its next pointer (either
13949 gptr() or pptr()) is a null pointer and the new offset newoff
13950 is nonzero, the positioning operation fails.
13951 </blockquote>
13952 <hr>
13953 <a name="455"><h3>455.&nbsp;cerr::tie() and wcerr::tie() are overspecified</h3></a><p><b>Section:</b>&nbsp;27.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.iostream.objects"> [lib.iostream.objects]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Bill Plauger&nbsp; <b>Date:</b>&nbsp;30 Jan 2004</p>
13954 <p>
13955 Both cerr::tie() and wcerr::tie() are obliged to be null at program
13956 startup. This is overspecification and overkill. It is both traditional
13957 and useful to tie cerr to cout, to ensure that standard output is drained
13958 whenever an error message is written. This behavior should at least be
13959 permitted if not required. Same for wcerr::tie().
13960 </p>
13961 <p><b>Proposed resolution:</b></p>
13962
13963 <p>Add to the description of cerr:</p>
13964 <blockquote>
13965 After the object cerr is initialized, cerr.tie() returns &amp;cout.
13966 Its state is otherwise the same as required for basic_ios&lt;char&gt;::init
13967 (lib.basic.ios.cons).
13968 </blockquote>
13969
13970 <p>Add to the description of wcerr:</p>
13971
13972 <blockquote>
13973 After the object wcerr is initialized, wcerr.tie() returns &amp;wcout.
13974 Its state is otherwise the same as required for basic_ios&lt;wchar_t&gt;::init
13975 (lib.basic.ios.cons).
13976 </blockquote>
13977
13978 <p><i>[Sydney: straw poll (3-1): we should <i>require</i>, not just
13979   permit, cout and cerr to be tied on startup.  Pre-Redmond: Bill will
13980   provide wording.]</i></p>
13981 <hr>
13982 <a name="457"><h3>457.&nbsp;bitset constructor: incorrect number of initialized bits</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Dag Henriksson&nbsp; <b>Date:</b>&nbsp;30 Jan 2004</p>
13983 <p>
13984 The constructor from unsigned long says it initializes "the first M
13985 bit positions to the corresponding bit values in val. M is the smaller
13986 of N and the value CHAR_BIT * sizeof(unsigned long)."
13987 </p>
13988
13989 <p>
13990 Object-representation vs. value-representation strikes again. CHAR_BIT *
13991 sizeof (unsigned long) does not give us the number of bits an unsigned long
13992 uses to hold the value. Thus, the first M bit position above is not
13993 guaranteed to have any corresponding bit values in val.
13994 </p>
13995 <p><b>Proposed resolution:</b></p>
13996 <p>In 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> paragraph 2, change "M is the smaller of
13997   N and the value CHAR_BIT * sizeof (unsigned long). (249)" to
13998   "<tt>M</tt> is the smaller of <tt>N</tt> and the number of bits in
13999   the value representation (section 3.9 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/basic.html#basic.types"> [basic.types]</a>) of <tt>unsigned
14000   long</tt>."
14001 </p>
14002 <hr>
14003 <a name="460"><h3>460.&nbsp;Default modes missing from basic_fstream member specifications</h3></a><p><b>Section:</b>&nbsp;27.8.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstreams"> [lib.fstreams]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Ben Hutchings&nbsp; <b>Date:</b>&nbsp;1 Apr 2004</p>
14004 <p>
14005 The second parameters of the non-default constructor and of the open
14006 member function for basic_fstream, named "mode", are optional
14007 according to the class declaration in 27.8.1.11 [lib.fstream].  The
14008 specifications of these members in 27.8.1.12 [lib.fstream.cons] and
14009 27.8.1.13 lib.fstream.members] disagree with this, though the
14010 constructor declaration has the "explicit" function-specifier implying
14011 that it is intended to be callable with one argument.
14012 </p>
14013 <p><b>Proposed resolution:</b></p>
14014 <p>In 27.8.1.12 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstream.cons"> [lib.fstream.cons]</a>, change</p>
14015 <pre>  explicit basic_fstream(const char* s, ios_base::openmode mode);
14016 </pre>
14017 <p>to</p>
14018 <pre>  explicit basic_fstream(const char* s,
14019                          ios_base::openmode mode = ios_base::in|ios_base::out);
14020 </pre>
14021 <p>In 27.8.1.13 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.fstream.members"> [lib.fstream.members]</a>, change</p>
14022 <pre>  void open(const char*s, ios_base::openmode mode);
14023 </pre>
14024 <p>to</p>
14025   void open(const char*s,
14026             ios_base::openmode mode = ios_base::in|ios_base::out);
14027 <hr>
14028 <a name="461"><h3>461.&nbsp;time_get hard or impossible to implement</h3></a><p><b>Section:</b>&nbsp;22.2.5.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.locale.time.get.virtuals"> [lib.locale.time.get.virtuals]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Bill Plauger&nbsp; <b>Date:</b>&nbsp;23 Mar 2004</p>
14029 <p>
14030 Template time_get currently contains difficult, if not impossible,
14031 requirements for do_date_order, do_get_time, and do_get_date. All require
14032 the implementation to scan a field generated by the %x or %X conversion
14033 specifier in strftime. Yes, do_date_order can always return no_order, but
14034 that doesn't help the other functions. The problem is that %x can be
14035 nearly anything, and it can vary widely with locales. It's horribly
14036 onerous to have to parse "third sunday after Michaelmas in the year of
14037 our Lord two thousand and three," but that's what we currently ask of
14038 do_get_date. More practically, it leads some people to think that if
14039 %x produces 10.2.04, we should know to look for dots as separators. Still
14040 not easy.
14041 </p>
14042
14043 <p>
14044 Note that this is the <i>opposite</i> effect from the intent stated in the
14045 footnote earlier in this subclause:
14046 </p>
14047
14048 <blockquote>
14049 "In other words, user confirmation is required for reliable parsing of
14050 user-entered dates and times, but machine-generated formats can be
14051 parsed reliably. This allows parsers to be aggressive about interpreting
14052 user variations on standard formats."
14053 </blockquote>
14054
14055 <p>
14056 We should give both implementers and users an easier and more reliable
14057 alternative: provide a (short) list of alternative delimiters and say
14058 what the default date order is for no_order. For backward compatibility,
14059 and maximum latitude, we can permit an implementation to parse whatever
14060 %x or %X generates, but we shouldn't require it.
14061 </p>
14062 <p><b>Proposed resolution:</b></p>
14063
14064 <p><b>In the description:</b></p>
14065 <pre>iter_type do_get_time(iter_type s, iter_type end, ios_base&amp; str,
14066         ios_base::iostate&amp; err, tm* t) const;
14067 </pre>
14068
14069 <p>
14070 2 Effects: Reads characters starting at suntil it has extracted those
14071 struct tm members, and remaining format characters, used by
14072 time_put&lt;&gt;::put to produce the format specified by 'X', or until it
14073 encounters an error or end of sequence.
14074 </p>
14075
14076 <p><b>change:</b> 'X'</p>
14077
14078 <p><b>to:</b> "%H:%M:%S"</p>
14079
14080
14081 <p>Change</p>
14082 <pre>iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
14083         ios_base::iostate&amp; err, tm* t) const;
14084
14085 4 Effects: Reads characters starting at s until it has extracted those
14086 struct tm members, and remaining format characters, used by
14087 time_put&lt;&gt;::put to produce the format specified by 'x', or until it
14088 encounters an error.
14089 </pre>
14090
14091 <p>to</p>
14092 iter_type do_get_date(iter_type s, iter_type end, ios_base&amp; str,
14093         ios_base::iostate&amp; err, tm* t) const;
14094
14095 4 Effects: Reads characters starting at s until it has extracted those
14096 struct tm members, and remaining format characters, used by
14097 time_put&lt;&gt;::put to produce one of the following formats, or until it
14098 encounters an error. The format depends on the value returned by
14099 date_order() as follows:
14100
14101         date_order()  format
14102
14103         no_order      "%m/%d/%y"
14104         dmy           "%d/%m/%y"
14105         mdy           "%m/%d/%y"
14106         ymd           "%y/%m/%d"
14107         ydm           "%y/%d/%m"
14108
14109 An implementation may also accept additional implementation-defined formats.
14110 <pre></pre>
14111
14112 <p><i>[Redmond: agreed that this is a real problem.  The solution is
14113   probably to match C99's parsing rules.  Bill provided wording.
14114 ]</i></p>
14115
14116 <hr>
14117 <a name="464"><h3>464.&nbsp;Suggestion for new member functions in standard containers</h3></a><p><b>Section:</b>&nbsp;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.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Thorsten Ottosen&nbsp; <b>Date:</b>&nbsp;12 May 2004</p>
14118
14119 <p>To add slightly more convenience to vector&lt;T&gt; and map&lt;Key,T&gt; we should consider to add</p>
14120 <ol>
14121 <li> add vector&lt;T&gt;::data() member (const and non-const version)
14122 semantics: if( empty() ) return 0; else return buffer_;</li>
14123 <li> add map&lt;Key,T&gt;::at( const Key&amp; k ) member (const and non-const version)
14124 <i>semantics</i>: iterator i = find( k ); if( i != end() ) return *i; else throw range_error();</li>
14125 </ol>
14126
14127 <p>Rationale:</p>
14128
14129 <ul>
14130 <li>To obtain a pointer to the vector's buffer, one must use either
14131 operator[]() (which can give undefined behavior for empty vectors) or
14132 at() (which will then throw if the vector is empty). </li>
14133 <li>tr1::array&lt;T,sz&gt; already has a data() member</li>
14134 <li>e cannot use operator[]() when T is not DefaultDonstructible</li>
14135 <li>Neither when the map is const.</li>
14136 <li>when we want to make sure we don't add an element accidently</li>
14137 <li>when it should be considered an error if a key is not in the map</li>
14138 </ul>
14139
14140 <p><b>Proposed resolution:</b></p>
14141 <p>In 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.adaptors"> [lib.container.adaptors]</a>, add the following to the <tt>vector</tt>
14142   synopsis after "element access" and before "modifiers":</p>
14143 <pre>  // <i>[lib.vector.data] data access</i>
14144   pointer       data();
14145   const_pointer data() const;
14146 </pre>
14147
14148 <p>Add a new subsection of 23.2.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.container.adaptors"> [lib.container.adaptors]</a>:</p>
14149 <blockquote>
14150 <p>23.2.4.x <tt>vector</tt> data access</p>
14151 <pre>   pointer       data();
14152    const_pointer data() const;
14153 </pre>
14154 <p><b>Returns:</b> A pointer such that [data(), data() + size()) is a valid
14155    range.  For a non-empty vector, data() == &amp;front().</p>
14156 <p><b>Complexity:</b> Constant time.</p>
14157 <p><b>Throws:</b> Nothing.</p>
14158 </blockquote>
14159
14160 <p>In 23.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map"> [lib.map]</a>, add the following to the <tt>map</tt>
14161 synopsis immediately after the line for operator[]:</p>
14162 <pre>  T&amp;       at(const key_type&amp; x);
14163   const T&amp; at(const key_type&amp; x) const;
14164 </pre>
14165
14166 <p>Add the following to 23.3.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.map.access"> [lib.map.access]</a>:</p>
14167 <blockquote>
14168 <pre>  T&amp;       at(const key_type&amp; x);
14169   const T&amp; at(const key_type&amp; x) const;
14170 </pre>
14171
14172 <p><b>Returns:</b> A reference to the element whose key is equivalent
14173   to x, if such an element is present in the map.</p>
14174 <p><b>Throws:</b> <tt>out_of_range</tt> if no such element is present.</p>
14175
14176 </blockquote>
14177
14178 <p><b>Rationale:</b></p>
14179 <p>Neither of these additions provides any new functionality but the
14180   LWG agreed that they are convenient, especially for novices.  The
14181   exception type chosen for <tt>at</tt>, <tt>std::out_of_range</tt>,
14182   was chosen to match <tt>vector::at</tt>.</p>
14183 <hr>
14184 <a name="465"><h3>465.&nbsp;Contents of &lt;ciso646&gt;</h3></a><p><b>Section:</b>&nbsp;17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Steve Clamage&nbsp; <b>Date:</b>&nbsp;3 Jun 2004</p>
14185 <p>C header &lt;iso646.h&gt; defines macros for some operators, such as
14186 not_eq for !=.</p>
14187
14188 <p>Section 17.4.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.headers"> [lib.headers]</a> "Headers" says that except as noted in
14189 clauses 18 through 27, the &lt;cname&gt; C++ header contents are the same
14190 as the C header &lt;name.h&gt;. In particular, table 12 lists
14191 &lt;ciso646&gt; as a C++ header.</p>
14192
14193 <p>I don't find any other mention of &lt;ciso646&gt;, or any mention of
14194 &lt;iso646.h&gt;, in clauses 17 thorough 27. That implies that the
14195 contents of &lt;ciso646&gt; are the same as C header &lt;iso646.h&gt;.</p>
14196
14197 <p>Annex C (informative, not normative) in [diff.header.iso646.h] C.2.2.2
14198 "Header &lt;iso646.h&gt;" says that the alternative tokens are not
14199 defined as macros in &lt;ciso646&gt;, but does not mention the contents
14200 of &lt;iso646.h&gt;.</p>
14201
14202 <p>I don't find any normative text to support C.2.2.2.</p>
14203
14204 <p><b>Proposed resolution:</b></p>
14205 <p>Add to section 17.4.1.2 Headers [lib.headers] a new paragraph after
14206   paragraph 6 (the one about functions must be functions):</p>
14207
14208 <blockquote>
14209 <p>Identifiers that are keywords or operators in C++ shall not be defined
14210 as macros in C++ standard library headers.
14211 [Footnote:In particular, including the standard header &lt;iso646.h&gt;
14212 or &lt;ciso646&gt; has no effect. </p>
14213 </blockquote>
14214
14215 <p><i>[post-Redmond: Steve provided wording.]</i></p>
14216
14217 <hr>
14218 <a name="467"><h3>467.&nbsp;char_traits::lt(), compare(), and memcmp()</h3></a><p><b>Section:</b>&nbsp;21.1.3.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.char.traits.specializations.char"> [lib.char.traits.specializations.char]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jun 2004</p>
14219
14220 <p>
14221 Table 37 describes the requirements on Traits::compare() in terms of
14222 those on Traits::lt(). 21.1.3.1, p6 requires char_traits&lt;char&gt;::lt()
14223 to yield the same result as operator&lt;(char, char).
14224 </p>
14225
14226 <p>
14227 Most, if not all, implementations of char_traits&lt;char&gt;::compare()
14228 call memcmp() for efficiency. However, the C standard requires both
14229 memcmp() and strcmp() to interpret characters under comparison as
14230 unsigned, regardless of the signedness of char. As a result, all
14231 these char_traits implementations fail to meet the requirement
14232 imposed by Table 37 on compare() when char is signed.
14233 </p>
14234
14235
14236 <p>Read email thread starting with c++std-lib-13499 for more. </p>
14237 <p><b>Proposed resolution:</b></p>
14238
14239
14240 <p>Change 21.1.3.1, p6 from</p>
14241 <blockquote>
14242     The two-argument members assign, eq, and lt are defined identically
14243     to the built-in operators =, ==, and &lt; respectively.
14244 </blockquote>
14245 <p>to</p>
14246 <blockquote>
14247   The two-argument member assign is defined identically to
14248   the built-in operator =. The two
14249   argument members eq and lt are defined identically to
14250   the built-in operators == and &lt; for type unsigned char.
14251 </blockquote>
14252
14253 <p><i>[Redmond: The LWG agreed with this general direction, but we
14254   also need to change <tt>eq</tt> to be consistent with this change.
14255   Post-Redmond: Martin provided wording.]</i></p>
14256
14257 <hr>
14258 <a name="468"><h3>468.&nbsp;unexpected consequences of ios_base::operator void*()</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jun 2004</p>
14259
14260 <p>The program below is required to compile but when run it typically
14261 produces unexpected results due to the user-defined conversion from
14262 std::cout or any object derived from basic_ios to void*.
14263 </p>
14264
14265 <pre>    #include &lt;cassert&gt;
14266     #include &lt;iostream&gt;
14267
14268     int main ()
14269     {
14270         assert (std::cin.tie () == std::cout);
14271         // calls std::cout.ios::operator void*()
14272     }
14273 </pre>
14274
14275 <p><b>Proposed resolution:</b></p>
14276
14277 <p>
14278 Replace std::basic_ios&lt;charT, traits&gt;::operator void*() with another
14279 conversion operator to some unspecified type that is guaranteed not
14280 to be convertible to any other type except for bool (a pointer-to-member
14281 might be one such suitable type). In addition, make it clear that the
14282 pointer type need not be a pointer to a complete type and when non-null,
14283 the value need not be valid.
14284 </p>
14285
14286 <p>Specifically, change in [lib.ios] the signature of</p>
14287 <pre>    operator void*() const;
14288 </pre>
14289 <p>to</p>
14290 <pre>    operator unspecified-bool-type() const;
14291 </pre>
14292 <p>and change [lib.iostate.flags], p1 from</p>
14293 <pre>    operator void*() const;
14294 </pre>
14295 <p>to</p>
14296 <pre>operator unspecified-bool-type() const;
14297
14298      -1- Returns: if fail() then a value that will evaluate false in a
14299       boolean context; otherwise a value that will evaluate true in a
14300       boolean context. The value type returned shall not be
14301       convertible to int.
14302
14303      -2- [Note: This conversion can be used in contexts where a bool
14304       is expected (e.g., an if condition); however, implicit
14305       conversions (e.g., to int) that can occur with bool are not
14306       allowed, eliminating some sources of user error. One possible
14307       implementation choice for this type is pointer-to-member.  - end
14308       note]
14309 </pre>
14310
14311 <p><i>[Redmond: 5-4 straw poll in favor of doing this.]</i></p>
14312 <p><i>[Lillehammer: Doug provided revised wording for
14313   "unspecified-bool-type".]</i></p>
14314
14315 <hr>
14316 <a name="469"><h3>469.&nbsp;vector&lt;bool&gt; ill-formed relational operators</h3></a><p><b>Section:</b>&nbsp;23.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;28 Jun 2004</p>
14317
14318 <p>
14319 The overloads of relational operators for vector&lt;bool&gt; specified
14320 in [lib.vector.bool] are redundant (they are semantically identical
14321 to those provided for the vector primary template) and may even be
14322 diagnosed as ill-formed (refer to Daveed Vandevoorde's explanation
14323 in c++std-lib-13647).
14324 </p>
14325
14326 <p><b>Proposed resolution:</b></p>
14327 <p>
14328 Remove all overloads of overloads of relational operators for
14329 vector&lt;bool&gt; from [lib.vector.bool].
14330 </p>
14331 <hr>
14332 <a name="474"><h3>474.&nbsp;confusing Footnote 297</h3></a><p><b>Section:</b>&nbsp;27.6.2.5.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.ostream.inserters.character"> [lib.ostream.inserters.character]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;1 Jul 2004</p>
14333
14334 <p>
14335 I think Footnote 297 is confused. The paragraph it applies to seems
14336 quite clear in that widen() is only called if the object is not a char
14337 stream (i.e., not basic_ostream&lt;char&gt;), so it's irrelevant what the
14338 value of widen(c) is otherwise.
14339 </p>
14340 <p><b>Proposed resolution:</b></p>
14341 <p>
14342 I propose to strike the Footnote.
14343 </p>
14344 <hr>
14345 <a name="475"><h3>475.&nbsp;May the function object passed to for_each modify the elements of the iterated sequence?</h3></a><p><b>Section:</b>&nbsp;25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Stephan T. Lavavej, Jaakko Jarvi&nbsp; <b>Date:</b>&nbsp;9 Jul 2004</p>
14346 <p>
14347 It is not clear whether the function object passed to for_each is allowed to
14348 modify the elements of the sequence being iterated over.
14349 </p>
14350
14351 <p>
14352 for_each is classified without explanation in [lib.alg.nonmodifying], "25.1
14353 Non-modifying sequence operations". 'Non-modifying sequence operation' is
14354 never defined.
14355 </p>
14356
14357 <p>
14358 25(5) says: "If an algorithm's Effects section says that a value pointed to
14359 by any iterator passed as an argument is modified, then that algorithm has
14360 an additional type requirement: The type of that argument shall satisfy the
14361 requirements of a mutable iterator (24.1)."
14362 </p>
14363
14364 <p>for_each's Effects section does not mention whether arguments can be
14365 modified:</p>
14366
14367 <blockquote>
14368   "Effects: Applies f to the result of dereferencing every iterator in the
14369    range [first, last), starting from first and proceeding to last - 1."
14370 </blockquote>
14371
14372 <p>
14373 Every other algorithm in [lib.alg.nonmodifying] is "really" non-modifying in
14374 the sense that neither the algorithms themselves nor the function objects
14375 passed to the algorithms may modify the sequences or elements in any way.
14376 This DR affects only for_each.
14377 </p>
14378
14379 <p>
14380 We suspect that for_each's classification in "non-modifying sequence
14381 operations" means that the algorithm itself does not inherently modify the
14382 sequence or the elements in the sequence, but that the function object
14383 passed to it may modify the elements it operates on.
14384 </p>
14385
14386 <p>
14387 The original STL document by Stepanov and Lee explicitly prohibited the
14388 function object from modifying its argument.
14389 The "obvious" implementation of for_each found in several standard library
14390 implementations, however, does not impose this restriction.
14391 As a result, we suspect that the use of for_each with function objects that modify
14392 their arguments is wide-spread.
14393 If the restriction was reinstated, all such code would become non-conforming.
14394 Further, none of the other algorithms in the Standard
14395 could serve the purpose of for_each (transform does not guarantee the order in
14396 which its function object is called).
14397 </p>
14398
14399 <p>
14400 We suggest that the standard be clarified to explicitly allow the function object
14401 passed to for_each modify its argument.</p>
14402
14403 <p><b>Proposed resolution:</b></p>
14404 <p>Add a nonnormative note to the Effects in 25.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.foreach"> [lib.alg.foreach]</a>: If
14405 the type of 'first' satisfies the requirements of a mutable iterator,
14406 'f' may apply nonconstant functions through the dereferenced iterators
14407 passed to it.
14408 </p>
14409
14410 <p><b>Rationale:</b></p>
14411 <p>The LWG believes that nothing in the standard prohibits function
14412   objects that modify the sequence elements. The problem is that
14413   for_each is in a secion entitled "nonmutating algorithms", and the
14414   title may be confusing.  A nonnormative note should clarify that.</p>
14415 <hr>
14416 <a name="478"><h3>478.&nbsp;Should forward iterator requirements table have a line for r-&gt;m?</h3></a><p><b>Section:</b>&nbsp;24.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iterators.html#lib.forward.iterators"> [lib.forward.iterators]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Dave Abrahams&nbsp; <b>Date:</b>&nbsp;11 Jul 2004</p>
14417 <p>
14418 The Forward Iterator requirements table contains the following:
14419 </p>
14420 <pre> expression  return type         operational  precondition
14421                                   semantics
14422   ==========  ==================  ===========  ==========================
14423   a-&gt;m        U&amp; if X is mutable, (*a).m       pre: (*a).m is well-defined.
14424               otherwise const U&amp;
14425
14426   r-&gt;m        U&amp;                  (*r).m       pre: (*r).m is well-defined.
14427 </pre>
14428
14429 <p>The second line may be unnecessary.  Paragraph 11 of
14430   [lib.iterator.requirements] says:
14431 </p>
14432
14433 <blockquote>
14434    In the following sections, a and b denote values of type const X, n
14435    denotes a value of the difference type Distance, u, tmp, and m
14436    denote identifiers, r denotes a value of X&amp;, t denotes a value of
14437    value type T, o denotes a value of some type that is writable to
14438    the output iterator.
14439 </blockquote>
14440
14441 <p>
14442 Because operators can be overloaded on an iterator's const-ness, the
14443 current requirements allow iterators to make many of the operations
14444 specified using the identifiers a and b invalid for non-const
14445 iterators.</p>
14446
14447 <p>Related issue: <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#477">477</a></p>
14448 <p><b>Proposed resolution:</b></p>
14449
14450 <p>Remove the "r-&gt;m" line from the Forward Iterator requirements
14451 table. Change</p>
14452 <blockquote>
14453     "const X"
14454 </blockquote>
14455
14456 <p> to </p>
14457
14458 <blockquote>
14459     "X or const X"
14460 </blockquote>
14461
14462 <p>in paragraph 11 of [lib.iterator.requirements].</p>
14463
14464
14465 <p><b>Rationale:</b></p>
14466 <p>
14467 This is a defect because it constrains an lvalue to returning a modifiable lvalue.
14468 </p>
14469 <hr>
14470 <a name="495"><h3>495.&nbsp;Clause 22 template parameter requirements</h3></a><p><b>Section:</b>&nbsp;22 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-locales.html#lib.localization"> [lib.localization]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;10 Jan 2005</p>
14471 <p>It appears that there are no requirements specified for many of the
14472 template parameters in clause 22. It looks like this issue has never
14473 come up, except perhaps for Facet.</p>
14474
14475 <p>Clause 22 isn't even listed in 17.3.2.1 [lib.type.descriptions],
14476 either, which is the wording that allows requirements on template
14477 parameters to be identified by name.</p>
14478
14479 <p>So one issue is that 17.3.2.1 [lib.type.descriptions] Should be
14480 changed to cover clause 22. A better change, which will cover us in
14481 the future, would be to say that it applies to all the library
14482 clauses. Then if a template gets added to any library clause we are
14483 covered.</p>
14484
14485 <p>charT, InputIterator, and other names with requirements defined
14486 elsewhere are fine, assuming the 17.3.2.1 [lib.type.descriptions] fix.
14487 But there are a few template arguments names which I don't think have
14488 requirements given elsewhere:</p>
14489
14490 <ul>
14491 <li>internT and externT.  The fix is to add wording saying that internT
14492 and externT must meet the same requirements as template arguments
14493 named charT.</li>
14494
14495 <li>stateT.  I'm not sure about this one. There already is some wording,
14496 but it seems a bit vague.</li>
14497
14498 <li>Intl.  [lib.locale.moneypunct.byname] The fix for this one is to
14499 rename "Intl" to "International". The name is important because other
14500 text identifies the requirements for the name International but not
14501 for Intl.</li>
14502 </ul>
14503 <p><b>Proposed resolution:</b></p>
14504 <p>Change 17.3.2.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-intro.html#lib.type.descriptions"> [lib.type.descriptions]</a>, paragraph 1, from:</p>
14505 <blockquote>
14506 The Requirements subclauses may describe names that are used to
14507 specify constraints on template arguments.153) These names are used in
14508 clauses 20, 23, 25, and 26 to describe the types that may be supplied
14509 as arguments by a C++ program when instantiating template components
14510 from the library.
14511 </blockquote>
14512 <p>to:</p>
14513 <blockquote>
14514 The Requirements subclauses may describe names that are used to
14515 specify constraints on template arguments.153) These names are used in
14516 library clauses to describe the types that may be supplied as
14517 arguments by a C++ program when instantiating template components from
14518 the library.
14519 </blockquote>
14520
14521 <p>In the front matter of class 22, locales, add:</p>
14522 <blockquote>
14523 Template parameter types internT and externT shall meet the
14524 requirements of charT (described in 21 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.strings"> [lib.strings]</a>).
14525 </blockquote>
14526 <p><b>Rationale:</b></p>
14527 <p>
14528  Again, a blanket clause isn't blanket enough. Also, we've got a
14529  couple of names that we don't have blanket requirement statements
14530  for. The only issue is what to do about stateT. This wording is
14531  thin, but probably adequate.</p>
14532 <hr>
14533 <a name="496"><h3>496.&nbsp;Illegal use of "T" in vector&lt;bool&gt;</h3></a><p><b>Section:</b>&nbsp;23.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;richard@ex-parrot.com&nbsp; <b>Date:</b>&nbsp;10 Feb 2005</p>
14534 <p>
14535 In the synopsis of the std::vector&lt;bool&gt; specialisation in 23.2.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.vector"> [lib.vector]</a>,
14536 the non-template assign() function has the signature</p>
14537
14538 <pre>  void assign( size_type n, const T&amp; t );
14539 </pre>
14540
14541 <p>The type, T, is not defined in this context.</p>
14542 <p><b>Proposed resolution:</b></p>
14543 <p>Replace "T" with "value_type".</p>
14544 <hr>
14545 <a name="497"><h3>497.&nbsp;meaning of numeric_limits::traps for floating point types</h3></a><p><b>Section:</b>&nbsp;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>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;2 Mar 2005</p>
14546
14547 <p>18.2.1.2, p59 says this much about the traps member of numeric_limits:</p>
14548
14549 <blockquote>
14550 <p>static const bool traps;<br>
14551 -59- true if trapping is implemented for the type.204)
14552 <br>
14553 Footnote 204: Required by LIA-1.
14554 </p>
14555 </blockquote>
14556
14557 <p>It's not clear what is meant by "is implemented" here.</p>
14558
14559 <p>
14560 In the context of floating point numbers it seems reasonable to expect
14561 to be able to use traps to determine whether a program can "safely" use
14562 infinity(), quiet_NaN(), etc., in arithmetic expressions, that is
14563 without causing a trap (i.e., on UNIX without having to worry about
14564 getting a signal). When traps is true, I would expect any of the
14565 operations in section 7 of IEEE 754 to cause a trap (and my program
14566 to get a SIGFPE). So, for example, on Alpha, I would expect traps
14567 to be true by default (unless I compiled my program with the -ieee
14568 option), false by default on most other popular architectures,
14569 including IA64, MIPS, PA-RISC, PPC, SPARC, and x86 which require
14570 traps to be explicitly enabled by the program.
14571 </p>
14572
14573 <p>
14574 Another possible interpretation of p59 is that traps should be true
14575 on any implementation that supports traps regardless of whether they
14576 are enabled by default or not. I don't think such an interpretation
14577 makes the traps member very useful, even though that is how traps is
14578 implemented on several platforms. It is also the only way to implement
14579 traps on platforms that allow programs to enable and disable trapping
14580 at runtime.
14581 </p>
14582 <p><b>Proposed resolution:</b></p>
14583 <p>Change p59 to read:</p>
14584 <blockquote>True if, at program startup, there exists a value of the type that
14585   would cause an arithmetic operation using that value to trap.</blockquote>
14586 <p><b>Rationale:</b></p>
14587 <p>
14588  Real issue, since trapping can be turned on and off. Unclear what a
14589  static query can say about a dynamic issue. The real advice we should
14590  give users is to use cfenv for these sorts of queries. But this new
14591  proposed resolution is at least consistent and slightly better than
14592  nothing.</p>
14593 <hr>
14594 <a name="505"><h3>505.&nbsp;Result_type in random distribution requirements</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.1 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.req"> [tr.rand.req]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
14595 <p>
14596 Table 17: Random distribution requirements
14597 </p>
14598 <p>
14599 Row 1 requires that each random distribution provide a nested type "input_type";
14600 this type denotes the type of the values that the distribution consumes.
14601 </p>
14602 <p>
14603 Inspection of all distributions in [tr.rand.dist] reveals that each distribution
14604 provides a second typedef ("result_type") that denotes the type of the values the
14605 distribution produces when called.
14606 </p>
14607 <p><b>Proposed resolution:</b></p>
14608 <p>
14609 It seems to me that this is also a requirement
14610 for all distributions and should therefore be  indicated as such via a new second
14611 row to this table 17:
14612 </p>
14613 <table border="1" cellpadding="5">
14614 <tbody><tr>
14615 <td>X::result_type</td>
14616 <td>T</td>
14617 <td>---</td>
14618 <td>compile-time</td>
14619 </tr>
14620 </tbody></table>
14621
14622 <p><i>[
14623 Berlin:  Voted to WP.  N1932 adopts the proposed resolution:  see Table 5 row 1.
14624 ]</i></p>
14625
14626 <hr>
14627 <a name="507"><h3>507.&nbsp;Missing requirement for variate_generator::operator()</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.var"> [tr.rand.var]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
14628 <p>
14629 Paragraph 11 of [tr.rand.var] equires that the member template
14630 </p>
14631 <blockquote><pre>template&lt;class T&gt; result_type operator() (T value);
14632 </pre></blockquote>
14633 <p>
14634 return
14635 </p>
14636 <blockquote><pre>distribution()(e, value)
14637 </pre></blockquote>
14638 <p>
14639 However, not all distributions have an operator() with a corresponding signature.
14640 </p>
14641
14642 <p><i>[
14643 Berlin:  As a working group we voted in favor of N1932 which makes this moot:
14644 variate_generator has been eliminated.  Then in full committee we voted to give
14645 this issue WP status (mistakenly).
14646 ]</i></p>
14647
14648 <p><b>Proposed resolution:</b></p>
14649 <p>
14650 We therefore  recommend that we insert the following precondition before paragraph 11:
14651 </p>
14652 <blockquote>
14653 Precondition:  <tt>distribution().operator()(e,value)</tt> is well-formed.
14654 </blockquote>
14655 <hr>
14656 <a name="508"><h3>508.&nbsp;Bad parameters for ranlux64_base_01</h3></a><p><b>Section:</b>&nbsp;TR1 5.1.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.rand.predef"> [tr.rand.predef]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Walter Brown&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
14657 <p>
14658 The fifth of these engines with predefined parameters, ranlux64_base_01,
14659 appears to have an unintentional error for which there is a simple correction.
14660 The two pre-defined  subtract_with_carry_01 engines are given as:
14661 </p>
14662 <blockquote><pre>typedef subtract_with_carry_01&lt;float,  24, 10, 24&gt; ranlux_base_01;
14663 typedef subtract_with_carry_01&lt;double, 48, 10, 24&gt; ranlux64_base_01;
14664 </pre></blockquote>
14665 <p>
14666 We demonstrate below that ranlux64_base_01 fails to meet the intent of the
14667 random number generation proposal, but that the simple correction to
14668 </p>
14669 <blockquote><pre>typedef subtract_with_carry_01&lt;double, 48,  5, 12&gt; ranlux64_base_01;
14670 </pre></blockquote>
14671 <p>
14672 does meet the intent of defining well-known good parameterizations.
14673 </p>
14674 <p>
14675 The ranlux64_base_01 engine as presented fails to meet the intent for
14676 predefined engines, stated in proposal N1398 (section E):
14677 </p>
14678 <blockquote><p>
14679 In order to make good random numbers available to a large number of library
14680 users, this proposal not only defines generic random-number engines, but also
14681 provides a number of predefined well-known good parameterizations for those.
14682 </p></blockquote>
14683 <p>
14684 The predefined ranlux_base_01 engine has been proven [1,2,3] to have a very
14685 long period and so meets this criterion.  This property makes it suitable for
14686 use in the excellent discard_block  engines defined subsequently.  The proof
14687 of long period relies on the fact (proven in [1]) that 2**(w*r) - 2**(w*s)
14688 + 1 is prime (w, r, and s are template parameters to subtract_with_carry_01,
14689 as defined in [tr.rand.eng.sub1]).
14690 </p>
14691 <p>
14692 The ranlux64_base_01 engine as presented in [tr.rand.predef] uses w=48, r=24, s=10.
14693 For these numbers, the combination 2**(w*r)-2**(w*s)+1 is non-prime (though
14694 explicit factorization  would be a challenge).  In consequence, while it is
14695 certainly possible for some seeding states that this engine would have a very
14696 long period, it is not at all Òwell-knownÓ that this is the case. The intent
14697 in the N1398 proposal involved the base of the ranlux64 engine, which finds heavy
14698 use in the physics community.  This is isomorphic to the predefined ranlux_base_01,
14699 but exploits the ability of double variables to hold (at least) 48 bits of mantissa,
14700 to deliver 48 random bits at a time rather than 24.
14701 </p>
14702 <p><b>Proposed resolution:</b></p>
14703 <p>
14704 To achieve this intended behavior, the correct template parameteriztion  would be:
14705 </p>
14706 <blockquote><pre>typedef subtract_with_carry_01&lt;double, 48, 5, 12&gt; ranlux64_base_01;
14707 </pre></blockquote>
14708 <p>
14709 The sequence of mantissa bits delivered by this is isomorphic (treating each
14710 double as having the  bits of two floats) to that delivered by ranlux_base_01.
14711 </p>
14712 <p>
14713 <b>References:</b>
14714 </p>
14715 <ol>
14716 <li>F. James, Comput. Phys. Commun. 60(1990) 329</li>
14717 <li>G. Marsaglia and A. Zaman, Ann. Appl. Prob 1(1991) 462</li>
14718 <li>M. Luscher, Comput. Phys. Commun. 79(1994) 100-110</li>
14719 </ol>
14720
14721 <p><i>[
14722 Berlin: Voted to WP.  N1932 adopts the proposed resolution in 26.3.5,
14723 just above paragraph 5.
14724 ]</i></p>
14725
14726 <hr>
14727 <a name="519"><h3>519.&nbsp;Data() undocumented</h3></a><p><b>Section:</b>&nbsp;TR1 6.2.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.array.array"> [tr.array.array]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Pete Becker&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
14728 <p>
14729 <tt>array&lt;&gt;::data()</tt> is present in the class synopsis, but not documented.
14730 </p>
14731 <p><b>Proposed resolution:</b></p>
14732 <p>
14733 Add a new section, after 6.2.2.3:
14734 </p>
14735 <blockquote><pre>T*       data()
14736 const T* data() const;
14737 </pre></blockquote>
14738 <p>
14739 <b>Returns:</b> <tt>elems</tt>.
14740 </p>
14741 <p>
14742 Change 6.2.2.4/2 to:
14743 </p>
14744 <blockquote>
14745 In the case where <tt>N == 0</tt>, <tt>begin() == end()</tt>. The return value
14746 of <tt>data()</tt> is unspecified.
14747 </blockquote>
14748 <hr>
14749 <a name="520"><h3>520.&nbsp;Result_of and pointers to data members</h3></a><p><b>Section:</b>&nbsp;TR1 3.6 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.func.bind"> [tr.func.bind]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Pete Becker&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
14750 <p>
14751 In the original proposal for binders, the return type of bind() when
14752 called with a pointer to member data as it's callable object was
14753 defined to be mem_fn(ptr); when Peter Dimov and I  unified the
14754 descriptions of the TR1 function objects we hoisted the descriptions
14755 of return types into the INVOKE pseudo-function and into result_of.
14756 Unfortunately, we left pointer to member data out of result_of, so
14757 bind doesn't have any specified behavior when called with a pointer
14758 to  member data.
14759 </p>
14760 <p><b>Proposed resolution:</b></p>
14761 <p><i>[
14762 Pete and Peter will provide wording.
14763 ]</i></p>
14764
14765 <p>
14766 In 20.5.4 [lib.func.ret] ([tr.func.ret]) p3 add the following bullet after bullet 2:
14767 </p>
14768 <ol start="3">
14769 <li>If <tt>F</tt> is a member data pointer type <tt>R T::*</tt>, <tt>type</tt>
14770 shall be <tt><i>cv</i> R&amp;</tt> when <tt>T1</tt> is <tt><i>cv</i> U1&amp;</tt>,
14771 <tt>R</tt> otherwise.</li>
14772 </ol>
14773
14774 <p><i>[
14775 Peter provided wording.
14776 ]</i></p>
14777 <hr>
14778 <a name="521"><h3>521.&nbsp;Garbled requirements for argument_type in reference_wrapper</h3></a><p><b>Section:</b>&nbsp;TR1 2.1.2 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.refwrp.refwrp"> [tr.util.refwrp.refwrp]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Pete Becker&nbsp; <b>Date:</b>&nbsp;3 Jul 2005</p>
14779 <p>
14780 2.1.2/3, second bullet item currently says that reference_wrapper&lt;T&gt; is
14781 derived from unary_function&lt;T, R&gt; if T is:
14782 </p>
14783 <blockquote>
14784 a pointer to member function type with cv-qualifier cv and no arguments;
14785 the type T1 is cv T* and R is the return type of the pointer to member function;
14786 </blockquote>
14787 <p>
14788 The type of T1 can't be cv T*, 'cause that's a pointer to a pointer to member
14789 function. It should be a pointer to the class that T is a pointer to member of.
14790 Like this:
14791 </p>
14792 <blockquote>
14793 a pointer to a member function R T0::f() cv (where cv represents the member
14794 function's cv-qualifiers); the type T1 is cv T0*
14795 </blockquote>
14796 <p>
14797 Similarly, bullet item 2 in 2.1.2/4 should be:
14798 </p>
14799 <blockquote>
14800 a pointer to a member function R T0::f(T2) cv (where cv represents the member
14801 function's cv-qualifiers); the type T1 is cv T0*
14802 </blockquote>
14803 <p><b>Proposed resolution:</b></p>
14804
14805 <p>
14806 Change bullet item 2 in 2.1.2/3:
14807 </p>
14808
14809 <blockquote>
14810 <ul>
14811 <li>
14812 a pointer to member function <del>type with cv-qualifier <tt><i>cv</i></tt> and no arguments;
14813 the type <tt>T1</tt> is <tt><i>cv</i> T*</tt> and <tt>R</tt> is the return
14814 type of the pointer to member function</del> <ins><tt>R T0::f() <i>cv</i></tt>
14815 (where <tt><i>cv</i></tt> represents the member function's cv-qualifiers);
14816 the type <tt>T1</tt> is <tt><i>cv</i> T0*</tt></ins>
14817 </li>
14818 </ul>
14819 </blockquote>
14820
14821 <p>
14822 Change bullet item 2 in 2.1.2/4:
14823 </p>
14824
14825 <blockquote>
14826 <ul>
14827 <li>
14828 a pointer to member function <del>with cv-qualifier <tt><i>cv</i></tt> and taking one argument
14829 of type <tt>T2</tt>; the type <tt>T1</tt> is <tt><i>cv</i> T*</tt> and
14830 <tt>R</tt> is the return type of the pointer to member function</del>
14831 <ins><tt>R T0::f(T2) <i>cv</i></tt> (where <tt><i>cv</i></tt> represents the member
14832 function's cv-qualifiers); the type <tt>T1</tt> is <tt><i>cv</i> T0*</tt></ins>
14833 </li>
14834 </ul>
14835 </blockquote>
14836
14837 <hr>
14838 <a name="530"><h3>530.&nbsp;Must elements of a string be contiguous?</h3></a><p><b>Section:</b>&nbsp;21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Matt Austern&nbsp; <b>Date:</b>&nbsp;15 Nov 2005</p>
14839 <p>Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#69">69</a>, which was incorporated into C++03, mandated
14840 &nbsp;&nbsp; that the elements of a vector must be stored in contiguous memory.
14841 &nbsp;&nbsp; Should the same also apply to <tt>basic_string</tt>?</p>
14842
14843 <p>We almost require contiguity already. Clause 23.3.4 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-containers.html#lib.multiset"> [lib.multiset]</a>
14844 &nbsp; defines <tt>operator[]</tt> as <tt>data()[pos]</tt>. What's missing
14845 &nbsp; is a similar guarantee if we access the string's elements via the
14846 &nbsp; iterator interface.</p>
14847
14848 <p>Given the existence of <tt>data()</tt>, and the definition of
14849 &nbsp; <tt>operator[]</tt> and <tt>at</tt> in terms of <tt>data</tt>,
14850 &nbsp; I don't believe it's possible to write a useful and standard-
14851 &nbsp; conforming <tt>basic_string</tt> that isn't contiguous. I'm not
14852 &nbsp; aware of any non-contiguous implementation. We should just require
14853 &nbsp; it.
14854 </p>
14855 <p><b>Proposed resolution:</b></p>
14856 <p>Add the following text to the end of 21.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.basic.string"> [lib.basic.string]</a>,
14857 paragraph 2. </p>
14858
14859 <blockquote>
14860 &nbsp; <p>The characters in a string are stored contiguously, meaning that if
14861 &nbsp; <tt>s</tt> is a <tt>basic_string&lt;charT, Allocator&gt;</tt>, then
14862 &nbsp; it obeys the identity
14863 &nbsp; <tt>&amp;*(s.begin() + n) == &amp;*s.begin() + n</tt>
14864 &nbsp; for all <tt>0 &lt;= n &lt; s.size()</tt>.
14865   </p>
14866 </blockquote>
14867 <hr>
14868 <a name="533"><h3>533.&nbsp;typo in 2.2.3.10/1</h3></a><p><b>Section:</b>&nbsp;TR1 2.2.3.10 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.smartptr.getdeleter"> [tr.util.smartptr.getdeleter]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#DR">DR</a>&nbsp; <b>Submitter:</b>&nbsp;Paolo Carlini&nbsp; <b>Date:</b>&nbsp;9 Nov 2005</p>
14869 <p>
14870 I'm seeing something that looks like a typo. The Return of <tt>get_deleter</tt>
14871 says:
14872 </p>
14873 <blockquote>
14874 If <tt>*this</tt> <i>owns</i> a deleter <tt>d</tt>...
14875 </blockquote>
14876 <p>
14877 but <tt>get_deleter</tt> is a free function!
14878 </p>
14879 <p><b>Proposed resolution:</b></p>
14880 <p>
14881 Therefore, I think should be:
14882 </p>
14883 <blockquote>
14884 If <tt><del>*this</del> <ins>p</ins></tt> <i>owns</i> a deleter <tt>d</tt>...
14885 </blockquote>
14886 <hr>
14887 <a name="535"><h3>535.&nbsp;std::string::swap specification poorly worded</h3></a><p><b>Section:</b>&nbsp;21.3.5.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-strings.html#lib.string::swap"> [lib.string::swap]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Beman Dawes&nbsp; <b>Date:</b>&nbsp;14 Dec 2005</p>
14888 <p>
14889 std::string::swap currently says for effects and postcondition:
14890 </p>
14891
14892 <blockquote>
14893 <p>
14894 <i>Effects:</i> Swaps the contents of the two strings.
14895 </p>
14896
14897 <p>
14898 <i>Postcondition:</i> <tt>*this</tt> contains the characters that were in <tt><i>s</i></tt>,
14899 <tt><i>s</i></tt> contains the characters that were in <tt>*this</tt>.
14900 </p>
14901 </blockquote>
14902
14903 <p>
14904 Specifying both Effects and Postcondition seems redundant, and the postcondition
14905 needs to be made stronger. Users would be unhappy if the characters were not in
14906 the same order after the swap.
14907 </p>
14908 <p><b>Proposed resolution:</b></p>
14909 <blockquote>
14910 <p>
14911 <del><i>Effects:</i> Swaps the contents of the two strings.</del>
14912 </p>
14913
14914 <p>
14915 <i>Postcondition:</i> <tt>*this</tt> contains the <ins>same sequence of</ins>
14916 characters that <del>were</del> <ins>was</ins> in <tt><i>s</i></tt>,
14917 <tt><i>s</i></tt> contains the <ins>same sequence of</ins> characters that
14918 <del>were</del> <ins>was</ins> in <tt>*this</tt>.
14919 </p>
14920 </blockquote>
14921 <hr>
14922 <a name="537"><h3>537.&nbsp;Typos in the signatures in 27.6.1.3/42-43 and 27.6.2.4</h3></a><p><b>Section:</b>&nbsp;27.6.1.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-iostreams.html#lib.istream.unformatted"> [lib.istream.unformatted]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Paolo Carlini&nbsp; <b>Date:</b>&nbsp;12 Feb 2006</p>
14923 <p>
14924 In the most recent working draft, I'm still seeing:
14925 </p>
14926
14927 <blockquote><pre>seekg(off_type&amp; off, ios_base::seekdir dir)
14928 </pre></blockquote>
14929
14930 <p>
14931 and
14932 </p>
14933
14934 <blockquote><pre>seekp(pos_type&amp; pos)
14935
14936 seekp(off_type&amp; off, ios_base::seekdir dir)
14937 </pre></blockquote>
14938
14939 <p>
14940 that is, by reference off and pos arguments.
14941 </p>
14942 <p><b>Proposed resolution:</b></p>
14943 <p>
14944 After 27.6.1.3p42 change:
14945 </p>
14946
14947 <blockquote><pre>basic_istream&lt;charT,traits&gt;&amp; seekg(off_type<del>&amp;</del> <i>off</i>, ios_base::seekdir <i>dir</i>);
14948 </pre></blockquote>
14949
14950 <p>
14951 After 27.6.2.4p1 change:
14952 </p>
14953
14954 <blockquote><pre>basic_ostream&lt;charT,traits&gt;&amp; seekp(pos_type<del>&amp;</del> <i>pos</i>);
14955 </pre></blockquote>
14956
14957 <p>
14958 After 27.6.2.4p3 change:
14959 </p>
14960
14961 <blockquote><pre>basic_ostream&lt;charT,traits&gt;&amp; seekp(off_type<del>&amp;</del> <i>off</i>, ios_base::seekdir <i>dir</i>);
14962 </pre></blockquote>
14963 <hr>
14964 <a name="538"></a><h3><a name="538">538.&nbsp;241 again: Does unique_copy() require CopyConstructible and Assignable?</a></h3><p><b>Section:</b>&nbsp;25.2.8 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lib-algorithms.html#lib.alg.unique"> [lib.alg.unique]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Howard Hinnant&nbsp; <b>Date:</b>&nbsp;9 Feb 2006</p>
14965 <p>
14966 I believe I botched the resolution of
14967 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#241">
14968 241 "Does unique_copy() require CopyConstructible and Assignable?"</a> which now
14969 has WP status.
14970 </p>
14971
14972 <p>
14973 This talks about <tt>unique_copy</tt> requirements and currently reads:
14974 </p>
14975
14976 <blockquote>
14977 -5- <i>Requires:</i> The ranges <tt>[<i>first</i>, <i>last</i>)</tt> and
14978 <tt>[<i>result</i>, <i>result</i>+(<i>last</i>-<i>first</i>))</tt>
14979 shall not overlap. The expression <tt>*<i>result</i> = *<i>first</i></tt> shall
14980 be valid. If neither <tt>InputIterator</tt> nor <tt>OutputIterator</tt> meets the
14981 requirements of forward iterator then the value type of <tt>InputIterator</tt>
14982 must be CopyConstructible (20.1.3). Otherwise CopyConstructible is not required.
14983 </blockquote>
14984
14985 <p>
14986 The problem (which Paolo discovered) is that when the iterators are at their
14987 most restrictive (<tt>InputIterator</tt>, <tt>OutputIterator</tt>), then we want
14988 <tt>InputIterator::value_type</tt> to be both <tt>CopyConstructible</tt> and
14989 <tt>CopyAssignable</tt> (for the most efficient implementation).  However this
14990 proposed resolution only makes it clear that it is <tt>CopyConstructible</tt>,
14991 and that one can assign from <tt>*<i>first</i></tt> to <tt>*<i>result</i></tt>.
14992 This latter requirement does not necessarily imply that you can:
14993 </p>
14994
14995 <blockquote><pre>*<i>first</i> = *<i>first</i>;
14996 </pre></blockquote>
14997 <p><b>Proposed resolution:</b></p>
14998 <blockquote>
14999 -5- <i>Requires:</i> The ranges <tt>[<i>first</i>, <i>last</i>)</tt> and
15000 <tt>[<i>result</i>, <i>result</i>+(<i>last</i>-<i>first</i>))</tt>
15001 shall not overlap. The expression <tt>*<i>result</i> = *<i>first</i></tt>
15002 shall
15003 be valid. If neither <tt>InputIterator</tt> nor <tt>OutputIterator</tt> meets the
15004 requirements of forward iterator then the <del>value type</del>
15005 <ins><tt>value_type</tt></ins> of <tt>InputIterator</tt>
15006 must be CopyConstructible (20.1.3) <ins>and Assignable</ins>.
15007 Otherwise CopyConstructible is not required.
15008 </blockquote>
15009 <hr>
15010 <a name="540"><h3>540.&nbsp;shared_ptr&lt;void&gt;::operator*()</h3></a><p><b>Section:</b>&nbsp;TR1 2.2.3.5 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.smartptr.shared.obs"> [tr.util.smartptr.shared.obs]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;15 Oct 2005</p>
15011 <p>
15012 I'm trying to reconcile the note in tr.util.smartptr.shared.obs, p6
15013 that talks about the operator*() member function of shared_ptr:
15014 </p>
15015
15016 <blockquote>
15017   Notes: When T is void, attempting to instantiate this member function
15018   renders the program ill-formed. [Note: Instantiating shared_ptr&lt;void&gt;
15019   does not necessarily result in instantiating this member function.
15020   --end note]
15021 </blockquote>
15022
15023 <p>
15024 with the requirement in temp.inst, p1:
15025 </p>
15026
15027 <blockquote>
15028   The implicit instantiation of a class template specialization causes
15029   the implicit instantiation of the declarations, but not of the
15030   definitions...
15031 </blockquote>
15032
15033 <p>
15034 I assume that what the note is really trying to say is that
15035 "instantiating shared_ptr&lt;void&gt; *must not* result in instantiating
15036 this member function." That is, that this function must not be
15037 declared a member of shared_ptr&lt;void&gt;. Is my interpretation
15038 correct?
15039 </p>
15040 <p><b>Proposed resolution:</b></p>
15041 <p>
15042 Change 2.2.3.5p6
15043 </p>
15044
15045 <blockquote>
15046 -6- <del><i>Notes:</i></del> When <tt>T</tt> is <tt>void</tt>, <del>attempting to instantiate
15047 this member function renders the program ill-formed. [<i>Note:</i>
15048 Instantiating <tt>shared_ptr&lt;void&gt;</tt> does not necessarily result in
15049 instantiating this member function. <i>--end note</i>]</del> <ins>it is
15050 unspecified whether this member function is declared or not, and if so, what its
15051 return type is, except that the declaration (although not necessarily the
15052 definition) of the function shall be well-formed.</ins>
15053 </blockquote>
15054
15055 <hr>
15056 <a name="541"><h3>541.&nbsp;shared_ptr template assignment and void</h3></a><p><b>Section:</b>&nbsp;TR1 2.2.3 <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/tr1.html#tr.util.smartptr.shared"> [tr.util.smartptr.shared]</a>&nbsp; <b>Status:</b>&nbsp;<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#WP">WP</a>&nbsp; <b>Submitter:</b>&nbsp;Martin Sebor&nbsp; <b>Date:</b>&nbsp;16 Oct 2005</p>
15057 <p>
15058 Is the void specialization of the template assignment operator taking
15059 a shared_ptr&lt;void&gt; as an argument supposed be well-formed?
15060 </p>
15061 <p>
15062 I.e., is this snippet well-formed:
15063 </p>
15064 <blockquote><pre>shared_ptr&lt;void&gt; p;
15065 p.operator=&lt;void&gt;(p);
15066 </pre></blockquote>
15067
15068 <p>
15069 Gcc complains about auto_ptr&lt;void&gt;::operator*() returning a reference
15070 to void. I suspect it's because shared_ptr has two template assignment
15071 operators, one of which takes auto_ptr, and the auto_ptr template gets
15072 implicitly instantiated in the process of overload resolution.
15073 </p>
15074
15075 <p>
15076 The only way I see around it is to do the same trick with auto_ptr&lt;void&gt;
15077 operator*() as with the same operator in shared_ptr&lt;void&gt;.
15078 </p>
15079
15080 <p>
15081 PS Strangely enough, the EDG front end doesn't mind the code, even
15082 though in a small test case (below) I can reproduce the error with
15083 it as well.
15084 </p>
15085
15086 <blockquote><pre>template &lt;class T&gt;
15087 struct A { T&amp; operator*() { return *(T*)0; } };
15088
15089 template &lt;class T&gt;
15090 struct B {
15091     void operator= (const B&amp;) { }
15092     template &lt;class U&gt;
15093     void operator= (const B&lt;U&gt;&amp;) { }
15094     template &lt;class U&gt;
15095     void operator= (const A&lt;U&gt;&amp;) { }
15096 };
15097
15098 int main ()
15099 {
15100     B&lt;void&gt; b;
15101     b.operator=&lt;void&gt;(b);
15102 }
15103 </pre></blockquote>
15104 <p><b>Proposed resolution:</b></p>
15105 <p>
15106 In [lib.memory] change:
15107 </p>
15108 <blockquote><pre>template&lt;class X&gt; class auto_ptr;
15109 <ins>template&lt;&gt; class auto_ptr&lt;void&gt;;</ins>
15110 </pre></blockquote>
15111
15112 <p>
15113 In [lib.auto.ptr]/2 add the following before the last closing brace:
15114 </p>
15115
15116 <blockquote><pre>template&lt;&gt; class auto_ptr&lt;void&gt;
15117 {
15118 public:
15119 &nbsp; &nbsp; typedef void element_type;
15120 };
15121 </pre></blockquote>
15122
15123 <p>----- End of document -----</p>
15124 </body></html>